Deep Noodle Security Review Guide

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds a meaningful behavioral directive: 'Interpret the results locally,' telling the agent that this tool returns information to act on rather than performing interpretation itself. No contradiction with annotations exists.

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?

The description is two concise sentences with no filler. It front-loads the core action and result contents, then adds the operational note to interpret results locally. Every sentence contributes useful information.

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?

For a simple read-only retrieval tool, the description plus annotations provide a viable baseline for invocation. However, the stack parameter semantics are missing and there is no output schema describing the shape of investigation steps, evidence requirements, or the prompt. An agent can call the tool but may not fully understand how to choose stack or what to do with the returned artifacts.

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%, and the description only indirectly addresses check_id via 'one published check ID.' The stack parameter is completely unexplained, including what the enum values mean, how it affects results, or why 'general' is the default. With two parameters and no schema-level descriptions, the description fails to compensate for the coverage gap.

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?

The description uses a specific verb ('Get') and names the exact resource: investigation steps, suggested tools, evidence requirements, and a prompt for one published check ID. This clearly differentiates it from siblings like get_report_kit or get_review_workflow, which operate at report or workflow scope. The title 'Work through one check' reinforces this specificity.

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 description implies use when a specific published check needs investigation details, but it never explicitly says when to use this tool versus siblings like get_report_kit, get_review_guidance, or get_review_workflow. No exclusions, alternatives, or conditions are provided. The agent is left to infer routing based on the tool name and resource scope.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, lowering the burden. The description adds useful context beyond those flags: it returns download metadata and instructions for a local HTML/Markdown builder, and it accepts no report data. Minor details like external URL behavior or rate limits are absent, but they are not critical for a zero-parameter read-only tool.

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?

The description is two sentences with no filler. It front-loads the deliverable list (URLs, hashes, format, instructions) and includes a concise warning about report data. Every sentence earns its place.

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?

Given the tool has no parameters, rich safety annotations, and no output schema, the description is complete enough. It tells the agent what will be returned and what will not be accepted, which is all an agent needs to invoke this tool correctly.

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?

The tool has zero parameters and the schema coverage is 100%, so the schema fully defines inputs. The description adds value by explicitly saying no report data is accepted, which helps an agent avoid assuming it can pass content. This matches the baseline 4 for a no-parameter tool.

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?

The description specifies a clear verb ('get') and resource: download URLs, SHA-256 hashes, report format, and instructions for a local HTML/Markdown report builder. It is distinguishable from siblings like get_check_details and get_review_guidance. The title 'Make a report on your machine' is slightly misleading because the tool does not make a report, but the description corrects this.

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 description provides clear context for when to use the tool: obtain assets and instructions for a local report builder. It also explicitly states that the tool accepts no report data, which prevents an agent from attempting to pass content. It does not name alternative tools or exclusion conditions, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds a useful constraint about not sending sensitive project artifacts, but it does not describe the output format, pagination, or other runtime behavior. With annotations present, this is adequate but not rich.

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?

The description is two short sentences: the first states the tool's purpose, and the second states the critical input constraint. There is no filler, no repetition of schema details, and the most important information is front-loaded.

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?

For a simple read-only planning tool with two optional enum-driven parameters, the description covers what the tool does, what inputs are acceptable, and what should be avoided. The lack of an output schema is not critical because 'review plan' is reasonably self-explanatory, though the exact shape of the returned plan is left to inference.

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%, so the description must carry the burden. It maps the two parameters by mentioning 'broad app features and stack' and clarifies that only the listed enum categories should be sent. However, it does not explain the meaning of individual feature values or stack options beyond their names, so it only partially compensates for the missing schema descriptions.

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?

The description clearly states the action ('Get a review plan') and the resource/scope ('broad app features and stack'), so an agent knows what the tool produces. However, it does not explicitly distinguish this from the similarly named sibling get_review_workflow or get_check_details, so sibling differentiation is weak.

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 description gives a strong input rule: send only the listed categories and never project details, code, findings, or results. This implies the tool is for high-level planning rather than detailed review, but it never explicitly names alternatives or states when another sibling tool would be more appropriate.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior, so the description rightly avoids repeating those. It adds value by listing the workflow stages and advising to keep progress and decisions in local files, which is useful context for the agent's actions. No contradiction with annotations.

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?

Two sentences with no fluff. The first sentence front-loads the core purpose (procedure for various stages), and the second adds a practical note. It is appropriately sized and structured, though it could be slightly more compact without losing detail.

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?

For a simple read-only retrieval with no parameters and no output schema, the description covers the essential content (workflow stages) and a key user directive (local files). It doesn't detail return format, but that is not critical for a 'get procedure' tool. Given the annotations and simplicity, this is adequately complete.

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?

The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, a baseline of 4 applies. The description adds no parameter-specific info but none is needed.

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?

The description clearly states the tool's purpose: it returns a procedure covering scoping, testing, evidence recording, resuming work, and retesting. This is a specific verb (get) and resource (procedure) with enumerated stages, distinguishing it from sibling tools like get_check_details (check details) or get_report_kit (report materials). It doesn't explicitly name siblings, but its scope is sufficiently specific to differentiate.

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 is given on when to use this tool versus its siblings (get_check_details, get_report_kit, get_review_guidance). The description does not mention alternatives or exclusion conditions. An agent would have to infer from the names and descriptions of other tools, which is not explicitly provided here.

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