Model Context Protocol server especializado em Terragrunt 0.82.3 para análise de projetos e insights de infraestrutura
The server defines 8 tools with complete input schemas and descriptions in Portuguese. Tool names use verb_noun patterns (analyze_project, validate_config, get_dependencies) which follow conventions. However, descriptions lack critical metadata: none specify whether operations are read-only or have side effects (critical for agent planning), output schemas are not documented anywhere in the code, and error handling guidance is absent. All tools are READ_ONLY per risk assessment, but this is not communicated in descriptions. Parameters have types and descriptions, but lack granular constraints (enums, min/max ranges). The schema quality is moderate, all 8 tools expose complete input schemas with required fields and type definitions, but response structures are nowhere visible in the code. Missing are: output schema documentation, per-tool error recovery guidance, confirmation patterns for destructive operations (though all are read-only, this is good), and composition guidance showing how tools chain together.
Análise completa de um projeto Terragrunt, incluindo estrutura, configurações e dependências
Analisa a estrutura de stacks Terragrunt e identifica problemas
Detecta problemas comuns em projetos Terragrunt
Identifica módulos Terragrunt não utilizados ou órfãos
Mapeia e analisa dependências entre módulos Terragrunt
Coleta métricas detalhadas do projeto Terragrunt
Sugere otimizações para melhorar performance e manutenibilidade
No output schemas documented. The code shows input schemas for all 8 tools but zero response structure definitions. LLMs cannot predict what fields to extract, forcing them to parse unstructured text or make assumptions about response format.
Descriptions lack actionable context. Tool descriptions state WHAT (e.g., 'Mapeia e analisa dependências') but not WHEN to use or error recovery guidance. For example, get_dependencies doesn't explain: What if the path is invalid? What does each outputFormat return? When should I prefer 'graph' vs 'tree'?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Valida arquivos de configuração Terragrunt (terragrunt.hcl, terragrunt.stack.hcl)
Parameter 'categories' in suggest_optimizations has enum constraint in schema but no description explaining what each category reveals. Enum values like 'performance', 'structure', 'security', 'maintenance' are undefined, the LLM cannot reason about which to request without hints.
Parameter 'severity' in detect_issues uses enum constraint but lacks description explaining levels. What's the difference between 'error', 'warning', and 'info' in Terragrunt context? Should an agent request 'all' by default or filter?
No error handling guidance in tool definitions. If validate_config receives an invalid file path, what does the tool return? Can the agent retry? Must it ask the user? This forces agents to guess recovery strategies.
Tool names use Portuguese descriptions but English operation names (get_dependencies vs 'obtém dependências'). This inconsistency may confuse multilingual LLMs about which language to reason in.
Parameter descriptions do not specify formats or constraints. 'projectPath' and 'configPath' lack guidance: absolute vs. relative paths? Must the path exist? What if it's a symlink or on a different filesystem? Validation errors will not be actionable.