Skip to content

Recipes

Step-by-step guides for putting contextweaver in front of specific MCP clients and real-world MCP servers. Each recipe walks from pip install contextweaver to a working integration end-to-end.

contextweaver's gateway runtime is a regular MCP server, so any MCP client can point at it. The recipes here cover the two most common clients people ask about:

Client Recipe Config file
Claude Desktop Claude Desktop examples/recipes/claude_desktop_config.json
GitHub Copilot (VS Code) GitHub Copilot examples/recipes/copilot_mcp.json

Both recipes share the same launcher: examples/recipes/serve_gateway.py. The launcher takes either --stub (built-in 2-tool catalog for sanity checks) or --catalog PATH (a real-MCP-server snapshot from examples/architectures/mcp_context_gateway/real_catalogs/). When the contextweaver mcp serve CLI lands, the recipes' launcher line will drop in for the dedicated CLI with no other changes.

What "in front of" means

┌────────────────┐    bounded ChoiceCard list    ┌──────────────────┐
│ Claude Desktop │ ─────────────────────────────▶│ contextweaver    │
│ / VS Code      │                               │  gateway (stdio) │
└────────────────┘ ◀────────────────────────────│                  │
                       firewalled tool result   └────────┬─────────┘
                                                         │ raw tools/list
                                                         ▼
                                              ┌───────────────────┐
                                              │ Upstream MCP      │
                                              │  server(s)        │
                                              └───────────────────┘

The MCP client sees one virtual MCP server that exposes a bounded list of ChoiceCards instead of the upstream's full tool catalogue, and receives a firewalled summary (plus an artifact handle) instead of the raw tool output. The upstream servers are unchanged — you do not have to fork or patch them.

See also