Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations and no output schema, so the description carries the full disclosure burden, yet it only says it answers 'how to'. It does not say whether it returns code, commands, or prose, whether the operation is read-only, or what happens when an unsupported stack/noodle combination is requested.

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 short sentence with no padding, which is good, but it is a fragment that omits the details an agent needs, so brevity is partly under-specification rather than tightness.

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?

With no annotations, no output schema, and two undocumented enum parameters, one sentence is not enough. An agent cannot tell what it receives back or which noodle/stack combinations are valid.

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 description accounts for 'stack' only implicitly and says nothing about the second parameter, noodle, which has a 60-value enum with no explanation of its meaning or default. Enum values help but do not explain interaction between stack and noodle.

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?

States a specific resource (setup/install instructions) and scopes it to a stack, so an agent can tell this apart from get_component or get_example. The wording 'add MIAN to a project' is slightly narrower than the schema's noodle enum, which lists ~60 options, so the scope may mislead an agent into thinking only MIAN is supported.

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?

No guidance on when to choose this over get_site_guide, get_example, or get_noodle, and no mention of prerequisites, ordering, or what to do with the returned instructions. The 'given stack' phrasing is the only contextual hook.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.