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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is covered structurally. The description adds real context beyond them: the cancellation is irreversible and only valid pre-start. It does not disclose the effect on fares/refunds or that repeat calls are safe (idempotency), which the annotations already imply.

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 tight sentences, front-loaded with the action and its precondition, then the irreversibility warning and the required inputs. No filler.

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?

An output schema exists and annotations carry the safety profile, so the description need only convey action, precondition, and required inputs — all of which are present. Nothing an agent needs in order to call this correctly is missing.

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% — both ride_id and rider_phone are fully documented in the schema, including format examples. The description only restates that both are needed ('the ride id and the rider phone used to book'), adding no syntax or edge-case detail 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?

States a specific verb and resource ('Cancels a BinaSmart ride') plus a scope constraint ('that has not started yet'), which separates it from request_ride/quote_ride/get_ride_status. It never names a sibling explicitly, so differentiation is inferred rather than stated.

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?

Gives a clear applicability condition: use it only for a ride that has not started. It does not name what to do instead once a ride is underway or already cancelled, so no explicit alternatives or exclusions 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: an approximate 2.5 km search radius and the ordering rule that driver-opened cars at stations come first. It stops short of stating result limits or pagination.

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?

One dense sentence that front-loads the verb, scope, and radius before listing return fields. The inline share-url template is slightly more detail than needed for tool selection, but nothing is wasted or padded.

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?

An output schema exists, so return-value explanation is optional; the description still summarizes the payload fields helpfully. Combined with the annotation-provided read-only profile and the geographic constraint, an agent has enough to call this 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% and the bounds (8.5–9.5 lat, 38.4–39.2 lng) already pin the coordinates to Addis Ababa. The description's 'point in Addis Ababa' and 'Requires lat/lng' only restate what the schema conveys, so this is the baseline 3.

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 a specific verb (Find) and resource (BinaPool cars currently filling near a point), then enumerates the returned fields. It is clearly distinguishable from siblings like list_pool_corridors, quote_ride, and request_ride.

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 via 'Requires lat/lng' and the 2.5 km radius, but never states when to pick this over list_pool_corridors or how it relates to the ride-booking siblings. Usage is inferable rather than explicit.

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 openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral detail: address and location are returned only 'when we hold them', i.e. those fields may be absent. It says nothing about pagination or vacancy list size, which is a plausible concern for a company with many postings.

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 short sentences, no filler, and the resource contents are front-loaded ahead of the input-provenance note. Slightly dense phrasing ('what it does, its address and location when we hold them') but nothing wasted.

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?

With an output schema present, the description is not obliged to explain return values, and annotations carry the read-only profile. It adequately covers scope and input sourcing; only vacancy-list volume/pagination behavior is left unaddressed.

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% for the single slug parameter, which already documents the expected format ('e.g. from list_jobs employer_url'). The description reinforces provenance and adds a second valid source (get_job), a marginal gain over the schema, so the baseline 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 names a specific resource (a company on BinaSmart) and enumerates the payload: profile, address/location, and all posted vacancies. This clearly separates it from get_job, which returns a single posting, though it never states the verb and relies on the name to convey retrieval.

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?

It tells the agent where the required slug comes from (list_jobs or get_job), which implicitly routes the workflow: enumerate jobs first, then hydrate the employer. It stops short of an explicit 'use this instead of X when Y' statement or any 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 openWorldHint=false, so safety is covered. The description adds useful context that the guides are bilingual and carry correct official names and links, but says nothing about list size, pagination, or truncation of the full text, which are the practical traits an agent needs for a content-retrieval 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 purpose and the slug/no-slug behavior are front-loaded and useful. The middle of the description is a single run-on sentence listing roughly twenty guide topics, which is heavy for a one-parameter tool and could be condensed, though the enumeration does aid discoverability.

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?

With an output schema present, return values need not be described, and annotations cover the read-only profile. The description supplies mode behavior and content scope, leaving only minor gaps (pagination, list size) for what is a simple single-parameter lookup.

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 the schema already documents the slug with an example. The description goes beyond the schema by explaining the otherwise-undocumented behavior of omitting slug entirely (returns the guide list rather than an error), which is genuine added meaning for an optional 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 states a concrete resource (bilingual step-by-step guides to Ethiopian government and banking services) and enumerates the covered topics, which clearly separates it from siblings like get_news_article or search_knowledge. It does not explicitly name a sibling to avoid, but the domain scoping is specific enough that an agent can place 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?

