Close API

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

Discloses metered token cost (1 token per returned row) and that rows carry a numeric mode_id. Indicates it is a read-only query. Without annotations, the description provides useful behavioral context beyond the schema, though it could mention result structure or limits more explicitly.

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 main purpose, no redundant words. Each sentence adds essential information: purpose, area specification, token cost, and output hint.

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 and no annotations, the description covers the main purpose, area methods, token cost, and a hint about output format. The 7 parameters are fully described in the schema. Missing details like exact output columns or pagination, but sufficient for an agent to invoke correctly.

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

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

Schema coverage is 100% with each parameter described. The description adds meaning by clarifying the mutual exclusivity of place_geoid vs lat/lon/radius and the source of place_geoid (find_place). This contextualizes parameter usage beyond the schema descriptions.

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 per-block travel times for an area, with two area specification methods (place_geoid or lat/lon/radius). This verb+resource is specific and distinguishes from sibling tools like isochrone or nearby_pois.

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 how to specify the area: using place_geoid from find_place for a whole city, or center lat/lon+radius. Mentions token cost as a usage consideration. Does not explicitly state when not to use or compare to alternatives, but the context is clear enough.

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

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

With no annotations, the description carries full burden. It discloses that the tool is 'free, no key' and returns specific data (GEOID, centre point). This is sufficient for a read-only lookup tool. It lacks explicit mention of side effects, but none are expected.

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 exactly two sentences, both essential. The first states purpose and returns, the second provides usage chaining. 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's simplicity (2 parameters, no output schema), the description is complete. It explains the return value and how to use it with sibling tools.

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 both parameters described. The description adds minimal extra meaning beyond the schema, such as 'City or town name' which is already in the schema. 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 uses specific verbs and resources: 'Look up a US city or town by name' and 'Returns matches with their census place GEOID and centre point (lon/lat).' It clearly distinguishes this tool from siblings like blocks_in_area and walkability_summary by stating it provides the input for them.

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 guides on how to use the output: 'feed a GEOID to blocks_in_area, or a centre to walkability_summary.' This provides clear usage context. However, it does not explicitly state when not to use this tool or suggest alternatives, but the purpose is clear enough.

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

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

With no annotations, the description provides behavioral context: it lists data (free, no key) and specifies constraints like 'no drive mode'. Does not detail rate limits or auth, but for a simple listing, this is sufficient.

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 wasted words. Front-loaded with action and resource, immediately useful.

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 all needed context for a zero-parameter tool: what it lists, why to use it (resolve IDs), and a constraint (no drive mode). No gaps given the low complexity and lack of 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?

No parameters exist, so schema coverage is 100%. The description adds value by explaining what the tool returns (modes and taxonomy) and its purpose, beyond just the empty 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?

Clearly states the tool lists travel modes and destination-type taxonomy, with specific verb 'list' and resource description. Distinguishes from siblings by focusing on taxonomy, not location-based 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?

Explicitly instructs to use for resolving type names to numeric IDs for other tools. Also notes that modes are walk, bike, transit (no drive), setting expectations and guiding proper usage.

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

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

No annotations provided, so description carries full burden. Discloses key behavioral traits: operation is read-only (no token spending) and works at zero balance. Could mention rate limits or response format, but for a simple balance check this is sufficient.

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?

Extremely concise: two sentences that front-load the core verb and resource. Every word adds value—no filler 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?

Covers the essential aspects: purpose, side effects, prerequisites. Lacks specification of the return value format, but given the low complexity (no params, no output schema), the description is mostly complete. A slightly richer description could mention the response type.

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 has zero parameters, and schema description coverage is 100%. The description adds context by explaining that no input is needed and that the tool checks the balance of the authenticated key. Since there are no parameters, the description effectively fulfills the role.

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 the action ('Check the token balance'), the resource ('of the API key in use'), and a key property ('without spending any tokens, works even at a zero balance'). Distinguishes from sibling tools which are unrelated to token balance.

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 describes when to use (to check token balance) and a prerequisite (Requires Authorization bearer key). No alternatives among siblings, so exclusion guidance is not needed. Could be more specific about typical use cases.

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 adds value by mentioning metering (10 tokens per contour) and response size warning, but lacks details on error handling, direction defaults, or required parameters.

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 the purpose front-loaded, 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 7 parameters, no output schema, and no annotations, the description covers key usage aspects: location, default contour, metering, and size. It could mention direction default or that mode defaults to walk.

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 description clarifies location input options (block_geoid vs lat+lon) and advises on contour defaults, adding meaning beyond the schema's 57% coverage. However, it does not enumerate direction values or exact formats.

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 computes the area reachable within a time budget as GeoJSON contours. It is specific and distinguishes from sibling tools like blocks_in_area or nearby_pois.

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 recommends giving block_geoid or lat+lon and warns against asking for many contours, but does not explicitly state when to use this tool versus alternatives or provide 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?

No annotations provided. Description discloses key behaviors: returns a Stripe Checkout URL, user pays in their own browser, requires a fresh code. Missing details on error handling or idempotency but acceptable for a simple 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?

