Connect MCP

What this gives you

The Model Context Protocol (MCP) lets an AI client ask MANA to do selected work in your workspace. Once connected, it can create a project, break a brief into tasks, manage task labels, draft or publish a document, log an expense, check a calendar, or summarise a client's history.

This is a deliberately small, safe set of MANA actions—not a copy of every screen or every underlying service. Your client discovers the available tools automatically after it connects.

AIClient

MANA MCP

TOOLSWorkspace tools

AuthenticateBearer token from MANA Settings

DiscoverYour client loads the available tools

WorkCalls stay scoped to your account

Get your token

In MANA, open Settings → AI → MCP connection and press Copy setup. Save the private token as MANA_MCP_TOKEN; the MANA address never contains the token.

Keep it in an environment variable rather than pasting it into shared config:

export MANA_MCP_TOKEN=your-token-here

Connection details

Use the bearer-token form. MANA does not accept tokens in URLs, because URLs can be copied into browser history and access logs.

What stays private

• Your connection can only access the MANA account that owns its token.
• Tool lists and read results are intentionally limited, so the client starts with only the context it needs.
• MANA HQ can turn individual external tools off for your connection at any time.
• Google Calendar actions go through MANA’s existing connection and plan rules. MANA never gives an AI client your Google OAuth token.
• Before an AI client publishes a document or sends a change to an already-linked Google Calendar, it must ask you to confirm first.
• Infrastructure and provider administration—such as Neon, Sentry, Cloudflare, and Stripe—are not MCP tools.

Choose your client

Open one setup at a time. Every code block has a Copy button.

claude mcp add --transport http mana https://mana-api.fly.dev/mcp \
  --header "Authorization: Bearer $MANA_MCP_TOKEN"

[mcp_servers.mana]
url = "https://mana-api.fly.dev/mcp"
bearer_token_env_var = "MANA_MCP_TOKEN"

gemini mcp add --transport http mana https://mana-api.fly.dev/mcp \
  --header "Authorization: Bearer $MANA_MCP_TOKEN"

{
  "mcpServers": {
    "mana": {
      "httpUrl": "https://mana-api.fly.dev/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

{
  "mcpServers": {
    "mana": {
      "url": "https://mana-api.fly.dev/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

{
  "servers": {
    "mana": {
      "type": "http",
      "url": "https://mana-api.fly.dev/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

{
  "mcpServers": {
    "mana": {
      "command": "bunx",
      "args": ["mcp-remote", "https://mana-api.fly.dev/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer YOUR_TOKEN" }
    }
  }
}

Check it works

Before blaming the client, ask the server directly:

curl -s https://mana-api.fly.dev/mcp \
  -H "Authorization: Bearer $MANA_MCP_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

A JSON payload listing tools means the connection is good. Unauthorized means the client did not send a current bearer token. Copy setup again or regenerate the token in MANA if you think it was exposed.

If the direct check works but the client does not, restart the client and confirm that MANA_MCP_TOKEN is visible in the environment that launched it.