'Call with no slug to list guides; call with a slug for the full text' clearly documents the two invocation modes, which is real operational guidance. However, it gives no when-to-use context versus alternatives (e.g. search_knowledge for general queries) and no exclusions, so it stays at implied usage rather than explicit routing.

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 openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context the annotations do not: it discloses the returned field set (fee, doctors, hours, location, live slot availability) and the cross-tool slug dependency, though it says nothing about pagination or how stale the slot data is.

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 dense sentences with zero filler; the resource and its output are front-loaded and the prerequisite is deferred to the trailing sentence where it belongs. Nothing repeats the name or title.

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 read-only lookup with an output schema, complete param coverage, and only two inputs, this says everything an agent needs: what comes back, the optional date scoping, and where the required slug originates. No material gap remains.

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 both parameters are already documented, including the date pattern and 'default today' semantics. The description only reinforces slug provenance, matching the baseline 3 when 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 names a specific verb+resource (departments of a hospital) and enumerates the exact payload — consultation fee in ETB, doctors, hours, floor/room, and remaining appointment slots for a date. That specificity lets an agent distinguish this detail-lookup from a broader discovery tool like search_health without opening the schema.

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?

It states the prerequisite explicitly: 'Use the slug from search_places (is_hospital = true)', which routes the agent to the correct upstream sibling. It stops short of naming when NOT to use it or how it differs from search_health, so it is clear context rather than full when/when-not 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful detail that prices are in ETB, but says nothing about freshness of pricing, availability guarantees, or pagination behavior.

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 compact sentences with zero filler; the returned fields lead and the prerequisite follows. Nothing is padded or restated.

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?

An output schema exists, so return values need not be detailed, and the one required parameter plus its source are covered. The definition is sufficient to invoke the tool correctly, with only minor gaps around pricing freshness.

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 the single slug parameter is already documented as coming from search_places, so the schema carries the load. The description's only marginal addition is the is_hotel = true filter hint for choosing the right slug, which is a minor but real clarification.

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 names the resource (room types, prices, capacity, amenities for a hotel) and implicitly the retrieval action, so an agent knows exactly what data comes back. It also ties itself to the slug-based lookup pattern, though it does not explicitly contrast with the sibling search_hotels/search_places tools beyond sourcing the slug.

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?

It gives a concrete prerequisite chain: obtain the slug from search_places and only use results where is_hotel = true. That is clear actionable context, but there is no explicit when-not-to-use or mention of alternative hotel tools such as search_hotels.

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 openWorldHint=false, so the safety profile is covered. The description goes further by enumerating the payload's substance (duties, requirements, how to apply, company with address when held), which usefully sets expectations about completeness and conditional fields.

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?

One front-loaded sentence that opens with the core purpose before listing payload contents; no filler or restated title. Dense but every clause carries 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?

An output schema exists, so return values needn't be spelled out, and the description covers origin of the input, scope, and payload shape. Nothing essential for correct invocation is missing; only explicit usage exclusions are absent.

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 there is a single parameter, so the schema already documents the slug fully. The description only repeats its origin ('from list_jobs'), adding no format or constraint detail beyond the schema. 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?

States a specific verb and resource ('the full advert for a single vacancy on BinaSmart') plus the identifier it keys on, and explicitly separates itself from list_jobs. An agent can distinguish it from get_employer and list_jobs without opening a schema.

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 phrase 'by its slug from list_jobs' tells the agent this follows a list_jobs call and what input it needs, which is clear usage context. It stops short of stating when not to use it (e.g. preferring list views for browsing), so it doesn't reach the explicit alternatives level.

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 openWorldHint=false, so the safety profile is covered and the bar is lower. The description's only added signal is that the response is the complete article text (not a snippet). With an output schema present, no return-value detail is owed, but nothing is said about error behavior.

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?

One sentence, zero filler, with the resource and its lookup key front-loaded. Nothing could be removed without losing 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?

