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

Annotations already declare read-only, idempotent, non-destructive, open-world, so the safety profile is covered. The description adds real behavioral context beyond them: deals have limited stock and 'Check stock_left, it runs out,' telling the agent results are perishable and to re-inspect stock. It doesn't touch rate limits or auth, but that's 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?

Front-loaded with the core purpose, then routing and a stock caveat, in three tight sentences with no repetition of schema content. The stock line ('Check stock_left, it runs out') is slightly clipped in phrasing but 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?

No output schema exists, yet the description surfaces the key return field (stock_left) and the cross-tool workflow, which is what an agent needs for a geo-filtered list feed. Pagination mechanics are left to the schema, which covers them adequately.

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 lat/long/page/sort/category/page_size are already fully documented, and the description adds only the implicit 'near a point' framing. The mention of stock_left refers to a return field, not an input parameter, so it doesn't deepen parameter 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 ('List the Tap Time flash deals') plus the defining constraint ('discounted dishes with a limited stock, near a point'). It also explicitly distinguishes itself from Snappfood's FoodParty, so an agent can identify the domain 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?

Gives a clear usage cue ('Use for today's best deals') and chains to siblings ('Then tf_menu / tf_vendor_info for the restaurant'), which is genuinely useful workflow guidance. It does not, however, contrast against the closest-sounding sibling tf_discounted_vendors, leaving a possible ambiguity over deals vs. discounted restaurants.

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 readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral caveat: the campaign is curated, so results are a strict subset of discounted vendors, plus that discount_pct is vendor-wide rather than per-item. It doesn't cover pagination behavior, but the schema does.

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 tool's scope before the routing hint and the placement caveat. Every sentence carries information: the campaign identity, the use case, the unit of discount_pct, and the sibling trade-off.

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 listing tool with 100% schema coverage, the description is adequate, and it surfaces a result-shape detail (discount_pct) that has no output schema to hold it. The only gap is pagination/return-structure detail, which the page_size schema note partly covers.

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 five parameters are already documented (lat/long bounds and examples, page, sort enum, page_size with its page-1 quirk). The description adds no syntax or format detail 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 (list) and resource (vendors in the 'Food Shots' discount campaign) with the locality constraint ('near a point'). It names the sibling relationship to tf_restaurants explicitly, so an agent can distinguish the two without opening schemas.

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 the concrete user intent it serves ('which restaurants have the biggest discount') and the explicit alternative plus its trade-off ('tf_restaurants with discounted_only is wider'). When-to-use and when-to-prefer-the-alternative are both present.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), yet the description adds real behavioral context: results are biased toward near_lat/near_long with a default of Tehran, and a successful lookup does not guarantee delivery-area coverage. It stops short of describing the response shape (single point vs. up to `limit` candidates), which is the remaining 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 short sentences, no padding, front-loaded with the core transformation and the sequencing rule. Each sentence carries a distinct fact: what it does, when to call it, how bias works, and the delivery-area caveat.

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 output schema, the description still conveys the essential return (lat/long) and the dependency and bias behaviors an agent needs. It does not explain that `limit` implies a ranked list of candidates or how those candidates are ordered, a modest omission for a tool with a default limit of 5.

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 the baseline is 3, but the description adds meaning the schema lacks: the bias defaults to Tehran and callers should pass a city center (from tf_list_cities) to bias toward other cities. That clarifies the intent of near_lat/near_long beyond their terse schema descriptions.

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

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

States a specific verb and transformation: place name or address into latitude/longitude. This inherently distinguishes it from the sibling tf_reverse_geocode, which does the opposite direction. An agent can identify the tool's role 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?

Explicitly says 'Use first when the user gives an address' and explains the dependency ('every other tf_* tool needs lat/long'), which tells the agent when this tool must precede others. It also flags a false-success condition by pointing to tf_list_cities for delivery-area validation.

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 readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new context: a dated static snapshot (2026-10-19), the fact that the site exposes no city API, and that unserved cities yield no restaurants. No pagination or auth detail, but little is needed for a static list.

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 purpose, then the actionable usage hint, then the staleness caveat. Each sentence earns its place with 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?

