// concepts

Tools and tool families

One MCP connection puts a working set of tools in front of your agent, not a catalog dump. Tools are grouped into families, families are what you switch on and off, and an agent can search for what it is missing and turn it on from inside the session it is already in.

Copy the setup prompt.
Your agent does the rest.

works with any agent+ 8 more
Fetch and execute the appropriate instructions to set me up for superagnt_ from https://superagnt.com/agent-setup/prompt.md
or follow the detailed setup instructions

» the base connection already serves the workspace database, files, first-party people and company data, and every vendor you have connected. Everything else is one search away.

01// families

A family is the unit of enablement

Nobody enables tools one at a time. Every tool belongs to exactly one family, and the family id is what you pass to enable, disable, search and the dashboard picker. Some families are fixed parts of the platform; the rest come into existence as you add sources, vendors and servers.

static families

  • databaseWorkspace database
  • filesWorkspace files
  • controlTool discovery
  • lifecycleAgent lifecycle
  • bindingsAgent bindings and connections
  • schedulesAgent schedules
  • queuesQueues
  • agent-invocationAgent invocation
  • observabilityAgent observability
  • canvasCanvas
  • canvas_shareCanvas sharing
  • knowledgeKnowledge bases
  • guidancePlatform guidance
  • emailInbox management
  • webhooksWebhooks
  • data-jobsData pipelines
  • code-executionTypeScript skill testing
  • utilitiesUtilities

dynamic families

  • data:<slug>One curated data source, e.g. data:reddit
  • connection:<vendor>One your-credential vendor, e.g. connection:hubspot
  • connector:<id>One first-party connector, e.g. Slack
  • mcp:<serverId>One remote MCP server you connected
  • vendor-db:<vendor>One vendor database you connected

One family per vendor, never a shared bucket: picking a vendor database gives you that vendor's tools and nothing else.

02// how tools are named

Four reserved prefixes, one per surface

Tool names are generated, not authored, and they mirror the REST paths one to one — so a tool name tells you which surface it hits and what it costs before you call it.

