Stellary: hosted Streamable HTTP MCP for project management (Bearer PAT, not stdio/npx)

[Anymfah]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Hi — I'm Soheil. Sharing a hosted MCP server we run for Stellary (AI-native project piloting / project management SaaS, open beta, Paris) and looking for feedback on a few transport and governance choices.

This is not a local stdio or npx server. The native remote is Streamable HTTP with a Bearer PAT:

• Endpoint: https://api.stellary.co/mcp
• Transport: Streamable HTTP (GET and POST)
• Auth: Authorization: Bearer <personal access token>
• Registry: io.github.Anymfah/stellary-project-management

The official registry remote is streamable-http at that URL and marks the Authorization header required (Bearer YOUR_STELLARY_TOKEN). Discovery and client manifests live in Anymfah/stellary-mcp; they point at the hosted URL. None of them starts a local stdio/npx process.

How hosted Streamable HTTP + Bearer works

The MCP server is built into the NestJS backend. There is no separate daemon, sidecar, or bridge.

• GET is used for discovery / protocol negotiation.
• POST carries the MCP requests.
• Each request creates a fresh stateless transport, specifically so clients that do not persist Mcp-Session-Id still work.
• Create a PAT under Account settings → API tokens and send it as Authorization: Bearer. Start with read-only scopes; add write scopes only when required. Treat PATs like passwords and do not commit them.

Documented client wiring (URL is Streamable HTTP; attach the Bearer PAT as the Authorization header):

claude mcp add stellary \
  --transport streamable-http \
  https://api.stellary.co/mcp

{
  "mcpServers": {
    "stellary": {
      "url": "https://api.stellary.co/mcp"
    }
  }
}

A good first call is list_projects: it confirms authentication and project visibility without changing data. Then inspect one project's cards before enabling write scopes.

Tool surface (as documented today)

Tools are assembled from core board / cockpit / agent registries plus installed workspace plugins — one endpoint, not one flat usage pattern.

Board read: list_projects, get_project_details, list_cards, get_card_details, get_card_comments

Board write & collaboration: create_card, create_cards_bulk, move_card, update_card, assign_card, add_comment

Cockpit & supervision: get_pilotage_state, get_cockpit_dashboard, get_agent_status, list_pending_proposals

Agent runtime: stellary_init, get_next_mission, wait_for_mission, complete_mission, fail_mission

Several board tools also accept name-based convenience (exact-or-fuzzy matching). For long-lived agent loops the documented pattern is still: discover IDs first (list_projects / list_cards), then reuse exact IDs.

Installed plugin tools are auto-registered on the same MCP surface when the plugin is installed and enabled. IDs are prefixed by plugin slug. Shipped definitions currently include GitHub, Slack, Email, Discord, and X — for example github_list_repos, github_create_pr, slack_post_message, email_send_email, discord_post_message, x_create_draft. Those require workspace context plus decrypted plugin configuration and are typically consumed through agent tokens.

For agent tokens, stellary_init is the documented bootstrap: it returns autonomy mode, rules, skills, and the filtered tool list actually available to that agent. The usual loop is stellary_init → get_next_mission / wait_for_mission → read card/document context → execute with exact IDs → complete_mission or fail_mission.

Permissions and governance

Access is rechecked on every call: credential scopes, project access, workspace permissions, agent status and policy, autonomy, and the mission snapshot stay authoritative. The exact tool list is resolved at connection time and checked again for the selected identity on every call. All requests remain subject to Stellary permissions and rate limits.

A human using a PAT acts directly as themselves.

Agent tokens additionally go through the tool-policy / autonomy layer:

Agent autonomy mode	Read tools	Write and collaboration tools
autonomous	Execute directly	Execute directly
supervised	Execute directly	Safe tools execute directly; tools marked approval_required return a persisted proposal
approval	Execute directly	Every non-read tool becomes a proposal

MCP-only agents keep the autonomy mode configured in Stellary. In approval mode, non-read writes become persisted proposals even when the execution client is external. Suspending an agent disables it immediately.

Feedback I'd value

1. Stateless Streamable HTTP (fresh transport per request, no required Mcp-Session-Id) — any client-compat pitfalls we should document more loudly?
2. Registry remote as Streamable HTTP + required Bearer PAT, with no stdio/npx entrypoint — does that match how you expect hosted servers to publish?
3. Tool-policy proposals (autonomous / supervised / approval) on the same endpoint as human PAT calls — useful, or would you split those surfaces?

Happy to answer implementation questions. Full behavior is documented at https://stellary.co/docs/mcp/

Relevant Links

• Docs: https://stellary.co/docs/mcp/
• Discovery repo: https://github.com/Anymfah/stellary-mcp
• Registry listing: https://registry.modelcontextprotocol.io/v0.1/servers/io.github.Anymfah%2Fstellary-project-management/versions/latest
• Endpoint: https://api.stellary.co/mcp
• Site: https://stellary.co
• App: https://app.stellary.co