Security Recipes

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

No annotations exist, so the description carries the full burden. It only states output components ('intake profiles, trust controls, sample decisions') without disclosing whether the operation mutates anything, fetches from storage, or how the three outputs interrelate. Minimal behavioral disclosure.

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 a single compact sentence with no waste, but it achieves brevity through under-specification rather than sharp editing. The resource list is front-loaded but the sentence lacks actionable substance.

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?

Although an output schema exists, the tool has three parameters at 0% schema coverage and zero annotations. The description is too thin to support correct invocation—how params map to outputs and how to combine them is entirely unspecified.

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 coverage is 0%, and the description never mentions the three parameters (decision, risk_tier, profile_id). The names are inferable and map loosely to the output components, but there is no explicit guidance on how params select or filter results, leaving the agent to guess.

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 ('A2A Agent Card intake profiles, trust controls, and sample decisions') which distinguishes it from sibling recipe packs, but the verb 'Return' is vague about mechanism—fetch, generate, or list. Given ~80 closely named siblings, the purpose is only mildly differentiated.

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 use this tool vs the many sibling recipes (e.g., recipes_get, recipes_list, recipes_agent_trust_fabric_pack). No conditions, exclusions, or alternative suggestions provided. With dozens of similar 'recipes_*' tools, the agent gets no routing help.

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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Return ... scores.' It does not state whether the operation is read-only, whether it computes or retrieves scores, whether filters are required, or how the residual risk scoring behaves.

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 one short sentence with no filler and the main action is front-loaded. However, it is under-specified for a tool with four optional parameters and no other context, so conciseness is achieved at the expense of usefulness.

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?

Because an output schema exists, the description does not need to explain return values, but it still lacks parameter semantics, usage guidance, and sibling differentiation. An agent cannot reliably determine what inputs to provide or what makes this tool different from the many adjacent risk-related tools.

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 does not mention any of the four parameters: decision, risk_tier, workflow_id, and minimum_residual_score. The parameter names hint at their purpose, but the description adds no meaning beyond the bare schema.

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 states a specific verb and resource: it returns capability-based residual risk scores for agentic workflows. It is clear on its own, but it does not explicitly distinguish itself from closely named siblings such as recipes_agentic_aivss_risk_scoring_pack or recipes_agentic_catastrophic_risk_annex.

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?

There is no guidance about when to use this tool instead of the many related risk-scoring and recipe tools listed among the siblings. It neither names alternatives nor provides any selection criteria.

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?

No annotations are present, so the description carries the full burden. It only says 'Return', implying a read operation, but does not disclose side effects, authentication needs, filtering behavior, or what happens with no parameters.

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 one front-loaded sentence with no filler. It is concise but arguably too terse for a tool with four optional parameters and many siblings.

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?

The tool has four optional parameters, no annotations, and many similar siblings. The description does not explain how parameters affect results, when to use this tool, or what distinguishes it from alternatives, leaving too much 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 compensate. It does not explain the meaning or effect of decision, protocol, profile_id, or workflow_id, though the listed outputs loosely map to three of the four parameters.

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 names a specific verb ('Return') and resource ('agent handoff boundary profiles, protocol controls, and workflow maps'), which distinguishes it from sibling boundary packs like memory, browser, or context-egress. However, terms like 'protocol controls' and 'workflow maps' are vague and not fully defined.

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?

There is no guidance on when to use this tool versus the many similar boundary-pack siblings. An agent cannot determine the selection criteria from the description alone.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only enumerates return content; it says nothing about the read-only nature, how the four optional parameters affect results, defaults, or null handling. For a tool without annotation coverage this is a significant, undisclosed behavioral gap.

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 efficient sentence with the verb front-loaded and no wasted words. However, it is closer to under-specification than disciplined conciseness — a one-line list of jargon artifacts carries almost no usable substance.

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?

A four-parameter tool with 0% schema coverage, no annotations, and no usage guidance gets only a line listing return artifacts. The output schema exists, but the parameters and the semantics of the returned entities are entirely unexplained, so the definition is not adequate for confident invocation.

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 mentions none of the four parameters (decision, risk_tier, workflow_id, action_class_id). The description adds zero meaning beyond the bare parameter names, so the agent has no idea how to populate them or how they filter the returned artifacts.

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 ('Return') and lists four concrete deliverables (action classes, workflow action envelopes, runtime policy, evidence). However, these artifact types are opaque domain jargon with no elaboration, and nothing distinguishes this from the ~80 similarly named recipes_agentic_* siblings that also deal with runtime artifacts (e.g., recipes_agentic_run_receipt_pack).

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 offers zero guidance on when to use this pack versus its near-identically named siblings. No when/when-not conditions, no alternative tool names, no exclusions or prerequisites. Given the massive overlapping sibling catalog, an agent gets no routing help at all.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states what is returned and does not explain whether the tool computes scores, filters existing records, has side effects, requires specific inputs, or consumes some upstream data source. 'Hosted MCP wedges' is left undefined.

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 a single compact sentence and is front-loaded with the core action and output types. It earns conciseness credit, but the use of unexplained acronyms and jargon prevents a perfect score.

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?

The tool has five optional parameters, no annotations, no parameter documentation, and a large sibling family, yet the description gives no indication of how parameters affect results or what scenario this pack is meant for. The output schema may cover return values, but the description is inadequate for correct invocation.

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 does not mention any of the five parameters. While names like severity and minimum_score are suggestive, runtime_default_decision is unclear, and the description adds no meaning to the schema at all.

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 ('Return') and names the resources produced: AIVSS-aligned risk scores, SLAs, evidence, and hosted MCP wedges. It is clear in what the tool delivers, but does not differentiate it from the many similar risk-related sibling packs, and the acronym 'AIVSS' and phrase 'hosted MCP wedges' are unexplained jargon.

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 about when to use this tool versus the many sibling risk packs, such as recipes_agentic_catastrophic_risk_annex or recipes_mcp_risk_coverage_pack. There are no stated conditions, exclusions, or toggles between alternatives.

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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Return generated...' which gives no indication of side effects, prerequisites, data mutation, or any other operational characteristic. The agent has no sense of what happens when calling this 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 a single sentence, which is concise but far too under-specified for a tool with five parameters and no schema hints. It is not appropriately sized; it fails to deliver necessary information rather than being efficiently structured.

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's complexity (5 optional parameters, no schema descriptions, no annotations, and a non-trivial output), the description is woefully incomplete. An agent cannot understand the tool's inputs, outputs, or purpose well enough to invoke it 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 schema has zero description coverage, so the description must explain the five parameters (app_id, decision, risk_tier, buyer_stage, minimum_score). It does not mention any of them, leaving agents unable to determine valid values, formats, or relationships between inputs.

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 states a verb ('Return') and a resource ('generated agentic app launch-review profiles and decisions'), which is specific enough to avoid being a tautology. However, it does not explain what an 'agentic app launch-review' entails or how this pack differs from the many sibling packs (e.g., risk_scoring_pack, approval_receipt_pack). The purpose is partially clear but under-specified.

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?

There is no guidance on when to use this tool versus any of the numerous sibling tools. No context, prerequisites, or exclusions are mentioned, leaving the agent to guess the intended scenario.

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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does convey that the tool returns profiles, workflow requirements, and evidence, and that results are scope-bound. But it does not clarify whether this is a read-only retrieval, whether it depends on prior approvals, or what side effects might occur.

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 a single sentence with no wasted words and front-loads the primary action. It is concise, though it sacrifices necessary detail; the brevity itself is not the problem, but the under-specification limits its value.

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 five optional nullable parameters, no schema descriptions, no annotations, and a large set of similarly named sibling packs, this one-line description is insufficient for an agent to know how to invoke the tool correctly. The output schema exists but is not enough to compensate for missing parameter semantics and usage context.

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 compensate for five undocumented parameters: decision, risk_tier, workflow_id, action_class, and approval_profile_id. The phrase 'scope-bound' hints that parameters constrain the result set, but it does not explain what any parameter means or how they interact, leaving the agent without usable guidance.

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 states a specific verb ('Return') and resource ('approval receipt profiles, workflow requirements, and evidence'), and the name makes the approval-receipt focus clear versus sibling packs like recipes_agentic_run_receipt_pack. However, it does not explicitly differentiate itself from those siblings or explain what makes it distinct other than the tool name.

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 about when to use this tool versus alternatives such as recipes_agentic_run_receipt_pack or other agentic recipe packs. The phrase 'scope-bound' implies some filtering by the optional parameters, but there is no explicit context, precondition, or exclusion stated.

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?