Tool nameREST twinWhat it is
data_<slug>_<operationId>/v1/data/:source/*A curated data source we pay the upstream for, priced per call.
connection_<vendor>_<operationId>/v1/connections/:vendor/*A vendor you connected, called with your own credentials.
mcp_<slug>_<tool>no REST twinA tool re-exported from a remote MCP server.
agnt_db_*/v1/db/*The workspace Postgres database.
agnt_credits_* · agnt_usage_* · agnt_webhooks_*/v1/credits · /v1/usage · /v1/webhook-endpoints/*First-party utility surfaces.
generated namestext
data_reddit_post_details
connection_hubspot_list_contacts

Names are lowercased and stripped to letters, digits and underscores, then capped at 64 characters with a deterministic hash suffix when they run long. The cap is applied where the name is produced, so the name a server lists is always the name it dispatches on, and the same operation always produces the same name across deploys.

reserved space

The mcp_ prefix is what makes a user-supplied server slug safe: a custom slug can never generate a name that shadows a data_, connection_ or agnt_ tool.
03// served by default

What a fresh connection already has

A default server serves an always-on base without anyone switching anything on:

  • Base utilities and memory — the small always-useful set every agent leans on.
  • The workspace database and workspace files.
  • First-party people and company data, which has no per-call upstream of its own beyond your credits.
  • Every vendor, connector, remote MCP server and vendor database the workspace has actually connected.
  • The platform stack: agent lifecycle, schedules, queues, webhook management, knowledge bases, platform guidance, observability, agent invocation, canvas, canvas sharing and data-pipeline management.

Registration is free. A family sold under a Toolkit module the organization does not hold is still listed and still discoverable; it is refused at call time with an offer, not hidden. Queues and the Slack channel-management tools are shipped and live.

04// what is opt-in

The catalog is not the default

Curated pay-per-call data sources — every data:<slug> family — are not in the base. That is what keeps a fresh workspace on a working set instead of the entire catalog, which is the difference between an agent that can choose and an agent drowning in a tool list.

Three more families stay off until someone deliberately turns them on, because they reach a real person or run code:

FamilyWhy it waits
bindingsSlack and iMessage routing. Serving it silently would let any connected client page or re-route a human.
emailInbox triage. Same reason: it touches somebody's real mail.
code-executionThe sandboxed TypeScript skill dry-run and its status poll.

connecting is the opt-in

There is no separate enable call for a vendor. Connect it in the dashboard and its tools appear on the next list; disconnect it and they go away. Disable only removes opt-in entries — it cannot hide the base or a connected vendor.
05// growing the surface

An agent can turn on what it is missing

A default server also carries a set of control tools, injected only there — never into a deployed agent's runtime catalog or a custom subset server. They are how a session discovers the rest of the platform without a dashboard round-trip.

ToolDoes
agnt_onboardingThe first call after connecting. Records who the user is and what they want automated, and returns the full platform brief.
agnt_platform_mapThe whole map of what the platform can do, with tool names and module pricing. Read-only and free.
agnt_tools_searchSearch the catalog this server can expose but is not serving. Returns families with tool counts, enabled state and per-tool config_ref objects.
agnt_tools_enableTurn families or individual tools on. Saved immediately and permanently.
agnt_tools_disableTurn off entries you enabled. Cannot hide the base or a connected vendor's tools.
agnt_tools_list_enabledWhat this server serves right now: your opt-ins, the base, and the connected integrations.
agnt_subscription_getThe organization's plan, modules, credit commitment and seats. Read-only.
agnt_subscription_previewDry-run a plan change. Never charges; returns a token.
agnt_subscription_changeTurn a previewed change into a confirm URL a person must open. Never charges.
  1. 01

    Search

    agnt_tools_search returns matching families with their id, label, tool count and whether they are already enabled. Every attachable tool carries a config_ref object you can copy verbatim to wire that tool onto an agent; a tool with no config_ref is always-on base and cannot be attached.
  2. 02

    Enable

    Pass family ids to agnt_tools_enable. The change is saved immediately and permanently, the server starts serving the new tools right away, and a tools/list_changed notification goes out.
  3. 03

    Refresh the client

    Most clients ignore that notification, so the newly enabled tools may stay invisible for the rest of the session. That is expected and does not mean the enable failed. Direct-config clients pick them up on a new session or a reconnect; cloud-connector clients need the connector refreshed in its own settings first. The enable result spells out the steps per client, and agnt_tools_search always reports the true state even while your tool list is stale.
06// what a refusal looks like

A refused call is an offer, not an error

When a family is sold under a Toolkit module the organization does not hold, the call comes back as a normal tool result carrying a requires_upgrade offer: the module, its tier and monthly price, whether a trial is still available, and a confirm URL. It is never a protocol error, because clients retry and bury errors while a result gets relayed to the person who can act on it.

requires_upgradejson
{
  "status": "requires_upgrade",
  "tool": "agnt_schedules_create",
  "family": "schedules",
  "module": {
    "id": "automation",
    "name": "Automation",
    "tier": "starter",
    "price_usd_month": 19,
    "requires": [],
    "trial_days": 7,
    "trial_available": true,
    "confirm_url": "https://app.superagnt.com/confirm/<token>"
  },
  "confirm_url": "https://app.superagnt.com/confirm/<token>",
  "human_step": "The call did not run — this tool is sold under the named module and this organization does not hold it. A person has to confirm the purchase: send them the confirm_url; they review the module, its price and trial there. Money is always human-confirmed. A person confirms on the page; nothing here charges anyone. Retry the call once they have confirmed."
}

a person confirms

No tool on this platform charges money. The confirm URL is the only path, and a human has to open it and agree there. The same shape comes back from an enable that needs a module the organization does not hold.

A call into a vendor nobody has connected is refused the same way, with a structured result naming the vendor and a link to the connections page rather than an exception.

Some families are marked elevated in the catalog — lifecycle, bindings, schedules, queues, webhooks, knowledge, email, agent invocation, canvas and canvas sharing. That is display metadata the dashboard badges, not a gate: it tells a person which tools carry real authority. It refuses nothing.

07// guidance is free

The platform documents itself, in-session

The guidance family serves the platform's own how-to corpus straight into a session, and it is never sold under a module. An agent that reads the doctrine builds working things; charging for that would be charging for the manual.

guidance

agnt_guidance_load

Load a named skill from the platform corpus, with its reference sections.

guidance

agnt_guidance_search

Search the corpus when you do not know which skill covers the job.

guidance

agnt_guidance_build_instructions

The build-time instructions for assembling an agent on this platform.

guidance

agnt_sdk_docs

The typed surface a generated skill may import and call.

Related: permissions and approvals for whether a tool runs or waits, workspaces and organizations for who pays, and the API reference for every data source endpoint and its per-call price.