num

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, reducing the burden on the description. The description adds value by disclosing the quota cost ('Counts against your daily read quota'), which is a behavioral trait not captured by annotations. It does not discuss rate limits or response format, but given the annotation coverage, this is above adequate.

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 short sentences with zero wasted words. The first sentence front-loads the core purpose ('Full record for one place by place_id'), and the second adds a key constraint. 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?

The tool has low complexity (one parameter, no enums, no nested objects). However, with no output schema, the description should compensate by describing the return value. It says 'Full record' but does not outline what fields the record contains. The quota warning is present. The description is adequate but leaves a gap regarding the output structure.

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%: the input schema already documents the single parameter (place_id) with a description. The tool description does not add further semantic meaning for the parameter. Per the scoring rule, with high schema coverage, the baseline 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 states 'Full record for one place by place_id' which uses a specific verb ('get' is implied) and clearly identifies the resource (place by unique ID). It distinguishes itself from sibling tools like num_search_places (which returns multiple results) and num_list_submissions (which is about submissions).

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 mentions a usage constraint ('Counts against your daily read quota') but does not explicitly state when to use this tool versus alternatives such as num_search_places. The input schema references place_id from num_search_places, implying a prior search step, but no clear 'when to use / when not to use' guidance is provided.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering safety and side-effect profile. The description adds that it is 'free and unmetered', which is useful cost context beyond annotations, but does not elaborate on response format, pagination, or any potential side-effects or auth requirements. With strong annotations, the added value is modest but adequate.

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

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

The description is a single clear sentence, front-loaded with the core purpose and adding the 'free and unmetered' note. It conveys essential information without waste, making it very concise 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?

The tool has 3 optional parameters, no output schema, and is a simple listing operation with strong annotations. The description covers the purpose and cost, but does not specify the response shape, pagination behavior, or parameter semantics. For a simple read-only list with an intuitive schema, this is adequate but not fully complete; it could benefit from mentioning that status filters results and that limit/offset are for pagination.

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

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

Schema coverage is 0%, meaning the description does not explain any of the three parameters (limit, offset, status). However, the schema itself has clear names and types: limit has min/max, offset is an integer, and status is an enum with obvious values. The description's mention of 'submissions' and 'reviewer decided' gives context but not parameter-specific meaning. Baseline 3 is appropriate because the schema is fairly self-documenting, though description could add value by mentioning that status filters by submission state.

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 title and description clearly state this lists a user's submissions, with the description adding that it includes reviewer decisions. It is distinct from siblings like num_submit_business and num_submit_promo, which are for creating submissions, and num_search_places which searches places, so it differentiates well.

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 a read-only listing of submissions with reviewer decisions, which fits with the readOnlyHint. It does not explicitly state when to use this versus alternatives, but sibling names make it apparent that this is the listing tool while others are for submission or searching. However, no exclusions or alternative recommendations are provided.

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

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

The description notes that the tool 'Counts against your daily read quota,' which is a behavioral detail beyond the annotations (readOnlyHint, idempotentHint, etc.). The annotations already indicate it is read-only and non-destructive, so the description adds useful quota information without contradicting anything.

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: one clearly stating purpose and scope, the second providing usage constraint and a behavioral note. Every sentence is informative and non-redundant. 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 there is no output schema, the description does not detail return format, but the annotations (openWorldHint) suggest flexibility. The tool has only 5 parameters, all documented, and the description is sufficient for an agent to invoke it correctly. It covers purpose, constraint, and quota impact, but could optionally hint at pagination or default 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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minor value by summarizing the requirement (give at least one of q, city, country or category), but this is already inferable from the schema's lack of required parameters. A 4 is justified as the description does not conflict or add major new 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 searches a directory of 2.5 million places across many destinations, listing specific examples like restaurants, bars, hotels, etc. It distinguishes itself from siblings, such as num_get_place which likely retrieves a specific place, by focusing on search functionality.

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 when to use the tool — to search for places — and provides a clear prerequisite: at least one of q, city, country, or category must be given. It does not explicitly mention when not to use it or name alternative tools, though the sibling list provides 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?

Annotations provide readOnlyHint=false and destructiveHint=false. The description adds key behavioral traits: the submission is reviewed by a person and nothing goes live automatically. However, it does not explain the callback_url mechanism, idempotency behavior (despite external_ref hinting at it), or what happens after submission. Some transparency is provided, but gaps remain.

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 four sentences, tightly packed with meaningful information: purpose, freeness, review process, ethical guidelines. No filler. Front-loaded with the core action. 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 15 parameters, no output schema, and a callback mechanism, the description lacks important context. It does not explain the response format, the callback flow, or the external_ref idempotency feature. While the human review note is useful, the tool's full workflow is not conveyed, leaving an agent underinformed.

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 low (40%). The description adds generic semantics for relationship and contact parameters (e.g., 'Say honestly whether you own the business' and 'Never invent contact details'), but does not detail each of the 15 parameters or explain optional fields like callback_url or external_ref beyond what the schema already describes. The contribution is marginal.

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 'Submit a business to NUM' with a specific verb and resource. It distinguishes from sibling tools like num_search_places and num_list_submissions by focusing on submission for review. The additional context of free/unmetered and human review reinforces its unique role.

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

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

The description provides ethical usage guidance (e.g., 'Say honestly whether you own the business' and 'Never invent contact details') but does not explicitly compare to sibling tools like num_submit_promo or state when not to use this tool. The guidance is helpful but lacks direct alternatives or exclusions.

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

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

The description adds valuable behavioral context beyond annotations: 'Free and unmetered, and reviewed by a person before it is shown to anyone.' This clarifies costs, rate limits, and human review. No contradiction with annotations is present. However, it does not disclose aspects like response time or what happens if the business is 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?

The description is a concise two-sentence structure, front-loaded with the primary action. Every sentence adds value: the first states what the tool does, the second adds important behavioral traits. No fluff or 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 the tool has 10 parameters and no output schema, the description is too brief. It does not explain the return value, the human review timeline, required prerequisites (e.g., business must exist), or how to handle the `kind` enum. The description lacks sufficient context for an agent to use the tool confidently.

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 schema description coverage at 50% (5 of 10 parameters described), the description does not compensate. It only mentions needing a business but does not clarify which parameter (`submission_id` or `external_ref`) to use, nor does it explain the meaning of `kind` values or other parameters. The description adds minimal parameter guidance.

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

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

The description clearly states the verb 'post' and the resource 'promotion, special, event or ad' attached to a previously submitted business. It distinguishes this from siblings like `num_submit_business` by specifying the requirement of an existing business, 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 the tool is for adding promotions to already-submitted businesses ('against a business you already submitted'), but it does not explicitly state when to use this versus alternatives (e.g., `num_submit_business` for new businesses). No when-not-to-use guidance is provided.

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