bidda-compliance

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

No annotations provided, so description carries full burden. Discloses no authentication needed, returns aggregate counts per topic, and explains topic-pillar relationship. Misses potential behavioral details like rate limits or pagination, but adequate for a simple read operation.

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?

Five sentences, each earning its place: action, examples, return info, relationship, access, and parameter use. No redundancy or fluff.

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 simplicity (one optional param, no output schema), description covers purpose, return, usage, and access. Could mention error cases or empty results, but overall complete for the domain.

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 100% (parameter described), but description adds value by clarifying optional usage ('Pass a topic string to drill into one') and giving example topic values, surpassing schema alone.

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?

Description clearly states the tool browses compliance topics, provides concrete examples, and distinguishes from siblings which perform other actions (checking compliance, comparing jurisdictions, etc.).

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?

Explicitly mentions 'Free, no key required' and explains how to use the optional topic parameter to drill in. Lacks explicit when-not-to-use or alternatives, but context is clear given sibling tool names.

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 full burden. It explains the input (natural language action) and output (ranked regulations + risk indicator). However, it does not disclose side effects (none expected for a check), authentication requirements, or rate limits. The description is adequate but could be more explicit about non-destructive nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences effectively convey purpose, input/output, and use-case. Examples are illustrative without being verbose. Every word earns its place, making it highly 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?

The description explains the core functionality: input (natural language), output (ranked regulations + risk indicator). With no output schema, it covers return values. It does not discuss error handling or edge cases, but for a compliance check tool, the description is sufficiently complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description reiterates that 'action' is natural language and provides examples, adding some value. For 'limit' and 'jurisdiction', it does not add beyond schema descriptions, so overall it meets but does not exceed the baseline.

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 it is a 'Pre-flight regulatory check' with concrete examples of natural-language actions. It positions itself as 'primary tool for runtime compliance gating', distinguishing it from sibling tools which are more about crosswalks, dependencies, and searching.

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 explicitly frames itself as the primary tool for compliance checks during autonomous workflow execution. While it does not list specific alternatives or when-not-to-use, the context of sibling tools (e.g., get_crosswalk, search_nodes) implies differentiation, and the description gives clear use-case 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, the description carries full burden. It discloses that the tool does not rank jurisdictions (a key behavioral constraint) and requires a subscription (authentication). However, it does not mention side effects or what happens with invalid keys, but overall behavior is well explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences covering purpose, behavioral details, example, and authentication requirement. No redundant text, highly 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?

The description covers the core purpose and behavioral constraints, but lacks details on return format (e.g., how the comparison is presented) and which jurisdictions are compared (all or subset). Given no output schema, more completeness would be beneficial.

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 100% with descriptions for both parameters. The main description adds extra meaning by giving an example of numeric thresholds (72 hours vs 30 days) and clarifying that api_key is the Bidda subscription key, going beyond the schema's basic description.

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 compares jurisdictions side-by-side on a compliance topic, including numeric threshold differences, and explicitly says it does not rank which is stricter. This makes the purpose very specific and distinguishes it from tools that might rank or analyze single jurisdictions.

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 implicitly tells users to use this tool when they need a comparison of jurisdictions on a compliance topic, but it does not provide explicit when-to-use or when-not-to-use guidance relative to sibling tools like get_jurisdiction_bundle or search_nodes.

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 discloses that it consumes one call on the key, records a verified entry, and pins the node version/hash for run receipt. It also mentions the subscription requirement. It doesn't detail side effects like destructiveness, but the recording action is clearly a write operation.

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 paragraph that front-loads the key behavior and provides necessary context. Each sentence contributes meaning without unnecessary fluff. It could be slightly more structured, but it is concise and clear.

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 9 parameters and no output schema, the description explains the combined two-step action and the recording effect. It covers the essential context for an agent to understand when and why to use it. It lacks error handling or prerequisites beyond subscription, but it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since schema description coverage is 100%, the baseline is 3. The description does not add specific parameter details beyond what the schema provides; it only gives high-level context about the tool's purpose. This is adequate but not exceptional.

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 it fetches a full vault node and records a consultation entry in one step, and explicitly distinguishes itself from get_node by specifying it should be used inside a run. The verb 'fetch and record' combined with the resource context is specific and unambiguous.

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 clear guidance: 'Use this instead of get_node when you are inside a run.' It also specifies the prerequisite of an active Bidda subscription and passing api_key. It doesn't explicitly state when not to use it, but the context implies it's not for use outside of a run.

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 covers key behaviors: returns record ID and public verify URL, records are signed and time-stamped for immutability. Does not discuss rate limits, destruction semantics, or error scenarios, but adequately discloses primary 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?