For a trivial single-parameter read with an output schema, full annotation coverage, and a complete input schema, the description supplies everything needed to call it correctly. Only slug-validation or not-found behavior is left unstated, which is a minor gap.

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% and there is a single parameter, so the schema already documents 'slug' fully, including its origin. The description's 'by its slug from list_news' merely echoes the schema wording rather than adding format or validation detail, so baseline 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?

States a specific verb and resource (fetch the full text of one news article) plus the exact lookup key (slug). It also names list_news as the origin of that slug, so an agent can immediately tell it apart from the sibling listing tool.

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 phrase 'by its slug from list_news' effectively routes the agent: call list_news first, then come here with a slug. It gives clear context for use but states no exclusions or failure conditions (e.g., unknown/expired slug).

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 establish readOnlyHint=true and openWorldHint=false, and the description adds real value on top: the status state machine and the fact that driver name, vehicle and plate only appear 'once assigned'. It still says nothing about what happens on an unknown ride id or a phone mismatch.

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 status enumeration and then the input requirement; there is no filler and nothing that could be cut without losing 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?

An output schema exists, so return values need no explanation, and the description covers the status set and conditional driver/vehicle availability. It is nearly complete, with only edge-case behavior (invalid id, mismatched phone) left unstated.

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% and both parameters are already documented (ride_id returned by request_ride, Ethiopian phone formats). The description only restates that the ride id and booking phone are needed, adding no syntax or format detail beyond the schema. Baseline 3 is correct.

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 a specific verb+resource ('Current status of a BinaSmart ride') and enumerates the full status lifecycle, which cleanly separates it from the sibling write operations request_ride, cancel_ride and quote_ride. An agent can route to it without opening the schema.

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?

It gives the precondition for a successful call ('Needs the ride id and the rider phone used to book'), which tells the agent this is a post-booking lookup rather than a booking action. It does not, however, explicitly name alternatives or state 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?

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds real value beyond them by disclosing what the payload contains (requirements, bid bond, submission place/time, original link), which helps the agent decide to fetch full text rather than a summary.

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?

A single front-loaded sentence with a colon-delimited content list; every clause carries information and nothing is repeated.

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?

With an output schema present, return values need not be explained, and the description still sketches the payload contents plus the slug dependency, making the tool callable without further context. Minor gap only in not contrasting with other single-item detail siblings.

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 the single slug parameter is already documented as coming from list_tenders. The description only restates that origin, adding no format, length, or lookup guidance beyond the schema, so the baseline 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?

States a specific verb and resource ('full text of a single tender notice on BinaSmart') and enumerates the content returned. The word 'single' plus the slug reference cleanly separates it from list_tenders without needing the schema.

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 phrase 'by its slug from list_tenders' tells the agent this is the follow-up detail call to list_tenders, which is clear context. It gives no explicit when-not case or comparison to sibling detail tools like get_news_article or get_job, so it stops short of a 5.

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 openWorldHint=false, and the description adds genuinely useful behavior beyond them: this tool does not transact, seating and payment occur at the returned url via Chapa or at the counter, and the ticket is a QR code. That clarifies the full flow. It says nothing about result ordering, volume, or pagination, keeping it out of the top band.

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, zero filler. The first front-loads what the tool returns; the second carries only the behaviorally relevant downstream flow (payment location and QR ticket). Every clause 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?

With no parameters and an output schema present, the description does not need to explain return values or arguments. It covers scope, contents, and the post-listing purchase path, which is everything an agent needs to select and call it 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?

The tool takes zero parameters and the schema is empty, so there are no parameter semantics to add or omit. Baseline for a no-parameter tool is 4; nothing in the description contradicts or muddies 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?

The description states a concrete resource set (films, concerts, theatre, events) scoped to BinaSmart in Addis Ababa, and enumerates the fields returned (venue, hall, start time, prices per tier, seats left). That is far beyond restating the name. It stops short of distinguishing itself from close siblings like list_films or search_places, so an agent must infer the boundary.

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?

Usage is implied by the content — an agent can tell this is the browse-upcoming-events tool — but there is no explicit when-to-use, when-not-to-use, or named alternative such as list_films for cinema-specific queries. Nothing misleading, but nothing that routes the agent either.

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?

