MCP

Call StackResolve as a tool from any MCP client, hosted or stdio.

StackResolve runs one hosted MCP server. It serves both toolsets, discovery plus research, from a single endpoint. There is no separate server to add per product.

Endpoint: https://mcp.stackresolve.dev/mcp
Transport: streamable HTTP, stateless. Send a JSON-RPC request with POST /mcp.
Auth: send your key in the x-api-key header. The hosted server requires a valid key for every call.

Warning

Registry reads (search_tools, get_profile, list_registry, compare_products) work without a key. Every metered tool needs one in the x-api-key header and returns an error naming the missing key without it. Get a key at app.stackresolve.dev.

#Add the server

The fastest path is the installer. It covers Claude Code, Cursor, Codex, Windsurf, and VS Code in one go, and writes the agent skill:

Shell

npx stackresolve@latest install

By hand, for Claude Code:

Shell

claude mcp add --transport http stackresolve https://mcp.stackresolve.dev/mcp \
  --header "x-api-key: $STACKRESOLVE_API_KEY"

For other clients, point them at https://mcp.stackresolve.dev/mcp and set the x-api-key header. See the editor guides for Claude Code, Codex, and Cursor.

#Tools

Fifteen tools. The cheap reads run on any valid key. The expensive tools (audit, get_company, get_pricing, research_company, find_tools_for_task) run a billing entitlement check and record a usage event for your workspace.

Tool	Input	Metered	Docs
`find_tools_for_task`	`{ task: string }`	`agent_discovery_check`	Find tools
`search_tools`	`{ query: string, api?, mcp?, self_serve?, openapi?, cli? }`	No	Find tools
`compare_products`	`{ slugs: string[] }`	No	Registry
`get_profile`	`{ slug: string }`	No	Registry
`list_registry`	`{ category?: string, minScore?: number, limit?: number }`	No	Registry
`audit`	`{ domain: string }`	`audit_run`	Audit
`get_company`	`{ domain: string }`	`workflow_execution`	Company
`get_pricing`	`{ domain: string }`	`workflow_execution`	Pricing
`research_company`	`{ domain: string, question?: string }`	`workflow_execution`	Research
`get_usage`	`{}`	No	Billing & metering

Note

search_tools takes the capability filters as flat booleans on the input, not as a nested requirements object. The REST /v1/search endpoint nests them under requirements. Same filters, different shape.

The competitor and company-comparison primitives (find_competitors, compare_companies) are available over REST and the CLI, not as MCP tools.

#Example call

A raw JSON-RPC tools/call over the hosted transport:

Shell

curl https://mcp.stackresolve.dev/mcp \
  -H "x-api-key: $STACKRESOLVE_API_KEY" \
  -H "content-type: application/json" \
  -H "accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": { "name": "find_tools_for_task", "arguments": { "task": "send transactional email" } }
  }'

The tool result comes back as a text content block holding the JSON response:

JSON

{
  "content": [
    { "type": "text", "text": "{ \"task\": \"send transactional email\", \"results\": [ { \"slug\": \"resend\", \"name\": \"Resend\", \"agentready\": 98 } ] }" }
  ]
}

In practice you never build this by hand. Your MCP client (Claude Code, Codex, Cursor) handles the JSON-RPC and shows the tools to the agent.

#Local stdio

Prefer to run a server on your own machine, for example to point at a local API during development? The CLI packages ship the same engine functions. Wrap them in a small stdio MCP server, or just use the CLI directly. For most agents the hosted server is the right default: it is one line to add and always current.

Tip

One server serves every tool. Let the agent first pick a tool with find_tools_for_task, then dig into a vendor with research_company, without adding a second server.

PreviousREST API NextCLI