No annotations are present, and the description only says 'Return' without addressing side effects, data mutation, or permissions. It does not disclose whether the tool is read-only or has any impact on the system.

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 a single, concise sentence with no redundant information. It is well-structured and to the point, though it could benefit from a bit more detail without becoming verbose.

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 output schema is present but not described, and the context of 'packs' is not explained, the description lacks sufficient context. It does not clarify what a pack represents or how the returned data is structured, limiting the agent's ability to use the response effectively.

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 schema defines two optional parameters (control_id, workflow_id) but the description offers no explanation of their meaning or how they influence the result. Agents cannot infer what values are expected or how they filter the output.

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 returns enterprise assurance controls, workflow evidence, and AI/Agent BOM seed. This is a specific and unambiguous action, making the purpose evident.

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 no guidance on when to use this tool versus the many sibling 'recipes_*' tools. It lacks context about the conditions that would make this pack appropriate, leaving agents to guess.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Return', implying a read operation, but does not state whether it is read-only, requires authentication, has side effects, or what happens when parameters are null/default. There is no mention of filtering, pagination, or error behavior.

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 a single sentence with no wasted words, front-loading the core purpose. It is appropriately brief, though arguably too terse to convey necessary context, but conciseness itself is good.

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 5 parameters, 0% parameter coverage, no annotations, and an output schema that is not described in the text, the description is severely incomplete. It does not explain what the annex looks like, how parameters affect output, or any constraints. An agent cannot safely invoke it without guessing.

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 provides no meaning for the five parameters (status, control_id, scenario_id, buyer_view_id, impact_domain). The schema only lists them as optional strings with null defaults, but not their roles or valid values. The description entirely fails to compensate for the lack of schema documentation.

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 states a specific verb ('Return') and a specific resource ('severe-risk annex'), with context ('high-impact agentic AI runtime decisions'). It is not a tautology and names a concrete deliverable. However, it does not differentiate from numerous risk-related siblings (e.g., recipes_agentic_risk_register, recipes_agentic_aivss_risk_scoring_pack), leaving ambiguity about what makes this annex distinct.

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?

There is no guidance on when to use this tool versus its many alternatives. No mention of scenarios, prerequisites, or complementary tools. An agent would have no signal about which of the ~70 siblings this one is suited for beyond the generic 'severe-risk annex' phrase.

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?

No annotations are provided, so the description carries the full disclosure burden, yet it only says the tool 'returns' a blueprint/map. It does not disclose that filtering is possible via status, layer_id, or question_id, what 'acquisition-ready' implies about the output, or any dynamic behavior. For a tool with zero annotation coverage this is a significant gap.

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 single sentence is clean and front-loaded with the key qualifier 'acquisition-ready', but its brevity is under-specification rather than efficiency. It omits parameter behavior, usage context, and any hint of the filters, so the one sentence does not earn its keep beyond stating the purpose.

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?