Concise yet comprehensive. Two sentences front-load the main action and include critical details (cost, benefits, workflow, prerequisite). No extraneous 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's simplicity (2 params, no output schema, no annotations), the description covers the essential context: action, user interaction, prerequisite. Could mention error states but not necessary for basic functionality.

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 50% because email lacks description. Description adds meaning: code is six-digit from email, email is user's. Partially compensates but does not fully describe email format or constraints.

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 'Get' and resource 'Stripe Checkout URL for the Close+ membership', including specific benefits ($10/month, 5,000 API tokens) and distinguishes from siblings by referencing request_sign_in as a prerequisite.

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 the workflow: give the user the URL and stop. Also specifies a prerequisite: a fresh six-digit code from request_sign_in. Does not explicitly state when not to use but context is clear.

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

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

No annotations provided; description fully shoulders transparency. Discloses token cost (1 per row), batch behavior (no limit/pagination, rows tagged by origin), truncation conditions (balance/row budget), and rate-limit request count. Contradicts nothing.

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?

Four sentences, each packed with information. Front-loaded with main action and key constraints. Could be slightly more structured (e.g., separate single vs batch), but 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?

9 parameters, no output schema, no annotations. Covers origins, batching, filtering, token cost, truncation. Lacks output format details but given complexity and zero annotations, the description is highly informative.

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 67%; description adds critical meaning: distinguishes single vs batch origins (lat+lon/block_geoid vs points/block_geoids), explains limit applies only to single origin, clarifies max_minutes cap (<=30). Does not detail every parameter but compensates with behavioral context.

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 ('travel time to each') and resource ('points of interest'), specifies origins (block_geoid or lat+lon) and batch capabilities, and distinguishes from siblings by highlighting batch processing and token costing.

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: keep limit small for cost control, filter with type/mode/max_minutes, use batching to save requests. Does not explicitly state when not to use, but covers key usage scenarios.

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 transparency burden. It discloses that the API key is shown once, grants 5,000 free tokens, and should be stored as an Authorization bearer. It could mention error cases but adequately covers key behavioral traits.

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 sentences, front-loaded with purpose and return value, followed by prerequisite and token usage. Every sentence adds value with no redundancy.

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

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

The description covers the core flow (sign-up, key return, token grant) but misses details on error handling, one-time use guarantee, return format (just 'API key'), and the purpose of the optional 'label' parameter. Given no output schema, more return context would help.

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 67% (code and label documented, email missing). The tool description does not add meaning for the 'email' parameter, which lacks schema description. It merely implies email is used for identification but doesn't specify format or purpose beyond 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 completes sign-up using a six-digit code and returns a new API key. It specifies the resource (API key) and action (redeem code), and distinguishes from sibling 'request_sign_in' by noting it as a prerequisite.

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 to call 'request_sign_in' first, providing clear context on when to use this tool. It doesn't list alternatives or when not to use, but the prerequisites are well-defined.

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 reveals that the tool sends an email (side effect), is part of a two-step signup process, and yields an API key with free tokens. This provides useful behavioral context beyond the schema.

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 redundant words, front-loaded with action. Every sentence adds value, making it highly 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?

For a simple tool with one parameter and no output schema, the description fully covers the purpose, process, and next step (redeem_code). No 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?

The single parameter 'email' is fully described in the schema (100% coverage). The description adds that the email is used to send the code, but no additional semantic meaning beyond 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 'start free sign-up' and the resource 'user' with the action of emailing a six-digit code. It distinguishes from sibling tools like 'redeem_code' by mentioning the follow-up 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?

Explicitly tells the agent that the user must read the code and then call redeem_code, providing clear context for when to use this tool. It does not explicitly state when not to use it, but the guidance is sufficient.

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

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

Discloses metering (1 token per row), batch behavior (rows tagged by origin), truncation signaling (non-empty truncated + truncated_reason), and the implication of missing categories (unreachable within 30 min). Since no annotations exist, the description fully carries the burden and does it well.

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

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

The description is concise given the tool's complexity, with key information front-loaded. It could be slightly more structured (e.g., separating input and output behavior), but it remains clear and informative without 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?

Covers input scenarios (single vs batch, origin types), behavioral details (metering, truncation, batching trade-offs), and output interpretation (missing categories). With no output schema, it adequately explains what to expect from results, making it contextually complete.

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

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

Schema coverage is 67% (lat/lon lack descriptions). The description adds value by explaining how parameters are used (single origin via lat+lon or block_geoid, batch via points or block_geoids, mode options). It compensates for schema gaps but does not enumerate each parameter.

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 computes fastest travel times from an origin to destination categories by mode. It distinguishes itself from sibling tools like isochrone (which focuses on reachable areas) or nearby_pois (which lists points of interest).

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 explains when to use single vs batch origins, mentions batching saves API requests and rate-limit requests but not tokens, and warns about truncated results. This provides clear guidance on tool selection and usage context.

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