A
licenseA
qualityC
maintenanceA Model Context Protocol (MCP) server that integrates Claude with the Terraform Cloud API, allowing Claude to manage your Terraform infrastructure through natural conversation.
62
23
MIT
terraform-best-practices-mcp-server
Delivers curated Terraform best practices and guidance for Google Cloud Platform.
Enables cost estimation and optimization suggestions for Terraform infrastructure.
Offers tools for analyzing, linting, and generating best practices for Terraform code, including CLI analysis and reporting.
Provides vulnerability scanning for Terraform configurations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@terraform-best-practices-mcp-serveranalyze my terraform code for security issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Terraform Best Practices MCP Server
Note: This is a community-maintained MCP server. It is not an official Model Context Protocol server from HashiCorp or any cloud provider.
A Model Context Protocol (MCP) server for producing better Terraform through CLI analysis (tflint, checkov, trivy, kics, infracost), best-practice guidance from terraform-best-practices.com, cloud provider recommendations (Azure, AWS, GCP), and Terraform Registry resource and module guidance.
Overview
This server provides eighteen MCP tools across CLI analysis, best-practice retrieval, and interactive reporting workflows:
run_tflintto lint Terraform code.run_checkovto run security and compliance scanning.run_trivyto scan Terraform configuration for vulnerabilities.run_kicsto run IaC security and compliance scanning.run_infracostto estimate cloud costs.fetch_terraform_best_practicesto retrieve curated Terraform best practices.fetch_provider_best_practicesto retrieve cloud provider Terraform guidance.fetch_terraform_registry_guidanceto retrieve Terraform Registry resource and module guidance.analyze_terraform_codeto analyze code structure, modularity, and best practices.analyze_terraform_performanceto identify runtime and performance bottlenecks.analyze_state_managementto assess backend state strategy and collaboration safety.generate_cost_reportto generate cost analysis with optimization suggestions.generate_terraform_module_docsto produce module documentation from Terraform code.recommend_terraform_modulesto recommend reusable modules from detected patterns.suggest_terraform_architectureto suggest multi-environment and multi-region patterns.suggest_terraform_testing_strategyto recommend CI-driven testing by risk profile.suggest_security_hardeningto provide security hardening recommendations.generate_compliance_summaryto create compliance reports from scan outputs.
Platform Compatibility
This MCP server is platform-agnostic and works in local and CI environments:
Local development
GitHub Actions
GitLab CI/CD
Azure DevOps
CircleCI, Jenkins, and Bitbucket Pipelines
AI Agents and Copilot workflows
The primary requirements are Node.js and optionally the CLI tools on PATH. If a CLI is missing, the server returns installation guidance instead of failing silently.
Tool Matrix
Tool | Category | Typical outcome |
| CLI Analysis | Lint findings for Terraform code |
| CLI Analysis | Security and compliance scan results |
| CLI Analysis | Vulnerability scan results for IaC |
| CLI Analysis | IaC security findings |
| CLI Analysis | Monthly cost baseline for current IaC |
| Guidance | Curated best-practice checklist from terraform-best-practices.com |
| Guidance | Cloud provider (Azure/AWS/GCP) Terraform recommendations |
| Guidance | Registry guidance for providers, resources, and modules |
| Analysis | Code structure and modularity assessment |
| Analysis | Performance bottleneck and optimization report |
| Analysis | State backend strategy and collaboration safety review |
| Reporting | Cost analysis with optimization suggestions |
| Reporting | Generated module documentation markdown |
| Reporting | Reusable module recommendations from code patterns |
| Architecture | Multi-environment and multi-region architecture patterns |
| Testing | CI-driven testing strategy by risk profile |
| Security | Security hardening recommendations from scan output |
| Compliance | Compliance report from scan outputs |
Related MCP server: AWS Terraform MCP Server
Tools
run_tflint
Run tflint against a Terraform project directory.
Inputs:
path(string, optional): Terraform project path to scan. Default:..extraArgs(string[], optional): Extra CLI arguments.timeoutMs(integer, optional): Command timeout in milliseconds.
run_checkov
Run checkov over a Terraform directory.
Inputs:
path(string, optional): Terraform project path to scan. Default:..extraArgs(string[], optional): Extra CLI arguments.timeoutMs(integer, optional): Command timeout in milliseconds.
run_trivy
Run trivy config scanning against Terraform code.
Inputs:
path(string, optional): Terraform project path to scan. Default:..extraArgs(string[], optional): Extra CLI arguments.timeoutMs(integer, optional): Command timeout in milliseconds.
run_kics
Run kics IaC scanning against Terraform code.
Inputs:
path(string, optional): Terraform project path to scan. Default:..extraArgs(string[], optional): Extra CLI arguments.timeoutMs(integer, optional): Command timeout in milliseconds.
run_infracost
Run infracost breakdown for a Terraform directory.
Inputs:
path(string, optional): Terraform project path to scan. Default:..extraArgs(string[], optional): Extra CLI arguments.timeoutMs(integer, optional): Command timeout in milliseconds.
fetch_terraform_best_practices
Fetch Terraform best-practice guidance from curated checks and optional live summaries from terraform-best-practices.com.
Inputs:
topic(string, optional): Topic filter such as state, modules, security, or naming.liveFetch(boolean, optional): When true, fetches and summarises live content. Default:true.
fetch_provider_best_practices
Fetch Terraform best-practice guidance for Azure, AWS, or GCP from curated checks and optional live provider docs summaries.
Inputs:
provider(string, required): Cloud provider (azure,aws, orgcp).topic(string, optional): Focus area such as state, IAM, modules, networking, or cost.liveFetch(boolean, optional): When true, fetches and summarises the linked provider guidance page. Default:true.
fetch_terraform_registry_guidance
Fetch Terraform Registry guidance for providers, resources, and modules.
Inputs:
provider(string, optional): Provider name (e.g.aws,azurerm,google).resource(string, optional): Resource type used with provider (e.g.s3_bucket,resource_group).module(string, optional): Module path in the formnamespace/name/provider.topic(string, optional): Topic filter for the summary output.liveFetch(boolean, optional): When true, fetches and summarises selected Registry pages. Default:true.
analyze_terraform_code
Analyze Terraform code structure, modularity, and best practices.
Inputs:
code(string, required): Terraform code snippet to analyze (max 50,000 chars).focusArea(string, optional): Analysis focus area (modularity,variables,outputs,locals,general). Default:general.
analyze_terraform_performance
Analyze Terraform runtime and performance bottlenecks and optimization opportunities.
Inputs:
terraformCode(string, required): Terraform code for performance-focused heuristics.stateSizeMb(number, optional): State size in MB for scale-aware recommendations.workspaceCount(integer, optional): Number of workspaces sharing the same root stack.providerRateLimitSensitive(boolean, optional): When true, emphasise provider API throttling protections. Default:true.
analyze_state_management
Assess backend state strategy and collaboration safety.
Inputs:
terraformCode(string, required): Terraform code including backend and state-related configuration.teamSize(integer, optional): Number of engineers applying Terraform changes. Default:6.environmentCount(integer, optional): Number of environments managed by the estate. Default:2.currentBackend(string, optional): State backend in use (auto,s3,azurerm,gcs,remote,local,unknown). Default:auto.useWorkspaces(boolean, optional): Whether multiple environments are managed through workspaces. Default:false.
generate_cost_report
Generate cost analysis with optimization suggestions from Infracost output.
Inputs:
infracostJson(string, required): JSON output from infracost breakdown or diff command.includeOptimizations(boolean, optional): When true, generates cost optimization suggestions. Default:true.
generate_terraform_module_docs
Generate module documentation markdown from Terraform code.
Inputs:
terraformCode(string, required): Terraform module code to document.moduleName(string, optional): Friendly name used in generated markdown docs. Default:terraform-module.includeUsageExample(boolean, optional): Include a usage example section. Default:true.includeInputsOutputsTables(boolean, optional): Render inputs and outputs as markdown tables. Default:true.
recommend_terraform_modules
Recommend reusable Terraform modules from detected code patterns.
Inputs:
terraformCode(string, required): Terraform code used to infer module recommendations.provider(string, optional): Preferred cloud provider (aws,azure,gcp,any). Default:any.deploymentIntent(string, optional): Primary deployment goal (networking,kubernetes,serverless,storage,database,observability,security,general). Default:general.maxRecommendations(integer, optional): Maximum recommendations to return (1--10). Default:5.
suggest_terraform_architecture
Suggest architecture patterns for multi-environment and multi-region estates.
Inputs:
workloadType(string, optional): Primary workload profile (web-api,data-platform,event-driven,platform-foundation,general). Default:general.environments(string[], optional): Target environments (dev,test,stage,prod,sandbox,dr). Default:["dev", "prod"].multiRegion(boolean, optional): Whether workloads run across multiple regions. Default:false.complianceProfile(string, optional): Compliance profile (none,cis,pci-dss,hipaa,sox). Default:none.teamSize(integer, optional): Number of engineers operating Terraform code. Default:6.currentPainPoints(string, optional): Pain points or constraints in the current architecture.includeReferenceLayout(boolean, optional): Include a suggested repository and folder layout. Default:true.
suggest_terraform_testing_strategy
Recommend CI-driven Terraform testing strategy by risk profile.
Inputs:
terraformCode(string, optional): Terraform code for complexity-aware recommendations.deploymentCriticality(string, optional): Business impact level (low,medium,high,mission-critical). Default:medium.changeFrequency(string, optional): How often infrastructure changes are introduced (low,medium,high). Default:medium.ciSystem(string, optional): Target CI system (github-actions,azure-devops,gitlab,circleci,jenkins,other). Default:github-actions.includeExamplePipeline(boolean, optional): Include an example pipeline sequence. Default:true.
suggest_security_hardening
Provide security hardening recommendations from scan output.
Inputs:
scanOutput(string, required): Output from a security scanning tool (checkov, trivy, or kics).scanTool(string, optional): Name of the scanning tool (checkov,trivy,kics). Default:checkov.
generate_compliance_summary
Create compliance reports from scan outputs.
Inputs:
checkovOutput(string, optional): Output from checkov scan.trivyOutput(string, optional): Output from trivy scan.kicsOutput(string, optional): Output from kics scan.complianceFramework(string, optional): Compliance framework to assess against (cis,pci-dss,hipaa,sox,general). Default:general.
Prompt Cookbook
Use these minimal prompts in Copilot Chat with @tf-best-practices. CLI tools default to the current workspace root when no path is provided. Adding #file or #folder context can improve chat understanding, but tool execution path is controlled by explicit tool inputs (for example, path).
Quick Start (Zero-Argument Prompts)
@tf-best-practices run run_tflint
@tf-best-practices run run_checkov
@tf-best-practices run run_trivy
@tf-best-practices run run_kics
@tf-best-practices run run_infracost
@tf-best-practices run fetch_terraform_best_practicesCLI Analysis
@tf-best-practices run run_tflint with path ./modules/network
@tf-best-practices run run_checkov with path ./environments/prod
@tf-best-practices run run_trivy with path .
@tf-best-practices run run_kics with path .
@tf-best-practices run run_infracost with path .Best Practices and Guidance
@tf-best-practices run fetch_terraform_best_practices with topic modules
@tf-best-practices run fetch_provider_best_practices with provider azure
@tf-best-practices run fetch_terraform_registry_guidance with provider azurerm and resource resource_groupCode Analysis
@tf-best-practices run analyze_terraform_code with code <paste code> and focusArea modularity
@tf-best-practices run analyze_terraform_performance with terraformCode <paste code>
@tf-best-practices run analyze_state_management with terraformCode <paste code>Reporting and Recommendations
@tf-best-practices run generate_cost_report with infracostJson <paste json>
@tf-best-practices run generate_terraform_module_docs with terraformCode <paste code>
@tf-best-practices run recommend_terraform_modules with terraformCode <paste code> and provider azure
@tf-best-practices run suggest_terraform_architecture with workloadType web-api and environments ["dev","stage","prod"]
@tf-best-practices run suggest_terraform_testing_strategy with ciSystem github-actions
@tf-best-practices run suggest_security_hardening with scanOutput <paste output> and scanTool checkov
@tf-best-practices run generate_compliance_summary with complianceFramework cisDependencies
System Dependencies
Node.js
>=24.14.0npm (bundled with Node.js)
Optional CLIs available on
PATHfor command tools:tflintcheckovtrivykicsinfracost
If a CLI is missing, the server returns installation guidance instead of failing silently.
npm Dependencies
Runtime:
@modelcontextprotocol/sdk(MCP server SDK)zod(input schema validation)
Development:
typescript(build/compile)tsx(development runner)vitest(unit test runner)@types/node(Node.js typings)
Environment Variables
INFRACOST_API_KEY: Infracost API key for cloud-backed cost estimates.
Installation
npm install
npm run buildConfiguration
Usage with VS Code Copilot Chat
This workspace is preconfigured in .vscode/mcp.json:
{
"servers": {
"tf-best-practices": {
"type": "stdio",
"command": "npm",
"args": ["run", "dev"]
}
}
}Reload VS Code (Cmd+Shift+P -> Developer: Reload Window) after changing MCP configuration.
Then query the server from Copilot Chat with @tf-best-practices, for example:
@tf-best-practices run run_tflint
@tf-best-practices run fetch_terraform_best_practices with topic modulesUsage with Other MCP Clients
Use stdio transport with the built entrypoint:
{
"name": "terraform-best-practices-mcp-server",
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/terraform-best-practices-mcp/dist/index.js"]
}Build first with npm run build, then start your MCP client.
Running
npm startDevelopment mode:
npm run devDebugging
Use .vscode/launch.json:
Debug MCP Server(runsnpm run dev)Debug MCP Server (Built)(runsdist/index.jsafter build)
Set breakpoints in src/index.ts, then press F5.
Testing
See docs/TESTING.md for Copilot Chat scenarios, manual JSON-RPC checks, and troubleshooting guidance.
Quick validation prompt in Copilot Chat:
@tf-best-practices run run_tflintInteractive VS Code Workflows
1. Security Triage
Run a scan:
@tf-best-practices run run_checkovRequest hardening suggestions:
@tf-best-practices run suggest_security_hardening with scanOutput <paste checkov output> and scanTool checkovGenerate a compliance summary:
@tf-best-practices run generate_compliance_summary with checkovOutput <paste output> and complianceFramework cis2. Cost Impact Review
Generate a cost baseline:
@tf-best-practices run run_infracostProduce a cost report:
@tf-best-practices run generate_cost_report with infracostJson <paste json>3. Architecture Review
Analyse code quality:
@tf-best-practices run analyze_terraform_code with code <paste code> and focusArea modularityReview state management:
@tf-best-practices run analyze_state_management with terraformCode <paste code>Get architecture recommendations:
@tf-best-practices run suggest_terraform_architecture with workloadType web-api and multiRegion trueBest Practices
Start with CLI analysis tools to establish a baseline before using guidance tools.
Use
fetch_terraform_best_practicesto align with community conventions.Use
fetch_provider_best_practicesfor provider-specific patterns.Keep
timeoutMshigh enough for large Terraform projects.Run
suggest_terraform_testing_strategywhen onboarding new CI/CD pipelines.Use
generate_compliance_summaryregularly for audit readiness.
Additional Use Cases
Pre-merge security and compliance gates in pull requests.
Automated cost impact reviews for infrastructure changes.
Architecture pattern recommendations for greenfield projects.
Module documentation generation for shared Terraform modules.
CI-driven testing strategy definition by deployment risk profile.
Compliance evidence generation for audit trails.
Related Projects
Terraform Resources
Model Context Protocol
Community and Contributing
Attribution and License
Maintained by Carl Dawson under the Down At The Bottom Of The Mole Hole organization.
Development
npm run lint
npm test
npm run buildLicense
Licensed under the MIT License.
Available Tools
18 toolsanalyze_state_managementB
Assess Terraform backend/state strategy and recommend safer state management patterns.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terraformCode | Yes | Terraform code that includes backend and state-related configuration. | |
| teamSize | No | Number of engineers applying Terraform changes. | |
| environmentCount | No | Number of environments managed by the Terraform estate. | |
| currentBackend | No | State backend in use. Use auto to infer from code. | auto |
| useWorkspaces | No | Whether multiple environments are managed through Terraform workspaces. |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. The phrase 'assess and recommend' implies analysis without side effects, but this is not explicitly stated, leaving uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, clear sentence that conveys the core purpose without unnecessary words. It is front-loaded with the action and resource, making it easy for an agent to quickly understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 100% schema coverage, the description is too brief for a tool with 5 parameters and no output schema. It fails to set expectations about the format or detail of recommendations, and does not explain how inputs like team size or environment count influence the assessment. More context would aid effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides. For example, terms like 'backend strategy' are generic, and parameters like 'useWorkspaces' are already well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it assesses Terraform backend/state strategy and recommends safer patterns, which is a distinct purpose from sibling tools like analyze_terraform_code (code analysis) or generate_cost_report (cost analysis). The specific verb 'assess' and resource 'backend/state strategy' provide clear intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for state management issues, but it does not mention when not to use (e.g., if the goal is general code analysis, use analyze_terraform_code). Absence of exclusions or comparisons limits decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_terraform_codeB
Analyze Terraform code structure, modularity, variables, and best practices.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Terraform code snippet to analyze (max 50,000 chars). | |
| focusArea | No | Analysis focus area: modularity, variables, outputs, locals, or general. | general |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the tool is read-only, any limits (beyond the code character limit stated in the schema), or potential side effects. The description is too minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that starts with the action. It is appropriately front-loaded, though it could be more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description fails to explain return values, behavior, or processing details (e.g., whether it performs static analysis only). This is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters well-described in the schema. The tool description adds only 'best practices' as an extra focus area not listed in the schema enum, but this is a minor addition. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and resource ('Terraform code') and lists distinct aspects (structure, modularity, variables, best practices), clearly differentiating it from siblings like analyze_state_management or analyze_terraform_performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or when not to use it. The description only states what it does, without explicit usage context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_terraform_performanceC
Analyze Terraform code for performance risks and optimization opportunities.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terraformCode | Yes | Terraform code used for performance-focused heuristics. | |
| stateSizeMb | No | Optional state size in MB for scale-aware recommendations. | |
| workspaceCount | No | Optional number of workspaces sharing the same root stack. | |
| providerRateLimitSensitive | No | When true, emphasize provider API throttling protections. |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose whether the tool modifies data, requires external API calls, or has side effects. The output format is unspecified, lacking behavioral details beyond the basic action of 'analyze'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, conveying the essential purpose without extra content. Every word is necessary, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, performance domain), the description lacks specifics about the type of performance risks, optimization categories, or how parameters influence analysis. It feels incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all four parameters with clear descriptions, achieving 100% schema coverage. The description does not add additional meaning beyond the schema, such as inter-parameter relationships or examples, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Terraform code for performance risks and optimization opportunities. It specifies verb (analyze), resource (Terraform code), and domain (performance). However, it does not explicitly differentiate from sibling tools like analyze_terraform_code or fetch_terraform_best_practices, so a higher score is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no scenarios. It only states the basic functionality, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_provider_best_practicesA
Fetch Terraform best-practice guidance for Azure, AWS, or GCP from curated checks and optional live provider docs summaries.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Cloud provider to retrieve Terraform best practices for. | |
| topic | No | Optional focus area, for example state, IAM, modules, networking, or cost. | |
| liveFetch | No | When true, attempts to fetch and summarize the linked provider guidance page. |
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that guidance comes from curated checks and optionally from live provider docs, but does not explain behavior when liveFetch is false (only curated checks), potential latency, caching, or authentication requirements. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of 16 words, which is very concise. However, it lacks structure (e.g., bullet points for parameters) that could improve scanability. Efficient but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (3 params, no output schema), the description covers the main purpose and parameters. However, it omits information about the return format (list, text, etc.) or how results are presented, which would help the agent understand what to expect. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema: it explains that 'topic' is an optional focus area and that 'liveFetch' triggers live summaries. Although schema coverage is 100%, the description clarifies the behavior of liveFetch and the role of topic, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'Terraform best-practice guidance' for specific cloud providers (Azure, AWS, GCP). However, it does not explicitly distinguish itself from the sibling 'fetch_terraform_best_practices', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for provider-specific best practices but provides no explicit guidance on when to use it versus alternatives like 'fetch_terraform_registry_guidance' or when not to use it. The mention of 'curated checks' and 'optional live provider docs' hints at context but does not state clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_terraform_best_practicesB
Fetch Terraform best-practice guidance from curated checks and optional live summaries from terraform-best-practices.com.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic filter such as state, modules, security, or naming. | |
| liveFetch | No | When true, attempts to fetch and summarize live content from terraform-best-practices.com. |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses basic behavior: fetching from curated checks and attempting live summaries. However, it lacks details like whether internet access is required, rate limits, or fallback behavior if live fetch fails. The transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Fetch Terraform best-practice guidance'). It is concise with no wasted words. However, it lacks structural elements like bullet points, but for the length, it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should cover what the tool returns and any constraints. It mentions 'guidance from curated checks and optional live summaries' but does not specify the return format (e.g., list, summary text) or error handling. The completeness is adequate for a simple fetch tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the context 'curated checks' but does not provide additional meaning beyond the schema's parameter descriptions. The overall description and schema together offer sufficient semantic clarity for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Terraform best-practice guidance) and verb (fetch). It mentions curated checks and optional live summaries, providing a clear purpose. However, it does not explicitly differentiate from sibling tools like fetch_provider_best_practices or fetch_terraform_registry_guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. It mentions optional live summaries but provides no guidance on when to enable liveFetch or which topics to filter. No exclusions or conditions of use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetch_terraform_registry_guidanceB
Fetch Terraform Registry best-practice guidance with optional provider/resource/module context.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional provider name, for example aws, azurerm, or google. | |
| resource | No | Optional resource type used with provider, for example s3_bucket or resource_group. | |
| module | No | Optional module path in the form namespace/name/provider. | |
| topic | No | Optional topic filter for the summary output. | |
| liveFetch | No | When true, fetches and summarizes selected Terraform Registry pages. |
TDQS
B3.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It indicates the tool fetches guidance from the Terraform Registry (non-destructive read). The liveFetch parameter description adds some behavioral info (fetches and summarizes pages), but lacks details on side effects, rate limits, or caching. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the core purpose. Every word is functional, and there is no redundant information. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the lack of annotations and output schema. It does not explain the output format (summary? list?), how parameters interact (e.g., combining provider and resource), or what 'best-practice guidance' entails. Incomplete for a tool with 5 optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described. The description adds no extra meaning beyond restating that context is optional. Baseline of 3 is appropriate; no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch' and the resource 'Terraform Registry best-practice guidance'. It mentions optional context parameters (provider, resource, module), which distinguishes it from generic fetch tools, but it doesn't fully differentiate from siblings like fetch_provider_best_practices or fetch_terraform_best_practices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus similar sibling tools (e.g., fetch_provider_best_practices, fetch_terraform_best_practices). The description does not provide context on prerequisites or alternatives, leaving ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_compliance_summaryB
Generate a compliance summary report from multiple security scan outputs.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| checkovOutput | No | Optional output from checkov scan. | |
| trivyOutput | No | Optional output from trivy scan. | |
| kicsOutput | No | Optional output from kics scan. | |
| complianceFramework | No | Compliance framework to assess against. | general |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention side effects, required permissions, whether the operation is read-only, or what happens if no scan outputs are provided. The description is minimal and lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded. However, it could be slightly more descriptive without losing brevity, hence a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important completeness elements: it does not specify the output format, how the compliance framework is applied, whether at least one scan output is required, or any error handling. With no output schema and 4 optional parameters, more detail is needed for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter. The tool description adds no extra meaning beyond the schema, e.g., it does not explain how multiple scan outputs are combined or how the compliance framework affects the report. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a compliance summary report from multiple security scan outputs. It uses a specific verb ('Generate') and resource ('compliance summary report'), and implicitly distinguishes from sibling tools like run_checkov, run_trivy, run_kics which perform scans individually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., need to have run scans first), and no exclusions. The agent is left to infer usage from context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_cost_reportB
Generate a comprehensive cost report from infracost output with optimization suggestions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| infracostJson | Yes | JSON output from infracost breakdown or diff command. | |
| includeOptimizations | No | When true, generates cost optimization suggestions. |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the tool generates a report with optimization suggestions, lacking details on side effects, authentication, rate limits, or error behavior. The read-only nature is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently communicates the tool's purpose and scope. No wasted words, and the structure is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should elaborate on the report content (format, sections, etc.) but only says 'comprehensive cost report.' Missing details on what the report includes or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters. The description adds context ('comprehensive', 'optimization suggestions') but does not provide additional semantic meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a comprehensive cost report from infracost output with optimization suggestions. It uses a specific verb and resource, and distinguishes from siblings like run_infracost which runs the tool, not generates a report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like run_infracost or generate_compliance_summary. Does not mention prerequisites (e.g., having infracost output) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_terraform_module_docsB
Generate markdown documentation for Terraform modules from source code.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terraformCode | Yes | Terraform module code to document. | |
| moduleName | No | Friendly name used in generated markdown docs. | terraform-module |
| includeUsageExample | No | Include a usage example section. | |
| includeInputsOutputsTables | No | Render inputs and outputs as markdown tables. |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states 'generate markdown documentation' without detailing processing time, required code validity, or what happens with malformed input. The tool's behavior is underexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, though could be expanded to include more context without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should provide more context about the generated output, limitations, or dependencies. The current description is incomplete for a document generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the input schema (100% coverage). The description does not add additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates markdown documentation for Terraform modules from source code. It uses specific verb 'generate' and resource 'markdown documentation for Terraform modules', and distinctly differs from sibling tools which focus on analysis, scanning, or recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no mention of prerequisites, or scenarios where it is not appropriate. Since there are no sibling tools for documentation generation, the lack of usage guidance is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_terraform_modulesB
Recommend Terraform Registry modules based on code patterns and deployment intent.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terraformCode | Yes | Terraform code used to infer likely module recommendations. | |
| provider | No | Preferred cloud provider. | any |
| deploymentIntent | No | Primary deployment goal used to prioritize recommendations. | general |
| maxRecommendations | No | Maximum number of recommendations to return. |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks disclosure of behavioral traits. It does not specify that this is a read-only operation (likely safe), any authentication needs, rate limits, or what happens with the provided code. With no annotations, the description should have covered these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that captures the essence of the tool. It is front-loaded and avoids redundancy, making it easy to read. However, it could be slightly richer with usage hints without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description does not explain what the recommendation output looks like (e.g., list of module names, URLs, descriptions). Given the presence of siblings that return structured results, this gap reduces usability for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, each parameter is well-documented with type, constraints, and defaults. The description adds no extra meaning beyond summarizing the tool's purpose; the schema already explains how each parameter influences recommendations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends Terraform Registry modules based on code patterns and deployment intent. It uses a specific verb and resource, and it distinguishes itself from sibling tools that analyze code, run linters, or suggest architecture/security strategies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the goal is to get module recommendations from the Terraform Registry given existing code and a deployment intent. However, it does not provide explicit guidance on when not to use it or how it compares to sibling tools like 'suggest_terraform_architecture' or 'fetch_terraform_registry_guidance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_checkovC
Run checkov over a Terraform directory.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Terraform project path to scan. | . |
| extraArgs | No | Extra CLI arguments. | |
| timeoutMs | No | Optional command timeout in milliseconds. |
TDQS
C2.6/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only states 'Run checkov', which implies execution but does not indicate if the tool is read-only, what side effects occur (e.g., file modifications, network calls), required permissions, or output format. This omission severely limits an agent's ability to gauge safety and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at one sentence, but it sacrifices useful context such as the purpose of Checkov or output behavior. It is concise but not optimally informative, as it fails to elaborate on critical details that would aid tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (3 parameters, multiple sibling scanners, no output schema), the description is incomplete. It does not explain return values, success/failure signals, or how it fits with other Terraform analysis tools. The description is too minimal to fully guide an agent in using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters (path, extraArgs, timeoutMs). The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate given the schema already provides sufficient parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'checkov over a Terraform directory', which directly conveys the tool's action. However, it does not elaborate on what Checkov does or how it differs from sibling tools like tflint or trivy, leaving some ambiguity for agents unfamiliar with the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as run_tflint, run_trivy, or run_kics. It lacks any context about prerequisites, typical use cases, or scenarios where it is preferred over other security scanners.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_infracostB
Run infracost breakdown for a Terraform directory.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Terraform project path to scan. | . |
| extraArgs | No | Extra CLI arguments. | |
| timeoutMs | No | Optional command timeout in milliseconds. |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'Run infracost breakdown' without indicating side effects (e.g., network calls, file modifications), error behavior, or resource usage. The agent cannot infer whether this is a read-only or destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is concise but could be slightly expanded to include key behavioral information without losing brevity. Still, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description does not cover important aspects like return format (likely JSON), error handling, or prerequisites (infracost installation). The tool has optional parameters and no required fields, but the description does not help the agent understand what a typical invocation looks like. Sibling tools provide more context, so this one feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the description adds marginal value. The descriptions are minimal but sufficient: path indicates default value and type, extraArgs is generic, timeoutMs adds constraints. No examples or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (run), the specific tool (infracost breakdown), and the target (Terraform directory). It effectively distinguishes this tool from sibling tools like run_tflint or run_trivy, which focus on linting or security scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description does not mention that infracost must be installed or that the tool is intended for cost estimation, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_kicsB
Run kics IaC scanning against Terraform code.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Terraform project path to scan. | . |
| extraArgs | No | Extra CLI arguments. | |
| timeoutMs | No | Optional command timeout in milliseconds. |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks any behavioral details such as permissions needed, side effects, or limitations beyond 'run scan'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, but could be slightly clearer about the action's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a tool with 3 parameters and no output schema; lacks details on return values, behavior, or integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions; description adds no extra meaning beyond 'scan Terraform'. Baseline 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific tool (kics) and target (Terraform code), clearly distinguishing from sibling scanning tools like run_checkov or run_tflint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use kics over other scanners (e.g., Checkov, Trivy), nor context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_tflintC
Run tflint against a Terraform project directory.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Terraform project path to scan. | . |
| extraArgs | No | Extra CLI arguments. | |
| timeoutMs | No | Optional command timeout in milliseconds. |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Run tflint', which discloses that it executes a command, but fails to mention potential side effects, required environment (e.g., Terraform installed), output format, or error handling. This is insufficient for an agent to understand the behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It fits the purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, and the tool's nature of running an external command, the description is incomplete. It does not specify return values, error behavior, or system prerequisites, leaving significant gaps for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 3 parameters. The description adds no additional meaning beyond what's already in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run') and the specific tool ('tflint') against a 'Terraform project directory'. While it distinguishes from sibling tools by naming a specific linter, it does not explain what tflint does (e.g., static analysis), which may slightly reduce clarity for agents unfamiliar with the tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like run_checkov or run_trivy, nor does it indicate prerequisites or exclusions. It simply asserts the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_trivyB
Run trivy config scanning against Terraform code.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Terraform project path to scan. | . |
| extraArgs | No | Extra CLI arguments. | |
| timeoutMs | No | Optional command timeout in milliseconds. |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only states 'config scanning' without explaining whether it is read-only, destructive, or requires specific permissions. Safety and side effects are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no extraneous information. It is highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and 3 optional parameters, the description does not explain what results to expect, how to interpret output, or any error conditions. For a scanning tool, more context on behavior and output is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The tool description adds minimal extra meaning beyond the schema. Baseline 3 is appropriate as the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Run trivy config scanning' and the resource 'Terraform code'. It is specific and distinguishes this tool from sibling scanning tools like run_checkov or run_kics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like run_checkov or run_tflint. No when-to-use or when-not-to-use criteria are given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_security_hardeningB
Analyze security scan output and suggest hardening steps to improve infrastructure security.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| scanOutput | Yes | Output from a security scanning tool (checkov, trivy, or kics). | |
| scanTool | No | Name of the scanning tool that produced the output. | checkov |
TDQS
B3.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that the tool analyzes output and suggests steps. It fails to disclose behavioral traits such as side effects, authorization needs, output format, or limitations, leaving the agent without critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 14 words, containing no extraneous information. It is front-loaded with the main action, but could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the output format, preconditions, or examples. It fails to do so, making it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The description adds no additional meaning beyond the schema for either parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool takes security scan output and suggests hardening steps to improve infrastructure security. It specifies the verb 'analyze' and 'suggest' and the resource 'scan output', distinguishing it from sibling tools like run_checkov or analyze_terraform_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus alternatives. It implies use after running a security scanner, but lacks 'when-not' conditions or comparisons to sibling analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_terraform_architectureA
Suggest Terraform architecture and repository patterns for multi-environment infrastructure.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| workloadType | No | Primary workload profile for architecture recommendations. | general |
| environments | No | Target environments to support in the architecture. | |
| multiRegion | No | Whether workloads run across multiple regions. | |
| complianceProfile | No | Compliance profile used to tune governance recommendations. | none |
| teamSize | No | Number of engineers operating Terraform code. | |
| currentPainPoints | No | Optional pain points or constraints in the current architecture. | |
| includeReferenceLayout | No | Include a suggested repository and folder layout. |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It states the tool 'suggests', which implies a non-destructive, read-only operation, but it does not describe what the output looks like (e.g., text, structured data), whether it requires any permissions (e.g., access to Terraform configs), or any limitations like rate limits. This leaves the agent with incomplete understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. Every word is meaningful, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (7 parameters, many optional) and lack of output schema, the description is insufficiently complete. It does not explain how parameters like 'currentPainPoints' or 'includeReferenceLayout' affect the suggestion, nor does it specify the format or depth of the returned architecture recommendations. The description provides a high-level purpose but lacks sufficient detail for accurate invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context like 'multi-environment infrastructure' but does not enhance parameter meaning beyond the schema. For example, 'environments' default is clearly listed; no additional insight is provided. The description does not explain how parameters interact or influence the suggested architecture.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Suggest Terraform architecture and repository patterns for multi-environment infrastructure,' which is a specific verb ('suggest') and resource ('architecture and repository patterns'). It effectively distinguishes from sibling tools like 'analyze_state_management', 'run_tflint', or 'recommend_terraform_modules' that focus on analysis, scanning, or module recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for architecture suggestions but provides no explicit guidance on when to use this tool versus alternatives. With 17 sibling tools covering analysis, security, cost, and testing, the lack of when-not or alternative references is a noticeable gap. A user must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_terraform_testing_strategyB
Recommend Terraform testing strategy and CI stages based on risk and change cadence.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| terraformCode | No | Optional Terraform code for complexity-aware recommendations. | |
| deploymentCriticality | No | Business impact level if infrastructure changes fail. | medium |
| changeFrequency | No | How often infrastructure changes are introduced. | medium |
| ciSystem | No | Target CI system for pipeline guidance. | github-actions |
| includeExamplePipeline | No | Include an example pipeline sequence. |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the high-level recommendation, lacking details on side effects, required permissions, rate limits, or output format. This is insufficient for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the core function. It is front-loaded and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should describe the nature of the recommendation (e.g., text, structured format). It only says 'strategy and CI stages' without specifics, leaving the agent without crucial information about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description connects 'risk' and 'change cadence' to two parameters, adding minimal context beyond the schema. It does not elaborate on parameter interdependencies or usage nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: recommending Terraform testing strategies and CI stages. It specifies the basis (risk and change cadence), which differentiates it from sibling tools that focus on analysis, scanning, or best practices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when considering risk and change cadence, but it does not explicitly state when to use or avoid this tool compared to siblings. No exclusion criteria or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
18 tool updates
v1.0.0- First observed
analyze_state_management - First observed
analyze_terraform_code - First observed
analyze_terraform_performance - First observed
fetch_provider_best_practices - First observed
fetch_terraform_best_practices - First observed
fetch_terraform_registry_guidance - First observed
generate_compliance_summary - First observed
generate_cost_report - First observed
generate_terraform_module_docs - First observed
recommend_terraform_modules - First observed
run_checkov - First observed
run_infracost - First observed
run_kics - First observed
run_tflint - First observed
run_trivy - First observed
suggest_security_hardening - First observed
suggest_terraform_architecture - First observed
suggest_terraform_testing_strategy
TDQS
A3.6/5.0
Disambiguation5/5
Each tool targets a distinct aspect of Terraform best practices, such as state management, code analysis, performance, fetching guidance from different sources, generating reports, running various security scanners, and suggesting improvements. No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using present-tense verbs (analyze, fetch, generate, recommend, run, suggest) and snake_case. The naming is predictable and clearly indicates the tool's action and target.
Tool Count5/5
With 18 tools, the server covers analysis, fetching guidance, generating outputs, running external tools, and providing suggestions. This is a well-scoped set for a best-practices advisor, not too few or too many.
Completeness5/5
The tool surface covers the full workflow for Terraform best practices: analysis, fetching external guidance, running security scanners, generating documentation and reports, and providing actionable suggestions. There are no obvious gaps for its stated purpose.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Related MCP Servers
- FlicenseAqualityDmaintenanceA containerized Model Context Protocol server that enables using natural language to develop AWS infrastructure with Terraform, offering best practices guidance, security scanning with Checkov, and access to AWS provider documentation.7-
- AlicenseNot gradedqualityCmaintenanceA secure, containerized MCP server that enables AI assistants to manage Terraform infrastructure using integrated Language Server Protocol (LSP) tools. It facilitates safe operations like initialization, validation, and planning while providing context-aware code completion and documentation.10MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that exposes Terraform CLI operations as tools for Claude and other MCP-compatible AI assistants, enabling AI-driven infrastructure-as-code workflows including planning, applying, and validating Terraform configurations.32MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DownAtTheBottomOfTheMoleHole/terraform-best-practices-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server