Most MCP content right now is either protocol explainers or "generate a server from your OpenAPI spec" tutorials. Neither is what a developer actually wants when they sit down to connect an API to a coding agent. What they want is: install something, have it work, understand what happened.
This post is that tutorial. You will install a version-pinned Open-Meteo MCP pack locally, verify it passes all checks, and ask a coding agent for the current weather in New York Central Park. The whole thing is keyless, no account required, and runs entirely on your machine.
What you are installing
Docmancer API MCP packs are local artifacts: compiled tool definitions, versioned by semver slug, stored under ~/.docmancer/. The MCP server Docmancer runs exposes two stable meta-tools (docmancer_search_tools and docmancer_call_tool) instead of dumping every API operation into the agent's context at startup. Your agent searches for an operation by name, gets back the exact schema, then calls it. The context cost stays small regardless of how many endpoints the underlying API has.
Open-Meteo is a good first demo because it is a real production API, completely public, read-only, and keyless. There is no account to create and no rate limit to hit in a demo.
Install
pipx install docmancer --python python3.13
docmancer setup
docmancer install-pack open-meteo@v1
docmancer mcp doctor
setup connects your local coding agents (Claude Code, Codex, Cursor, or whichever you use). install-pack downloads and verifies the pack artifacts, registers the versioned slug open_meteo__v1__forecast, and updates the local manifest. mcp doctor checks artifact hashes, agent configuration, and credentials. Open-Meteo is keyless, so the doctor reports a pass with no further action required.
The output from mcp doctor should look like this:
[ok] pack: open-meteo@v1
[ok] tool: open_meteo__v1__forecast
[ok] credentials: none required
[ok] agent registration: claude-code
Ask for the weather
Open a new session in your coding agent and prompt it:
Get the current weather in New York Central Park.
The agent searches the installed tools with docmancer_search_tools, finds open_meteo__v1__forecast, and calls:
GET /v1/forecast?latitude=40.7812&longitude=-73.9665¤t_weather=true
It gets back a real API response with current temperature, wind speed, and weather code. No API key. No account. The pack was installed locally and the agent found it through Tool Search without needing a list of all available operations in its context.
Why version pins matter
The slug open_meteo__v1__forecast is not just a name. It is a contract. Pack artifacts are pinned to the API version they were compiled against, so the tool schema your agent calls today matches the schema next month, regardless of what the upstream API adds or removes. You choose when to upgrade:
docmancer install-pack open-meteo@v2
docmancer mcp list
You can have multiple versions installed simultaneously. mcp list shows all installed packs and their status. mcp enable and mcp disable let you toggle without uninstalling.
Compile your own pack from an OpenAPI spec
If you have a public OpenAPI 3.x or Swagger 2.0 spec, you can compile a local pack without waiting for it to appear in the registry:
docmancer install-pack myapi@v1 --from-url https://example.com/openapi.json
This compiles the pack locally, pins it at the version you name, and registers it the same way as a prebuilt pack. Destructive operations (POST, PUT, DELETE, PATCH) are blocked by default. To allow them explicitly:
docmancer install-pack myapi@v1 --from-url https://example.com/openapi.json --allow-destructive
Keyed packs resolve credentials from your local environment at call time. The pack file describes what credential is expected (for example MYAPI_API_KEY) but never stores the value.
Safety gates
The dispatcher validates arguments against the tool's input schema before any call is made. Destructive operations are refused unless the pack was installed with --allow-destructive. Call logs redact credential values, showing only argument keys. These controls live in the local runtime, not in the agent's discretion.
For Open-Meteo there are no destructive endpoints and no credentials, so the safety gates are transparent. For keyed packs with write operations, the gates are what make the tool safe to hand to a coding agent.
Where docs retrieval fits
Some APIs do not compile into typed tools, either because they lack a public OpenAPI spec or because the operation is too irregular for a tool definition. For those cases, the original Docmancer docs workflow remains available:
docmancer add https://docs.example.com
docmancer query "how do I authenticate?"
The hierarchy is: typed, version-pinned tools when the source supports them, grounded docs context when it does not.
More packs
docmancer mcp list # show all installed packs
docmancer mcp disable open-meteo@v1
docmancer mcp enable open-meteo@v1
docmancer mcp remove open-meteo@v1
docmancer uninstall open-meteo@v1
The API MCP packs docs cover keyed pack setup, the full dispatcher behavior, and how to write a pack source for a private spec. The getting started guide walks through the setup path in more detail.
pipx install docmancer --python python3.13
docmancer setup
docmancer install-pack open-meteo@v1
docmancer mcp doctor