Loading ToolBench
Convert any application into an MCP server using AI — analyze, generate, test, rollback, and chat with the forge agent from inside Claude Code.
MCP Forge has 16 tools with complete input schemas and descriptions, but quality is uneven. Naming follows verb_noun convention well (create_project, list_projects, analyze_source). Descriptions are present but often lack actionable context, many are 50-150 chars, below the 194-char baseline for A+ tools. Parameter descriptions exist but are sparse; e.g., 'Project ID' lacks guidance on how to obtain it. Output schemas are not documented in the source, responses are inferred from docstrings. Error handling is minimal; no recovery guidance or categorization. Tool composition is reasonable (single responsibility), but several tools (analyze_source, generate_mcp, run_tests) perform long-running async operations without clear polling guidance in descriptions. Security: no visible secret injection pattern; auth headers are constructed client-side. Overall: functional but below production baseline.
Trigger source code / API analysis for a project and wait for it to complete. Optionally provide a new source_url to override the project's current source. Returns a summary of what was found once analysis finishes.
Answer a clarification question from the AI agent.
Send a message to the AI forge agent for a project — ask it to refactor, clarify, or explain decisions.
Create a new MCP conversion project.
Delete a project and all its snapshots and test runs.
Export a project's generated code as a downloadable archive (zip or tar.gz).
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns confirmation and a preview of generated files') but do not specify field names, types, or structure. LLMs cannot plan downstream calls or extract data reliably.
Async operations lack polling guidance. Tools like analyze_source, generate_mcp, and run_tests trigger long-running tasks and return immediately, but descriptions do not explain how to poll for completion. Agents must infer the polling pattern (call get_project_status repeatedly).
Parameter descriptions are minimal. 'Project ID to analyze' lacks context: how does the agent obtain a project_id? Must it call create_project first? Can it list existing projects? Descriptions should include dependency hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Generate MCP server code for a project and wait for it to complete. Requires analysis to have been run first. Returns confirmation and a preview of generated files when done.
Get any pending clarification questions from the AI agent for a project.
Get the currently generated MCP code for a project.
Check the current status of a project, optionally waiting until the status changes. When wait_for_change=True (default), this call blocks server-side for up to 30 seconds until the status changes from its current value, then returns. Status values: pending, analyzing, clarifying, generating, testing, ready, error.
Get the generated code files from a specific snapshot version.
Get the latest test run results for a project.
List all MCP Forge projects with their current status.
List all snapshots (versions) of generated code for a project.
Roll back a project to a previous snapshot version.
Trigger test run for the generated MCP server. Returns immediately. After calling this, use get_project_status(project_id) to track progress.
No error handling guidance. Descriptions do not explain what errors are possible, whether they are retryable, or what the agent should do next. E.g., analyze_source could fail if the source_url is invalid, but no recovery path is documented.
Destructive operations lack confirmation. delete_project is irreversible but has no dry-run or confirmation step. Agents can accidentally delete projects without safeguards.