Loading ToolBench
MCP server exposing InFoundry cloud architecture tools to Cline. Mirrors the InFoundry Kestra pipeline for analyzing repositories, collecting telemetry, proposing cloud architectures using AI, rendering graphs, generating Terraform IaC, validating, and managing GitHub PRs.
InFoundry MCP server has reasonable parameter documentation and schema structure but suffers from several critical gaps in definition quality. All 9 tools are explicitly registered with names, descriptions, and Zod schemas, which is good foundation. However, descriptions vary in quality and actionability, parameter descriptions lack contextual detail for many parameters, and error handling lacks recovery guidance. The tool chain design is sound (services → telemetry → architecture → IaC → PR), but descriptions often fail to explain WHEN to call each tool vs alternatives or HOW to interpret results. Response schemas are documented in code comments but not formally exposed in tool definitions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications in the spec.
Create GitHub pull request with generated infrastructure-as-code
AI evaluation of deployment results and architecture decisions
Generate Terraform infrastructure-as-code from architecture graph
Analyze a repository to detect services, databases, and queues. Supports local paths or GitHub URLs.
Collect and summarize service telemetry metrics (latency, error rate, CPU, memory)
Propose optimal cloud architecture using InFoundry's Oumi AI model
Convert architecture to React Flow graph for visualization
Missing tool annotations despite clear risk classifications. Tools like create_pr (IRREVERSIBLE) and generate_iac (WRITE) should use destructiveHint/idempotentHint annotations per MCP spec. LLMs cannot infer side effects from descriptions alone.
Descriptions lack WHEN/WHY context. 'Propose optimal cloud architecture using InFoundry's Oumi AI model' does not explain when to call propose_architecture vs other optimization tools, what preconditions are needed, or what the output looks like. Contrast with: 'Given a service profile and telemetry from ingest_repo/ingest_telemetry, generate a cost-optimized architecture proposal. Call after gathering service inventory and baseline metrics.'
Parameter descriptions lack format/constraint details. 'metricsJson' in ingest_telemetry says 'Optional JSON with real metrics, otherwise generates mock data' but does not specify the JSON schema expected. 'serviceProfile' in propose_architecture says 'JSON string of service profile from ingest_repo' but does not describe the required fields. LLMs will guess or pass malformed JSON.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Validate Terraform configuration for syntax errors and best practices
Check GitHub PR status, CI checks, and review status
No error recovery guidance in descriptions. ingest_repo can fail on invalid paths or failed git clones; the error response includes a message but the description does not tell the LLM WHAT TO TRY NEXT. Similar for all other tools, errors mention what went wrong but not how the agent should recover.
Response schemas not formalized in tool definitions. The code includes internal return objects (e.g., profile = { source, services, databases, queues, ... }) but these are never declared in the tool schema or description. LLMs cannot plan downstream calls without knowing what fields will be returned.
create_pr lacks confirmation/dry-run pattern. This tool is IRREVERSIBLE (creates a real GitHub PR) but has no confirmation step or dry-run option. An agent making a mistake will commit real IaC to a repository. Should support a 'confirm_before_execute' handshake per pattern:confirmation-request.
Input validation error messages lack actionability. Code includes generic error handling ('Error: ' + error) without specific guidance. When repoPath validation fails, the error says 'Invalid path: contains dangerous characters' but does not suggest what characters to remove or what a valid path looks like. LLMs cannot self-correct.
Tool composition assumptions not documented. The pipeline assumes ingest_repo → ingest_telemetry → propose_architecture → render_graph → generate_iac → create_pr, but descriptions do not state which tools are prerequisites or which can be skipped. An LLM might try to call propose_architecture without ingest_repo output first.