agent

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

No annotations are supplied, so the description carries the burden. 'Check whether' implies a non-mutating boolean lookup, which conveys the basic safety profile, but it says nothing about the result shape, how an unrecognized district is reported, or whether partial/alternative name matches are handled.

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 that front-loads the action and appends the one input caveat that matters, 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?

For a one-parameter lookup with no annotations and no output schema, most of what an agent needs is present. The notable gap is result semantics — whether the answer is a boolean, a list of served areas, or an error for unknown districts — which the description never addresses.

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

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

Schema coverage is 0% (only a maxLength constraint on 'area'), so the description must compensate — and it does, specifying that the parameter is a district or settlement name and explicitly not a street address. That is meaningful disambiguation beyond the schema; only the 200-character limit and format expectations remain undocumented.

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: 'Check whether the laundry courier serves a district or settlement.' That distinguishes it from the other lookups (prices, hours, FAQ, slots, business info). It stops short of naming any sibling explicitly, so it is clear but not maximally differentiated.

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?

Implicit usage is clear (verify coverage for an area before ordering), and it adds a valuable input constraint: 'give the district/settlement name, not a street address.' However, it offers no when-not guidance, no mention of what to do for ambiguous or partial area names, and no pointer to an alternative tool.

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

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

No annotations exist, so the description carries the full disclosure burden, yet it says nothing about read-only behavior, whether the record is scoped to the caller's company/API key, or what happens if data is missing. Only a data-field inventory is provided, which is minimal for a no-annotation 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?

It is brief and front-loaded, but it is a bare noun-phrase fragment with no verb or framing, so it reads as a field list rather than a task statement. Nothing is wasted, yet a few words could have made it action-oriented.

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

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

For a simple, single-optional-parameter lookup with no output schema, listing the returned fields is roughly adequate. It nonetheless omits whether the tool is scoped to a specific company and how it relates to the overlapping 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?

The single 'lang' parameter has 100% schema description coverage including an enum and a stated default (et), so the schema does the work. The description adds nothing about language handling, which is acceptable under the coverage 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?

The description enumerates the resource's contents (addresses, phone, e-mail, registry code, opening hours) but supplies no verb, so it's an implicit 'retrieve company details'. It doesn't differentiate from get_opening_hours, which overlaps on one of the listed 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?

There is no when-to-use guidance at all — nothing tells the agent whether to call this versus get_opening_hours for hours, or get_faq for contact/company questions. The agent must infer selection from the field list alone.

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

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

With no annotations provided, the description carries the behavioral burden and does well: it discloses the 7-day default window, that the same rules as the online order form apply, working-day and public-holiday handling, booking cut-off, capacity constraints, and area-limited windows. It also makes clear that actual booking is external via order_url, which is important context for an agent.

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

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

The description is two tight sentences with the core purpose and default scope front-loaded, followed by important constraints and the external booking note. Every sentence contributes useful information without unnecessary wording.

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 two-parameter read tool with no output schema, the description is fairly complete: it explains the slot rules, area limitations, and that booking happens elsewhere. It could be stronger by explicitly pointing to check_courier_area for area verification or by describing the returned slot structure, but the essentials are covered.

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 schema already has 100% description coverage for both parameters, including the date default and lang enum, so the baseline is 3. The description reinforces the date behavior by saying next 7 days or one given date, but adds no further meaning for lang or other 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?

The description clearly states that the tool returns free laundry courier pickup times for the next 7 days or a specific date. It adds scope details like working days, public holidays, cut-off, capacity, and area-limited windows, making the resource understandable, though it does not explicitly name sibling tools such as check_courier_area.

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

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

The description implies the tool is for checking available courier pickup slots and clarifies that booking happens on the order page, not through this tool. However, it does not explicitly say when to use this versus check_courier_area or other sibling tools, so usage guidance remains implied 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?

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about return shape (single answer vs list of Q&A), whether an empty query returns everything, or whether matching is fuzzy. For a no-annotation tool this is a serious 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?

Five words is concise but the brevity reflects under-specification rather than efficiency; there is no front-loaded statement of what an agent actually needs to know before calling it.

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 two undocumented-in-description parameters, no annotations, and no output schema, the definition leaves the agent unable to predict return content or query behavior. It is inadequate for even a simple lookup 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 50%: lang is documented with its default, but query has only maxLength and no description. The tool description adds nothing about either parameter, so the meaning of query (search term? topic filter?) remains undefined in both places.

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?

"Frequently asked questions and answers" is essentially a restatement of the tool name get_faq; it signals the resource is FAQ content but supplies no verb, no scope, and no differentiation from siblings like get_business_info or get_opening_hours, which could equally answer customer questions.

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?

There is no guidance on when to call this versus the sibling info tools, and no indication of whether the query parameter is a search filter or ignored. The agent must infer usage entirely.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose one useful trait — public holidays are factored into the answer — but it does not say whether a missing date defaults to today, whether omitting 'point' returns both locations' hours, or how a closed day is represented.

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 with no filler; the location scope and the holiday caveat come before anything else. The phrasing 'including public holidays on a given date' is slightly compressed but still readable.

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 annotations and no output schema, this definition should explain defaults (date, lang, point omission) and the shape of the returned hours. It leaves all of that to inference, so an agent cannot confidently predict the response.

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 67%: date and lang are documented in the schema, while 'point' has no description. The description partially compensates by naming the two service points, implicitly mapping to the mustamae/haabersti enum values, but it adds nothing about date format, defaults, or combined results.

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 (opening hours) and two specific service points (Mustamäe and Haabersti in Tallinn), plus the holiday nuance, so an agent can tell this apart from siblings like get_prices or get_courier_slots without opening the schema. It stops short of a crisp verb+scope statement, but the resource 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?

There is no when-to-use guidance, no mention of when to prefer get_business_info, and no statement about what happens when the optional date or point is omitted. The usage is only inferable from the name and the phrase 'on a given date'; nothing tells the agent the conditions for calling it.

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

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

No annotations are provided, so the description carries the full burden. It does add useful behavioral context — prices are in EUR and include VAT — which an agent could not get from the schema, but it says nothing about return format, completeness of the list, or that it is a non-mutating lookup (only implied by the 'get_' name).

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 no filler, and the scope is front-loaded. It reads as a label rather than a full sentence, which is efficient but slightly telegraphic.

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

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

For a simple two-optional-parameter read tool with no output schema, the description covers the resource and pricing units. It does not describe what a result entry looks like (item name, price, category), which would help an agent use the output without a 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 lang and query are already documented in the schema with defaults and constraints. The description adds no additional meaning about filtering behavior or language fallback, so the baseline of 3 applies.

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

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

The description names the resource (Pesupanda price list) and enumerates the service categories it covers (dry cleaning, laundry, ironing, carpets, courier), so an agent can distinguish it from siblings like get_business_info or get_faq. It lacks a direct verb phrase and makes no explicit sibling comparison, but the resource scope 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?

There is no statement of when to call this tool versus alternatives such as get_business_info, nor any guidance on using the query filter or the language option. The agent must infer usage entirely from the tool name and schema.

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