Facets Module MCP Server
Server Quality Checklist
Latest release: v0.1.21
- Disambiguation3/5
Some tools have overlapping purposes (e.g., edit_file_block and write_resource_file both modify .tf files, though with different safety guarantees; also deployment tools mix with module creation tools), but most tools have distinct descriptions that help differentiate.
Naming Consistency2/5Names are mostly snake_case but vary widely in verb choice (add, discover, edit, FIRST_STEP, fork, generate, get, list, mark, push, read, register, search, test, validate, write) and include unusual prefixes like 'FIRST_STEP_', breaking consistency.
Tool Count2/5With 30 tools, the server is overstuffed for a module-centric domain, mixing module creation, deployment testing, and output type management into one surface; a leaner set would be more coherent.
Completeness3/5Covers module lifecycle (create, fork, validate, preview, publish, test) and related intents/output types, but lacks delete/remove operations and some update capabilities, leaving notable gaps.
Average 4/5 across 30 of 30 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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.jsonto 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 must disclose behavioral traits. It only states 'Get logs' without mentioning read-only nature, authentication requirements, rate limits, or potential 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes an Args and Returns section which is structured but could be more concise. It is not overly verbose but could be tightened to a single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough given the two simple parameters and presence of an output schema. However, it does not cover potential errors, permissions, or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args section adds crucial meaning: 'cluster_id' is the environment ID and 'release_trace_id' is the deployment's release trace ID, beyond the schema's minimal labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves logs for a deployment, distinguishing it from sibling tools like check_deployment_status which checks status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as check_deployment_status. The description does not mention any prerequisites 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 must carry the full burden of behavioral disclosure. It only states that it finds and returns data, but does not mention permissions, side effects (e.g., read-only), pagination, or any other behavioral traits beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a concise docstring format with three sentences: a purpose statement, an Args section, and a Returns section. No extraneous text, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic functionality, parameter, and return type. Lacks context on how it relates to sibling tools (e.g., when to use this vs 'list_all_output_types') and potential limitations (e.g., case sensitivity, error handling).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no description for the 'provider_source' parameter. The description compensates by explaining it as 'The provider source name to search for', adding clear meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states that it finds all output types including a specific provider source and that they can be used as inputs for module configurations. However, it does not differentiate from sibling tools like 'list_all_output_types' or 'get_output_type_details', which may 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 Guidelines2/5Does 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 such as 'list_all_output_types' or 'get_output_type_details'. The description omits context about when this tool is appropriate or when to avoid it.
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 carries full burden. It discloses the steps (check project existence, verify preview support, terraform apply) and return type (JSON string). However, it omits side effects (e.g., resource changes), permissions required, and failure modes. It adds some value but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with clear sections: purpose, mechanism, args, returns. There is some redundancy (first sentence repeats project_name from Args) and extra detail about monitoring tools, but overall it is front-loaded and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (deployment with checks) and lack of output schema details (only JSON string), the description adequately covers the workflow but misses prerequisites, error handling, and detailed return structure. It is moderately complete but has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. The Args section provides brief explanations for each parameter (e.g., environment_name is optional and should only be provided if user asks). This adds meaning beyond the schema but is minimal. No enums, examples, or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tests a module that has been previewed by deploying to a project. The verb 'test' and resource 'module' are specific. However, the phrase 'by asking the user for the project_name' is ambiguous since the parameter is provided as input, not by asking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 sibling tools like validate_module or push_preview_module. The description only mentions post-use monitoring tools (get_deployment_logs, check_deployment_status) without clarifying preconditions 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, so the description carries the full burden. It mentions the working directory constraint and returns JSON, but does not disclose potential side effects, authentication needs, or rate limits. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The important prerequisite is highlighted with HTML tags. The Args and Returns sections are structured but not overly verbose. Could be slightly tighter by removing redundant formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an existing output schema, the description covers the core behavior, prerequisite, and return format. It does not need to explain return values in depth due to the output schema. Sibling tool relationships are not mentioned, but the core context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for file_path (0% coverage), so the description's Args section adds minimal value: 'The path to the file.' This restates the property name and type without deeper meaning, failing to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reads' and the resource 'content of a file', with a useful constraint 'within the working directory'. While it doesn't explicitly differentiate from sibling tools like list_files or edit_file_block, the verb 'read' is sufficiently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes a prerequisite: 'Make Sure you have Called FIRST_STEP_get_instructions first'. This provides a clear when-to-use instruction. However, it does not mention alternatives or when not to use the tool.
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 explains the wait mechanism, timeout, and poll interval. However, it does not disclose if the tool is read-only or has side effects, nor does it mention authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear header, parameter list, and return statement. It is concise yet comprehensive, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status-check tool, the description covers inputs, behavior, and output format. It lacks error handling details and explicit safety info, but given the output schema exists, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains all five parameters with their roles, defaults, and semantics (e.g., wait, timeout, poll). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks deployment status. It lists parameters but does not distinguish it from the sibling 'get_deployment_logs', which could also relate to monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_deployment_logs. No explicit when-to-use or when-not-to-use 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?
With no annotations provided, the description must fully disclose behavioral traits. It fails to mention critical details like whether existing README.md is overwritten, directory creation behavior, or required permissions (e.g., write access). The return format is noted but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear sentences. The Arg block is structured but could be integrated more naturally. No extraneous words, and the main purpose is stated upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write operation, the description covers the basic action and parameters. However, it lacks context on key behaviors like file overwriting, error conditions, and whether directory creation is handled. With an output schema present, return value explanation is less critical, but behavioral gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the Arg block adds value by briefly describing each parameter. However, the descriptions are minimal and do not specify format constraints (e.g., absolute vs relative path, markdown expectations for content).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Writes' and the resource 'README.md file for the module directory'. It distinguishes from sibling tools like write_generic_file or write_config_files by specifying the target file type and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating README content for modules but does not explicitly state when to use this tool versus other write tools (e.g., write_generic_file). No alternatives or exclusions are mentioned, leaving the agent to infer the context.
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 must carry the burden. It discloses the output format (JSON string) and a safety constraint (staying within working directory), but does not clarify permissions, error handling, or whether the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear main statement, followed by an instruction and then Args/Returns sections. Every part serves a purpose, though the instruction could be placed elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, an output schema exists), the description adequately covers the purpose, parameter specification, and return format. It is sufficient for an LLM to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides a title for module_path, while the description specifies it expects an absolute path and explains it refers to the module directory, adding meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all files in a given module path while ensuring the scope stays within the working directory. This distinguishes it from sibling tools like read_file or edit_file_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an instruction to ask the user about variables or other FTF commands, but it provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
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, placing the full burden on the description. The description states it returns a JSON string but does not explicitly state that the operation is read-only, idempotent, or side-effect-free. It lacks disclosure of auth requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, and no unnecessary words. It is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately covers what the tool does and returns. No additional detail is needed for a simple list retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so baseline is 4. The description adds meaning by stating the output is a JSON string with a success message and list of test projects, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves and returns names of all available test projects. It uses a specific verb ('Retrieve and return') and resource ('test projects'), and it is distinguishable from sibling tools which focus on deployments, modules, and files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description does not mention prerequisites, exclusions, or context for when listing test projects is appropriate.
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, yet the description does not disclose whether the tool is read-only or has side effects. It only describes the search action and return format, leaving safety profile unclear. For a search tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear structure: main action, usage guidelines, then Args/Returns. No extraneous content. The Args/Returns section could be integrated, but it is functional and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with pagination, the description covers purpose, usage, and basic parameters. However, it does not explain how the search string matches (full text? field-specific?), default page behavior, or the 'instructions' field in the return. Output schema exists but is not fully utilized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add substantial meaning. It provides only minimal context ('in modules' for search_string, 'for pagination' for page) that barely extends beyond the schema titles and types. Parameters are not fully compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'Search' and resource 'facets.yaml files to filter modules', clearly conveying the tool's function. The name and description together distinguish it from siblings by emphasizing it is for confirmed searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states this tool should only be used after confirming search intent and instructs to explain search capabilities for exploratory searches, providing clear when-to-use and when-not-to-use 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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'writes' without specifying whether it overwrites, appends, or creates the file. It does not mention any preconditions (e.g., module_path must exist), permissions needed, or side effects. The return format is mentioned but not the actual 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose in first sentence, exclusion in second, then parameter list and return type. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) and the description mentions the return format. With no annotations, the description should provide more behavioral details (e.g., overwriting behavior) to be complete for an agent. While it covers basic usage, gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides a brief Args section clarifying each parameter (module_path, file_name, content). However, it lacks constraints, examples, or valid formats. This adds some value but is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it writes Terraform resource files (main.tf, variables.tf, etc.) to a module directory. It explicitly excludes outputs.tf and directs to write_outputs(), distinguishing itself from that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: does not write outputs.tf, and directs users to use write_outputs() for that purpose. This helps avoid misuse. However, it does not clarify when to use this tool over other file-writing siblings like write_config_files or write_generic_file.
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?
Annotations are absent, so the description must carry full burden. It mentions the need for facets.yaml and the output format but does not disclose whether the tool overwrites an existing outputs.tf file or if it has any destructive behavior. Some behavioral traits are described, but key aspects are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Example, and Returns sections, front-loading the purpose. It is reasonably concise, though some phrasing could be tighter. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, simple output), the description covers parameters and gives a return type. However, it omits critical context like whether the file is created or overwritten, and error handling details are sparse. An output schema exists but is not leveraged to reduce description burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: it explains each parameter (module_path must contain facets.yaml, output_attributes and output_interfaces are maps with value and sensitive keys) and provides a concrete example. This compensates well beyond the schema's minimal type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states 'Write the outputs.tf file for a module with properly formatted Terraform locals block.' It uses a specific verb (write) and resource (outputs.tf), clearly distinguishing from sibling tools like write_config_files or write_resource_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example and lists parameters but does not explicitly state when to use this tool versus alternatives like write_resource_file or write_config_files. No exclusions or contextual guidance are given.
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?
The description discloses that the tool fails on forbidden files and checks the working directory, and it describes the return format. However, it lacks details on overwrite behavior, permissions, or side effects. Given no annotations, the description covers some behavioral aspects but has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 80 words) and well-structured, with a clear opening sentence, usage notes, parameter list, and return description. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, exceptions, failure case, and return format. However, it omits details on existing file behavior and required permissions. Given the tool's simplicity and the presence of an output schema, it is fairly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description's 'Args' section merely repeats parameter names and types without adding constraints, examples, or format details. It does not compensate for the missing schema descriptions, as it only mirrors the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a generic file to the module directory, with explicit exceptions for .tf files, facets.yaml, or README.md. It also specifies that it can be used for supporting files like Python or Bash scripts, distinguishing it from sibling write tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for supporting files) and what files are forbidden (e.g., .tf, facets.yaml, README.md), implying that other tools should be used for those. However, it does not explicitly name alternative tools like write_resource_file or write_readme_file.
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 the full burden of behavioral disclosure. It states the action (add import declaration) and return type (JSON response), but does not disclose potential side effects, permissions required, or error conditions. This is adequate but not rich; it leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence core purpose, usage precondition, conditional rules, parameter list, and return type. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation, output schema present), the description covers purpose, preconditions, all parameters, and return type. It lacks details about error handling and file implications, but the output schema likely fills some gaps. Overall, it is sufficiently complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It provides brief explanations for all 7 parameters in the 'Args' section, including examples for index and key. However, distinctions like resource vs resource_address are not fully clarified, leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Add import declaration to facets.yaml.' It also distinguishes itself from siblings by referencing a specific predecessor tool (discover_terraform_resources), which is listed as a sibling, making the tool's purpose and context unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use after discovering resources with discover_terraform_resources.' It also provides conditional guidance for parameters (index for count, key for for_each). However, it does not explicitly mention when not to use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses recursive directory scanning, file reading, and return format. No annotations, but description covers behavior well, though omits side-effect status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Information is front-loaded but includes a bold instruction that may confuse (references another tool). Some verbosity in 'Returns' section could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and a described return format, the tool is adequately documented. No major gaps are evident for its use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, schema coverage 100%. Description adds no parameter-specific info beyond tool purpose; baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans for facets.yaml files to list Terraform modules and fetches outputs.tf content. Differentiates from siblings like list_modules_for_fork.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call FIRST_STEP_get_instructions first, implying a usage order. Does not fully distinguish from alternative module-listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes irreversible action and safety steps (dry_run, user confirmation). Without annotations, this provides necessary behavioral context beyond just writing a file. Lacks details on file overwrite behavior or authentication, but sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately structured with a warning and steps, but could be tighter. The caution about 'Make sure you have Called...' and the step list add value but are verbose. Not exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers prerequisites, safety workflow, and return types (success, diff, error). Missing details on file overwrite behavior, but overall complete for a config file tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description lists all three parameters (module_path, facets_yaml, dry_run) with brief explanations. 'dry_run' explanation (preview vs. apply) is helpful, but module_path and facets_yaml lack format or constraint details. Baseline compensation is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it writes a specific file: 'facets.yaml configuration file for a Terraform module.' Uses specific verb and resource, differentiating it from siblings like write_generic_file which lack specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly calls out prerequisite to call FIRST_STEP_get_instructions first and provides a step-by-step workflow for safe usage (dry_run then confirmation). However, it does not explicitly exclude alternatives or describe when not to use this tool.
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 exist, so the description carries full weight. It discloses the API call and return format (JSON with status, message, instructions, details or error). However, it lacks safety indications (read-only), authentication needs, or rate limits. The error handling is generically 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear intro, API endpoint mention, args, and returns. It is concise (under 100 words) with no filler; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers purpose, param format, and return structure. It also mentions error handling. However, it could explicitly state that the operation is safe/read-only and provide more detail on the return fields, given the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial context for the single parameter: the required format '@namespace/name'. This compensates for the missing schema description and provides actionable guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details for a specific output type, mentions the API endpoint, and specifies the retrieved information (properties and providers). This distinguishes it from sibling tools like list_all_output_types or find_output_types_with_provider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing detailed info on one output type but does not explicitly contrast with siblings like find_output_types_with_provider or list_all_output_types. No when-not 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool can create or update, implying upsert behavior. It also states the return value is a JSON response with success/failure. Since no annotations are present, the description carries the full burden; it covers the basic behavior but could mention idempotency or conflict resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. Every sentence is informative, with no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and low schema coverage, the description covers all parameters and the return format. It is mostly complete, though additional details about update behavior or error conditions would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for icon_url by noting it is optional and should only be sent when explicitly provided. For other parameters, it provides minimal explanations that mostly restate the property names, offering little additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates an intent, specifying the resource and action. It distinguishes from siblings like get_intent and list_all_intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage guideline for icon_url, stating it should never be sent unless explicitly provided. However, it lacks explicit guidance on when to use this tool versus alternatives like get_intent or list_all_intents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses return behavior (details if found, not found status) and input. It adds context beyond the schema, though it does not mention permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with docstring sections for args and returns; front-loaded, no wasted words, and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, read operation, output schema exists), the description is largely complete. It could mention idempotency or read-only nature, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the parameter description 'The name of the intent to query' adds meaningful context. While minimal, it adequately explains the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'intent', specifying the action of checking existence by name. It distinguishes from siblings like 'list_all_intents' and 'create_or_update_intent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking existence before creating/updating but does not explicitly state when to use vs alternatives or provide exclusions.
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 provided, the description carries the full burden of disclosure. It explains that the tool pushes a test version, auto-extracts git details, and includes a validation step that may require skipping. However, it does not detail potential side effects (e.g., overwrite of existing previews) or authentication requirements, which would be beneficial for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, with a clear front-loaded purpose. The Args section is structured and each sentence serves a distinct purpose: purpose, git details, parameter explanations, and return value. No unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, no annotations) and the presence of an output schema (returning JSON string), the description adequately covers the core functionality. It omits prerequisites like FTF CLI installation or required permissions, but these are implicit in a CLI-based tool. The description is sufficient for an agent to use the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. For 'module_path', it simply restates 'The path to the module', which adds little over the schema title. However, for 'skip_terraform_validation_if_provider_not_found', it provides a clear usage condition ('send as true only if you see...'), significantly adding value beyond the schema. Overall, the description partially compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to preview a module using the FTF CLI and push a test version to the control plane. It also mentions automatic extraction of git details, which distinguishes it from sibling tools like 'validate_module' or 'generate_module_with_user_confirmation' that handle different aspects of module management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific usage condition for the boolean parameter, advising to set it to true only when a 'Provider configuration not present' error occurs during validation. However, it does not explicitly state when to choose this tool over alternatives like 'validate_module' or 'test_already_previewed_module', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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 discloses that the tool performs a read-only validation, checks multiple criteria, and returns a JSON string. This is sufficient for the agent to understand safety and outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet comprehensive, using a clear structure: a one-line summary, a paragraph explaining behavior, and bullet-pointed arguments and return. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema, the description covers purpose, parameters, and return value adequately. It could be more complete by mentioning performance or error conditions, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's docstring explains each parameter's purpose (module_path, check_only, skip_terraform_validation_if_provider_not_found). This adds significant meaning beyond the schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a module directory using FTF CLI, specifying what it checks (structure, formatting, required files, output types). This is specific and distinguishes it from sibling tools like discover_terraform_resources or fork_existing_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when validation of module standards is needed, but it does not explicitly state when not to use it or mention alternatives. There is no clear guidance contrasting it with sibling tools.
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 provided, the description should cover behavioral traits. It describes the return format and mentions it is a discovery operation, but does not explicitly state if it is read-only or if it has side effects. It is moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences and a structured Args section. Every sentence adds value, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and an output schema referenced in the description, the description fully explains what the tool does, what it returns, and when to use it. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides a clear explanation for the only parameter 'module_path': 'Path to the module directory containing Terraform files.' This adds value beyond the schema's title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover all Terraform resources in a module directory.' It also specifies the use case: 'Use this first to see what resources are available for import.' This differentiates it from sibling tools that handle import, writing, or deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool first in the import workflow, providing a clear context of use. It does not explicitly mention alternatives or when not to use, but the guidance is strong.
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 weight. It states the return type (JSON string) and that it lists intents, but does not disclose that it is a read-only, safe operation. For a simple list tool, this is adequate but lacks explicit safety or side-effect disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and a return doc, with no wasted words. It is front-loaded with the core purpose and immediately useful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description covers all necessary context: what it does and what it returns. No gaps remain for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not add parameter details. According to guidelines, baseline for 0 params is 4, which is appropriate as the description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available intents in the control plane, using a specific verb ('list') and resource ('intents'). Among siblings like 'get_intent' (single) and 'create_or_update_intent' (mutate), it distinguishes itself as the broad listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is useful for discovering existing intent types and names, giving clear context. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses irreversibility, requires user confirmation, and details the dry-run safety pattern. However, no annotations are provided, and the description could mention error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear steps, important warnings front-loaded, and emoji emphasis. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core workflow and safety aspects for an irreversible action. Mentions output schema exists. Minor gap: no discussion of error scenarios or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose and default values, including key details like 'dry_run' behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Fork an existing module') and clearly distinguishes this tool from siblings like 'list_modules_for_fork' and 'search_modules_after_confirmation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a detailed step-by-step workflow with dry-run emphasis and user confirmation, but does not explicitly state when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description effectively conveys the irreversible action and the mandatory user confirmation via dry_run. It explains the dry_run behavior but lacks details on side effects or what exactly happens during generation (e.g., file creation, overwriting).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a warning, numbered steps, and bullet points for arguments. It is slightly verbose but every sentence adds value, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, irreversible action, output schema), the description covers the workflow, parameter meanings, and return type. It could mention the output schema explicitly, but the description of return as JSON string is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage. It explains each parameter (intent, flavor, cloud, title, description, dry_run, working_dir) and explicitly instructs the critical use of dry_run, compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a new module using the FTF CLI, with a specific multi-step process. It distinguishes from siblings like 'fork_existing_module' and 'validate_module' by emphasizing the generation and confirmation workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit step-by-step instructions for using dry_run first, presenting output to the user, and finalizing without dry_run. It highlights the irreversible nature but does not explicitly state when not to use the tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the tool returns 'basic module information in a simple format' and specifies the return type as a 'JSON formatted list'. This discloses the read-only nature and format, though it could mention if any side effects exist (none implied).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences and a 'Returns' block. Every sentence adds value: the first states the action and scope, the second describes the output. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and an output schema exists (even if not shown), the description sufficiently covers what the tool does and returns. It is complete for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema provides no additional info beyond the empty object. The description adds meaning by specifying the source ('control plane') and the constraint ('can be forked'), which is valuable context not derivable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource 'available modules from the control plane that can be forked'. This distinguishes it from siblings like 'fork_existing_module' (which performs the fork) and 'get_local_modules' (which lists local modules).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. While the purpose is clear, there is no guidance on prerequisites, exclusions, or references to sibling tools like 'fork_existing_module' which likely depend on this tool.
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 must convey behavior. It implies mutation ('publish') and mentions output is JSON string. However, it lacks details on side effects, permissions, or reversibility. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: two sentences for purpose, a note, and an args list. Every part adds value; no fluff. Well-structured with clear sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameters. Could mention that publishing is a write operation and may have consequences. But given the output schema exists and tool is simple, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's 'Args:' section explains both parameters: module_path (path) and the boolean flag with specific usage condition. This adds significant meaning beyond the schema's titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Publish a production-ready module version.' This distinguishes it from siblings like push_preview_module_to_facets_cp (testing) and validate_module.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to test using push_preview_module_to_facets_cp before publishing, and provides condition for the skip_terraform_validation parameter (only if 'Provider configuration not present' error).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is fully transparent for a read-only list operation with no parameters. It explicitly states the action and return type. No annotations are provided, but the description carries the burden adequately, revealing no side effects or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences that state purpose and return value. No extraneous words, front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description is complete. It specifies the return type and behavior for a simple list operation. No additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so schema coverage is 100% vacuously. The description adds no parameter details, but baseline for zero parameters is 4. No need for further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all output types from the Facets control plane,' using a specific verb and resource. It distinguishes itself from siblings like 'find_output_types_with_provider' and 'get_output_type_details' by indicating it lists all types without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 such as 'find_output_types_with_provider' or 'get_output_type_details'. The description implies usage through purpose but lacks when-not or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the check-then-act behavior, the need for override_confirmation, and the return format. It also includes an example and a note on incorrect usage, adding valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-paragraph but well-organized: purpose, logic, parameter docs, example, correction note, return. Every section adds value. It is appropriately sized for the tool's complexity, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (mentioned in description), the description adequately explains return values. It covers all parameters, behavioral flow, and edge cases. The tool is complex, and the description fully captures needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides detailed parameter documentation: name format, interfaces/attributes as JSON schema with an example and correction note, providers structure, and override_confirmation purpose. This far exceeds the schema's minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: registering a new output type in the Facets control plane. It explains the conditional logic (checking existence, comparing properties), distinguishing it from sibling read-only tools like list_all_output_types and get_output_type_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the registration process and when an update may occur with confirmation. It does not explicitly mention alternatives or when not to use this tool, but the context of siblings provides some guidance. The usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool reads instruction files and returns a JSON string. While no annotations are provided, the description adequately conveys it is a read-only operation. However, it does not explicitly state non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one critical directive followed by a clear statement of purpose and return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (JSON string with file contents). With an output schema present, this is sufficient context for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter meaning, so baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it loads all module writing instructions, with the name emphasizing it's the first step. It clearly differentiates from sibling tools as the mandatory initial call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes the directive 'ALWAYS Call this tool first before calling any other tool of this mcp.' This provides explicit usage guidance and no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully carries burden by explaining find/replace behavior, safety aspects, default expected_replacements, and JSON return format with success/error details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with initial summary, important prerequisite callout, behavioral description, restrictions in list, best practices, and formatted Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, zero schema descriptions, and 4 parameters, the description covers purpose, usage, constraints, parameters, and return format sufficiently for an editing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds comprehensive meaning for each parameter: file_path includes directory constraint, old_string includes uniqueness advice, new_string is clear, expected_replacements explains default and safety purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies surgical edits to text blocks in files and distinguishes from alternatives like write_outputs and write_config_files by listing restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites (call FIRST_STEP_get_instructions first), when not to use (cannot edit outputs.tf or facets.yaml), and alternatives (use write_outputs or write_config_files). Also includes best practices for usage.
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:
Score Badge
Copy to your README.md:
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/Facets-cloud/facets-module-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server