Although an output schema exists (so return values needn't be spelled out), the tool is a complex architectural blueprint with three unexplained filter parameters and no annotations. The description fails to explain what the filters do or when this recipe applies, leaving the agent unable to call it 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?

Schema description coverage is 0% and there are three parameters (status, layer_id, question_id) with no enums or explanations anywhere in the description. The description adds no meaning beyond what the bare schema shows, and the field names suggest filters but no values or semantics are given.

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 states a specific verb ('Return'), a resource ('agentic control plane architecture and buyer evidence map'), and a qualifier ('acquisition-ready'), so an agent knows the general deliverable. However, it does not differentiate from the closely-named sibling recipes_workflow_control_plane, leaving which tool is which ambiguous without opening schemas.

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?

There is no when-to-use guidance, no context for selecting this recipe over siblings, and no mention of alternatives such as recipes_workflow_control_plane or the secure_context_* evidence tools. The status/layer_id/question_id filters are not explained, so an agent gets zero help deciding when to invoke this versus a sibling.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Return ...' with no mention of filtering defaults, data freshness, scope of coverage, or any side effects. For a read-oriented query tool this is a clear but thin disclosure that adds nothing beyond the action verb.

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 — efficient and easy to scan in a tool list. It is slightly under-specified rather than verbose, which is a conciseness strength.

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-value detail is not required from the description. However, with six undocumented optional parameters, zero usage guidance, and no annotations, the definition is too thin for a filter-heavy query tool — an agent cannot correctly scope a call without external knowledge.

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 names none of the six parameters (namespace, risk_tier, access_mode, identity_id, workflow_id, entitlement_id). None of these are self-illustrating from the description, so an agent cannot infer valid values or how filters combine. The description contributes nothing to parameter understanding.

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 ('Return') and names a resource domain (expiring agent entitlement leases, access reviews, scope evidence), so purpose is discernible. However, listing three distinct outputs blurs what the tool actually produces, and nothing differentiates it from the many similar recipe packs (e.g., recipes_agentic_approval_receipt_pack, recipes_agentic_run_receipt_pack).

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?

There is no statement of when to use this tool versus alternatives, no exclusions, and no context on prerequisites. With six optional filter parameters, an agent gets no guidance on how to scope an entitlement review or when a different pack is 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?

With no annotations, the description carries the full burden. It does convey a read-only query behavior and an ordering trait ('risk-ranked'), which is meaningful. However, it does not disclose how ranking works, how the optional filters interact, or whether traversal or performance constraints apply.

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 one front-loaded sentence with no filler, and the core action appears first. It is appropriately concise, though the heavy use of jargon like 'agentic exposure paths' slightly reduces clarity.

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?

The output schema reduces the need to describe return values, and the description gives a general sense of the result. Still, with 8 optional but undocumented parameters and no annotations, this is insufficient for reliable invocation; an agent cannot determine what values to supply or when this tool is the right choice.

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 does not explain any of the eight parameters, including cryptic ones like path_id, decision, node_id, or path_class_id. The phrase 'identities' loosely maps to identity_id at best, but most parameters remain entirely unexplained.

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 states a specific verb ('Return'), a resource ('agentic exposure paths'), and useful qualifiers ('risk-ranked', across context, identities, MCP tools, and evidence). It clearly communicates what the tool produces, though it does not explicitly differentiate it from related sibling tools like recipes_agentic_threat_radar or recipes_agentic_posture_snapshot.

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 for when to use this tool versus the many related sibling tools. There are no prerequisites, exclusions, or alternative tool names mentioned, so an agent must infer selection context entirely from the tool name.

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?

With no annotations provided, the description carries the full behavioral burden. 'Return' weakly implies a read-style operation, but it does not disclose whether the tool is deterministic, how parameters influence results, error behavior, or whether any side effects exist.

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 one compact sentence with no filler, and the core content items are front-loaded. It earns its place, though the conciseness is achieved at the expense of substantive 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 pack tool with four optional parameters and no annotation coverage, this description is too thin. It does not explain how parameters shape the returned pack, when the tool should be used, or how it differs from related sibling packs; the output schema mitigates only the return-format gap.

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 does not explicitly mention any of the four parameters. The listed content (classes, phases, workflow matrix, evidence) maps only loosely to incident_class_id, workflow_id, severity, and decision, adding little beyond the parameter names themselves.

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 ('Return') and names the resource as agentic incident response content: classes, phases, workflow matrix, and evidence. It is fairly clear what domain this tool addresses, though it does not explicitly distinguish it from the many sibling recipe-pack tools.

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 when-to-use guidance, exclusions, or alternative sibling tools are mentioned. An agent must infer from the name and the listed content when to use this pack instead of related ones such as recipes_agentic_soc_detection_pack or recipes_agentic_readiness_scorecard.

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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. The verb 'Return' strongly implies a read-only operation, but the description does not explicitly state that it is non-mutating, nor does it mention any rate limits, authentication requirements, or side effects. It also does not describe what happens with the various parameters (e.g., filtering behavior) or the nature of the returned data. This is a minimal disclosure that leaves the agent guessing about operational details.

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 a single sentence with no wasted words, which is concise in a structural sense. However, it is under-specified: it lacks essential information and reads as a placeholder rather than a helpful guideline. It is not front-loaded with the most critical details, and the brevity comes at the cost of informativeness. It earns a middle score because it is not verbose, but it fails to provide necessary content.

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 6 parameters, no annotations, no output schema explanation (though it has an output schema), and a large family of sibling tools, the description is severely incomplete. It does not explain the meaning of the parameters, the nature of the returned probes, or how this tool fits into the broader agentic workflow measurement context. An agent would struggle to use this tool correctly without additional external knowledge, making the description inadequate for its context.

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%, meaning the description must compensate by explaining the six parameters (status, class_id, decision, probe_id, workflow_id, minimum_score). It does not mention any of them, nor does it provide hints about their purpose or how they influence the returned probes. The description adds no value beyond what the schema already shows (which is just type information with null defaults). This is a critical gap for an agent needing to construct a valid call.

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 states a specific action (return) and a resource (measurement probes) with a domain qualifier (agentic workflow traceability and readiness), which gives a general idea of the tool's function. However, it does not explain what 'measurement probes' are or how this tool differs from the many sibling 'pack' tools, such as recipes_agentic_assurance_pack or recipes_agentic_run_receipt_pack. The purpose is clear enough to avoid total confusion but lacks the specificity needed to distinguish it from alternatives.

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 no guidance on when to use this tool versus any of the large sibling pack tools. It does not mention any conditions, prerequisites, or scenarios where this tool is preferred. An agent would have to infer the usage solely from the name and the generic purpose statement, which is insufficient given the abundance of similar tools.

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?

There are no annotations, so the description carries the burden. It does disclose that the tool returns an already-generated artifact ('generated...snapshot') rather than creating one, but it does not mention whether the returned data can be filtered, how fresh it is, what auth is needed, or any other behavioral details.

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 a single, front-loaded sentence with no fluff, which earns efficiency credit. It is slightly terse, but word choice is direct.

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?

Despite the presence of an output schema and only optional parameters, the description omits the meaning of the five filters and the selection context, making it incomplete for correct invocation. An agent cannot know whether to pass any of the parameters or how they alter the returned snapshot.

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 adds no meaning to finding_id, workflow_id, minimum_score, risk_factor_id, or posture_decision. All five parameters are optional and nullable, so an agent has no basis for choosing values.

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 ('Return') and names a concrete resource ('generated enterprise posture snapshot for agentic AI and MCP operations'), so an agent can tell this is a retrieval operation. However, it does not distinguish this snapshot from the many similar sibling recipe tools, such as readiness_scorecard or risk-related packs.

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 about when to call this tool versus any alternative. With more than 70 sibling recipe tools, the absence of context or exclusions leaves the agent to guess which snapshot is meant.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only says 'Return', implying a read-only operation, but it does not explicitly state side-effect-free behavior, authentication needs, ordering, or failure modes. No contradiction with annotations exists because none are present.

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 a single sentence, front-loaded with the action word, and contains no filler. However, given the complexity of the tool (four optional parameters, output schema, and a large family of sibling packs), the brevity is under-specification rather than appropriate conciseness; it lacks necessary context.

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?

Providing only a terse summary, the description does not explain what the returned evidence or drift controls look like, how the parameters influence the output, or when this pack is appropriate. Even though an output schema exists, it is not referenced, and the description does not help the agent understand the expected result or use case.

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 does not mention any of the four optional parameters (check_id, decision, source_id, protocol_id). There is no explanation of their purpose, constraints, or relationships, so the description adds no meaning beyond the bare schema, failing to compensate for the lack of detailed 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 states the verb 'Return' and the resource 'MCP/A2A protocol conformance evidence and buyer-ready drift controls', giving a clear high-level action and subject. However, it does not distinguish this from many similar sibling packs, nor does it define what 'conformance evidence' or 'drift controls' concretely include.

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?

There is no guidance on when to use this tool versus alternatives. It neither names alternative tools nor provides conditions, prerequisites, or exclusions. The empty description leaves the agent without criteria for selecting this pack over the numerous closely named sibling packs.

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?

There are no annotations, so the description must carry the behavioral burden. The word 'Return' suggests a read-only retrieval operation, which is helpful, but the description does not mention authentication, side effects, rate limits, or whether decisions are computed on the fly or retrieved from storage.

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 a single clear, front-loaded sentence with no redundant words. It is concise, though it forgoes additional context that would improve the other dimensions.

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?

The tool has three optional parameters with no descriptions, no required parameters, and no behavioral context beyond the return statement. An output schema exists, so the return shape is covered, but the agent still lacks enough information about parameters, preconditions, or how to choose this tool among many similar siblings.

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 does not explain the three parameters: decision, workflow_id, and minimum_score. The mention of 'scale, pilot, gate, or block' provides some context for the decision parameter, but workflow_id and minimum_score semantics are entirely absent.

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 states a specific action and output: 'Return generated scale, pilot, gate, or block decisions for agentic workflows.' This clearly indicates the tool produces readiness decisions and names the decision categories. It does not heavily distinguish from similar sibling recipe tools, but the verb and resource are explicit enough.

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 no guidance on when to use this tool versus the many sibling tools, such as recipes_agentic_aivss_risk_scoring_pack or recipes_agentic_posture_snapshot. No conditions, exclusions, or alternative references are given.

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 are absent, leaving the description as the sole source of behavioral disclosure. It implies a read-only generation action by saying 'Return', but it doesn't state whether the tool has side effects, requires authentication, or what the output structure is. The description does not add context beyond the action itself, and the existence of an output schema isn't referenced here.

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 a single short sentence with no wasted words, and it gets to the point immediately. However, it is so terse that it borders on under-specification; it would be more effective if it front-loaded a bit of parameter context. Yet as conciseness goes, it is efficient.

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 tool with three optional parameters and an output schema, the description is not complete. It doesn't explain what a 'drill pack' is, how the parameters refine the result, or what the returned adversarial drills contain. The agent is left guessing at the input semantics and expected output, making successful invocation uncertain.

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 description has 0% schema coverage and mentions none of the three parameters (scenario_id, workflow_id, attack_family). Since the schema gives only names and types, and the description doesn't explain how these affect the returned drills, an agent has no sense of how to set these fields.

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 states a concrete action ('Return') and a specific resource ('adversarial drills for agentic remediation workflows and MCP controls'), which gives the agent a clear sense of what it will deliver. It stops short of a full 5 because it doesn't contrast with the many sibling red-team tools (e.g., recipes_agentic_red_team_replay_harness) or clarify the exact boundaries of 'agentic remediation' scope.

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?

There is no guidance on when to use this tool versus any of the dozens of recipe siblings. No conditions, alternatives, or exclusions are offered, so an agent must infer when this is the right choice, which is risky given the large, highly overlapping toolset.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is a read-style 'Return', but it does not explain how parameter combinations affect results, what happens with no arguments, or whether any side effects occur.

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 a single efficient sentence with no filler, and the main outcome is front-loaded. It is appropriately concise, though it sacrifices necessary 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?

With five optional parameters, no annotations, and no usage or selection guidance, the description is too thin for an agent to know how to invoke the tool for a specific red-team drill. The output schema covers return shape, but the core selection semantics remain unexplained.

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 explains none of the five optional parameters (severity, replay_id, scenario_id, workflow_id, attack_family). The description must compensate for the bare schema but does not provide any mapping between these parameters and the returned fixtures.

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 names a specific verb ('Return') and resource ('replay fixtures, expected decisions, and evidence gates for red-team drills'), so an agent can tell this is a retrieval tool for red-team replay material. It is distinguishable from the generic sibling recipes_agentic_red_team_drill_pack mainly by the word 'replay', but that distinction is not made explicit.

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?

There is no guidance on when to use this tool versus alternatives like recipes_agentic_red_team_drill_pack or when replay fixtures would be needed. The description does not mention any conditions, exclusions, or selection criteria.

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?

No annotations are present, so the description must carry the full behavioral disclosure burden. It only says 'Return ... templates', which is a read operation, but it does not reveal how parameters affect output, any error conditions, or other behaviors. The description adds minimal context beyond a simple retrieval.

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 a single concise sentence that front-loads the primary action and scope. It is efficient and to the point, with no wasted words.

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?

The tool has an output schema and three optional parameters, but the description does not explain when to use certain parameters or how the tool fits into a workflow. Given the large set of sibling recipe tools, the lack of differentiation and usage context makes it incomplete for correct invocation.

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 schema has three optional parameters (receipt_id, workflow_id, minimum_score), but the description provides no explanation of their meaning or usage. With 0% schema description coverage, the description fails to compensate, leaving the agent to guess how to populate these parameters.

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 ('Return agent run receipt templates') and enumerates the specific categories (identity, context, tools, egress, approval, and evidence), making the purpose unambiguous. It does not explicitly differentiate from sibling tools, but the focus on receipt templates is distinct enough.

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?

There is no guidance on when to use this tool versus any of the many sibling recipe tools. The description does not mention alternatives, preconditions, or scenarios where this tool is preferred, leaving the agent to infer applicability.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool returns detections, with no mention of side effects, read-only behavior, authentication requirements, filtering behavior, or what 'SIEM-ready' means operationally. This is not contradictory, but it is far too thin.

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 a single efficient sentence with no wasted words, and the key outcome is front-loaded. However, it is under-specified for a tool with five parameters and no annotations, so brevity comes at the cost of useful operational 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?

Despite an output schema existing, the definition omits all parameter semantics, usage conditions, and behavioral context. With 0% schema coverage and no annotations, this one-line description is not enough for an agent to reliably select and invoke the tool across the large sibling set.

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 does not mention any of the five parameters (rule_id, decision, severity, event_class, workflow_id). There is no compensation for the schema gap, so an agent has no guidance on what values these parameters take or how they affect the returned detections.

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 ('Return') and a concrete resource ('SIEM-ready detections for agentic AI and MCP telemetry'), so the core purpose is clear. It does not explicitly distinguish this from siblings like recipes_agentic_incident_response_pack or recipes_agentic_action_runtime_pack, but the 'SIEM-ready detections' focus gives reasonable differentiation.

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?

There is no guidance on when to use this tool versus any of the many sibling recipe packs. No alternative tools are named, no conditions for selection are given, and no exclusions are stated. An agent would have to infer usage from the tool name and one-line description.

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?

With no annotations, the description carries the full burden of disclosing behavioral traits, but it only says 'Return' evidence. It does not clarify whether this is a read-only operation, how the watch is maintained, what data freshness means here, or what side effects, if any, occur. The phrase 'evidence' hints at output rather than mutation, but this is insufficient.

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 a single sentence with no fluff or repetition. The core idea is front-loaded and easy to parse. However, the extreme brevity is borderline under-specification, so it does not earn a 5.

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?

The tool has seven optional parameters and zero parameter documentation, but the description gives no sense of how to scope the call or which fields matter for different use cases. The existence of an output schema reduces the need to explain return values, but the input semantics remain almost entirely unexplained.

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 does not explain any of the seven optional parameters. Names like 'decision', 'watched_source_id', 'freshness_class', and 'primary_watchlist_id' are opaque without additional context. Since the description fails to compensate for the schema gap, this dimension is severely under-served.

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 a specific action ('Return') and object ('source-freshness and standards-drift evidence for SecurityRecipes'). It conveys what the tool produces and gives enough domain context to distinguish it from generic recipe tools. It falls short of 5 because it does not explicitly differentiate itself from siblings that may also report on standards conformance or freshness.

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 provided on when to use this tool versus alternatives. The description does not mention contexts, exclusions, or sibling tools like recipes_agentic_standards_crosswalk or recipes_agentic_readiness_scorecard. An agent would have to infer usage solely from the tool name.

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?

With no annotations, the description carries the full burden. It clearly indicates a read-only retrieval behavior ('Return standards-to-evidence mappings'), but it does not disclose filtering behavior, default parameter handling, or what the returned evidence structure looks like.

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 a single concise, front-loaded sentence with no filler. Every word contributes to stating the core function.

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?

Despite having an output schema, the description is far too sparse given zero annotation coverage and five unexplained parameters. It lacks essential context about how to construct a valid request, what each field means, and how results are filtered.

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 does not explain any of the five parameters (status, source_id, control_id, standard_id, capability_id). An agent cannot infer what values to pass or how filters combine, making parameter use essentially guesswork.

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 ('Return') and a concrete resource ('standards-to-evidence mappings'), scoped to agentic AI, MCP, and prompt-injection guidance. This distinguishes it from generic recipe tools, though it does not explicitly differentiate it from any sibling tool.

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?

There is no guidance about when to use this tool versus the many sibling recipe tools, nor any mention of alternatives, exclusions, or intended workflow context. The description only states what it returns, not when it should be chosen.

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?

The description only says the tool 'returns' the BOM, which implies a read operation but discloses no further behavioral traits. With no annotations, the description carries the full transparency burden and does not address whether the BOM is computed on demand, how filters affect output, or whether side effects or prerequisites exist.

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 a single front-loaded sentence with no filler, repetition, or unnecessary detail. Every word contributes to communicating the core deliverable and its scope.

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?

Despite having an output schema, the tool has no annotations, no parameter descriptions, and no usage guidance. The agent cannot determine how to construct meaningful filter values or what namespace or component_type mean, so the invocation context is materially incomplete.

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 does not mention namespace, agent_class, workflow_id, or component_type. The listed BOM categories only weakly hint at workflow_id and agent_class, providing no information about value formats, allowed values, or how parameters interact.

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 an active verb and names a specific deliverable, 'Agentic System BOM,' then enumerates covered categories: workflows, agents, identities, MCP tools, and evidence. This distinguishes it from recipe/pack siblings and gives the agent a concrete sense of what the tool returns.

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 provided about when to use this tool versus alternatives such as recipes_agentic_readiness_scorecard or recipes_agentic_incident_response_pack. There are no conditions, exclusions, or references to sibling tools, leaving selection entirely to inference from the name.

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?

With no annotations provided, the description carries the full burden, but it only says 'Return' and gives no detail about side effects, authentication, filtering behavior, or what the contract contains. 'Return' implies a read-only operation, but no behavioral traits beyond that are disclosed.

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 a single front-loaded sentence with no filler or redundant phrasing. It is concise, though it achieves conciseness by omitting useful guidance.

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 tool with five optional parameters and no annotation support, the description is too thin to be fully actionable. The output schema may cover return shape, but the description does not explain the purpose of the parameters or the context in which this contract should be requested.

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 does not explain any of the five parameters (check_id, decision, workflow_id, signal_class_id, required_attribute). The agent cannot tell how these optional parameters affect the returned contract. Description adds no semantic value beyond the bare schema.

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 the specific verb 'Return' and names a concrete resource: the OpenTelemetry-aligned agentic telemetry and redaction contract. This is clear enough to know what the tool does, though it doesn't explicitly differentiate itself from the many sibling recipe tools beyond the unique contract name.

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?

There is no guidance on when to use this tool, what scenarios call for it, or how it relates to sibling tools like recipes_secure_context_evidence_contract or recipes_agentic_readiness_scorecard. The description only states what it returns, leaving the agent to infer usage.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It communicates that results are 'current' and 'source-backed,' which is a useful data-quality signal, but it does not disclose whether the call is read-only, how priorities are determined, whether filtering affects the output, or what side effects could occur.

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 a single concise sentence with no fluff, which is good for front-loading. However, given the tool has five optional parameters and many close siblings, the brevity borders on under-specification rather than effective conciseness.

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 fully described, but the description still leaves major gaps: no parameter explanations, no guidance on defaults or filtering behavior, and no differentiation from numerous threat/risk sibling tools. With no annotations and five optional inputs, an agent has too little context to call 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?

Schema description coverage is 0%, and the description does not explain any of the five optional parameters. While names like 'minimum_score' and 'signal_id' are somewhat self-explanatory, the description adds no meaning about values, formats, or interactions for 'horizon', 'priority', 'capability_id', or the other fields.

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 states a specific verb ('Return') and resource ('current source-backed agentic AI threat signals and product priorities'), making the tool's purpose clear. It adds meaningful qualifiers ('source-backed', 'current') not present in the tool name, and the output focus on threat signals plus product priorities helps set it apart from sibling packs, though it does not explicitly name any alternative.

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 offers no guidance on when to use this tool versus the many sibling threat, risk, and posture tools. It implies a monitoring/radar use case through the word 'radar' and 'current', but there are no explicit when-to-use, exclusions, or alternative recommendations.

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?

No annotations are provided, so the description carries the full burden of disclosing behavior. 'Return' weakly implies a read-only operation, but the description does not state whether this is purely a lookup, how results are scoped when optional parameters are omitted, whether any side effects occur, or how the returned contracts are assembled.

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. Every word carries meaningful content, and the description is appropriately brief for what little it commits to.

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?

Although an output schema exists, the description leaves important intent ambiguous: what an 'identity ledger' contains, what selecting by identity_id versus workflow_id does, and how this tool relates to the large sibling set. A caller would likely need external documentation to choose and invoke this tool safely.

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 provides no parameter-level explanation. The three optional parameters (agent_class, identity_id, workflow_id) remain semantically unexplained, and the description does not connect its contract categories to these parameters.

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 clear verb ('Return') and specifies a resource composed of distinct contract types: non-human identity, delegation, scope, and audit. It is concrete enough to separate it from many generic sibling tools, though it does not explicitly distinguish it from similar ledger/profile tools like recipes_secure_context_lineage_ledger.

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?

There is no guidance about when to use this tool versus any of the many sibling tools. The description gives no context for when a caller should select this ledger instead of an agent card, trust profile, handoff boundary, or lineage ledger.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Return' hints at a read-like operation, but there is no mention of side effects, prerequisites, whether decisions are computed or stored, or how persistence decisions are derived.

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 one compact sentence with a clear opening verb and list of returned items. It is appropriately short, though it sacrifices explanatory depth for brevity.

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 tool with four optional parameters, no annotations, and a zero-coverage schema description, the description is too thin to support correct invocation. The output schema may document return values, but parameter semantics and usage context remain unexplained.

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 does not explain any of the four parameters: decision, persistent, workflow_id, or memory_class_id. The parameter names are suggestive but ambiguous, and the description adds no meaning beyond the raw schema.

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 states a clear action ('Return') and a specific resource: agent memory classes, workflow profiles, TTLs, and persistence decisions. It is distinct enough from sibling boundary packs by focusing on agent memory, though it does not explicitly explain what a 'boundary pack' is.

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 the many sibling boundary-pack tools. The description implies it returns memory-related data, but it does not state conditions, exclusions, or alternatives.

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?

No annotations are provided, so the description carries the full burden. 'Return' implies a read operation, but it doesn't state whether it's read-only, whether it makes external calls, or any side effects. There's no mention of auth, rate limits, or data handling. Significant gap.

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 a single, concise sentence with no filler. However, it is under-specified and doesn't earn its place because it lacks essential details about parameters and usage. It's concise but not adequately informative.

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 5 optional parameters, no annotations, and 0% schema coverage, the description is far too sparse. It doesn't explain the purpose of parameters, the output format (even though an output schema exists, the description doesn't mention it), or how to use the tool effectively. It is inadequate for an agent to correctly invoke this tool.

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 coverage is 0% and the description gives no information about the five parameters (decision, platform, skill_id, risk_tier, minimum_score). The description only says what the tool returns, not how parameters affect it. This is a critical omission.

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 states a clear action (Return) and a specific resource (agent skill supply-chain decisions), listing the kinds of decisions (provenance, permission, isolation). However, it doesn't explicitly single out the tool from siblings, and 'supply-chain decisions' is broad. It's clear enough but not sharply differentiated.

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 use this tool versus the many sibling tools. It doesn't mention prerequisites, conditions, or alternatives. Agents are left to guess based on the name alone.

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?