Adds real context beyond the readOnlyHint/openWorldHint annotations: free titles are public YouTube releases played through the YouTube player, while rentals require Chapa payment and last 48 hours in ETB. It does not mention ordering, pagination, or result-size behaviour, but the payment/playback distinction is genuinely useful behavioral detail.

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?

Purpose and scope are front-loaded in the first clause, and the sentence carries the field list, the free/rental distinction, and the optional filter without padding. It is a long run-on sentence, but every clause adds 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?

With an output schema present, the description needn't enumerate return values, yet it usefully clarifies what a film record contains and how playback/payment works. The only gap is ordering/result-window behaviour, which is left to the 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 both parameters are already documented in the schema; the description only restates the query filter ('search by title or genre') and says nothing about limit. Baseline 3 applies when 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?

States a specific verb+resource (licensed Amharic films watchable online on BinaSmart Watch) and enumerates the returned fields, so an agent can immediately distinguish it from every sibling (news, tenders, rides, hotels, etc.). There is no near-duplicate tool it could be confused with.

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 says search by title or genre is optional, which tells the agent both the filtered and the unfiltered ('latest films') modes. However, it never frames when to use this tool versus any alternative path, and there is no explicit exclusion.

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 openWorldHint=false, so the safety profile is covered. The description adds some behavioral value by implying freshness ('right now') and an aggregated/ranked result shape, but it says nothing about result size limits, pagination, or caching of the counts.

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?

A single front-loaded sentence with zero filler: the primary payload comes first, the secondary payload second, and the call-to-action last. Every clause 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 zero-parameter, read-only listing tool with an output schema already describing the return shape, the description covers what is returned and when to reach for it. Nothing an agent needs in order to invoke it correctly is missing.

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 tool takes zero parameters, so the baseline is 4 and there is no schema surface for the description to compensate for. No parameter claims are made or needed.

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 names the exact resource ('fields of work with open vacancies'), the aggregation ('how many are in each'), and the secondary payload ('cities hiring most'), so it is unmistakably not list_jobs or get_job. The only shortfall is that it is phrased as a noun clause rather than an explicit verb+resource statement, and the differentiation from list_jobs is delivered as usage advice rather than as a contrast.

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?

It names the sibling to use next ('useful before calling list_jobs with a field or city filter') and the condition that makes this tool the right first step, which is genuine routing guidance. It stops short of stating when not to call it (e.g., when the caller already knows the field).

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description adds real context: daily morning refresh, sourcing from multiple Ethiopian job boards and employers, server-side default of open vacancies only, and a UI caveat that results render as job cards with apply links under MCP Apps.

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?

Front-loaded with the resource and scope, then progressively narrows to filters and defaults. It is somewhat long and repeats the field-of-work enumeration that the schema already carries, but every sentence is informational rather than filler.

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?

An output schema exists, so return values need no explanation, yet the description still covers the practical essentials: what is indexed, refresh cadence, open-vs-closed default, search language support, and the job-card rendering. Nothing an agent needs to call it correctly is missing.

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 baseline is 3. The description adds marginal value by noting Amharic keyword search and that closed vacancies are excluded unless include_closed is set, but it largely restates the field-of-work list and city filter already documented 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?

States a specific verb and resource ('Open job vacancies in Ethiopia listed on BinaSmart') plus the exact fields returned (title, company, city, deadline, salary, requirements). This clearly separates it from get_job (single vacancy), get_employer, and list_job_fields.

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?

It gives usable search patterns ('Search by keyword in English or Amharic, and filter by field of work or by city') and the open/closed default, but it never routes to alternatives such as get_job for a single vacancy or list_job_fields for field discovery. Usage is implied rather than explicitly delimited.

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 openWorldHint=false, so safety and locality are covered. The description adds a genuinely useful behavioral trait the annotations cannot convey: content is mostly Amharic. It does not mention pagination or result-ordering behavior, which keeps it short of a 5.

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 filler; the identity and topic scope come first, then the return fields and the hand-off to the sibling. Every clause 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?

