Loading ToolBench
OpenTofu MCP Server for accessing the OpenTofu Registry
The OpenTofu MCP server provides a well-structured interface to the OpenTofu Registry with 7 read-only tools. All tools are properly named with action verbs (search-, get-), have clear descriptions (140-250 chars, well within baseline), and include detailed parameter schemas with types, descriptions, and constraints. Input schemas are comprehensive with enum constraints where appropriate (e.g., type parameter in search-opentofu-registry). Output schemas are implicitly documented through the RegistryClient class return types and API-generated TypeScript types. Minor gaps: no per-tool error handling guidance, no output schema documentation visible in tool definitions themselves, and descriptions lack dependency hints (e.g., 'search first if you only have a partial name'). The server is read-only (all tools marked READ_ONLY), so no destructive operation confirmation patterns are needed. Tool composition is strong, tools chain naturally (search → get-details → get-versions → get-*-docs). Parameter naming is consistent and clear (namespace, name, target, version). Tools appropriately abstract away API complexity (e.g., get-provider-versions returns a lightweight call vs. full details).
Get documentation for a specific data source from an OpenTofu provider. Do NOT include provider prefix in data source name.
Get detailed information about a specific OpenTofu module by namespace, name, and target. Use the simple module name, NOT the full repository name.
Get the list of available versions for a specific OpenTofu module by namespace, name, and target. Use the simple module name, NOT the full repository name.
Get detailed information about a specific OpenTofu provider by namespace and name. Do NOT include 'terraform-provider-' prefix in the name.
Get the list of available versions for a specific OpenTofu provider by namespace and name, without fetching full provider documentation. Do NOT include 'terraform-provider-' prefix in the name.
Get documentation for a specific resource from an OpenTofu provider. Do NOT include provider prefix in resource name.
No output schema documentation in tool definitions. Return types are implicit (via generated API types) and not visible in the MCP tool schema registry. LLMs cannot predict what fields to expect without examining implementation.
Descriptions lack dependency hints and context for tool selection. E.g., 'get-provider-details' doesn't hint 'Call search-opentofu-registry first if you only have partial provider names.' This increases tool selection ambiguity.
No explicit error recovery guidance in tool descriptions. Descriptions do not indicate what to do if a provider/module/resource is not found (e.g., 'Try search-opentofu-registry with a broader query').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 65 | - | v1 |
Search the OpenTofu Registry to find providers, modules, resources, and data sources. Use simple terms without prefixes like 'terraform-provider-' or 'terraform-module-'.
API error responses (404, 500, etc.) are not caught and translated to actionable LLM guidance. Raw HTTP errors ('API request failed: 404') do not tell the LLM what to do next.