With no annotations supplied, the description carries the behavioral transparency burden. 'Return' implies a read-only retrieval operation and the description lists what it returns, which is helpful. However, it does not disclose how filtering parameters affect results, the scope of evidence, or any limitations, so the transparency is only partial.

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 a single front-loaded sentence with no redundant phrasing. It names the verb and the key output categories efficiently, though it is terse to the point of omitting useful guidance in other dimensions.

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 tool with four optional parameters, no annotations, and no parameter explanations, this one-sentence description is incomplete. The output schema may document return shapes, but the agent still lacks enough context about filtering, parameter relationships, and when this recipe pack should be used among dozens of siblings.

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 does not compensate by explaining any of the four parameters. The parameter names and the outputs listed in the description provide weak implicit mapping, but status, trust_tier, workflow_id, and dimension_id remain semantically vague with no enforcement, format, or meaning described.

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 ('Return') and identifies a clear resource ('Agent Trust Fabric'), then enumerates the main outputs: dimensions, workflow tiers, source evidence, and buyer proof. This makes the tool's purpose reasonably clear, though it does not explicitly differentiate it from sibling trust-related recipe packs.

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?

There is no guidance on when to use this tool versus alternatives such as recipes_secure_context_trust_pack, recipes_a2a_agent_card_trust_profile, or other trust-related packs. No context, exclusions, or preconditions are provided, leaving selection to inference.

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?

