Loading ToolBench
A comprehensive Model Context Protocol server for Azure Terraform operations
The server provides 17 tools with mostly complete schemas and parameter descriptions. Naming follows consistent verb_noun patterns (get_, run_, check_, export_, validate_, audit_). However, there are critical gaps: (1) Output schemas are not documented, the server provides input schemas but no structured response documentation, forcing LLMs to infer return types. (2) Several tool descriptions lack actionable context about when to use them vs. alternatives. (3) Error handling guidance is absent, no recovery hints or error classification. (4) Some descriptions are generic or incomplete (e.g., 'Retrieve documentation' without stating what fields are returned). (5) Parameter defaults for risky operations (e.g., run_terraform_command with environment_variables) lack safety warnings. The server sits at the upper end of 'Fair' because schemas and naming are solid, but missing output documentation and error guidance prevent it from reaching 'Good.'
Audit Terraform configuration coverage against Azure resources.
Check if aztfexport is installed and return installation information.
Export existing Azure resources to Terraform configuration and state files using aztfexport.
Export an entire Azure resource group to Terraform configuration using aztfexport.
Export Azure resources matching an Azure Resource Graph query to Terraform configuration.
Retrieves the latest version of a specified Azure verified module.
Retrieves all available Azure verified modules. Returns: A list of Azure verified modules. Each item in the list contains the following fields: - module_name: The name of the Azure verified module, which is typically used as the input parameter of other tools. - description: A brief description of the module. - source: The value of `source` field in the module's definition. (e.g., `source = "Azure/avm-res-apimanagement-service/azurerm"`)
Output schemas not documented. Every tool returns data but no tool documents the structure of its response (field names, types, nested objects). LLMs cannot plan downstream calls or extract needed data without trial-and-error.
WRITE operations lack destructive hints and confirmation patterns. Tools like export_azure_resources_with_aztfexport and export_resource_group_with_aztfexport modify filesystem state but descriptions do not flag them as WRITE. No dry_run is mandatory; only optional. Missing explicit destructive warnings.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Retrieves the outputs of a specified Azure verified module. The outputs can be used to assign values to other resources or modules in Terraform.
Retrieves the variables of a specified Azure verified module. The variables describe the schema of the module's configuration.
Retrieves all available versions of a specified Azure verified module.
Retrieve documentation for a specific AzAPI resource type in Terraform.
Retrieve the current aztfexport configuration.
Retrieve documentation for a specific AzureRM resource type in Terraform.
Run Conftest analysis using Azure Verified Module policies to validate Terraform configurations against policy rules.
Execute a Terraform command in a specified working directory.
Run TFLint analysis on a Terraform workspace folder to identify potential issues and violations.
Validate Terraform HCL configuration for syntax errors.
run_terraform_command accepts free-form 'command' string (no enum). LLM can hallucinate invalid commands like 'terraform magic' or 'terraform debug'. Should enumerate valid commands (init, plan, apply, destroy, validate, etc.) or accept a structured enum.
Error handling guidance is absent. No tool descriptions tell LLMs what to do on failure (retry? ask user? abandon?). For example, run_terraform_command may fail due to syntax, provider auth, or transient network, each needs different recovery. Missing error classification.
Parameter relationships undocumented. Tools like get_azurerm_provider_documentation have optional params argument_name and attribute_name but do not state: can both be specified? Are they mutually exclusive? Does one require the other?
Array parameters lack item schemas. enable_rules and disable_rules in run_tflint_workspace_analysis are arrays but do not specify what type of items (strings? objects?). Should include minItems/maxItems and item descriptions.
Vague defaults and parameter formats. terraform_version defaults to 'latest' (ambiguous). hcl_content in validate_terraform_configuration has no max size warning. environment_variables in run_terraform_command is an untyped object.
Query language not specified. export_with_aztfexport_query accepts a 'query' parameter but does not state the query language (KQL? ARM ResourceGraph? Custom syntax?). LLM will guess.
Generic descriptions lack actionable context. Several tools describe WHAT they do but not WHEN to use them or how they differ from similar tools. Example: get_avm_modules, get_avm_latest_version, and get_avm_versions are similar, which should an LLM choose first?