terraform-best-practices-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 3.2/5 across 18 of 18 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![terraform-best-practices-mcp MCP server](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/terraform-best-practices-mcp/badges/card.svg)](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/terraform-best-practices-mcp)

Score Badge

Copy to your README.md:

[![terraform-best-practices-mcp MCP server](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/terraform-best-practices-mcp/badges/score.svg)](https://glama.ai/mcp/servers/DownAtTheBottomOfTheMoleHole/terraform-best-practices-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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