With an output schema present, the description need not enumerate return fields in detail, and annotations cover the safety profile. Language, source, topics and the follow-up tool are all present, so nothing an agent needs to call this correctly is missing.

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 limit, query and category are fully documented in the schema, including the loose category matching and the Amharic/English keyword rule. The description's topic list largely restates the category parameter, adding no syntax or semantics beyond the schema. Baseline 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?

States a specific verb (list), resource (recent articles) and source (BinaSmart news / bina.et/news), plus the topic coverage. It explicitly contrasts with the sibling get_news_article, so an agent can route between the two without opening either schema.

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?

Clearly implies when to use it (recent articles, browse-level) and names the alternative get_news_article with the condition that selects it (full text). It does not state exclusions versus other list_* siblings, but the usage context is unambiguous.

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 openWorldHint=false, and the description adds genuine context beyond them: the upstream source (BinaSmart/GCC Domestic), the Ministry of Labor and Skills register flag, and the note that recruitment runs through LMIS under Proclamation 1389/2025. It does not discuss pagination or result-set size, so not a 5.

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?

Dense but front-loaded: the entity and returned fields come first, filtering second, legal context last. The explicit country enumeration partly duplicates the enum in the schema, which is the only real waste.

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?

With an output schema present, return structure need not be explained, and the description still covers scope, filter behavior, data provenance, and a relevant legal constraint. Complete enough for an agent to call correctly, though result volume/ordering is unmentioned.

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 has 100% schema coverage including the enum and the 'omit for all' default, so the baseline is 3. The description only re-lists the same six country values, adding no syntax or semantic detail 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 states a specific resource (Ethiopian overseas employment agencies licensed to send domestic workers to GCC countries) and the fields returned (name, licence, ministry-register status, per-country partner office). No sibling tool covers this domain, so it is unambiguous by construction.

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?

It says how to narrow results by country and implies usage (looking up agencies/partner offices families contact), but never states when to call this versus other lookups or any preconditions. Usage is inferable rather than prescribed.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the listing is time-gated (inbound/outbound cutoffs), pricing is a live 1–4 rider ladder, and it surfaces "cars currently filling", which tells the agent the result is volatile rather than a static catalog.

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?

One dense but well front-loaded sentence: the purpose verb lands first, then scope, timing rules, and the join URL. The Amharic brand gloss and corridor enumeration cost length but carry real orientation value; nothing is truly wasted, though it could be broken into two shorter sentences.

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?

An output schema exists, so return shape needn't be explained, and the description covers scope, time conditions, and pricing model. The one real gap is routing guidance against the ride/pool siblings, which is left to the agent.

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% and both lat/lng already have clear descriptions ("to sort by distance"), and the description adds nothing about them. Per the baseline rule for high-coverage schemas, a 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?

States a specific verb ("Lists") and resource (BinaPool commute corridors open right now) and enumerates the actual corridors (Megenagna → Bole, CMC → Bole, etc.), so the agent knows exactly what data comes back. The combination of shared-ride context and seat-price ladder is distinctive enough that no sibling in the catalog could be confused with 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 gives strong situational context ("corridors open right now", inbound until 13:00 Addis time, outbound after) which implies when the listing is valid, but it never tells the agent when to pick this over the ride siblings such as quote_ride, request_ride, or find_pool_groups. Usage is left to inference.

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 openWorldHint=false, so safety and worldliness are covered. The description adds that results reflect the current open set ('right now') and include per-category counts, which is modest but real context beyond the annotations. No pagination, freshness, or auth detail is given.

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?

A single sentence, front-loaded with what is returned and followed by the routing hint. No filler.

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?

An output schema exists, so the description needn't enumerate return fields, and it still tells the agent the shape is category→count. For a zero-param read-only discovery tool this is essentially complete, though it could note whether empty categories are omitted.

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 tool takes zero parameters (empty schema), so the baseline of 4 applies; there is nothing for the description to disambiguate.

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 a specific resource (tender categories), a scope constraint (open on BinaSmart right now), and the returned payload (count per category). It also implicitly distinguishes itself from the sibling list_tenders by being the pre-filter discovery 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 when to reach for it: 'useful before calling list_tenders with a category filter'. That names the sibling and the sequencing. It does not state when NOT to use it (e.g., if you already know the category), so it stops short of a full when/when-not pair.

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 openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the data source (BinaSmart, bina.et/tenders), the returned fields including deadline, days-left and original link, the issuer types covered, and the default open-only filter. It does not mention result caps or pagination, which is a minor gap.

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, front-loaded with the resource and scope before filters and defaults. Nearly every clause carries information, though the issuer-type enumeration ('Banks, government bodies, NGOs and World Bank–financed projects') is the one segment that could be trimmed without losing agent-relevant meaning.

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?

