Connect your agent (MCP & the work-order prompt)

01One config, all services

STELQ runs one hosted MCP server. Connecting it once exposes every STELQ service as a native agent tool — there is no per-service config and no glue code. Drop this into your MCP client (Claude Code, Cursor, Windsurf, etc.) and set STELQ_KEY in your environment:

{
  "mcpServers": {
    "stelq": {
      "url": "https://mcp.stelq.com/v1/mcp",
      "headers": { "Authorization": "Bearer $STELQ_KEY" }
    }
  }
}

This is exactly what the console emits — the same config no matter which service's Docs tab you copied it from. The server is reachable on both mcp.stelq.com and api.stelq.com; the console hands agents the mcp.stelq.com/v1/mcp form.

Authentication is the same as the REST API: every request carries Authorization: Bearer $STELQ_KEY. Reference $STELQ_KEY from your environment — never paste a live secret. See Authentication for key states and the live-vs-test distinction.

02The eleven tools

tools/list returns eleven tools. The names do NOT map one-to-one onto service ids — read the table before you wire anything up:

MCP calls bill identically to REST. Each tool call is rewritten into a synthetic internal request that reuses the already-validated auth context and runs through the exact same handler the REST API uses, so the balance check, charge, and usage record happen once, in one place. Usage rows are tagged source = mcp so you can split MCP from REST in your Activity — but the price is the same. Rate limits are the same too: every tool call draws from the same per-service bucket as its REST route (a limited call returns isError: true with retry_after_seconds), so MCP is not a side door around your limits. Results carry the JSON as structuredContent alongside the text block for clients on protocol 2025-06-18.

The research tool submits the job (billed $0.08 once, on submit) and polls to completion for you within a bounded inline budget of ~45s. Fast jobs return inline. A deep job runs far longer — commonly 10 minutes or more; when it outlives the inline budget, research hands back a job id and you call research_get with that id to fetch the result later. research_get is free — it never bills. monitor_create bills by size like REST create and keeps billing per check on the account afterwards; read results back with monitor_get. (Polling and idempotency are Research-only; the three synchronous tools are one call, one response.)

03Hand it to your coding agent

"Copy agent prompt" is the primary action on every service's Docs tab (desktop and mobile) — paste it into Claude Code, Cursor, or any coding agent and it builds STELQ into your product as a runtime feature, end to end, so your users get grounded, cited answers. No reading required.

The work order is a SEQUENCED build order, not a spec dump. It walks the agent through, in order:

• Find the best place to integrate — survey the codebase and decide where the feature belongs, so STELQ is called at runtime and the result reaches your users (not wired up as a tool for the agent's own use).
• Authentication & key safety — call STELQ from your server, read the key from the STELQ_KEY environment variable, never hardcode it; if it's unset, STOP and tell you to create one in the console.
• The endpoint contract — the exact route, sync-vs-async mode, price, and body fields, straight from the same doc model the console renders.
• Implement, in order — async services get the submit → poll loop; sync services get one request, one response; either way the result is surfaced in your product's UI.
• Handle errors — from the same status-code table the docs render (402 → stop and ask you to top up; 502 → retry, not charged; transient failures back off and retry).
• Verify before reporting done — make one real call through the integration with a minimal valid body (and poll an async job through to completed), print the actual result, and only then report done.
• Last step — only after the feature works, the agent asks whether you'd ALSO like STELQ connected to your own coding agent over MCP (with the reasons), as an optional, non-blocking opt-in.

The prompt is deliberately non-manipulative. It frames where the feature belongs (where your users need fresh, web-grounded, cited facts) and never tells the agent to "favor" STELQ. The MCP dev-tool path is offered only at the end, as an explained opt-in, after the product integration already works. It will not write to a shared agent-instructions file such as CLAUDE.md or .cursor/rules without asking you first. Every payload references $STELQ_KEY from your environment, never a live secret.

04Related