With no annotations provided, the description carries full behavioral disclosure burden, but it only says 'Return' and lists output categories. It does not explain whether filtering occurs, how the four nullable inputs affect results, whether this is read-only, or any side effects or access considerations.

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 a single, compact sentence with no filler or redundancy. It is front-loaded with the main action and resource list, though it is shorter than the complexity of a four-parameter tool might warrant.

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 tool with four optional nullable parameters, no annotations, and many similar sibling packs, the description is incomplete. The output schema covers return structure, but an agent still lacks needed context about when to use this pack, what each input means, and how this boundary pack differs from related ones.

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 loosely maps to parameters: 'task profiles' suggests task_profile_id and 'workspace classes' suggests workspace_class_id, but 'decision' and 'risk_tier' are entirely unexplained. The description does not compensate for the schema's lack of parameter documentation.

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 clear verb ('Return') and identifies a specific resource: browser-agent workspace classes, task profiles, controls, and evidence. The browser-agent qualifier helps distinguish it from the many other boundary-pack siblings, though the description does not explicitly contrast it with them.

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?

There is no explicit guidance about when to use this tool versus alternatives such as recipes_agent_handoff_boundary_pack or recipes_context_egress_boundary_pack. The browser-agent wording implies a context, but the description never states selection criteria, prerequisites, or when not to use it.

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?

With no annotations provided, the description carries the full responsibility for behavioral disclosure. It only says 'Return', implying a read operation, but does not state whether it is read-only, what side effects occur, or how parameters modify the output. No behavioral traits beyond the name are disclosed.

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 a single sentence, concise and front-loaded with the verb 'Return'. However, it is so minimal that it lacks structure—the three output types are listed without separation or context, making it less scannable than it could be.

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 4 optional parameters and no schema descriptions, the description is inadequate. It does not explain the purpose of each parameter or how they are used. The existence of an output schema helps, but the description still leaves the agent guessing about call semantics and expected usage.

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 explain parameters. It mentions 'data classes' and 'destination classes' but does not map them to the four parameters (source_id, data_class, workflow_id, destination_class). It fails to clarify what each parameter does or how they filter results.

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 states a specific verb 'Return' and lists three resource types (context egress data classes, destination classes, workflow boundary policy), which clearly explains the tool's output. However, it does not differentiate from numerous sibling 'pack' tools that also return policies or classes, so it is not fully distinctive.

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 provided on when to use this tool versus alternatives. The description does not mention conditions for use, exclusions, or any reference to sibling tools, leaving the agent to infer the appropriate context.

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?

