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 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?

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 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?

Discloses that the tool returns a list of pillars with node counts and provides specific statistics (10,040 nodes, 39 pillars, MITRE frameworks). Could be improved by specifying the output format, but given no annotations, it sufficiently describes the 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?

Three concise sentences, front-loaded with the main action. Every sentence adds value (purpose, usage guidance, illustrative details). 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?

Adequately covers the tool's role in the workflow and content, but lacks explicit description of return format (e.g., array of objects). Given the absence of an output schema, slightly more detail would strengthen completeness.

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?

No parameters exist, so schema coverage is trivially 100%. Description adds no parameter details but is not needed. Baseline 4 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?

Describes the tool as listing all compliance pillars with node counts, specifying the resource (Bidda Sovereign Intelligence registry) and explicitly distinguishing from sibling tools like search_nodes by recommending use before 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?

Explicitly states 'Use this first to discover available compliance domains before searching,' providing clear when-to-use guidance and implicitly differentiating from search 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 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, 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?

Discloses hash-chaining, subscription requirement, and default entry_type. No annotations provided, so description carries full burden; covers key behavioral aspects.

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 fluff. Front-loaded with 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?

Covers main functionality and preconditions, but lacks details on return values or error handling. Adequate for a logging tool with 9 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 covers all 9 parameters with descriptions. Description adds context about hash-chaining but not per-parameter details. Baseline 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?

Clearly states 'Append one entry to an open run' and lists what the entry contains. Distinguishes from sibling tools like open_run and get_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?

Specifies prerequisite of active Bidda subscription and need for api_key. Implicitly indicates use after open_run, but doesn't explicitly say when not to use or provide 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 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.