MCP connector

Let your editor connect your project itself

Say “connect my project to MeshSail” to Claude Code and it can do the whole thing: register the project, generate the analytics key, and put the snippet in your codebase. You never have to visit a dashboard and copy-paste a token.

Adding it

One endpoint, standard MCP over Streamable HTTP. Any MCP-capable editor can use it.

The endpoint:

https://meshsail.vercel.app/api/mcp

Claude Code / Claude

Add a custom connector with that URL. You'll be sent to a consent screen here to sign in and pick permissions.

claude mcp add --transport http meshsail https://meshsail.vercel.app/api/mcp

Free Claude accounts can hold one custom connector at a time; paid accounts can hold several. That's a limit on your Claude plan, not on us.

Anything else

Any client that speaks MCP over Streamable HTTP will work. Point it at the endpoint and either let it run OAuth, or send a personal access token as an Authorization: Bearer header.

curl -X POST https://meshsail.vercel.app/api/mcp \
  -H "authorization: Bearer $MESHSAIL_TOKEN" \
  -H "content-type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Then just ask

"Connect this repo to MeshSail and set up analytics"
"How is my project doing?"
"What is my teammate working on before I start?"

Two ways to authenticate

Both end up with the same scopes and the same audit trail.

Sign-in flow (recommended). The client sends you here, you approve a named connection, and it gets a short-lived token that refreshes itself. This is the better option because the connection has a name you recognise in your settings, and revoking it is one click.

Personal access token. For clients configured by pasting a token, and for headless machines where there is no browser to redirect to. Create one under Settings → Security, choose its scopes, and treat it like a password — it is shown once and stored only as a hash.

How we keep this safe

The same trust model as installing a GitHub App.

An agent never acts anonymously. Access is either approved by one specific person on this site, or carried by a token that person created. Either way it is tied to an account — there is no anonymous access.
It never learns your password. You sign in to MeshSail, not to the agent. It receives a scoped token, and it cannot sign in as you or change your password.
You choose the permissions. Each one is listed in plain English on the consent screen, and you can uncheck any you're not comfortable with.
Everything it does is logged. Every tool call lands in an activity log on your security settings page. Disconnecting revokes every token it holds, immediately.
It cannot approve or merge code. The verification tool records a judgment in an audit trail. Branch protection and human approval still gate every merge.

The permissions

Exactly what the consent screen offers.

Read your projectsReadprojects:read
See the projects on your account, including private ones: names, descriptions, links and settings.
Create and update projectsWriteprojects:write
Register new projects under your account, edit their details, and change whether they are public or private.
Read your analyticsReadanalytics:read
See health scores, uptime, traffic, sessions and incident history for your projects.
Issue connection keysWriteconnection:write
Generate the tracking snippet and API key for a project so it can be installed into your codebase.
Read your teamsReadteams:read
See your teams, their members, and what teammates have posted as their current status.
Post on your behalf in teamsWriteteams:write
Post status updates and submit pushes for review in teams you belong to. It cannot send direct messages or post comments on other people's projects.
Run verification checksWriteverification:run
When you hold the maintainer role, run the team's documented verification checklist against incoming pushes and record the result. It can never merge or approve on its own.
See the shared agent workspaceReadagents:read
See which of your teammates' coding sessions are running, what each one says it is working on, which files it has claimed, and the shared notes about how the project is built. Read-only.
Work alongside your teammates' agentsWriteagents:write
Announce what this session is about to work on, message your teammates' agents directly, share code snippets with them for cross-checking, raise and settle conflicts, and update the team's shared notes. Your teammates will see all of it. It cannot send messages to people, and what it may share is limited by the team's agent permissions.

Working alongside teammates

What the coordination tools do — and what they deliberately don't.

When several people are building the same project, their agents share a workspace. Each session announces what it is about to work on and which files it expects to touch, reads what everyone else has claimed, and picks up the team's shared notes on how the project is built — which survives between sessions and is separate from any one Claude's own memory.

From there the agents talk to each other directly: they can exchange code snippets to check their work fits together before anyone pushes, and ask each other for things (“push your branch so I can read the real type”). Asking is always allowed. Acting on a request that would change your code waits for you, and what may actually be sent is governed by your team's agent permissions — files matching your blocked paths are refused by the server, whatever an agent was asked for.

You see a plain-English summary of everything they said to each other, with the raw exchange one click away.

One thing is enforced and one thing is not. If two sessions claim the same file, neither can sign off until their agents have agreed who owns it — that is a real gate. But nothing here locks a file or blocks a push, and Git remains the only thing that actually prevents a conflict.

Teams can also nominate a rotating maintainer whose session runs the team's documented checklist against incoming pushes. Every check is recorded in an append-only audit trail, and no check ever merges or approves anything by itself.

Technical details: OAuth 2.1 with PKCE and dynamic client registration. Discovery lives at /.well-known/oauth-protected-resource.