The MCP provisioning server

The server holds no credential of its own. Every call forwards your token to the console API, so it can never do anything you could not already do. Mint one in the console under Team → API tokens.

Minting is admin-and-above. A token can never mint another token, and its powers are capped at its creator's current membership — promote the creator and existing tokens do not widen; remove them and their tokens are revoked outright.

The transport is Streamable HTTP. Authentication is the token on the Authorization header, and nothing else — there is no OAuth flow to complete.

Claude Code

# One project, one command. --scope user keeps it out of the repo.
claude mcp add --transport http agentifys https://agentifys.ai/mcp \
  --header "Authorization: Bearer eat_..." \
  --scope user

--scope user stores the server in your personal config, available in every project. --scope project stores it in .mcp.json inside the repository, which is shared with everyone who checks it out.

claude.ai — custom connector

Claude Desktop

{
  "mcpServers": {
    "agentifys": {
      "type": "http",
      "url": "https://agentifys.ai/mcp",
      "headers": {
        "Authorization": "Bearer eat_..."
      }
    }
  }
}

One tool is one logical provisioning step, not one HTTP call — eerraa_get_project reads six endpoints, eerraa_enable_tools turns on forty tools in one request. They are listed here in the order an agent uses them.

The sequence has real constraints, and an agent will not infer them from twelve descriptions. So every response carries status, what changed, a manual_steps array, and next_action — one imperative sentence naming the tool to call next. Following that chain is how the ordering survives.

eerraa_create_project
  -> eerraa_configure {identity_mode: "signed"}   returns the console step; a token may not set it
  -> eerraa_set_user_schema                       declare the user.data fields first
  -> eerraa_set_prompt
  -> eerraa_add_tool          (once per tool)
  -> eerraa_connect_mcp_server
       -> [manual: paste the server's token in the console]
       -> eerraa_discover_mcp_tools
       -> eerraa_enable_tools                     ONE call with every tool
  -> eerraa_add_policy        (once per policy)
  -> eerraa_configure {scheduling.writable_tools} now that the tools exist
  -> [manual: add a model provider key in the console]
  -> eerraa_verify_project

A prompt that puts an agent on the rails:

Use the agentifys MCP server to build me a support agent.

Create the project, declare a user schema with plan_tier and account_id,
write the prompt, add a create_ticket tool, and deny it for viewers.

Follow next_action on every response rather than guessing the order, read
the manual_steps array out to me at the end, and do not tell me the
project is ready until eerraa_verify_project says so.

These are structural, not advisory. Most of them are enforced twice — once by the token itself, and once by the provisioning server's own capability list, which is narrower still.

Secrets are never tool arguments.

There is no tool that takes a model provider key, and eerraa_connect_mcp_server takes no server token. A credential passed as a tool argument is written to your transcript and to your model provider's logs before it ever reaches Agentifys. Those steps come back instead as an entry in the manual_steps array — {id, title, why, who, where, steps, blocks, verify}, with a deep link into your console.

The one auth value the server may set is not a secret. Connecting a server with per_user_credential stores the template {{user.creds.<name>}}, which is resolved per turn from each end user's own vault — see per-user credentials.

Two of these are not bugs to be fixed later. They are what the design chose, and knowing them up front saves an afternoon.