Two efficient sentences plus a requirement line. Front-loads purpose, then return value, then usage guidance. Every word earns its place without redundancy.

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?

Adequate for a creation tool with 5 params (3 required) and no output schema. Describes return values (ID, URL) and subscription requirement. Could clarify optional field behavior and error handling, but overall sufficient for typical use.

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 100% with descriptions; the tool description adds value by noting nodes max 50 and the purpose of api_key (subscription). This supplements rather than repeats schema info.

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?

Explicitly states the tool creates a signed, time-stamped record of Bidda rules relied on for a decision. Distinguishes from siblings like browse_topics or check_action_compliance by focusing on audit trail creation.

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?

Provides clear when-to-use context ('agents that must keep an audit trail') and a prerequisite (active subscription with api_key). Does not explicitly mention alternatives or exclusions but sets appropriate expectations.

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 discloses key behaviors: the record is tamper-evident, obligation nodes are pinned to current version and integrity hash, max 50 nodes, and requires an API key. It does not mention reversibility or retrieval, but the core behavioral traits are well covered.

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 well-structured and concise. It front-loads the main action in the first sentence, explains the mapping and pinning, distinguishes from receipts, and concludes with the requirement. Every sentence adds value with no waste.

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 complexity (9 parameters, no annotations, no output schema), the description is largely complete. It explains the tool's purpose, behavior, prerequisites, and constraints (max nodes). It does not cover error conditions or detailed return format, but these are acceptable gaps without 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?

Schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema descriptions, only clarifying the purpose of nodes (obligation node_ids) and the context for control and statement. It does not significantly compensate for the high schema coverage, so a 3 is appropriate.

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 creates a tamper-evident record for your own controls/policies mapping to obligation nodes. It uses specific verbs like 'Sign' and 'record', distinguishes this design-side evidence from operating-side receipts, and explains the pinning of obligation versions, making the purpose distinct from sibling tools like create_attestation.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear guidance: use for design-side evidence when mapping controls to obligations, and contrasts with receipts for operating-side. It also notes the prerequisite of a Bidda subscription. While it doesn't explicitly state when not to use, the context is sufficient for an AI agent to choose appropriately among siblings.

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?

Discloses return outcomes (fresh, drifted, withdrawn) and batch scaling behavior. No annotations provided, so description carries full burden. It appropriately implies read-only nature without contradiction.

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?

Concise and front-loaded. Every sentence adds value: purpose, inputs, behavior, and plan scaling. No fluff.

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?

No output schema, but description explains return values. Parameter count is low, and no nested objects. All necessary context provided, including API tier 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?

Adds meaning beyond schema: explains hash can be omitted to fetch current fingerprint, and clarifies the purpose of each parameter. Schema coverage is 100%, but description adds valuable context for 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?

Description clearly states the tool checks whether cached compliance rules are current, using specific action (check) and resource (compliance rules). It distinguishes from siblings like check_action_compliance by focusing on cached rule integrity verification.

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?

Describes when to use: when agent has cached rules and needs to verify before acting. Mentions API tier and batch scaling, but lacks explicit when-not or alternatives. Context is clear but no 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?

With no annotations, the description carries full burden. It discloses the requirement for an active Bidda subscription and API key, and clarifies that the tool does not rank or determine compliance. It implies a read-only operation but does not explicitly state side effects, rate limits, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph of three sentences, efficiently front-loading the main action in the first sentence. Every sentence adds value 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?

Given the complexity (3 parameters, no output schema, no annotations), the description covers input, process, output, and constraints. It explains the gap-finding logic and withdrawn rule detection but lacks detail on return format, error scenarios, and depth parameter behavior beyond the 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?

Schema description coverage is 100%, so baseline is 3. The description adds minimal new meaning beyond the schema; it reinforces the 'api_key' requirement and the 'nodes' purpose but does not provide additional context or constraints not already 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 the tool's function: returning prerequisite rules from Bidda's dependency graph that were not listed (gaps) plus withdrawn rules. It uses specific verbs ('return', 'coverage aid') and distinguishes from siblings by disclaiming ranking or determination of compliance.

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 clear context: 'Given the compliance rules a team says it covers' and states it is a 'coverage aid for a qualified reviewer'. However, it does not explicitly mention when to use this tool over alternatives like check_action_compliance or obligation_deltas, nor does it provide when-not guidance.

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

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

