Mantrana speaks MCP.

1 · Create an API key

Sign in at the workbench, open the account menu (top right) → Developer & credits, and issue a key. Keys look like mk_…, are shown once, can be revoked any time, and are the only credential the MCP server accepts: Authorization: Bearer mk_…

Label each key for where you use it — lovable, replit, cursor — so you can revoke one app's access without touching the others.

2 · Connect your client

Terminal agents

Copyclaude mcp add --transport http mantrana \
  https://mantrana.co/mcp \
  --header "Authorization: Bearer mk_YOUR_KEY"

Copy{
  "mcpServers": {
    "mantrana": {
      "type": "http",
      "url": "https://mantrana.co/mcp",
      "headers": {
        "Authorization": "Bearer mk_YOUR_KEY"
      }
    }
  }
}

Copy{
  "mcpServers": {
    "mantrana": {
      "serverUrl": "https://mantrana.co/mcp",
      "headers": { "Authorization": "Bearer mk_YOUR_KEY" }
    }
  }
}

Copy[mcp_servers.mantrana]
url = "https://mantrana.co/mcp"
bearer_token_env_var = "MANTRANA_API_KEY"

App builders — Lovable, v0, Replit, Bolt

App builders connect from their own servers, so there is nothing to install: paste the server URL below, pick Bearer / API-key authentication, and paste your key.

Copyhttps://mantrana.co/mcp

Copyhttps://mantrana.co/mcp

Copyhttps://mantrana.co/mcp
header name:  Authorization
header value: Bearer mk_YOUR_KEY

Copyhttps://mantrana.co/mcp

Copy# endpoint + auth header
POST https://mantrana.co/mcp
Authorization: Bearer mk_YOUR_KEY
Content-Type: application/json
Accept: application/json, text/event-stream

3 · The tools

Evidence, clarification, and delivery

For repository work, collect relevant source excerpts, current behavior, constraints, and verification commands before calling. Mantrana evaluates the evidence you supply; it has no filesystem or shell access.

{
  "rough_idea": "Add optional case-insensitive matching to our search CLI.",
  "tier": "mvp",
  "client_request_id": "search-ignore-case-1",
  "planning_context": {
    "task_type": "existing_repository",
    "success_criteria": ["Default behavior and exit codes stay compatible"],
    "constraints": ["Standard library only"],
    "current_state": "A single-file Python CLI",
    "evidence": [{"id": "search", "source": "search.py:20", "content": "if query in line: print(line)"}],
    "answers": []
  }
}

task_type accepts auto, new_product, existing_repository, or research. Context is optional and limited to 48 KiB of serialized UTF-8 JSON; oversized input is rejected without truncation. Evidence IDs must be unique letters, digits, underscores, or hyphens (1–64 characters).

A status: needs_input response includes the request ID and at most three combined questions or evidence requests. Gather the excerpts or ask the user, append {"question": "…", "answer": "…"} records to answers, and resubmit the full context with that same client_request_id. Clarification creates no run, debits no credits. Intake errors are retryable and uncharged.

Submit the user's intent as-is. Record only constraints and success criteria the user actually stated as constraints / success_criteria; carry your own recommendations in current_state or an answers note labeled as a recommendation. For an open-ended brief — brainstorming, exploring, improving — confirm any scope narrowing with the user before submitting it as a constraint; intake may return needs_input to check exactly that. When a needs_input question is a preference, ask the user rather than answering on their behalf; settle factual questions from the repository yourself.

A paid run can also pause mid-deliberation with status: awaiting_answers — after the first review round, a clarification step asks up to three materially plan-changing questions. This is distinct from intake clarification: the run is already charged and underway, it holds no queue slot while paused, and it is not cancellable. mantrana_wait_for_run returns the questions immediately; relay them to the user and submit every answer through mantrana_answer in one call. A run left unanswered auto-continues after 72 hours with its questions recorded as explicit unresolved decisions. Answered questions are saved once to the account's remembered answers and are not re-asked for future briefs — the user can review and remove stored answers in the workbench's Developer & credits panel.

MVP collects four independent reviews. Full-Stack adds Architect and Red Team cross-review. Enterprise adds Product and Operations follow-up. Every tier synthesizes the complete record, then checks the plan against evidence and constraints. At most one correction and repeat audit are allowed.

Inspect quality.status: passed means no blocking issue remained in the review; draft means Draft — review required. Surface the report's unresolved issues before implementing a draft. Its warning stays in copied, downloaded, and shared Markdown. Both statuses count as delivered and use normal billing. Provider failures fail the run and follow normal refund rules. Historical outputs have quality: null.

4 · Billing through the API

Get $10 in signup credits once per account, including existing accounts when they sign in. One USD balance funds both website and MCP runs, at the displayed dollar price for the selected tier.

• Top up credits in the workbench (Account → Developer & credits): fixed $5, $10, $25, or $50 packs, or custom amounts from $5. Credits never expire. The existing checkout settles in INR at ₹90 per $1 of credits; the exact charge is shown before you pay.
• mantrana_specify debits the tier price from your shared balance. Choose any tier; there is no free-run ladder.
• A failed or queue-cancelled run refunds its credits to your balance automatically.

Good to know

• Keys are full-account scope; scoped keys are planned. Revoke and reissue if a key leaks — revocation is instant.
• Runs created through the API are archived to your account (not session-bound), so agents can fetch a spec days later with mantrana_get_specification.
• One host runs the deliberations: at most 3 concurrent and 20 queued. Wait estimates come back with every queued run.
• Pass client_request_id to mantrana_specify for idempotent retries.