Output schema exists, so return-value explanation is not required, yet the description still summarizes record contents helpfully. With a 5-parameter optional-only schema, a live data source, and category vocabularies, the description supplies everything an agent needs to call this 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 description coverage is 100%, so the baseline would be 3. The description goes beyond the schema by noting bilingual (English or Amharic) keyword matching, listing the concrete category values, and restating the include_closed default, which meaningfully enriches how the agent should populate 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 states a specific verb and resource (public tender and procurement notices listed on BinaSmart) plus scope (Ethiopia, open tenders). It enumerates exactly what each record contains and who issues them, which cleanly separates it from get_tender (single tender) and list_tender_categories (taxonomy). An agent can identify the tool without opening the schema.

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?

It gives clear context for use — keyword search in English or Amharic, category filtering, and the default that closed tenders are excluded unless include_closed is set. It does not explicitly state when to prefer this over get_tender or list_tender_categories (the latter pointer lives only in the schema), so it stops short of full routing 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: no surge pricing, accepted payment methods (cash or telebirr/Chapa), the full tier list returned, and a book_url confirmation link. It stops short of stating auth requirements or 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?

Three dense sentences with zero waste: the pricing promise and scope are front-loaded, the return contents follow, and the sibling routing closes. Every sentence carries distinct 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?

An output schema exists, so return values need not be enumerated, yet the description still names the key fields (distance, ETA, fare per tier, book_url) helpfully. Combined with annotations and a fully documented 2-param schema, nothing an agent needs to call this correctly is missing.

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% and both parameters are fully documented in the schema with format examples (place name or lat,lng). The description only reinforces the geographic constraint ('inside Addis Ababa'), adding little beyond the schema, so the baseline 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?

States a specific verb (quote) and resource (ride), scopes it geographically (inside Addis Ababa, Ethiopia), and explicitly separates itself from the booking sibling: 'request_ride books at the fare this returns.' An agent can distinguish it from request_ride and get_ride_status without opening any schema.

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 relationship to request_ride ('books at the fare this returns') makes the intended workflow clear: quote first, then book. It does not give explicit when-not conditions or name other alternatives, but the sequencing guidance is unambiguous.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), and the description adds real value on top: a real driver is dispatched, a human dispatcher assigns the driver, the rider is phoned, and it returns a ride id plus live tracking link. It misses the one thing the idempotentHint most warrants — whether a retried call re-books or returns the same ride — and says nothing about cancellation windows or payment timing.

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, front-loaded with the action and destination, then side effects and return values, then the alternate-booker case. The middle sentence ("It sends a real driver, so it takes ... as the user confirmed them") is compressed to the point of being slightly hard to parse, but no sentence is filler.

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?

Output schema exists, yet the description still usefully names the return payload, and the 8-parameter mutation surface is well covered including the optional passenger and payment paths. What's still absent is preconditions: account/registration needs and whether a payment authorization happens at booking time for chapa.

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 per-field semantics are already documented and the baseline is 3. The description does contribute the cross-field meaning of passenger_name/passenger_phone flipping rider_name/rider_phone into booker fields with a possibly foreign number, which the schema only states tersely, so it edges toward useful without reaching 4-level depth on fare/payment 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?

States a specific verb and resource ("Books a ride") scoped to Addis Ababa at the fixed fare from quote_ride. It is clearly distinguishable from the pricing sibling quote_ride and from get_ride_status/cancel_ride, which handle post-booking lifecycle.

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?