No annotations are provided, so the description carries full burden. It details the pack's components and the behavioral difference between sealed and open runs (api_key requirement). This covers all necessary disclosure about the tool's operation and 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 focused paragraph, front-loaded with the core purpose. Every sentence adds essential detail; no fluff. It is efficient and easy to 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?

Given the tool's complexity (2 params, no output schema), the description fully covers purpose, behavioral details, conditional parameters, and pack contents. An AI agent has sufficient information to decide and 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 coverage is 100% with basic descriptions. The tool description adds meaningful context: it clarifies that api_key is conditional on the run being unsealed (open), and implies run_id identifies the specific run. This adds value beyond the schema alone.

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 'Export a run as a governance evidence pack' and enumerates the contents (signed receipt, entries, nodes roll-up, hash-chain, coversheet). It differentiates from siblings like get_run (a simpler retrieval) and record_run_entry (a write operation) by specifying the comprehensive audit pack export.

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 explains when to use the tool: for sealed runs (readable by id) and for open runs (requires api_key). It does not explicitly state when not to use or name alternative tools, but the context is clear enough for an AI agent to decide.

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 must disclose behavioral traits. It reveals that full mapping values are vault-gated (access control) and that 'discovery returns available dimensions' (scope). However, it does not mention rate limits, idempotency, or potential side effects. The information is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no unnecessary words. The first sentence defines the action and resource with examples; the second adds a critical behavioral boundary. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description provides the core purpose and access gating. However, it does not fully describe the return structure or what 'dimensions' look like, leaving room for ambiguity about the output format. Could be more complete given the absence of 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?

Schema coverage is 100% for node_id, so baseline is 3. The description adds meaning by distinguishing between 'discovery' and 'full mapping values', explaining the two-tier nature of the output. This goes beyond what the schema provides.

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 clear resource 'cross-framework mapping dimensions for a node'. It distinguishes from sibling tools like 'get_mitre_mapping' by focusing on regulatory crosswalks and mentions examples (GDPR, CCPA, POPIA). The two-tier access note 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?

The description implies when to use the tool (to get cross-framework mappings) but does not explicitly state when not to use it or offer alternatives. It lacks guidance on choosing between this and siblings like 'get_dependency_chain' or 'get_mitre_mapping'.

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 burden. It explains the operation (walking prerequisite chain), defaults (depth 2, max 4), and typical behavior (3-8 upstream nodes). It implies a read-only operation, which is sufficient for 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 three concise sentences: action, return value, and usage context with defaults. No redundant information; every sentence adds 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?

For a tool with only two simple parameters and no output schema, the description fully covers what the tool does, why to use it, and key behavioral details (like default depth and typical tree size). No gaps.

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 100%, so baseline is 3. The description confirms defaults and adds context about typical usage, but does not significantly extend the schema descriptions (which already document node_id as root and max_depth with min/max/default).

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 verb 'walk' and the resource 'prerequisite chain for a compliance node,' with additional context about returning a full dependency tree. It distinguishes itself from sibling tools like check_action_compliance and get_node by focusing on dependency traversal.

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 explicit usage context: 'Use this to plan a complete compliance posture' and mentions typical upstream nodes. However, it does not specify when not to use it or alternatives, so it stops short of a 5.

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 honestly states the output is compliance nodes, but lacks details on pagination (limit parameter), ordering, or error handling. The schema covers limit, so behavioral disclosure is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no unnecessary words, front-loaded with purpose and use case. Highly concise and 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?

Given no output schema, the description adequately describes the output (compliance nodes) and use case. It lacks explicit mention of return format or default limit, but the schema covers limit details. Complete enough for a simple retrieval 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 100% (both parameters have descriptions). The description adds minimal value beyond the schema, only reiterating the jurisdiction list. Baseline 3 is appropriate as the schema already does the heavy lifting.

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?

Description clearly states the tool returns compliance nodes for a specific jurisdiction, with a specific verb 'return' and resource 'compliance nodes'. It distinguishes from siblings like check_action_compliance (specific action) and get_node (single node) by mentioning 'full regulatory surface for that geography'.

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?