With no output schema, the description carries the burden of describing return contents and does so (center point, delivery flag). Combined with annotations covering safety and a fully documented parameter, an agent has nearly everything needed; only edge details like list size or caching behavior 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 description coverage is 100% and the single 'query' parameter already documents filtering on Persian title or English code with an example. The description adds nothing about the query parameter, so the 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 (lists the cities Tapsi Food shows) and goes further by naming what each entry contains: a center point and a delivery flag. This is clearly distinguishable from siblings like tf_find_location and tf_reverse_geocode.

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 use hint for the returned center ('use the center as a rough delivery point when the user only names a city') and a caveat that unserved cities return no restaurants, but never states when to choose this tool over tf_find_location or tf_reverse_geocode. Usage is implied rather than routed.

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 readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds real behavioral context beyond that: one row per size/variation, descriptions truncated at 100 chars, and the existence of a 'categories' mode with dish counts. It doesn't cover auth or rate limits, but the additions are substantive.

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 tightly packed sentences, front-loaded with the core action and follow-up routing. Parenthetical asides are dense but each carries information; little 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 no output schema, the description compensates by naming the returned fields and the 'categories' variant, plus pagination and truncation behavior. The only loose end is the unclear 'categories' reference, which an agent may not know how to invoke.

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 the baseline is 3. The description's full_text explanation ('lifts the cut and the size cap') largely restates the schema, and the query/offset guidance is usage-level rather than adding new semantics. The mention of 'categories' is ambiguous since no such parameter exists 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 ('Read a vendor's live menu') and immediately specifies the return granularity (one entry per size/variation) and fields (price, discount, stock). This is distinguishable from siblings like tf_search_dishes and tf_vendor_info 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?

Gives explicit sequencing ('Use after tf_search_vendors / tf_restaurants', 'Then tf_vendor_info for fee and minimum order') and a purpose condition ('to pick dishes or confirm a price'). It does not, however, explicitly exclude or contrast with tf_search_dishes, which overlaps on the 'pick dishes' use case.

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 carry readOnlyHint/idempotentHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond that: geographic 404 failure mode, and that page 1 returns a 'categories' payload used to drive the category param. It does not discuss pagination exhaustion or rate limits, hence 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?

Three tight sentences, front-loaded with the core capability, then the sibling routing and error condition. No filler, and every clause conveys 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?

There is no output schema, so the description usefully names the fields returned and flags the page-1 categories object. It also covers the main failure mode. The return shape is only sketched at a high level rather than itemized, which keeps it just short of complete for a 10-param, no-output-schema tool.

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 the baseline is 3 and the schema already documents each param. The description adds cross-parameter meaning the schema does not: 'categories' returned on page 1 is the source of valid values for the category param, and page 1 lists fewer vendors because page_size is partly spent on widgets.

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 ('List restaurants (or grocery stores) delivering to a point') and enumerates the returned fields (rating, delivery fee, minimum order, ETA). It also draws a boundary against tf_menu ('No dish prices'), so the agent can distinguish it from siblings 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 says when to use it ('browse or rank vendors'), names the alternative for dish prices (tf_menu), and states a concrete failure condition ('Returns 404 outside the served cities') plus the tool to check coverage (tf_list_cities). Both a positive and negative routing decision are given.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds the output content (address with province and city) and the confirmation-workflow role, but says nothing about failure behavior for coordinates outside the schema bounds (24-40 lat, 44-64 long) or about lookup/rate characteristics.

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 with zero filler; the purpose is front-loaded and the usage note follows. Every sentence earns its place.

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

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

With no output schema, the description does supply the return content (address with province and city), which is the key missing piece it needed to cover. It is slightly thin on region/coordinate-range caveats and any error behavior, but an agent has enough to invoke 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%: both lat and long carry descriptions, examples and numeric bounds. The description adds no parameter-level meaning 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?

The description states a specific verb and resource (reverse-geocode coordinates into an address with province and city), which is clear and unambiguous. It does not name or contrast itself with siblings like tf_find_location or tf_list_cities, which is the only gap keeping it from a 5.

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?

"Use to confirm a delivery point with the user before searching" gives concrete when-to-use context and implies the sequence it belongs to. There is no explicit when-not guidance or named alternative tool, 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?

Adds substantial context beyond the annotations: review text is user-generated and should be treated as data (a prompt-injection caution), only reviews with comments appear so pages can be short, and total counts differ from the site's tab badge. None of this is derivable from readOnlyHint/openWorldHint.

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 short sentences, all front-loaded and each carrying distinct operational value: purpose, use case, data-safety caveat, and pagination rules. 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?