Gives concrete usage context: fare must come from quote_ride, inputs passed "as the user confirmed them", and a full explanation of the booking-for-someone-else variant. It does not explicitly name the when-not path (e.g. use cancel_ride to undo, or re-quote if details change), so the routing guidance is strong but not exhaustive.

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 openWorldHint=false, so the bar is lower, but the description still adds real context: weekly refresh cadence, provenance (dealers' own sites), and that results carry dealer phone/WhatsApp and a bina.et link with photos. It does not discuss pagination or the limit ceiling, so not a full 5.

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?

One dense, front-loaded passage that leads with the verb+resource before examples and exclusions. Minor waste: the bina.et URL appears twice, once inline and again as a trailing "Source:" line, which is redundant rather than clarifying.

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?

With an output schema present, return-value detail is not required, and the description covers purpose, freshness, provenance and routing. Given nine optional parameters and a curated dataset, it is complete enough to call correctly, though default behavior (limit=5) is left entirely to the 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 all nine parameters are already documented with types, enums and bounds; baseline 3 applies. The description's example queries (price in birr, brand names, body types) loosely reinforce make/price/body fields but add no syntax or filtering semantics 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?

States a specific verb and resource (search live new/used cars) with a concrete scope: Addis Ababa dealers and car markets. The listed attributes (make, model, year, price, mileage, fuel, gearbox, dealer contact, photos) make it unmistakable against siblings like search_properties or search_hotels.

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?

Gives explicit trigger examples ("used Toyota", "SUV under 10 million birr", "BYD") and an explicit exclusion ("Not for taxi rides"), which routes the agent toward quote_ride/request_ride. Both the when and the when-not are stated.

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?

Beyond the readOnlyHint/openWorldHint annotations, it discloses data provenance and quality (250+ places from the city map, services and doctors confirmed by facilities, doctor licences verified by the BinaSmart team) plus the returned fields (bina.et page, landline, sub-city, distance). It also flags the non-clinical nature of the results and the emergency number, which annotations cannot convey.

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?

A single dense paragraph but well front-loaded: purpose, then filters, then returns, then disclaimer. Every clause carries information, though the filter/return/disclaimer run-ons in one block make it slightly harder to scan than it could be.

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?

With five optional parameters, an output schema, and read-only annotations already covering safety, the description supplies everything else an agent needs: filter semantics, result ordering, return shape, provenance and a scope disclaimer. Nothing material is left for the agent to infer.

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 baseline is 3, but the description adds meaning: the specialty list expands the enum-like value space (children, gynecology, eye, heart, bone, fertility, skin, mental health, blood test), and 'nearest first' documents the ordering semantics of the near 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?

Opens with a specific verb and resource (find hospitals, clinics, dentists, laboratories, health centres and doctors) scoped to Addis Ababa, and names the data source (BinaSmart Health, 250+ places). The health-only scope makes it unmistakable against siblings like search_places or search_hotels.

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?

Enumerates the four usable filter dimensions (kind, sub-city, near, specialty) with concrete specialty examples, and sets a scope boundary ('Not medical advice; emergencies: 907'). It never explicitly states when to prefer a sibling such as search_places, so routing guidance is implicit rather than stated.

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 only declare readOnlyHint and openWorldHint, so the description adds real value: a directory with no prices or room availability, and a note that the hotel's own phone is the fallback channel. That tells the agent how to set expectations on results. It does not mention the hard result cap beyond what the schema's limit maximum enforces, so it stops short of a 5.

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, no filler. Scope and source are front-loaded, the limitation follows, and exclusions come last — a clean information hierarchy with every clause earning 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?

With an output schema present, the description needn't explain return values, and it covers scope, exclusions, and the price/availability caveat. The one gap is the relationship to get_hotel_rooms and search_properties, which the description leaves ambiguous.

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 area, kind, name, limit, and min_stars all documented, including the Amharic examples and the enum's synonym mapping. The description adds essentially nothing parameter-level beyond repeating 'sub-city' as a returned field, so the baseline 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 first sentence names the resource (hotels, guest houses, pensions, hostels, furnished apartments), the geography (Addis Ababa), the source (BinaSmart's directory, 1,000+ places) and the exact fields returned. It explicitly rules out adjacent categories by naming the sibling tools (search_health, search_places), so an agent can separate it from its neighbors without opening a schema.

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?