Explicitly says 'Use when an agent enters a new market and needs the full regulatory surface for that geography', providing clear context. While it doesn't explicitly state when not to use it, the context implies it is for the full set, differentiating from sibling 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. It describes a read-only list operation with no destructive behavior, but lacks details on authentication needs, rate limits, or response format. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then usage, then scheduling advice. No redundant words. Every sentence adds 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?

For a tool with low complexity (2 optional params, no output schema, no annotations), the description fully covers purpose, usage, and parameter semantics. No significant gaps.

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 100%, giving a baseline of 3. The description adds minimal value beyond the schema: 'Filter by pillar to focus on a domain' restates the schema. No additional semantics like default values or constraints are newly introduced.

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 lists the most recently updated compliance nodes (regulatory change feed). It distinguishes from siblings like browse_topics or search_nodes by focusing on recency and monitoring.

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 explicitly says when to use it: monitor incoming amendments, new guidance, fresh rules, and call on schedule. It does not mention when not to use or list alternatives, but the context is clear.

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 all behavioral traits. It does not mention side effects, authentication needs, rate limits, or whether the operation is read-only. While the tool is likely safe, the lack of behavioral context 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 description is informative and front-loaded with the key purpose. It uses a metaphor ('Rosetta Stone') and lists supported frameworks, but could be slightly more concise by trimming marketing language like 'Free.'

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 no output schema, the description should describe the output structure more fully. It mentions returning the Bidda node and compliance obligations, but does not detail the format, fields, or whether multiple results are possible. This leaves some ambiguity for the agent.

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 100%, so the parameter is already well-documented with examples. The tool description adds context about frameworks and compliance obligations but does not enhance understanding of the parameter itself 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 clearly states the tool's purpose: given a MITRE technique ID from multiple frameworks, it returns the Bidda node and mapped compliance obligations. The verb 'return' and specific resource ('Bidda node plus mapped compliance obligations') make it distinct from sibling tools like get_node or get_crosswalk.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use: as a bridge between SOC technique IDs and compliance control families. However, it does not explicitly state when not to use or provide alternatives among siblings (e.g., get_crosswalk, get_dependency_chain), which could refine the guidance.

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

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

With no annotations provided, the description carries the full burden. It states the return fields and mentions a full node is available elsewhere, but does not disclose if the operation is read-only, idempotent, or requires authentication. The behavioral transparency is adequate for a simple 'get' operation but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and returns, and includes a clear pointer to additional information. No unnecessary 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?

Given the tool is simple (one parameter, no output schema), the description adequately explains what it does and what it returns. It could mention error handling (e.g., invalid ID) but is otherwise complete for a node retrieval tool with clear sibling differentiation.

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?

Input schema coverage is 100% with a single parameter 'id' having examples. The description does not add meaning beyond the schema; it restates that the tool gets a node by ID. Baseline 3 is appropriate since schema already documents parameter semantics sufficiently.

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 retrieves a compliance node by ID and lists the specific fields returned (title, compliance pillar, version, last updated, BLUF). It distinguishes from sibling tools like get_dependency_chain or get_crosswalk by focusing on a single node summary.

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 makes clear this tool is for fetching a node by ID, which is the primary use case. It does not explicitly mention when not to use it or suggest alternatives, but the context of sibling tools implies different purposes (e.g., get_dependency_chain for dependency info).

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 adequately discloses it's a read operation, specifies authentication requirements, and mentions the return value includes signature validity for sealed runs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no redundancy. The first sentence states the core action, the second adds important 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?

The description covers key aspects: what it returns, access control, and auth needs. Given no output schema, it provides sufficient context for a fetch 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 100%, so baseline is 3. The description adds value by explaining the api_key parameter's purpose for open runs, beyond what the schema provides.

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 fetches a run and its entries, with a specific verb and resource. It distinguishes from sibling tools like open_run or seal_run by focusing on retrieval.

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 context on when to use the tool (to fetch runs) and conditions (api_key needed for open runs), but lacks explicit guidance on when not to use it 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 burden of behavioral transparency. It adds context about the registry (10,065 cryptographically-verified nodes across 39 pillars, listed frameworks) but does not disclose aspects like performance, ordering, or whether the listing is real-time. The description is adequate but not exhaustive.

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 with two sentences, front-loading the main action 'List all compliance pillars'. Every sentence adds value: the first states the purpose, the second gives usage guidance and rich context. 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?

