Terragrunt MCP Server

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a distinct aspect: config generation, CLI help, error diagnosis, function reference, best practices, HCL block reference, server metrics, and documentation search. No overlapping purposes.
Naming Consistency3/5
Most tools use imperative verbs (build, diagnose, get, search), but 'cli_reference' and 'function_reference' are noun phrases without verbs, creating slight inconsistency. Still readable.
Tool Count5/5
8 tools cover a well-scoped set of Terragrunt assistance capabilities. Not too few or too many for the domain.
Completeness4/5
Covers config generation, reference for blocks/functions/CLI, error diagnosis, and best practices. Lacks actual execution tools, but given the server's apparent purpose as a knowledge assistant, gaps are minor.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 states the tool gets or lists data, implying a read-only operation, but does not disclose any other behavioral traits such as side effects, authentication needs, or performance characteristics.
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 efficiently conveys the tool's core functionality. It is well-structured and front-loaded, with no superfluous information.
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 7 parameters and no output schema, the description is brief and does not explain return values, pagination behavior, or how parameters interact. The tool is relatively complex, but the description does not compensate for the missing output schema.
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 parameter descriptions. The tool description adds no additional meaning beyond the schema, achieving baseline. It does not help further clarify parameter combinations or advanced usage.
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 it retrieves details of Terragrunt built-in functions or lists them by category, with specific examples. It distinguishes the tool's focus on functions from siblings like cli_reference or get_hcl_config_reference, though not explicitly.
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. It does not mention prerequisites, contexts, or exclude scenarios, leaving the agent to infer from sibling names.
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?
Without annotations, the description should disclose behavioral traits like idempotency, authorization needs, or data sources. It only says 'Get', implying a read operation, but does not confirm safety, confirm if it requires network access, or describe any side effects. Minimal transparency beyond purpose.
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 efficiently conveys the core functionality. It could be slightly more structured (e.g., listing examples), but it is concise and front-loads the purpose without unnecessary details.
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?
For a guidance tool with 5 parameters and no output schema, the description provides the basic purpose but lacks details on behavior, prerequisites, or return information. It is minimally complete but misses context like authentication or pagination, which would enhance understanding.
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 5 parameters. The description adds some context about the types of guidance (best practices, comparisons, patterns) but does not elaborate on parameter usage beyond what the schema provides. Baseline 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 it retrieves best practices, comparisons, and DRY patterns specific to Terragrunt infrastructure-as-code. It uses a specific verb ('Get') and resource ('guidance'), and the distinct topics help differentiate from sibling tools like 'function_reference' or 'cli_reference', though not explicitly.
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 such as 'get_hcl_config_reference' or 'search_docs'. The description lists guidance types (best-practices, comparison, pattern) but does not explain contexts where this tool is preferred 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?
With no annotations, the description fully shoulders the transparency burden. It only states the tool fetches documentation, missing details on side effects (none expected), authentication needs, rate limits, or result format.
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?
Two tight sentences: first declares purpose, second lists blocks. No superfluous words. Information is front-loaded and easy to scan.
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?
For a simple reference tool with no output schema and no annotations, the description is adequate but could improve by explaining response format or how parameters interact (e.g., listBlocks vs config). Lacks depth for a fully self-contained description.
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?
Schema coverage is 100%, but the description adds value by enumerating valid block names (remote_state, dependency, etc.) for the 'config' parameter, which the schema does not constrain. This provides helpful context beyond the schema.
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 tool as retrieving Terragrunt HCL block documentation with syntax and examples. It lists specific blocks, making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like cli_reference or search_docs.
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 when block documentation is needed, but lacks when-not-to-use or alternative suggestions.
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 lists the metrics returned but does not explain whether retrieval is expensive, if counters are reset (despite a 'reset' parameter in schema), or any side effects. The tool's behavior beyond basic retrieval is unclear.
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 of 20 words covering the key purpose and metrics. Every word adds value, and there is no extraneous information.
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 three parameters, the description is incomplete. It does not explain the output format beyond listing metrics, nor does it describe parameters like 'filter' or 'reset'. An agent would need to infer or experiment to understand behavior fully.
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 its three parameters (filter, format, reset), but the tool description adds no additional meaning. It does not connect the listed metrics to the 'filter' parameter or explain the 'reset' behavior. Baseline is 3 due to high schema 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?
The description clearly states the tool's purpose: retrieving Terragrunt MCP server metrics including cache hit rates, invocation counts, response times, and memory usage for observability. It distinguishes itself from sibling tools like build_config or diagnose_terragrunt_error by focusing on server performance data.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or scenarios to avoid. The phrase 'for observability' implies context but lacks actionable direction.
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 exist, so description must bear full burden. It describes modes but does not disclose behavioral traits like error behavior, rate limits, authentication needs, or what happens on empty results.
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?
Single sentence with a list of modes. No unnecessary words or repetition. Efficiently front-loads the purpose.
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 10 parameters and no output schema, description adequately covers modes but lacks guidance on how parameters interact (e.g., which parameters are needed for each mode). Could be more complete but is not severely lacking.
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 description needs to add minimal value. The description adds mode names but does not clarify parameter dependencies per mode (e.g., which parameters are required for each mode). 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?
Description clearly states the tool searches Terragrunt documentation for HCL blocks, CLI commands, functions, and IaC patterns, listing specific modes. It distinguishes from sibling tools like cli_reference or function_reference by its general scope.
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?
Description implies usage through mode listing but does not explicitly state when to use this tool versus more specific sibling tools (e.g., cli_reference). No when-not-to-use or alternative guidance is provided.
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 the full burden. It mentions 'root cause analysis and solutions' but does not disclose whether the tool is read-only, requires authentication, or any side effects. For a diagnostic tool, more behavioral context (e.g., does it modify state?) is needed.
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?
Two sentences, front-loaded with purpose and scope. No redundant words. Efficient and easy to scan.
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?
With 12 parameters and no output schema, the description lacks information about return format, how to interpret confidence or maxMatches, and how parameters are used in analysis. It is incomplete for effective use without reference to external documentation.
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% (all 12 parameters have descriptions), so baseline is 3. The tool description does not add extra meaning beyond the schema's minimal parameter labels (e.g., 'Error message'). It provides no additional guidance on how parameters affect diagnosis.
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 that the tool diagnoses Terragrunt and Terraform errors with root cause analysis and solutions, listing specific error types (dependency cycles, state lock errors, etc.). This distinguishes it from sibling tools like 'cli_reference' or 'search_docs', which are not diagnostic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists specific error types handled (dependency cycles, state lock errors, provider issues, HCL syntax problems), giving clear context for when to use the tool. However, it does not explicitly state when not to use it or compare to siblings, so a perfect score is not warranted.
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 full burden. It mentions 'Generate or write' and includes write/overwrite/backup parameters, suggesting side effects, but does not explicitly state that files may be created or overwritten, nor does it describe permissions or destructive 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 very concise: two sentences clearly stating the purpose and use cases. Every word is necessary and front-loaded.
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 11 parameters, no required ones, and no output schema, the description is brief but covers the tool's intent. Lacks details on how parameters interact or expected output, but adequate for a 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?
Schema coverage is 100%, and the description lists use cases which clarify the enum parameters. However, it does not provide additional meaning beyond the schema's parameter descriptions (e.g., 'Template variables' remains vague). 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 specifies 'Generate or write Terragrunt HCL configuration files' with explicit use cases (remote_state, provider_generation, etc.). This clearly distinguishes it from sibling tools like cli_reference or search_docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates specific use cases (remote_state backends, provider generation, etc.), providing clear context for when to use the tool. However, it does not explicitly state when not to use it or suggest alternatives.
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 given, so the description must convey behavioral traits. It states the tool retrieves help/listings, which implies a read-only operation, but does not explicitly confirm idempotency, rate limits, or response type. Pagination behavior is implicit via parameters but not described.
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 clear sentence, front-loaded with the verb 'Get', and includes an alternative use case ('or list commands by category'). No unnecessary words or redundancy.
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 5 optional parameters, no output schema, and no annotations, the description is minimally complete. It explains what the tool does but does not describe the output format, error behavior, or constraints. For a simple reference tool, this may suffice, but additional context would improve completeness.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value by providing concrete examples of commands (run-all, plan) and clarifying that category is for listing, which enriches understanding beyond the schema descriptions.
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 specific verbs 'Get' and 'list', names the resource 'Terragrunt CLI command help', and provides examples of commands (run-all, plan, apply). It also distinguishes from siblings like function_reference or get_hcl_config_reference, which are different types of references.
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 obtaining CLI command help or listing commands by category, but does not explicitly state when to prefer this tool over siblings (e.g., function_reference for HCL functions). No exclusions or alternatives are provided.
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:

[![terragrunt-mcp-server MCP server](https://glama.ai/mcp/servers/omattsson/terragrunt-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/omattsson/terragrunt-mcp-server)

Score Badge

Copy to your README.md:

[![terragrunt-mcp-server MCP server](https://glama.ai/mcp/servers/omattsson/terragrunt-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/omattsson/terragrunt-mcp-server)

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/omattsson/terragrunt-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server