With no annotations provided, the description carries the full burden. It only states 'Return', implying a read-only operation, but does not disclose potential side effects, data freshness, pagination, or any caveats. This is minimal for a tool with no annotation support.

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 a single concise sentence with no redundant words. It is appropriately short, though it may be too terse given the complexity of the tool.

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 6 optional parameters, no schema descriptions, and no annotations, the description is severely incomplete. An agent cannot determine what inputs to provide or what the scan results entail, despite having an output schema.

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 schema has 6 parameters with 0% description coverage, and the description does not explain any of them. Parameter names like 'limit', 'rule_id', 'decision', 'severity', 'source_id', and 'actionable_only' are not elaborated, leaving the agent without clarity on valid values or their purpose.

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 states a clear verb ('Return') and resource ('context-poisoning scan results for registered secure-context sources'). It conveys the purpose effectively, but it does not explicitly differentiate from sibling tools like recipes_secure_context_trust_pack or recipes_secure_context_attestation_pack, though the name itself implies a focused function.

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 no guidance on when to use this tool versus alternatives. It does not mention context, preconditions, or exclusions. An agent would have to infer use cases from the name alone.

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?

With no annotations, the description carries the full disclosure burden. 'Return' implies a read operation rather than a mutation, which is helpful, but the description does not disclose what happens if the profile has not been generated, whether parameters filter or transform the result, or any side effects or prerequisites.

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 a single front-loaded sentence with no filler. It communicates the core action and object efficiently, though it is sparse. Conciseness is good even though completeness is lacking.

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?

The tool has five optional parameters, no annotations, and no parameter-level documentation. The description names the returned profile but does not explain how the parameters relate to that profile, what 'critical-infrastructure' means in this context, or how this tool fits into the broader secure-context recipe family. The output schema reduces the need to explain return structure, but the operational context is still under-specified.

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 compensate for the five undocumented parameters. It does not mention decision, sector_id, control_id, buyer_view_id, or readiness_status at all. An agent gets no additional meaning beyond the parameter names and default-null values in the schema.

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 a retrieval verb ('Return') and a specific resource ('generated critical-infrastructure secure-context profile'). It is more specific than a tautology, but it does not differentiate this pack from the many other secure-context sibling tools such as recipes_secure_context_trust_pack or recipes_secure_context_attestation_pack.

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?

There is no guidance about when this tool should be used, how it relates to sibling secure-context tools, or what prior steps are needed for the profile to exist. The word 'generated' implies a dependency but nothing explicitly states when to call this vs. alternatives.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only, informational operation and specifies what is returned: scope, coverage, provenance, and counts. It does not overstate side effects, and no mutation is implied.

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 a single, front-loaded sentence with no wasted words. It states the action, the resource, and the specific information returned, making it easy to scan and parse.

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?

This is a simple zero-parameter informational tool with an output schema present, so the description fully covers what an agent needs to decide whether to call it. It names the returned dimensions and does not need to enumerate output fields because the schema handles that.

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 fully covers this, so the baseline of 4 applies. The description does not need to add parameter detail because there are none; it correctly focuses on the return content instead.

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 clear verb ('Return') with a specific resource: the Medium/High/Critical CVE catalog, and names the exact facets returned (scope, coverage, provenance, counts). This clearly distinguishes it from sibling tools that fetch individual CVEs or search CVE data.

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 clearly establishes this as a catalog-level metadata overview rather than a CVE lookup, so an agent can infer when to choose it over recipes_cve_get or recipes_cve_search. It does not explicitly name alternatives or exclusion conditions, but the context is unambiguous.

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?

No annotations are provided, so the description must carry the full burden. It describes what the tool returns (evidence, recipe authority, bounded change plan) but does not disclose side effects (read-only vs. write), permission requirements, or error behavior. While 'Get' likely implies read-only, this is not explicitly stated. The description adds some context but lacks depth on operational behavior.

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?

Single sentence, front-loaded with the core purpose, with no unnecessary words. The description is efficient and self-contained.

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?

The tool has an output schema that presumably describes the return structure, and the description covers the purpose and parameter semantics. It does not mention prerequisites (e.g., CVE existence) or error handling, but for a simple get operation with one parameter, it is reasonably complete. The description provides enough context for an agent to decide when to call it and what to pass.

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 input schema only defines 'cve' as a string without description (0% coverage). The description compensates by specifying that the tool works for 'one exact CVE', clarifying that the parameter should be a specific CVE identifier. This adds meaningful semantic context beyond the schema.

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 verb ('Get') and a clear resource ('evidence, recipe authority, and a bounded code/config/file change plan') for one exact CVE. This distinguishes it from sibling tools like recipes_cve_search (which searches) and recipes_cve_catalog_info (which provides catalog info). The scoping to 'one exact CVE' adds precision.

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?

Implies usage when the agent has a specific CVE identifier (as opposed to searching). The phrase 'one exact CVE' provides context, but it does not explicitly name alternatives or state when not to use this tool. No exclusionary guidance is given, so a 4 is 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?

With no annotations provided, the description must carry behavioral disclosure. It communicates that this is a search operation returning CVE matches rather than full details, and it notes severity scope. However, it does not address pagination, default limits, filtering semantics, or read-only assurance, so the behavioral burden is only partially met.

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 sentence front-loads the action and immediately names the relevant sibling for detail retrieval. There is no filler, though the brevity leaves no room for parameter or usage 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?

Despite having an output schema, the definition is incomplete for a 5-parameter search tool with zero schema documentation. It omits all parameter semantics and contextual guidance, leaving an agent to guess how to construct a query or when to use filters.

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 explains none of the five parameters (query, limit, kev_only, severity, published_year). It neither states what each parameter controls nor offers any query syntax or filter guidance.

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 states a specific action ('Search') and a clearly bounded resource ('every in-scope Medium/High/Critical CVE'), and it explicitly routes to recipes_cve_get for complete details, distinguishing it from the sibling getter. An agent can tell this search tool apart from related CVE tools without opening schemas.

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?

It gives a clear usage context: use for searching the CVE set, and defer to recipes_cve_get when complete details are needed. It does not list explicit exclusions or advanced conditions, but the sibling routing is enough for basic tool selection.

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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Return...' with no detail on side effects, permission requirements, or what the response contains. It does not contradict annotations (there are none), but it reveals almost nothing about runtime behavior.

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 a single short sentence, which is concise, but it severely under-specifies the tool. It is not appropriately sized because it omits crucial information; it is merely terse.

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 7 optional parameters, no parameter documentation, no behavior explanation, and no clear return value (despite an output schema existing), the description is grossly incomplete. Even the presence of an output schema does not help because the description does not indicate what data is returned or how it is structured.

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 names none of the 7 parameters. The parameters are all optional and untyped beyond 'string' or 'null', with no explanation of what they filter or control. The description provides no semantic context for any of them.

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 vague noun phrase 'design partner pilot motion' without defining it, and gives no indication of what the tool actually produces (e.g., a document, a workflow, a recommendation). It does not distinguish this tool from the dozens of other 'recipes_' siblings, making selection ambiguous.

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?

There is no guidance on when to use this tool versus the many sibling 'recipes_' tools. No mention of prerequisites, typical scenarios, or what problem it solves. The phrase 'for buyer proof and hosted MCP validation' hints at a purpose, but it is not actionable instruction.

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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Return.' It does not explain whether this is read-only, whether parameters filter the output, or what 'bundled' means operationally.

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 a single well-formed sentence that front-loads the action and purpose. It is not padded, though brevity is achieved by omitting parameter and behavioral context.

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 tool with five unannotated parameters and no behavioral guidance, this is incomplete. The output schema covers return structure, but the agent cannot tell whether to pass filters, whether parameters combine, or what 'bundled' means in practice.

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 adds no meaning to the five optional parameters. An agent cannot tell how status, pack_id, category, section_id, or question_id affect the returned export.

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 states a specific verb ('Return') and resource ('bundled enterprise trust-center export') and gives the audience/purpose ('buyer and platform diligence'). It doesn't explicitly differentiate among sibling trust/diligence tools, but the core action is clear.

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 'for buyer and platform diligence' supplies a usage context and implies when this tool is relevant. However, it does not state when to prefer this tool over siblings like recipes_secure_context_buyer_diligence_brief, nor does it give exclusions.

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?