For a tool with no parameters and no output schema, the description covers the main aspects: what it lists (pillars with node counts) and when to use it (first step for discovery). It could be improved by briefly describing the output format (e.g., a list of pillar names and counts), but given the simplicity, it is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema coverage is trivially 100%. Baseline for 0 parameters is 4. The description does not need to explain parameters, and it does not attempt to, so this score is appropriate.

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 verb 'List all compliance pillars' and specifies the resource 'Bidda Sovereign Intelligence registry with node counts'. It distinguishes itself from sibling tools by instructing to use it first for discovery before searching, implying it provides an overview.

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 explicitly says 'Use this first to discover available compliance domains before searching', providing clear guidance on when to use. It does not explicitly state when not to use or compare to alternatives, but the context is sufficient for typical 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?

With no annotations, the description carries the full burden. It discloses that the feed includes both content changes and node withdrawals, and requires authentication. But it does not specify whether the operation is read-only, rate limits, or pagination behavior. The description is adequate but lacks depth on behavioral nuances.

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, two sentences front-loaded with the core purpose and use case. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description covers the tool's purpose, filtering options, and a concrete use case. However, it does not describe the output structure or mention default limits (e.g., default 100), which would aid in complete understanding.

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 100%, so the baseline is 3. The description adds value by stating that the tool is filterable by time, pillar, or nodes, and explicitly ties the api_key parameter to the Bidda subscription requirement, going beyond the schema's generic description.

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 specifies the tool as an obligation-level change feed, detailing what it returns (primary sources with changes mapped to obligation nodes) and its filtering capabilities. It distinguishes itself from siblings like 'watch_changes' by focusing on a pollable feed of changes.

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 a direct use case ('what obligations changed since I last reviewed?') and notes the requirement for a Bidda subscription and api_key. However, it does not explicitly contrast with sibling tools (e.g., watch_changes for real-time) or state when not to use this tool.

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

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

No annotations provided, so description must cover behavior. It explains that the run is tamper-evident and returns a run_id, but does not disclose potential side effects, error handling, or authorization details beyond api_key requirement.

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?

Three sentences, front-loaded with purpose, no wasted words. Could be slightly more structured but remains concise.

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?

Covers the main purpose, workflow, and prerequisite. Lacks details about return value format and edge cases, but sufficient given the simplicity and sibling 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 coverage is 100%, so baseline is 3. The description adds context for api_key (subscription requirement) but repeats schema descriptions for agent and does not mention label. Marginal added 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 clearly states 'Open a run ledger' and explains it is a signed, tamper-evident log, returning a run_id. It distinguishes from sibling tools by mentioning record_run_entry and seal_run as subsequent steps.

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?

Describes the workflow: open run, record entries per turn, then seal. Mentions prerequisite: 'Requires an active Bidda subscription: pass api_key.' Lacks explicit when-not-to-use scenarios but provides clear guidance.

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

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

With no annotations provided, the description carries full burden. It discloses the output structure (reviewed-controls, observations, props) and the access constraint (sealed vs. open run requiring api_key). It does not mention rate limits or error handling, but the key behavioral trait (different auth requirement) is well-covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence front-loads the core purpose and output contents; the second handles the access nuance. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only 2 parameters, no output schema, and no annotations, the description covers the tool's purpose, parameters with conditional behavior, and key output components. It is complete for a straightforward export 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?

The input schema has 100% description coverage, and the tool description adds meaningful context: run_id is 'the run to export' and api_key is 'optional, required for still-open run'. This clarifies the conditional necessity beyond the schema's simple description.

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 verb 'Export' and the resource 'governed run's evidence as a NIST OSCAL assessment-results document', listing the specific contents (reviewed-controls, observations, props). This distinguishes it from sibling tools like get_audit_pack or get_run, which serve different purposes.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool (to get OSCAL assessment-results) and notes the conditional requirement for an api_key on open runs. However, it does not explicitly mention when not to use it or suggest alternatives among siblings, though the context is sufficient.

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 discloses the return type ('signed record') and anchoring mechanism ('public history chain'), plus the authentication requirement. Does not explicitly state read-only nature or failure modes, but sufficient for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines core function, second adds usage guidance and requirement. Every word earns its place, no redundancy.

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?

Lacks output schema, but description compensates by indicating return type. Covers purpose, usage, and prerequisite. Could mention error conditions or rate limits, but adequate for the tool's simplicity.

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 100%, so baseline is 3. The description adds value for api_key ('free trial counts') and clarifies as_of defaults to now, exceeding baseline.

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 ('Get') and resource ('signed record of which committed version of a rule was authoritative at a specific past date'), clearly differentiating from sibling tools like get_node or get_latest_changes.

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?

