Connect an agent

An agent connects to passo.build so it can ask for the next production-readiness step, submit local assessment results, store evidence, and coordinate work with other agents.

For most users, the ideal flow is:

1. Add passo.build as an MCP server in the agent.
2. Run a passo command/tool from the agent.
3. The agent opens a login flow or gives you a verification link.
4. After login, the agent is bound to your user, tenant, and project.
5. The agent starts the assessment flow in its own chat/UI.

During rollout, some agent hosts may still require a provisioned MCP token. Treat that as a deployment detail, not the product experience.

Technical endpoint

Property	Value
MCP endpoint	POST https://mcp.passo.build/mcp
Transport	Streamable HTTP
Health check	GET https://mcp.passo.build/health
Live auth bridge	Bearer token issued by PyxCloud for rollout workspaces when local login is not available in the host.
Target auth	Agent-started local login bound to user, tenant, and project.

Rollout note

If https://mcp.passo.build/health is not healthy in your environment, use the web console while the MCP endpoint is being rolled out. Do not hard-code legacy PyxCloud domains in new agent configs.

Configure your agent

The exact MCP configuration shape depends on the host. The examples below show the intent: register a remote HTTP MCP server and keep secrets out of the repo.

Claude Code

Add a remote MCP server in .mcp.json (or via claude mcp add):

{
  "mcpServers": {
    "passo": {
      "type": "http",
      "url": "https://mcp.passo.build/mcp",
      "headers": { "Authorization": "Bearer ${MESH_AGENT_TOKEN}" }
    }
  }
}

Export the token in the environment Claude Code runs in if your workspace is on the provisioned-token flow. When local login is available for your host, prefer that flow instead. Exact transport keys differ by Claude Code version.

Codex

Register passo.build as a remote MCP server in your Codex MCP configuration, pointing at https://mcp.passo.build/mcp over HTTP transport. If your workspace uses a provisioned token, supply it from the environment, not from a committed config file.

Cursor

Add an entry under the MCP servers section of your Cursor settings (e.g. ~/.cursor/mcp.json or the in-app MCP settings):

{
  "mcpServers": {
    "passo": {
      "url": "https://mcp.passo.build/mcp",
      "headers": { "Authorization": "Bearer ${MESH_AGENT_TOKEN}" }
    }
  }
}

If your Cursor build only exposes URL-based MCP servers without a headers field, use its connector/secret mechanism or the local-login flow when available.

Antigravity

Register passo.build as a remote/HTTP MCP server in Antigravity's MCP configuration with the same endpoint. Use local login or a provisioned secret, depending on the rollout status of your workspace.

Lovable / Base44-style builder agents

Any builder agent that can attach a remote MCP server should point to https://mcp.passo.build/mcp and then discover available tools. If the builder supports a connector marketplace or secret vault, use that instead of putting credentials into generated code.

Minimal connection smoke

Use the host's MCP inspector or tool-discovery UI to check:

1. GET https://mcp.passo.build/health returns healthy.
2. The server responds to MCP initialization.
3. tools/list returns the live catalog.
4. The catalog includes the expected pyx_* or mesh_* family for your flow.
5. The first session/project tool either succeeds or returns an auth error that tells you how to log in.

If any step fails, use the web console and record the failure as evidence instead of hard-coding a legacy domain or copying secrets into the repo.

After connect

Do not guess tool names from this page. Ask the MCP server for its tool catalog, then let the agent continue with login/session binding and local scan.