It gives clear when-not-to-use guidance with named alternatives (search_health for clinics, search_places for restaurants and shops), which is more than most definitions offer. However, it omits any routing to get_hotel_rooms and instead says availability comes from the hotel's phone — the existence of a dedicated rooms sibling makes that advice misleading at the edges, and the overlap with search_properties for furnished apartments is unaddressed.

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 openWorldHint=false, so the safety profile is covered and the description adds the boundary of the corpus plus the result shape ('best-matching passages, each with its source url'). It stops short of noting result-count behaviour beyond k or any ranking/coverage caveats, but adds real context beyond the annotations.

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, front-loaded with the verb+resource before the coverage list. The long parenthetical enumeration of services is dense but it is the information that makes scope unambiguous; nothing is padding, though it could be trimmed slightly.

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?

An output schema and annotations exist, so the description does not need to explain return values; it still summarises them briefly. Purpose, corpus scope, use conditions, and the fare exception are all present, leaving nothing an agent needs before calling it.

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 both parameters carry their own descriptions including the default of k and the English/Amharic input allowance. The description adds no further parameter guidance, so the baseline 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?

States a specific verb and resource ('Semantic search over BinaSmart's knowledge base') and then enumerates the corpora it covers, so an agent can tell exactly what content is reachable. It also distinguishes itself from quote_ride on the one point of overlap (exact fares).

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?

Gives an explicit use condition ('For questions about BinaSmart, Ethiopian paperwork or getting around Addis') and an explicit exclusion with the alternative to use instead ('Exact fares are not in the passages: they come from quote_ride'). The agent is routed rather than left to guess.

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 only declare readOnlyHint and openWorldHint; the description adds substantial extra context — phone numbers appear only for claimed listings, coordinates are reusable as pickup/dropoff for quote_ride, hotels/hospitals are flagged, and the map fallback omits phone/hours/prices/menu. This is meaningful behavioral disclosure beyond the structured fields.

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?

Purpose and coverage are front-loaded, and the semicolon-separated content mostly earns its place, but the single dense paragraph packs in return-field and fallback detail that borders on overload.

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 an output schema exists, the description need not explain returns, yet it still covers the key asymmetries (claimed vs unclaimed phone, map fallback limitations) and routing to sibling tools, leaving nothing an agent needs to call it 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 description coverage is 100%, so query, limit (default 8, max 25), and category are already documented. The description lists categories in prose but adds no syntax or format detail beyond the schema, 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?

States a specific verb ('Find') and resource (buildings, hotels, hospitals, shops in Addis Ababa listed on BinaSmart) and enumerates the covered categories. It clearly differentiates itself from siblings like search_health, get_hotel_rooms, and get_hospital_departments, so an agent can route without opening a schema.

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 names alternatives and the conditions that select them: use get_hotel_rooms / get_hospital_departments for detail, search_health for health providers anywhere in the city, and it explains the map_place fallback for food searches with no listed shop. When-to-use and when-to-switch are both spelled out.

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 openWorldHint=false, and the description adds meaningful context beyond that: data is refreshed weekly, prices are unmodified (some expressed per m² or in USD), and listings carry the company's own phone/WhatsApp. The warning that prices are as-published rather than normalized is a genuinely useful behavioral caveat.

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 first sentence front-loads the source and refresh cadence well, but it then spends most of its length enumerating returned fields even though an output schema exists, making that portion largely redundant. The three-sentence structure is legible but the field list could be trimmed without loss.

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?

With an output schema present, return values need not be explained, and the annotations cover the safety profile. The description fills the remaining gaps an agent needs: provenance, refresh cadence, price-format caveats, and concrete query examples. The lack of any exclusion or alternative-tool guidance is the only notable gap.

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 baseline is 3. The description adds the important note that prices may be written per m² or in USD, which bears on interpreting max_price (documented as birr), but it does not explain how to use area, beds, type, or limit beyond what the schema already states.

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 identifies the resource (live Addis Ababa property listings sourced from real-estate companies' own sites via bina.et) and enumerates what each listing contains. There is no direct property sibling among the other search_* tools to differentiate from, so explicit sibling routing is absent, but the domain is 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?

It provides concrete example intents: "apartment for rent in Bole", "3 bedroom for sale", and the Amharic "ቤት ኪራይ", which tells the agent the kinds of queries this tool serves. It does not state when NOT to use it or name alternatives, so it stops short of explicit when/when-not guidance.

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