Server has 14 tools with consistent naming and reasonable descriptions, but exhibits significant gaps in schema completeness, parameter descriptions, and output documentation. Naming follows verb_noun pattern well (list_, get_, generate_, check_) which aligns with baseline expectations. Descriptions range from adequate to brief, averaging ~100-150 characters across most tools. However, critical issues include: (1) Most tool parameters lack descriptions beyond the parameter name itself, only ~30% have meaningful parameter-level documentation. (2) Output schemas are not documented anywhere in the visible code, the 'ToolResult' interface is generic JSON, not tool-specific. (3) Error handling is basic (errorResult wrapper) with no recovery guidance or categorization. (4) No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite having tools with clear risk levels. (5) Parameter schemas are defined via Zod types (referenced as .shape in server.tool calls) but those Zod definitions are not visible in the provided source, preventing full schema validation. The server is above median quality but has room for production readiness improvements.
Generate an aztfexport command to export an Azure resource group and all its resources to Terraform configuration. The command is returned for the agent to execute locally.
Generate an aztfexport command to export Azure resources matching an Azure Resource Graph query to Terraform configuration. The command is returned for the agent to execute locally.
Generate a conftest command to validate Terraform plan files against Azure security policies. The command is returned for the agent to execute locally.
Output schemas are not documented. The generic ToolResult interface does not explain what fields each tool returns, preventing LLMs from planning downstream calls or extracting specific data.
Parameter descriptions are missing or minimal. Visible schemas show required parameters (e.g., module_name, resourceType, resourceId) but lack inline descriptions explaining their format, constraints, or allowed values. LLMs cannot infer intent from bare parameter names.
get_avm_latest_version
Recommendations
Add tool annotations via MCP SDK. Mark all 11 READ_ONLY tools with readOnlyHint=true; mark 3 WRITE tools (generate_aztfexport_*, setup_conftest_environment) with destructiveHint=true where applicable.
Document output schemas for each tool. E.g., list_avm_modules should document: 'Returns {modules: [{module_name: string, description: string, source: string}]}'. get_azurerm_provider_documentation should document: 'Returns {resource_name: string, arguments: {[key: string]: {type: string, description: string, required: boolean}}, attributes: {...}}'.
Add parameter-level descriptions in Zod schemas. For module_name, explain: 'The name of the Azure verified module (case-sensitive, e.g., avm-res-storage-storageaccount)'. For resourceType, explain: 'The AzureRM resource type in terraform format (e.g., azurerm_resource_group, azurerm_storage_account)'.
Enhance error messages with recovery guidance. E.g., when module not found, return: 'Module 'invalid-name' not found. Call list_avm_modules to see available modules.' When version doesn't exist, suggest 'Call get_avm_versions to list valid versions for this module.'
Add input validation with actionable errors. For resourceCategory enum, validate only 'resources' or 'data' are accepted, returning 'Invalid resourceCategory. Must be one of: resources, data' if violated.
For command generation tools, return structured results instead of plain text. E.g., instead of returning a raw command string, return {command: string, workingDirectory: string, expectedOutput: string, errorPattern: string} so agents can execute and validate reliably.
Generate a conftest command to validate Terraform files in a workspace folder against Azure security policies. The command is returned for the agent to execute locally.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are registered without annotations despite clear risk stratification: 11 READ_ONLY tools and 3 WRITE tools. Annotations enable safer agent planning and prevent accidental state changes.
Error handling lacks recovery guidance. The errorResult() function wraps errors as plaintext but does not categorize them as retryable, user-fixable, or fatal. Provides no actionable next steps (e.g., 'Module not found. Try list_avm_modules() first').
Zod parameter schemas are referenced (.shape suffix) but not visible in source code. Cannot verify that parameter types, descriptions, enums, defaults, or constraints are properly defined. Full schema validation impossible.
Three command generation tools (generate_aztfexport_resource_command, etc.) return plain text commands for agents to execute, but no guidance on validation, error handling, or expected output. Agents cannot easily parse whether command succeeded.
Add per-tool telemetry context. The trackToolCall function currently logs only name, duration, success, errorType. Add requestId correlation and parameter counts to aid debugging.
Document idempotency guarantees. Are check_aztfexport_installation and check_conftest_installation safe to call repeatedly? State explicitly in descriptions.
Consider adding a pagination pattern for list_avm_modules if the list grows large. Include limit and offset parameters and return a total_count field.
Add security note: verify that no secrets (API keys, tokens, credentials) are logged in the telemetry.trackToolCall function or error messages.