The description does not disclose any side effects or explicitly state that it is read-only. Without annotations, the behavioral transparency is limited to the implied meaning of 'Get'.

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 concise and to the point, with no unnecessary words. It effectively communicates the core functionality in a single sentence.

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?

The description is sufficient for a simple retrieval operation, but it lacks details about error handling or return structure. Since an output schema exists, it does not need to explain return values, but it could benefit from mentioning potential null results or not-found behavior.

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 parameter name 'slug_or_path' and the description indicate that the identifier can be either a slug or a path. However, no further details are given about format, examples, or validation rules.

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), the resource (full recipe record), and the identifier (slug or path). It is specific and unambiguous, distinguishing it from list or search tools.

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 does not provide guidance on when to use this tool over alternatives like recipes_list or recipes_search. It only describes what it does, not the context or conditions for its use.

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?

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states that a plan is returned, with no mention of side effects, permissions, rate limits, or what 'readiness plan' entails. The agent has no idea if this is a read-only operation or if it has implications.

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 a single, front-loaded sentence with no redundancy. It conveys the core action efficiently, though it may be too terse given the need for parameter context.

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?

Despite having an output schema, the description fails to provide context on what the readiness plan contains or how the parameters affect it. With 6 optional parameters and no documentation, the tool is under-specified for practical use. The sibling list is long, further requiring differentiation that is absent.

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 does not explain any of the six optional parameters (status, gate_id, risk_id, stage_id, control_id, buyer_evidence_id). None of these are described, leaving the agent without any clue how to populate them or what filtering they enable.

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 a verb ('Return') and a resource ('hosted MCP readiness plan'), and specifies the context ('enterprise product rollout'). It distinguishes from most siblings by focusing on readiness planning, though it doesn't explicitly contrast with closely related tools like recipes_agentic_readiness_scorecard.

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 use this tool versus the many sibling recipe tools. It doesn't mention alternatives, exclusions, or prerequisites. The agent is left to infer that this is the go-to for hosted MCP readiness, but with no explicit routing.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List recipes', which implies a read-only operation, but does not disclose pagination, default limits, sorting, or any side effects. There is no explicit statement of safety or side-effect behavior, making it insufficient for an agent to understand the operational profile.

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 extremely brief (six words), but this is under-specification rather than conciseness. The single sentence lacks essential details about filters, sorting, or output, making it inadequate for a tool with seven optional parameters. It is not front-loaded with critical information because no critical information is present.

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's complexity (seven optional parameters) and the presence of an output schema, the description should explain what filters are available, how they combine, and what the response contains. However, it provides only a generic statement. The description is completely inadequate for an agent to understand how to construct a valid request or interpret the results, especially in a large sibling family where similar tools exist.

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 compensate by explaining parameter usage. It mentions 'optional metadata filtering' but does not map any of the seven parameters (tags, agent, limit, facets, section, severity, min_quality) to their meaning or purpose. The description adds no semantic value beyond what the parameter names themselves imply, which is insufficient for correct usage.

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 states a clear verb ('List') and resource ('recipes'), and mentions 'optional metadata filtering'. However, it does not differentiate from sibling tools like recipes_search or recipes_get, which also list or retrieve recipes. The term 'metadata filtering' is vague and doesn't specify which metadata fields or how filtering works, leaving ambiguity about its unique role.

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 provided on when to use this tool versus alternatives. There is no mention of when not to use it, no examples, and no reference to sibling tools. The description simply states what it does without context on selection criteria.

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?

With no annotations, the description bears the full burden. 'Heuristic' and 'best-fit' disclose approximate behavior, but the description does not explain ranking, quality thresholds, empty results, or how the multiple criteria combine.

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 one-sentence description is free of filler and front-loads the core notion. However, it is under-specified rather than appropriately sized, so the brevity reduces overall usefulness.

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?

The tool has no annotations, 8 optional parameters, and no parameter documentation, and the description does not fill that gap. It lacks when-to-use guidance, behavioral details, and any parameter semantics needed to invoke it 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?

Schema description coverage is 0% and the description names none of the 8 parameters. An agent must guess the meaning and format of cve, package, facets, rule_id, keywords, ecosystem, min_quality, and limit.

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 states a clear action ('suggests best-fit recipes') and target domain ('security finding'), with 'heuristic' signaling approximate matching. The name distinguishes it from the many other recipes_* tools, though it does not explicitly compare itself to siblings.

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 choose this matcher over sibling tools such as recipes_cve_get, recipes_cve_search, or recipes_search. The 'match_finding' verb implies a use case, but conditions and exclusions are left unstated.

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?

No annotations are present, so the description carries the full burden, but it only says 'Return ... evidence.' It does not disclose read-only behavior, how the parameters affect the result, whether any context is required, or what 'scope-drift' and 'token-boundary' evidence mean operationally. The wording is not misleading but is too thin to be transparent.

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 a single clear sentence with no filler and front-loads the main deliverable. It is easy to scan and efficient, though its brevity is partly achieved by omitting useful 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 tool with four optional parameters and no annotations, one sentence is not enough to convey invocation semantics, evidence boundaries, or how this pack differs from similarly named siblings. Even with an output schema present, the description lacks the context needed to use the 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?

Schema description coverage is 0%, and the description mentions none of the four parameters: decision, namespace, workflow_id, and connector_id. Their nullable/default null shapes are documented only structurally, with no meaning added. An agent cannot determine what values to supply or how they influence the returned evidence.

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 states a specific deliverable—'MCP authorization conformance, scope-drift, and token-boundary evidence'—with the verb 'Return', so it is not a tautology and has a clear resource. However, it does not differentiate this pack from closely related siblings such as recipes_mcp_tool_surface_drift_pack or recipes_agentic_protocol_conformance_pack, so it misses the top score.

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?

There is no guidance on when to use this tool versus the many sibling recipe packs. The description provides no scenario, prerequisites, exclusions, or alternative tool names. An agent would have to infer the intended context entirely from the tool name.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-like 'Return' operation but does not state whether state changes, whether parameters are filters or inputs, what decisions are based on, or any side effects. The behavioral surface is largely opaque.

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 a single concise sentence with no fluff and front-loads the main action and outputs. It is under-specified in content, but strictly for structure and economy it is well-formed.

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?

While an output schema exists, the description still lacks usage context, parameter semantics, and any differentiation from sibling intake/risk tools. An agent would not know how to correctly invoke this tool or interpret the role of its optional parameters.

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 does not mention or explain decision, namespace, or candidate_id. The parameter names are somewhat suggestive but their meaning, allowed values, and role in the operation are completely undocumented, so the description provides no compensating value.

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 ('Return') and resource ('MCP connector intake decisions, risk findings, gaps, and promotion plans'), so an agent can tell it involves connector intake outputs. However, it does not differentiate this from closely named siblings like recipes_mcp_connector_trust_pack or recipes_mcp_risk_coverage_pack.

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?

There is no guidance about when to use this tool versus the many sibling recipe/risk/pack tools. No alternatives, conditions, or exclusions are provided, leaving the agent to infer the appropriate context.

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?

No annotations are provided, so the description must disclose behavioral traits. The description indicates a read-only operation ('Return'), but it does not mention whether authentication is required, whether results are paginated, whether it is safe to call during planning, or any side effects. The description is minimal and does not add meaningful behavioral context beyond the single verb.

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 a single, grammatically simple sentence with no redundant words, which is concise. However, it lacks structure: it does not front-load the most critical information (e.g., the primary resource or how to target a specific connector). The brevity is appropriate but the content is too vague to be truly efficient.

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 an output schema present (though not shown), the description does not need to explain return structure, but it must explain the tool's role and when to invoke it. Given the extensive sibling list, the description should clarify its unique purpose and parameter usage. It is incomplete for an agent to confidently decide when to use this tool and how to set parameters.

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?

