Whaber Oracle

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

Without annotations, the description reveals the underlying API (Google Routes v2 with real-time traffic) and components (buffers, wait times, altitude modifiers). However, it omits error handling, rate limits, or fallback behavior, slightly reducing transparency.

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 no redundancy. The first sentence states the main purpose and key features; the second adds technical context. Every word carries weight.

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 purpose, behavioral traits, and parameter hints well. Missing output schema or return value description is a minor gap, but the tool's function is clear.

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?

All parameters have schema descriptions, so baseline is 3. The description adds context about flight_number enabling flight-specific buffers, but other parameters are not further elaborated. Adequate but not exceptional.

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 calculates recommended departure time for transfers in Quito, specifying inclusions like traffic buffers, airport wait times, and Quito-specific modifiers. This distinguishes it from sibling tools which focus on compliance, safety, or route enrichment.

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 use for departure time calculations but does not explicitly state when to use versus alternatives like 'whaber_enriched_route'. No mention of conditions where this tool is inappropriate 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?

With no annotations, the description carries full disclosure burden. It honestly states the tool is a hard gate that triggers a full service block, and lists all 7 documents checked. It does not cover authentication or side effects, but the key behavioral trait (severity of failure) is clearly communicated.

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, dense paragraph with no filler. It front-loads the key purpose and immediately lists the critical details (7 documents, hard gate behavior). Every sentence contributes essential information.

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 explains the return value ('binary compliant/non-compliant verdict') and the implications. It covers input, process, and outcome. It could mention error handling but is mostly complete for its complexity.

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 difference between 'full' and 'quick' check types (expiry dates vs. active status), which is not in the schema. However, it doesn't add new meaning for 'carrier_id' 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 uses specific language ('Full 7-document ANT compliance check', 'hard gate', 'binary compliant/non-compliant verdict') that precisely defines the tool's function. It distinguishes from sibling 'whaber_validate_carrier_compliance' by emphasizing the hard gate nature and full service block.

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 clearly states when to use this tool: for a strict enforcement gate that blocks service on any missing document. However, it does not explicitly contrast with alternatives like 'whaber_validate_carrier_compliance' or advise when not to use it.

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 stand alone. It discloses the tool's high cost, use of multiple APIs, and returned data fields. It does not mention error behavior or rate limits, but the detail is adequate for a calculation 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 two sentences, front-loaded with key functionality and ends with a usage note. Every sentence adds value, 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?

Given the tool's complexity (multiple APIs, high-cost) and no output schema, the description lists the main return fields (ETA, distance, traffic alerts, night-mode flag) and mentions encoded polylines. It could clarify if the polylines are part of output, but overall it is complete enough.

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 100% coverage, with each parameter described. The description adds no new information beyond the schema—it restates the origin/destination types and departure_time requirement. Thus, 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 calculates a transfer route with specific APIs and lists return values (ETA, distance, traffic alerts, night-mode flag). It is distinct from sibling tools like whaber_calculate_ops_window or whaber_get_hotel_context.

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 'Highest-cost tool — use when route fidelity is critical for scheduling,' providing clear context for when to use it. It implies not to use it for non-critical scenarios but does not name specific 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 are provided, so the description carries full burden. It clearly states the tool returns operational context and lists the categories of information. For a read-only operation, no further behavioral details (like side effects or auth) are needed, though some could be added.

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, front-loaded sentence with no extraneous words. It efficiently conveys the tool's action and scope, making every word earn 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 the tool's simplicity (one parameter, no nested objects, no output schema), the description fully covers what the tool returns and what is required. It is complete for its complexity level.

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 100% coverage for the single parameter (hotel_name) with examples. The description adds that it's for a registered hotel, but this adds little beyond what the field description already conveys.

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 starts with a specific verb 'Returns' and identifies the resource 'operational context for a hotel registered in the Whaber Place Graph'. It enumerates four concrete categories (pickup point, checkout policy, VIP rules, services), making the purpose very clear and distinct from sibling 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?

The description does not explicitly state when to use this tool versus alternatives. It implies usage for retrieving hotel context, but lacks guidance on exclusions or comparisons with sibling tools like whaber_get_safe_pickup_point.

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 coordinates are validated by local drivers, that raw risk scores are never exposed (moatGuard enforced), and that a zone safety label is semantic. This provides valuable behavioral context beyond a generic description.

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 states the core function and validation, second details output and security policy. No unnecessary words, well-front-loaded.

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 purpose, validation, and output contents (carriers, instructions, safety label). However, since there is no output schema, it does not fully specify the return structure (e.g., does it return coordinates? multiple points?). Missing details on error handling or fallback 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?

Schema coverage is 100% and already describes all three parameters well. The description adds context: service_time is used to determine zone safety at that hour, and the safety label is semantic. This extra information aids correct parameter 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?

