Loading ToolBench
Terraform provider for managing MCPG (mcpg.dev) custom resources via the operator plane with plan-time validation mirroring the operator's admission webhook
This is a Terraform provider, not an MCP server. It manages Kubernetes custom resources via the Terraform plugin framework, not the Model Context Protocol. All 8 tools are Terraform resources (mcpg_gateway, mcpg_plugin, etc.), not MCP tools. They lack verb-based naming (should be create_gateway, update_gateway, etc.), have generic descriptions that repeat boilerplate, and expose raw JSON spec parameters instead of structured, typed fields. No input validation guidance, no error recovery hints, no pagination, no output schema documentation. The provider is well-engineered for Terraform but fundamentally misaligned with MCP tool patterns.
A MCPGCluster custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
A MCPGGateway custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
A MCPGPlugin custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
A MCPGPluginMirror custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
A MCPGPluginSet custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
A MCPGRevocationList custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
Not an MCP server. This is a Terraform provider for Kubernetes CRD management. It does not implement the Model Context Protocol and cannot be used as an MCP tool server.
Tool names lack action verbs. All 8 resources use noun-only naming (mcpg_gateway, mcpg_plugin) instead of verb_noun pattern (create_gateway, update_gateway, delete_plugin). LLMs cannot infer intent from resource names alone.
Descriptions are generic boilerplate repeated across all 8 tools. Each says 'A MCPG* custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.' This provides no differentiation and does not explain when to use each resource or what it controls.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 20 | 2026-07-28+ | v2 |
A MCPGRoute custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
A MCPGTenant custom resource. `spec` is the CR spec as JSON (use `jsonencode`); validated at plan time against the operator's admission rules.
Spec parameter is a raw JSON string with no schema validation hints. Agents must construct JSON manually without type guidance, format constraints, or field documentation. This violates the constrained-input pattern and forces agents to guess valid spec structure.
No output schema documented. Terraform resources return computed fields (id, config_hash) but no guidance on what the API returns after create/update/read operations. Agents cannot plan downstream operations without knowing response structure.