The Four Tools

Overview

MetaMCP exposes exactly 4 tools to the LLM, no matter how many child MCP servers are connected. These 4 tools total approximately 1,000 schema tokens.

Traditional MCP setups register every child server's tools directly with the LLM. Five servers with 20 tools each means 100 tool schemas in the context window, roughly 15,000 tokens consumed before the conversation even starts. MetaMCP collapses that surface area down to 4 stable tools that act as a routing layer.

The four tools are:

mcp_discover

Search tool catalogs across all child MCP servers and list server status.

Parameters:

Without a query, mcp_discover returns the list of connected servers with their status and tool counts. With a query, it searches tool names and descriptions using hybrid scoring (keyword + semantic when configured).

Example: List all servers

{}

Example: Search for screenshot tools

{
  "query": "screenshot"
}

This returns matching tools ranked by relevance, with each result including the tool name, description, server name, and match score.

For details on how search ranking works, see Discovery & Search.

mcp_provision

Intent-based provisioning. Describe what you need, and MetaMCP resolves and provisions the right server.

Parameters:

mcp_provision searches local catalogs first. If no local server matches the intent, it queries the npm registry for published MCP servers. When autoProvision is true, a matched server is installed and started automatically.

Example: Find a server for web crawling

{
  "intent": "I need to crawl a website and extract links"
}

This searches local tool catalogs for matching capabilities. If nothing is found locally, it queries the MCP server registry at registry.modelcontextprotocol.io for published servers that match the intent.

For details on automatic provisioning, see Auto-Provisioning.

mcp_call

Forward a tool call to a specific child MCP server.

Parameters:

mcp_call is the most common tool for direct invocations. It provides explicit routing: you name the server, name the tool, and pass the arguments. If the target server crashes during the call, MetaMCP retries once automatically for vital servers.

Example: Navigate a browser

{
  "server": "playwright",
  "tool": "browser_navigate",
  "args": {
    "url": "https://example.com"
  }
}

Example: Run a database query

{
  "server": "sqlite",
  "tool": "query",
  "args": {
    "sql": "SELECT count(*) FROM users"
  }
}

The server is lazily spawned on first use. If the server is not already running, MetaMCP starts it from the connection pool before forwarding the call.

mcp_execute

Code-mode execution in a V8 sandbox. Write JavaScript that composes calls across multiple servers in a single tool invocation.

Parameters:

Inside the sandbox, provisioned servers are available via servers.<name>.call(tool, args). The code supports async/await, sleep(ms) for delays, and console.log for output capture.

Example: Query a database and return the result

{
  "code": "const result = await servers.sqlite.call('query', { sql: 'SELECT count(*) FROM users' }); return result;"
}

Example: Multi-step workflow across servers

{
  "code": "const page = await servers.playwright.call('browser_navigate', { url: 'https://example.com' });\nconst screenshot = await servers.playwright.call('browser_screenshot', {});\nawait sleep(1000);\nconst analysis = await servers.vision.call('analyze_image', { image: screenshot });\nreturn analysis;"
}

Code mode saves round-trips and tokens when the LLM needs to chain multiple tool calls together. Instead of 4 separate tool calls (4 round-trips), a single mcp_execute call handles the entire workflow.

For sandbox security details, see V8 Sandbox. For usage patterns, see Code Mode.

Decision Tree

Use this to determine which tool fits your situation:

A typical workflow progresses through these tools naturally:

1. Discover available capabilities with mcp_discover.
2. Provision a server if the needed tool is not yet available, using mcp_provision.
3. Call individual tools directly with mcp_call.
4. Execute multi-step workflows with mcp_execute when chaining is needed.

In practice, the LLM often skips straight to mcp_call for well-known servers and tools. Discovery and provisioning are for exploration and bootstrapping.

Token Comparison

The token savings are significant as server count grows.

MetaMCP's token cost stays constant at approximately 1,000 tokens regardless of how many child servers and tools exist behind it. The schema overhead shifts from O(N) to O(1).

This matters because context window space consumed by tool schemas is space not available for conversation history, reasoning, and output. At 20+ servers, traditional MCP setups can lose a meaningful fraction of the context window to schema definitions alone.