The description clearly states it returns a physically verified safe pickup point for a hotel or airport in Quito, specifying validated coordinates and included carriers/instructions. This is distinct from sibling tools like whaber_query_place_safety which handles general safety 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 implies when to use (to get a safe pickup point), but does not explicitly state when not to use or mention alternatives. It provides some context about the safety label being semantic, but lacks direct usage boundaries.

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 present, so the description carries the full burden. It discloses that only a semantic label is returned and that raw scores are never exposed. However, it does not mention side effects, authentication, or error handling (e.g., unknown zones). For a read-only query, this is acceptable but not exemplary.

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 no fluff. The first sentence front-loads the core purpose (returns safety classification), and the second adds a behavioral constraint. 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 simple query tool with 2 required params, no output schema, and no annotations, the description provides the return format (semantic label) and a safety guarantee (raw scores hidden). It could mention whether data is cached or real-time, but the given context is largely sufficient.

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%, baseline is 3. The description adds minimal value beyond schema: it mentions 'zone and time window' and 'Quito', but schema already includes examples and descriptions. No additional parameter semantics 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 returns an operational safety classification label ('safe / caution / avoid') for a specific zone and time window in Quito. It distinguishes itself from siblings: e.g., whaber_recompute_zone_safety (recomputes) and whaber_get_safe_pickup_point (returns a point, not classification).

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 querying existing safety data but does not explicitly state when to use this tool versus alternatives like whaber_recompute_zone_safety. It lacks when-to-use/when-not-to-use guidance or exclusion criteria.

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 real-time update behavior, return value (new semantic label), and importantly that the internal computed_score is never exposed. It does not mention authentication or rate limits, but the key behavioral traits are covered.

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: first sentence states action and trigger, second mentions real-time update, third describes return value and a hidden detail. No wasted words, well front-loaded with critical information.

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 trigger, behavior, return value, and a hidden internal score. It could mention prerequisites (e.g., zone must exist), but for a moderately complex tool with no output schema, it provides sufficient 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?

Both parameters (zone_name, incident_type) have schema descriptions covering 100%. The description does not add extra meaning beyond the schema; it only provides context that incident_type corresponds to triggers. Baseline 3 is appropriate since schema already documents the parameters adequately.

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 'triggers a recalculation' and the resource 'safety classification for a Quito zone'. It distinguishes itself from siblings like query (read-only) by focusing on write/update. The trigger context ('after a new driver report or verified incident') is explicit.

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 specifies when to use the tool ('after a new driver report or verified incident'). It does not explicitly state when not to use it or mention alternatives, but the sibling list includes a read-only query tool, which provides implicit 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 carries full burden. It discloses fuzzy matching, fallback behavior, and return of coordinates and POI node. But it omits details on failure modes, rate limits, or whether it modifies 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 concise sentences, front-loaded with the main action, 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 geocoding tool with no output schema, the description adequately explains return values (verified coordinates and matched POI node). It is sufficient for an agent to use effectively.

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 3. The description adds examples for 'query' and explains 'context' as a hint, but does not significantly enhance understanding beyond the schema's own 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?

The description clearly states the tool geocodes free-text addresses against the Whaber Place Graph with fuzzy matching, specific to Quito. It distinguishes from siblings like whaber_enriched_route or whaber_get_hotel_context by focusing on address resolution.

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 (free-text address/place name in Quito) and mentions fallback to Google Maps MCP. However, it does not explicitly state when not to use it or compare to alternatives beyond the fallback.

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 burden. Discloses data source (AeroDataBox webhooks), update frequency (<30s), and key behavioral traits (never estimated, includes delay/gate changes). Adequate 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 concise sentences: first defines output, second adds behavioral guarantee. No redundant or 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?

No output schema, so description should detail return fields. Mentions delay minutes and gate changes but not a complete list (e.g., status codes, times). Sufficient for basic understanding but lacks structured response details.

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 descriptions already cover both parameters with format and examples. Description adds no new parameter information; schema coverage is 100%, so 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?

Explicitly states it returns real-time flight status and derived terminal assignment for UIO airport. Verb 'Returns' and specific resource clearly define the tool's function, distinguishing it from sibling tools focused on operations, compliance, and safety.

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 usage for actual flight state ('never estimated') but lacks explicit when-to-use or alternatives. Grounding transfers to actual state provides context, but no direct comparison to 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?

With no annotations, the description discloses the deterministic strictness (zero exceptions, total block) and lists all 7 required documents. It does not cover error handling or read-only nature, but for a validation check this is fairly transparent.

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, using only three sentences to convey the tool's purpose, the 7 documents, the strict outcome, and its identity. 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 explains the return value (compliant/non-compliant) and the strict behavior. It covers the key validation context, including the specific documents, making it complete for this tool's complexity.

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 clear description for carrier_id. The tool description adds no extra parameter meaning beyond what the schema provides, so the baseline score of 3 applies.

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 validates carrier compliance with 7 specific ANT documents in Ecuador, listing them explicitly. It distinguishes itself from advisory tools by stating 'not advisory' and identifies itself as the 'Whaber Compliance Gate', making 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 explains the strict behavior (total block on any missing document) and that it returns compliant/non-compliant, implying it should be used for definitive compliance checks. However, it does not explicitly mention when not to use it or compare to sibling tools like 'whaber_compliance_gate', lacking exclusions.

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