Singapore Business Directory

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

No annotations provided; description carries full burden but omits safety properties (read-only status), return value structure, and whether this validates against ACRA database or local cache.

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 11-word sentence with zero waste; front-loaded with verb 'Check' and precisely defines the operation's domain and scope.

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

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

Appropriate for a simple single-parameter tool; mentions availability checking purpose but could clarify expected response format since no output schema exists.

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 100% schema coverage, description adds valuable semantic context by specifying 'business entity' and jurisdiction (Singapore), elaborating beyond the schema's generic 'entity name' 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?

States specific action (Check), resource (business entity name), and scope (available for registration in Singapore), clearly distinguishing from sibling search/get tools.

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

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

Implies pre-registration use case through 'available for registration' phrasing, but lacks explicit when-to-use guidance or differentiation from search_entities/get_entity 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?

No annotations provided, so description carries full disclosure burden. States 'get' implying read-only access and 'detailed information' suggesting comprehensive data return, but lacks specifics on error handling (invalid UEN), rate limits, or data freshness.

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

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

Two sentences with zero waste. First sentence front-loads purpose (what it does), second sentence provides prerequisite guidance (when to use). 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?

Appropriate for a simple 1-parameter lookup tool with no output schema. Covers the entity retrieval workflow and prerequisite chain. Missing only output format details and error behavior specifics, which would be necessary for a 5 without annotations.

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%, establishing baseline 3. Description mentions 'by UEN' but adds no semantic detail beyond the schema's existing 'Unique Entity Number (UEN) of the company' description. Schema already contains the prerequisite guidance about search_entities.

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?

Clear specific verb ('Get'), resource ('detailed information about a specific entity'), and scope ('by UEN'). Distinguishes from sibling search_entities by specifying UEN-based lookup vs name-based 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?

Excellent explicit guidance: 'If you only have a company name, call search_entities first to obtain the UEN, then call this tool.' Names the prerequisite workflow and alternative tool directly.

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 mentions pagination and filtering but does not disclose rate limits, authentication needs, or the fact that it is a read-only operation. The schema already details parameters, so description adds limited behavioral context beyond usage patterns.

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 the verb 'Search', no redundant information. Every sentence adds distinct value: first sentence states overall capability, second provides usage pattern.

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 9 parameters (all optional, 100% schema coverage) and no output schema, the description covers the two main use cases. It could mention the return format or typical response, but it is sufficient for a list tool with good schema documentation.

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 two main usage scenarios involving query and filter parameters, which is not obvious from the schema alone. However, it does not elaborate on each parameter beyond what is 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: searching, listing, filtering, sorting, and paginating Singapore business entities. It distinguishes from sibling tools like check_name_availability, get_entity, and search_ssic by specifying entity search vs. name availability, single entity retrieval, or SSIC code 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?

Provides explicit guidance on when to use a query (for name/UEN search) versus when to omit query and use filters (to list newly registered entities). This helps the agent choose the correct invocation pattern.

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 discloses the query logic (AND for keywords) and input formatting (space-separated, comma-separated), but omits safety characteristics, rate limits, or whether this accesses a live government database versus cached data.

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

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

Two sentences with zero waste. First sentence establishes purpose and resource; second provides parameter syntax guidance. The structure front-loads the actionable verb and resource before detailing input formats.

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?

Input parameters are well-documented between schema and description, but without an output schema, the description fails to indicate what the tool returns (e.g., just codes, code-descriptions pairs, or full hierarchical classifications). For a search tool with optional parameters, return value disclosure is necessary for complete 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%, establishing a baseline of 3. The description adds value by defining the SSIC acronym (domain context for the search target) and succinctly summarizing the parameter relationship ('and/or'), which reinforces that these are alternative filtering strategies.

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 searches for 'SSIC (Singapore Standard Industrial Classification) codes' using keywords or peer entities. It defines the acronym and distinguishes the domain (industry classification codes) from siblings that handle entity lookups and name availability.

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?

While it doesn't explicitly name sibling alternatives, it effectively guides usage by describing the two distinct query patterns: keywords (with AND logic) for description matching versus peers (UENs) for entity-based lookups. The 'and/or' construction signals that either or both approaches may be used.

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