- name
- meta-mcp-wizard
- description
- |
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
// ~/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:
| Tool | Purpose |
|---|---|
wizard_create_session | Start session; returns server_id |
wizard_chat | Send requirement message; returns is_ready flag |
wizard_start | Transition to tool suggestion (async) |
wizard_list_tools | List suggested tools with IDs, code, params |
wizard_refine_tools | Refine with feedback (async) |
wizard_submit_tools | Confirm selection by tool UUID list |
wizard_suggest_env_vars | Re-trigger env var suggestion (async) |
wizard_list_env_vars | List env vars with IDs and descriptions |
wizard_refine_env_vars | Refine env vars with feedback (async) |
wizard_submit_env_vars | Submit values as {uuid: value} dict |
wizard_set_auth | Generate bearer token |
wizard_generate_code | Trigger code gen (async) |
wizard_regenerate_tool_code | Regenerate single tool code (sync) |
wizard_deploy | Deploy and get server URL |
wizard_state | Poll 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
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_tokenAlways 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:
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 liveStates 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":
wizard_state(server_id) → check .processing_status
"processing" → wait and call again
"idle" → ready for next step
"error" → check .processing_errorConnecting a Deployed Server to MCP Clients
After wizard_deploy, construct the full server URL:
https://api.mcphero.app{server_url}where server_url is the relative path returned (e.g., /mcp/<server-id>/mcp).
Claude Desktop config
{
"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).