MCP-Server

Motir exposes a Model Context Protocol server — one streamable-HTTP endpoint that agents and the CLI call to read and drive the project-management core. It is the same surface the hosted agents use to execute a plan. Adding it to Claude takes one sign-in and no token; any other client, or a pipeline, connects with a token in three steps.

Add Motir to Claude

You sign in with your Motir account, pick one workspace and approve what Claude may do there. Nothing is copied or pasted — there is no token to mint or keep safe.

https://app.motir.co/api/mcp

https://app.motir.co/api/mcp

claude mcp add --transport http motir https://app.motir.co/api/mcp

What you approve, and how to take it back

The sign-in page on Motir names the app that is asking, has you choose one workspace, and lists the permissions it wants. Claude then acts as you in that workspace, within what you approved — never beyond what your own role allows.

When claude.ai connects with Claude’s published identity, Motir checks that claude.ai publishes it, and shows claude.ai as a verified domain on the sign-in page and in Connected apps. Any other MCP client that registers itself reads Unverified: the name it shows is one it chose, and Motir cannot check it.

Claude asks before it uses a tool that changes anything: every tool says whether it only reads, writes or deletes, and MCP-Tools shows which is which. Want the plugin for Claude Code instead? It brings this server with it — Skills.

Every app you connect is listed under Connected apps, on Settings → Account → Tokens in Motir, with its workspace, permissions and when it was last used. Revoke ends its access at its next request.

Other clients and CI: use a token

Choose this route for a client without OAuth sign-in, a headless agent, or a CI pipeline. It is the same server; a personal access token stands in for the sign-in.

This server, or the REST API?

Both speak to the same data and take the same credential. They are built for different consumers, and the difference that matters is what each promises about changing under you.

Wiring an agent? Stay here. Writing software other people install? The API-Referenz is the other half — it is the one that promises not to change under you.

1Mint a token

Every request carries a personal access token, minted in Motir under Settings → Account → Tokens. Choose the workspace it is bound to and grant it the narrowest scope set that does the job — the table at the bottom of this page says what each scope gates. A grant narrows your own role and never widens it, so a token can never do something you could not.

The secret is shown once, when the token is created. Copy it then; there is no way to read it again, and a lost token is replaced rather than recovered.

2Wire your client

Every client needs the same four facts under whatever names it gives them.

Keep the token out of a file your repository tracks. Where a client can read it from your environment or prompt you for it, the block below uses that instead of a literal — which is why two of them name MOTIR_TOKEN rather than a secret.

{
  "mcpServers": {
    "motir": {
      "type": "http",
      "url": "https://app.motir.co/api/mcp",
      "headers": { "Authorization": "Bearer motir_pat_<your-token>" }
    }
  }
}

{
  "mcpServers": {
    "motir": {
      "url": "https://app.motir.co/api/mcp",
      "headers": { "Authorization": "Bearer ${env:MOTIR_TOKEN}" }
    }
  }
}

{
  "inputs": [
    {
      "type": "promptString",
      "id": "motir-token",
      "description": "Motir personal access token",
      "password": true
    }
  ],
  "servers": {
    "motir": {
      "type": "http",
      "url": "https://app.motir.co/api/mcp",
      "headers": { "Authorization": "Bearer ${input:motir-token}" }
    }
  }
}

[mcp_servers.motir]
url = "https://app.motir.co/api/mcp"
bearer_token_env_var = "MOTIR_TOKEN"

Transport:  streamable HTTP
URL:        https://app.motir.co/api/mcp
Header:     Authorization: Bearer motir_pat_<your-token>

3Check the connection

Restart the client and ask it what tools it has; the server answers with the whole catalogue, scoped to your grant. To check the endpoint itself before involving a client, ask it directly — this is the same handshake, with the token in your environment.

curl -sS -X POST https://app.motir.co/api/mcp \
  -H "Authorization: Bearer $MOTIR_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

An unauthorized answer is about the TOKEN, not the wiring. A missing, malformed, unknown, revoked or expired token all return the same refusal, deliberately — distinguishing them would turn the endpoint into an oracle that answers whether a secret exists. Check that the header is spelled Authorization, that the value begins Bearer, and that the token has not been revoked in Motir.

What a connection may call

Every tool is gated by a scope. The permissions you approved for a connected app, or the grant a token carries, decide which tools it may call — so the list your client shows is already scoped to you. These are read from Motir itself when this page is requested, so they are whatever the server ships right now.

What next

MCP-Tools lists every tool the server exposes with the arguments it takes. The full reference in motir-core carries each tool’s complete description. Driving the same data from a terminal instead is the CLI.