Meta-MCP Wizard#

The MCPHero Meta-MCP server lets agents build persistent tools without leaving their MCP client. Instead of re-explaining an API or re-generating SQL on every run, the agent creates a hosted MCP server once and calls it forever — saving 95-99% on token usage for recurring tasks.

Connect it to Claude Desktop, Cursor, or any MCP client, and your agent can build, deploy, and register new MCP servers on the fly.

Meta-MCP endpoint: https://api.mcphero.app/mcp/meta/mcp

---

Setup#

Add the Meta-MCP server to your MCP client config:

Claude Desktop#

json

// ~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "mcphero": {
      "url": "https://api.mcphero.app/mcp/meta/mcp"
    }
  }
}

Config file locations:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json
• Linux: ~/.config/claude/claude_desktop_config.json

Cursor and other MCP clients#

Add the same URL https://api.mcphero.app/mcp/meta/mcp to your client's MCP server config. The client handles OAuth 2.1 authentication automatically on first use.

---

Available Tools#

The Meta-MCP server exposes these tools:

ToolPurposewizard_create_sessionStart session; returns server_id``wizard_chatSend requirement message; returns is_ready flagwizard_startTransition to tool suggestion (async)wizard_list_toolsList suggested tools with IDs, code, paramswizard_refine_toolsRefine with feedback (async)wizard_submit_toolsConfirm selection by tool UUID listwizard_suggest_env_varsRe-trigger env var suggestion (async)wizard_list_env_varsList env vars with IDs and descriptionswizard_refine_env_varsRefine env vars with feedback (async)wizard_submit_env_varsSubmit values as {uuid: value} dictwizard_set_authGenerate bearer tokenwizard_generate_codeTrigger code gen (async)wizard_regenerate_tool_codeRegenerate single tool code (sync)wizard_deployDeploy and get server URLwizard_statePoll current state — use after all async steps

---

Async vs Sync Tools#

Async (trigger then poll wizard_state): wizard_start, wizard_refine_tools, wizard_suggest_env_vars, wizard_refine_env_vars, wizard_generate_code

Sync (wait for result): wizard_create_session, wizard_chat, wizard_list_tools, wizard_submit_tools, wizard_list_env_vars, wizard_submit_env_vars, wizard_set_auth, wizard_regenerate_tool_code, wizard_deploy, wizard_state

---

The Wizard Pipeline#

text

1. wizard_create_session    → Returns server_id (save it, needed everywhere)
2. wizard_chat (loop)       → Gather requirements; stop when is_ready: true
3. wizard_start             → Transition to tool suggestion (async → poll)
4. wizard_list_tools        → Review AI-suggested tools
5. wizard_refine_tools      → Iterate on tools until satisfied (optional, async → poll)
6. wizard_submit_tools      → Confirm selection by tool UUID list
7. wizard_list_env_vars     → Review suggested env vars
8. wizard_refine_env_vars   → Iterate on env vars (optional, async → poll)
9. wizard_submit_env_vars   → Provide values as {uuid: value} dict (call even if empty)
10. wizard_set_auth         → Generate bearer token
11. wizard_generate_code    → Trigger code generation (async → poll)
12. wizard_deploy           → Deploy → returns server_url + bearer_token

Always call wizard_submit_env_vars, even when wizard_list_env_vars returns []. Pass an empty dict {} so the backend transitions to the next state.

---

State Machine#

The setup_status field in wizard_state tells you where you are:

text

gathering_requirements     → User is chatting about requirements
tools_generating           → LLM is generating tool suggestions (async, poll)
tools_selection            → Tools ready for review/selection
env_vars_generating        → LLM is generating env var suggestions (async, poll)
env_vars_setup             → Env vars ready for review/submission
auth_selection             → Ready for auth setup
code_generating            → LLM is generating code (async, poll)
code_gen                   → Code ready for review
deployment_selection       → Ready to deploy
ready                      → Server deployed and live

States ending in _generating are transient — poll until they transition. The processing_status field is the reliable check: "idle" means done, "processing" means wait, "error" means check processing_error.

---

Polling Pattern#

After any async tool, poll wizard_state until processing_status is "idle":

text

wizard_state(server_id) → check .processing_status
  "processing"  → wait and call again
  "idle"        → ready for next step
  "error"       → check .processing_error

---

Connecting a Deployed Server to MCP Clients#

After wizard_deploy, construct the full server URL:

text

https://api.mcphero.app{server_url}

where server_url is the relative path returned (e.g., /mcp/<server-id>/mcp).

Claude Desktop config#

json

{
  "mcpServers": {
    "my-server": {
      "url": "https://api.mcphero.app/mcp/<server-id>/mcp",
      "headers": {
        "Authorization": "Bearer <bearer_token>"
      }
    }
  }
}

---

Key Tips#

Free tier: Max 5 tools per server. wizard_submit_tools will error if more are selected.

server_id is everything: Save the UUID returned from wizard_create_session. Every subsequent call needs it.

Empty env vars: Even if wizard_list_env_vars returns [], you must still call wizard_submit_env_vars with {} so the backend transitions to the next state.

Regenerate without redeploy: After using wizard_regenerate_tool_code, the code change takes effect immediately for already-deployed servers (the server auto-remounts).