Provides explicit use case ('show what a rule said at the moment it acted') and a prerequisite ('Requires an active Bidda subscription'). Lacks explicit when-not-to-use or alternatives, but context is clear.

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 burden. It discloses hash-chaining and the need for a subscription, but does not mention safety profile, idempotency, response behavior, or error conditions. Some useful behavior is added but key aspects are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load the purpose, then add integrity details and prerequisites. No wasted words; every sentence adds 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 12 parameters, no output schema, and no annotations, the description covers the core purpose adequately and mentions key points like hash-chaining and verify_nodes. However, it lacks return value information and could elaborate on parameter combinations for a more complete picture.

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 100%, so baseline is 3. The description adds minimal parameter insight beyond the schema, such as the note/input_hash alternative and entry_type defaults. It does not elaborate on parameter interactions or constraints beyond what schema provides.

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 appends an entry to an open run, listing the types of data (rules, decision, user input) and mentions hash-chaining. It differentiates from siblings like open_run and seal_run by focusing on appending during an open run.

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 notes the requirement for an active Bidda subscription and an api_key, and implicitly that the run must be open (via run_id from open_run). It does not explicitly exclude usage after sealing or compare with alternatives, but the context is clear enough.

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

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

No annotations provided, so description carries full burden. It discloses idempotency and output (receipt with verify URL). Missing details on side effects like making run immutable or error conditions when run not open.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with main action, followed by idempotency and requirement. No wasted words, efficient structure.

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?

Without output schema, description explains output nature (signed receipt, verify URL) but omits details about receipt contents and prerequisites like run being open. Adequate for a simple operation.

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 100% with basic descriptions. The tool description adds context about subscription requirement but does not substantially extend parameter meaning 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 clearly states the verb 'seal' and the resource 'open run', producing a 'signed Run Receipt' with a public verify URL. It distinguishes from siblings like 'open_run' and 'record_run_entry' by being the finalization step.

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 specifies a prerequisite (active Bidda subscription with api_key) and implies use after opening and recording entries. However, it does not explicitly state when not to use or mention alternatives like 'get_run'.

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 bears full burden. It discloses key behavioral traits: returns summaries with a one-sentence BLUF, traces to primary legal sources, and claims no hallucination. This adds significant value beyond the schema, though it omits side-effect details (e.g., read-only nature).

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 concise (three sentences) with front-loaded purpose. Every sentence adds value: purpose, output format, and examples. 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?

Despite no output schema, the description covers tool purpose, output format, and trustworthiness (no hallucination). Missing details like pagination behavior or empty results are minor for a search tool. Completeness is slightly above average.

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 100%, so the schema already documents parameters. The description does not enhance parameter understanding beyond what the schema provides; it focuses on output semantics instead. Baseline score of 3 is appropriate.

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 searches 'Bidda compliance nodes by keyword' and specifies the unique output format (BLUF, tracing to primary legal sources). It effectively distinguishes itself from sibling tools like 'browse_topics' or 'get_node' by focusing on search and summarization.

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 example queries to imply usage but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'browse_topics', 'get_node'). No exclusions or when-not-to-use are mentioned, leaving the agent to infer context from examples.

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 explains the core behavior: subscribing and getting notifications when primary sources change. It mentions two delivery channels (email and webhook). However, with no annotations, it lacks details like subscription lifecycle, modification, or limits. Adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first states the function, second adds the prerequisite. It is concise with no fluff. Could integrate the prerequisite into a single sentence, but still 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?

Given the complexity (6 parameters, nested objects, no output schema), the description explains the purpose and notification mechanism. However, it does not mention the return value or how to manage subscriptions (update/delete). Adequate for basic understanding but has gaps.

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 100% with all parameters described. The description adds context by grouping parameters: 'nodes' as specific rules, 'pillars' as whole pillars, and 'channels' & 'webhook_url' for delivery. This adds meaning beyond the schema, but the bar is at baseline 3 due to high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Subscribe to regulatory change alerts'. It specifies the actions (watch specific rules and/or whole pillars) and the notification method (email or webhook). This distinguishes it from sibling tools like 'get_latest_changes' which are one-time queries.

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 explicitly states a prerequisite: 'Requires an active Bidda subscription: pass api_key.' This tells the agent when to use the tool and what is needed. It does not mention alternatives or when not to use it, but the context is clear for a subscription tool.

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