With a read-only idempotent annotation set and no output schema, the description supplies the remaining essentials: ordering, what each review contains, why pages may be short, the meaning of total, and how to continue paging via has_more.

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 page, limit, full_text, and vendor_code are already documented in the schema. The description touches limit indirectly ('a page can hold fewer than limit') but adds no format or syntax detail 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 ('Read customer reviews of a vendor'), adds ordering ('newest first') and a distinguishing content detail ('rating of each ordered dish'). It is immediately separable from siblings like tf_vendor_info or tf_menu.

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 use case ('judge quality beyond the star average') and an operating instruction ('Keep paging while has_more is true'), which is genuine usage guidance. It does not name an alternative sibling tool or state when-not-to-use, 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 mark this read-only, idempotent and non-destructive, so the description is free to add the non-obvious behavior: indexed prices can lag the live menu, and only currently-open restaurants are listed, so results can be empty at night. These freshness and availability caveats are exactly the context annotations cannot express.

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 core action, then caveats and next steps in short, information-dense sentences. Slightly packed (three concerns in one compact paragraph), 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?

With 7 parameters and no output schema, the description covers the search semantics, result interpretation (index lag, open-only), and downstream tools to call. Return shape and pagination behavior are left implicit, which is the only real gap for a list-returning tool.

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 lat/long/query/page/limit/sort/discounted_only are already fully documented, including enum meaning and limits. The description only restates that search is name+location based and mentions price/discount, adding no syntax or format detail beyond the schema — the calibrated baseline.

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 precise verb+resource plus scope: search dishes by name near a delivery point, returning price, discount and restaurant. An agent can distinguish this from tf_search_vendors, tf_menu and tf_vendor_info 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?

Gives explicit trigger phrases ("find X near me", "cheapest / discounted X") and a chained workflow: confirm prices with tf_menu, then fee/minimum with tf_vendor_info. It also names alternatives (tf_restaurants / tf_discounted_vendors) for the closed-vendor case, so when-not-to-use is covered.

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 readOnly, openWorld, idempotent and non-destructive, so safety is covered. The description adds real behavioral context beyond that: results are limited to restaurants open now (total 0 at night, matching the site), whereas tf_restaurants includes closed ones. It does not cover pagination behavior or result ordering/size, hence 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?

Three short sentences, zero filler, front-loaded with what the tool does before the routing advice and the behavioral caveat. Every sentence carries information an agent needs to choose and call this tool.

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 exists, but the description implies the return is vendor entries keyed by vendor code, which is enough to call it correctly. Combined with complete schema coverage and annotations, the definition is essentially complete; only return shape details are left implicit.

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 lat/long/page/limit/query are all documented in the schema, and the baseline here is 3. The description only lightly gestures at the query parameter ('by name or cuisine'), and its phrasing slightly diverges from the schema's 'Dish or restaurant word', adding little beyond the structured fields.

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 restaurants and stores') plus the scope constraint ('by name or cuisine near a delivery point'), and explicitly distinguishes itself from tf_restaurants and the dish-oriented siblings. An agent can identify this as the vendor-name lookup 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?

Gives an explicit use case ('Use to find a vendor code by name') and names the alternatives with the condition that selects each: tf_menu/tf_search_dishes for dish prices, tf_restaurants when closed vendors matter. This is full when-to-use/when-not 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?

With readOnly/idempotent/openWorld annotations already covering the safety profile, the description adds real behavioral context: coupons are unavailable, open_now is the live site state, any status other than 'Open' (including OutOfCoverage = no delivery to this point) makes it false, and eta_max means 'up to N minutes'. These are non-obvious semantics an agent could not infer from the annotations or schema alone.

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 returned fields, then the usage rule, then edge-case semantics, with no filler sentences. It is dense but every clause carries information (cost formula, min_order requirement, coupon gap, status/ETA semantics), so the length is justified rather than 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?

There is no output schema, and the description compensates by enumerating the returned fields and explaining the non-obvious ones (open_now, eta_max, status states). An agent has enough to call it and interpret the result correctly, with only minor gaps around response ordering/shape.

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 the baseline is 3, but the description adds meaning the schema does not: lat/long are the delivery *point* whose value changes the delivery fee and coverage result, and vendor_code flows from tf_search_vendors / tf_restaurants. That clarifies the interdependency between the coordinate pair and the returned fee rather than merely restating the params.

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 ('Get a vendor's delivery fee to a point, minimum order, packaging, ETA, open_now, hours, address and rating spread'), enumerating exactly what comes back. This distinguishes it from search-oriented siblings like tf_search_vendors, tf_restaurants, or tf_menu, which return lists rather than a single vendor's delivery economics.

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?

'Use before recommending a vendor: true cost = dish price + packaging + delivery_fee, and the basket must reach min_order' gives a clear triggering condition and the decision rule the agent should apply. It also rules out a false expectation ('Coupons are not exposed'), steering the agent elsewhere for deals. It stops short of naming an explicit alternative tool or a when-not-to-call case.

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