OpenSOSData

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

Annotations declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds behavioral context: it specifies a maximum batch size of 10 and that results are returned in order, which are useful details not covered by annotations. However, it does not disclose other traits like rate limits, error handling, or auth needs, so it adds some value but not comprehensive behavioral insight.

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 core purpose and followed by key constraints (max batch size, result order). Every sentence earns its place by providing essential information without waste, making it efficient and well-structured.

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

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

Given the tool's moderate complexity (batch search with constraints), annotations cover safety, and schema fully documents inputs, the description adds necessary context like batch limits and result ordering. However, without an output schema, it could benefit from more detail on return values or error cases, leaving minor gaps in completeness for a tool with no 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 description coverage is 100%, with the schema fully documenting the 'searches' parameter including its structure, max items, and nested fields. The description mentions 'maximum 10 entities per batch' and 'search for multiple business entities simultaneously across different states,' which aligns with but does not add significant meaning beyond the schema. Baseline 3 is appropriate as the schema handles 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?

The description clearly states the verb 'search' and resource 'multiple business entities simultaneously across different states,' distinguishing it from sibling tools like 'search_business_entity' (singular) and 'check_entity_status' (status check). It specifies the batch nature and scope, making the purpose explicit and distinct.

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

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

The description implies usage for batch searches across states, but does not explicitly state when to use this tool versus alternatives like 'search_business_entity' or other siblings. It provides context (multiple entities, different states) but lacks explicit exclusions or named alternatives, limiting guidance to clear context without full differentiation.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about compliance use cases but doesn't disclose behavioral traits like rate limits, authentication requirements, or what happens with invalid inputs. With annotations covering safety, a 3 is appropriate for adding some value without rich behavioral details.

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

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

The description is two concise sentences with zero waste. The first sentence states the purpose and scope, and the second sentence provides usage guidelines. Every sentence earns its place by adding distinct 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 the tool's moderate complexity (2 parameters, no output schema) and good annotations, the description is mostly complete. It covers purpose, scope, and usage contexts well. However, it lacks details on return values or error handling, which would be helpful since there's no 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 description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or constraints. Baseline 3 is correct when the schema does all the heavy lifting for parameters.

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

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

The description clearly states the specific action ('verify'), resource ('business entity'), and outcome ('active, inactive, or dissolved') with jurisdictional scope ('specific US jurisdiction'). It distinguishes from siblings like 'search_business_entity' by focusing on status verification rather than general search.

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 contexts ('KYB compliance, due diligence, and vendor verification workflows'), which gives clear guidance on when to use this tool. However, it doesn't specify when NOT to use it or name alternatives among siblings, though the purpose differentiation implies when to choose this over 'search_business_entity'.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false, which the description aligns with by describing a read operation ('Check'). The description adds valuable behavioral context beyond annotations by specifying what is returned ('remaining lookups and a link to add funds'), which helps the agent understand the output format and potential actions, though it lacks details on rate limits or error conditions.

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

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

The description is a single, well-structured sentence that efficiently conveys the tool's purpose and return values without any wasted words. It is front-loaded with the main action and resource, making it easy for an agent to parse and understand quickly.

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 (0 parameters, read-only operation) and lack of an output schema, the description provides sufficient context by explaining what the tool does and what it returns. However, it could be more complete by mentioning potential error states or authentication requirements, though annotations cover safety aspects adequately.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output. This meets the baseline for tools with no parameters, as it avoids unnecessary details while maintaining clarity.

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 specific action ('Check'), resource ('OpenSOSData credit balance and account status'), and distinguishes from siblings by focusing on account information rather than entity searches or jurisdiction listings. It explicitly mentions what is returned ('remaining lookups and a link to add funds'), making the purpose distinct and comprehensive.

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 usage context by stating 'Check your current... credit balance and account status,' suggesting it should be used when needing to monitor account resources. However, it does not explicitly state when to use this tool versus alternatives like batch_search or check_entity_status, nor does it provide exclusions or prerequisites, leaving some ambiguity in tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about its usefulness for 'multi-state compliance checks', which hints at practical applications, but does not disclose additional behavioral traits such as rate limits, authentication needs, or what 'jurisdictions' entail (e.g., states, territories). With annotations covering safety, the description adds some value but not rich behavioral details.

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

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

