VerveContext is one hosted MCP server. Point an agent at it and 204 sources become native tools — each with an input schema the model can read and an output schema that brings results back as data rather than as prose the model wrote about data.
There is no package to install, no per-source setup, and nothing to keep updated: the tool list is generated from the catalog, so a source that ships today is callable today.
Your account is ready. The connection below will authenticate against it.
Add the server
https://api.apiverve.com/v1/mcp
VS Code — mcp.json:
{ "servers": { "vervecontext": { "type": "http", "url": "https://api.apiverve.com/v1/mcp" } } }Cursor — ~/.cursor/mcp.json:
{ "mcpServers": { "vervecontext": { "url": "https://api.apiverve.com/v1/mcp" } } }Claude Desktop — Settings → Connectors → Add custom connector, with the same URL. This
one cannot be done from a file: claude_desktop_config.json only accepts stdio servers, so a
remote server configured there is silently ignored.
Restart the client afterwards so it re-reads the config and lists the tools.
Sign in
Connect with no credentials and the server answers 401 with a WWW-Authenticate challenge
pointing at its resource metadata. Your client runs the OAuth flow, you approve it in the
browser, and no key is ever written to a config file.
That is the right default for a config you commit or a machine you share.
For headless setups, send your key in the x-api-key header instead. Put a scoped
sub-key there rather than your primary key — the file is at rest on
disk, and a sub-key can be revoked without disturbing anything else.
Call a tool
Ask the agent something the model cannot know, and watch which tool it reaches for:
What is the current gold price per gram in euros?
The agent picks the tool, fills the input schema, calls it, and answers from the result. Nothing to wire up — discovery is the protocol's job.
What the agent sees for each tool:
| Field | Where it comes from |
|---|---|
name | The source's title, stripped to [a-zA-Z0-9_-] |
description | The source's description, with its credit cost appended |
inputSchema | JSON Schema built from the source's published parameters |
outputSchema | JSON Schema for the response envelope, on protocol 2025-06-18 and newer |
annotations | readOnlyHint: true, openWorldHint: true |
The cost in the description is deliberate: an agent choosing between two ways to answer a
question can see which is cheaper before it commits. And readOnlyHint says every tool here is a
lookup — nothing mutates state on your side — which is what lets a client skip a confirmation
prompt on each step.
Make the results usable
Two habits separate a demo from something you would put in front of users.
Read structuredContent, not the text block. Clients on protocol 2025-06-18 and newer get
the response object itself alongside the text an older client reads. Both carry the same
envelope, so they cannot disagree — but only one is parseable.
Narrow the tool list. 204 tools in one context window is a lot of schema for a model to hold, and it makes tool selection worse, not better. Most clients let you enable a subset; key scoping can also block tools at the account level, so a credential handed to an agent can only reach what that agent is for.
Watch what it spends
An agent decides how many calls to make, which is exactly the property that makes a budget worth setting before you leave it running.
- Every tool call spends credits by source — costs are on each source's page and in all sources.
- Analytics breaks usage down by source and by key, which is usually how a loop gets noticed.
- A sub-key per agent gives each one its own rate limit and its own line in that breakdown.
Next
MCP server is the full reference — transports, the stdio bridge for clients that need one, and how tools are generated. All sources is the catalog, one page per source with its inputs and response fields.