Lists bundled reference architectures for AWS, Azure, GCP, and other providers, letting you discover which template to load via get_template.
List bundled reference architectures (AWS, Azure, GCP) that can be loaded with get_template.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so the safety profile is covered. The description adds only the existence of bundled templates and their link to get_template; it says nothing about ordering, whether all templates are returned when no filter is given, or how the provider filter narrows results. With annotations carrying the behavioral load, a 3 fits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity comes at the cost of the provider coverage gap noted above.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations cover safety. What is missing is the provider filter's behavior and the full set of valid categories; for a simple one-parameter list tool this is adequate but leaves a real gap an agent would hit immediately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the single 'provider' parameter has no description and no separate enum field in the coverage count, so semantics rest on the schema alone. The description compensates only partially and inaccurately, naming three providers when eight are valid, so an agent could wrongly assume k8s/onprem/saas/programming/generic are unsupported or that the argument is optional-by-default with no filtering behavior explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (List) plus resource (bundled reference architectures), and it names the sibling get_template used to load one. That distinguishes it from get_template and from generation siblings. Minor deduction: the parenthetical '(AWS, Azure, GCP)' understates the actual provider set, since the schema also allows k8s, onprem, saas, programming, and generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'that can be loaded with get_template' implies a discovery-then-load workflow, which is useful routing. But there is no explicit when-to-use/when-not guidance, and no mention of what to do with the provider filter versus listing everything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.