The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds practical context. Both sentences earn their place by providing clarity and utility without redundancy or unnecessary details. It is efficient and well-structured for quick understanding.

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 low complexity (1 parameter, 100% schema coverage, annotations provided, no output schema), the description is reasonably complete. It explains the tool's purpose and usage context. However, without an output schema, it does not describe return values (e.g., format of the jurisdiction list), which is a minor gap. The annotations help cover safety aspects, making the description adequate but not fully comprehensive for output expectations.

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%, with the 'region' parameter fully documented in the schema, including an enum list. The description does not add any parameter-specific details beyond what the schema provides, such as explaining the 'all' option or differences between regions. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate with extra semantics.

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: 'Get the list of US jurisdictions in a specific region.' It specifies the verb ('Get') and resource ('list of US jurisdictions'), but does not explicitly differentiate it from sibling tools like 'list_supported_jurisdictions', which might have overlapping functionality. The mention of 'multi-state compliance checks' adds context but doesn't fully distinguish it.

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 implied usage guidance: 'Useful for multi-state compliance checks and understanding regional coverage.' This suggests when to use the tool, but it does not explicitly state when not to use it or name alternatives like 'list_supported_jurisdictions' for comparison. The guidance is helpful but lacks specificity about exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about what specific data is returned (53 US jurisdictions with coverage details), which goes beyond the annotations. However, it doesn't describe format, structure, or any behavioral constraints like rate limits.

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

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

Single sentence that efficiently conveys the tool's purpose, scope, and specific content. Every word earns its place - no redundancy, no unnecessary elaboration. Perfectly front-loaded with the core functionality.

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 parameterless read-only tool with good annotations, the description provides sufficient context about what data is returned. However, without an output schema, it could benefit from mentioning the return format or structure. The description covers the essential 'what' but leaves the 'how' of the response unspecified.

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

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

With 0 parameters and 100% schema description coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since there are none, and instead focuses on what the tool returns, which is the correct emphasis for a parameterless tool.

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

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

The description clearly states the verb ('Returns') and resource ('all 53 US jurisdictions with live business entity search coverage'), specifying exactly what the tool does. It distinguishes from siblings by focusing on jurisdiction listing rather than searching or checking status, and provides concrete examples of what's included.

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 usage context by mentioning 'live business entity search coverage,' suggesting this tool should be used when needing to know which jurisdictions support entity searches. However, it doesn't explicitly state when to use this vs. alternatives like 'get_jurisdictions_for_region' or provide explicit 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context beyond annotations by specifying the return fields (entity name, ID, status, etc.) and jurisdiction coverage, but it does not disclose behavioral traits like rate limits, authentication needs, or pagination. With annotations covering safety, this provides moderate additional value.

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 efficiently structured in two sentences: the first states the purpose and parameters, and the second specifies return fields and jurisdiction coverage. Every sentence adds essential information without redundancy, making it front-loaded and appropriately sized for the tool's complexity.

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 moderate complexity (2 required parameters, no output schema), the description is largely complete. It covers purpose, parameters, return fields, and jurisdiction scope. However, it lacks details on error handling, result limits, or how to interpret the return fields, which could be helpful for an agent. Annotations provide safety context, but some operational gaps remain.

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%, with clear descriptions for both parameters ('state' and 'entity_name'). The description adds minimal semantic value beyond the schema by reinforcing the parameter roles ('by name in a specific state or territory') and noting the state code format includes territories, but it does not provide additional syntax, examples, or constraints. Baseline 3 is appropriate as the schema 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?

The description clearly states the specific action ('Search for a US business entity by name in a specific state or territory'), identifies the resource ('business entity'), and distinguishes it from siblings like 'batch_search' (which likely handles multiple searches) or 'check_entity_status' (which focuses on status verification). It explicitly mentions the scope ('all 53 US jurisdictions') and return fields, making the purpose 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 implies usage by specifying the search context ('by name in a specific state or territory') and jurisdiction coverage, but it does not explicitly state when to use this tool versus alternatives like 'batch_search' or 'check_entity_status'. No exclusions or prerequisites are mentioned, leaving the agent to infer appropriate scenarios based on the description alone.

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