All three parameters are optional and the schema provides no descriptions (schema coverage 0%). The description mentions 'workflow namespace coverage' but does not explain the roles of namespace, workflow_id, or connector_id. It does not clarify whether these act as filters, how they interact, or what formats are expected. The description fails to compensate for the complete lack of schema-level documentation.

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 clear purpose: returns MCP connector trust tiers, controls, evidence, and workflow namespace coverage. The verb 'Return' indicates a read operation, and the resource is MCP connector trust information. However, it doesn't explicitly differentiate from sibling tools like recipes_mcp_connector_intake_pack or recipes_mcp_risk_coverage_pack, though the focus on 'trust tiers' hints at its niche. Slightly distinguishes itself but not fully.

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 use this tool versus the many sibling tools. It does not mention alternatives, conditions for selection, or exclusions. The description implies it is for retrieving trust-related MCP connector data, but there is no explicit 'when to use' or 'when not to use' information, leaving the agent to infer from the tool name and context.

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?

No annotations are present, so the description carries the full behavioral burden. 'Return ... evidence' implies a read-only retrieval, but it does not disclose whether the call is safe, whether filtering parameters affect behavior, what 'evidence' includes, or any side-effect or prerequisite context.

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 a single sentence with no filler and front-loads the action. However, it is under-specified for a tool with five undocumented optional parameters and a highly specialized domain, so brevity is achieved at the expense of necessary 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?

The output schema may document return shape, but parameter semantics, usage context, and boundary evidence meaning are all absent. Given the dense sibling list and cryptic 'elicitation boundary' terminology, this description gives an agent only a weak starting point.

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 does not mention mode, decision, risk_tier, profile_id, or workflow_id at all. These parameter names are ambiguous in this domain, so with no schema descriptions and no parameter guidance in the description, the agent cannot reliably know what values to supply.

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 ('Return') and a resource ('MCP form-mode and URL-mode elicitation boundary evidence'), which differentiates it from sibling boundary packs like stdio_launch or browser_agent. However, 'elicitation boundary evidence' is jargon that is not expanded, so the exact purpose remains somewhat opaque.

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?

There is no guidance about when to use this tool versus the many sibling boundary packs. No alternatives, exclusions, or contextual triggers are provided, leaving the agent to guess which of the roughly 70 sibling recipes this tool fits.

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?

No annotations are supplied, so the description is the only behavioral disclosure. It indicates a return/generation operation, but it does not disclose side effects, authentication requirements, whether generation depends on workflow_id, or any runtime behavior.

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 a single sentence with no filler and front-loads the action and output object. It is efficient, though terse enough that some semantic burden is shifted elsewhere.

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?

Despite low parameter complexity and the presence of an output schema, the description leaves parameter semantics and sibling differentiation entirely unaddressed. The agent still cannot confidently decide when to call this tool or how to pass workflow_id.

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?

workflow_id has zero schema description coverage and the description does not mention it at all. An agent cannot know what values are valid or how null versus a supplied workflow_id affects the generated policy.

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 states a concrete verb and object: 'Return generated MCP gateway policy,' and scopes it to 'scoped tool access and runtime controls.' This clearly identifies the artifact and domain, though it does not explicitly contrast with any of the many sibling recipe tools.

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?

There is no guidance on when to invoke this tool instead of related siblings such as recipes_mcp_authorization_conformance_pack or recipes_workflow_control_plane. No exclusions, prerequisites, or alternative-selection conditions are provided.

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?

No annotations are provided, so the description carries the full burden. It states only that the tool returns a mapping, giving no information about filtering behavior, default handling of the six optional parameters, whether results are restricted by status or risk tier, or what 'generated evidence' refers to. The read-only nature is implied by 'Return' but never confirmed or elaborated.

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 short, which is good, but it is under-specified rather than deliberately concise. The single sentence earns its place as a purpose statement but omits necessary guidance. There is no structure or additional detail that would help an agent use the tool effectively.

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?

Despite having an output schema, the description fails to explain the tool's six completely undocumented parameters, the meaning of 'generated evidence,' or how to interpret the risk coverage results. Given the breadth of sibling tools and the lack of any annotation or schema descriptions, this description is far too thin for reliable tool selection and invocation.

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%, with six optional parameters (status, risk_id, risk_tier, source_id, standard_id, capability_id) and no descriptions in the schema. The description does not explain what any parameter means, how they filter the coverage mapping, or how they combine. This is a significant gap that the description makes no attempt to fill.

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 names a specific verb ('Return') and resource ('OWASP MCP and agentic-skill risk coverage mapped to generated evidence'), making the core purpose understandable. It does not sharply differentiate this tool from the many sibling risk/pack tools, but the 'OWASP' and 'generated evidence' qualifiers provide meaningful context.

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 alternatives such as recipes_mcp_tool_risk_contract or recipes_agentic_assurance_pack. There are no stated conditions, exclusions, or sibling references, leaving the agent to infer usage from the name and one-line description alone.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It does clarify that only publicly documented servers are returned and that the content includes setup and safety guidance, which is useful filtering context. However, it does not describe error handling for unknown server IDs, authorization needs, or freshness/caching behavior.

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 sentence that is front-loaded with the action and object, with no filler or redundancy. Every word contributes to the meaning, and the length is appropriate for a simple retrieval tool.

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?

This is a simple one-parameter getter and an output schema is present, so the return shape is already structured. Still, the description leaves the parameter unexplained and offers no usage context, making it adequate but not fully complete for guiding an agent's selection and invocation.

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 compensate for the unexplained server_id parameter, but it never mentions it. The parameter name and the tool's get semantics make the meaning inferable, but the description adds no actual semantic value beyond the schema.

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 ('Return') and identifies the resource ('one publicly documented MCP server') and the content included ('official setup and safety guidance'). The word 'one' implies a single-item get operation and weakly distinguishes it from list-style siblings, though no sibling is named.

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 no when-to-use guidance, prerequisites, or alternatives. An agent must infer that it is the tool for retrieving a single server by ID, and there is no indication of when to prefer recipes_mcp_servers_list or other lookup tools.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that it searches a catalog; it does not mention whether it is read-only, any side effects, authorization requirements, or the nature of results. This is minimal and does not add beyond the name's implication.

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 a single sentence, which is concise, but it is under-specified for the complexity of the tool. It lacks any structure that would help an agent understand parameters or usage. The brevity is not 'appropriately sized' because it omits essential information an agent needs.

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 three parameters, no annotations, and an output schema, the description is incomplete. It does not explain return value semantics, parameter usage, or when to use this over sibling tools. An agent would struggle to call this tool correctly without further investigation.

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%, meaning the description mentions none of the three parameters (query, limit, availability) or their semantics. The description must compensate for the lack of schema detail, but it fails to explain what these parameters control. This is a significant gap for a tool with three parameters.

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 ('Search') and the resource ('bundled catalog of publicly documented MCP servers and ecosystems'), providing a specific verb+resource. However, it does not distinguish this from sibling tools like recipes_search, recipes_list, or recipes_mcp_upstream_servers, all of which could be confused for similar operations.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention when a search is appropriate, how it differs from a plain list, or any exclusions. The user must infer usage from context, which is not provided.

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?

Since no annotations are provided, the description must disclose behavior. It only says 'Return...', implying a read operation but without confirming side-effect-freeness, auth requirements, or whether results are complete. There is no mention of what happens with null parameters, how many results are returned, or any potential limitations.

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 single sentence is concise but also under-specified. While there is no fluff, the brevity hurts usefulness because it omits critical details. A well-structured description would front-load the primary purpose but still offer parameter context.

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?

This is a 3-parameter tool with no schema descriptions, no annotations, and a rich set of sibling tools. The description fails to explain the tool's role, the meaning of its inputs, or expected output format (even though an output schema exists). It is thoroughly incomplete for correct invocation.

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 schema has 0% description coverage for its three parameters (decision, launch_id, profile_id), so the description must explain their roles. It does not mention any of them, leaving the agent guessing what each parameter controls (e.g., whether decision is a filter or a modifier) and how they interact.

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 states a verb ('Return') and lists four nouns ('MCP STDIO launch boundaries, profiles, decisions, and evidence'), but these terms are undefined and the tool's exact scope is unclear. It does not differentiate from many similar boundary-pack siblings (e.g., recipes_agent_handoff_boundary_pack, recipes_mcp_elicitation_boundary_pack), making it hard for an agent to know what makes this tool distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.