Singapore Buying Desk (Connective Labs)

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful context about what is returned: office and IT supply categories with specs, event print and merch categories with instant-price flags, plus operator company details. It does not discuss auth, rate limits, or pagination, but with annotations covering the safety profile this is solid.

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 tool's purpose and return contents, followed by a clear usage instruction. The 'Example input: {}' sentence is mildly redundant given the schema has no properties, keeping it just below a 5.

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 carries the burden of explaining return values. It does so comprehensively by naming each category group, the associated details, and the operator information the caller will receive. For a zero-parameter, annotated read tool, this is complete.

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

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

The tool has zero parameters, so the baseline is 4. The description reinforces this with 'Example input: {}' and does not invent parameter requirements, which 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 ('List what the Singapore Buying Desk quotes') and enumerates the category types returned, making the tool's purpose clear. It implicitly distinguishes itself from sibling quote_* tools by framing this as a coverage check rather than a quoting action, though it does not explicitly name those alternatives.

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

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

Provides a clear use case ('check whether an item is covered before quoting'), which tells the agent when to reach for this tool. It stops short of stating when not to use it or naming specific alternatives, which keeps it at a 4 rather than 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 readOnly/idempotent/non-destructive, so the description is free to add pricing semantics instead: SGD, GST and Singapore delivery included, same-day to 5-day rush range, and that a deadline filters options with a note when none make it. It also states what is returned (all-in price plus ready-by date), which is needed since there is no output schema. It stops short of saying how quantity affects tiering or whether prices are guaranteed.

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?

Price/scope is front-loaded, then usage, then the sibling redirect, then an example — a sensible order. Minor filler remains ('for staff, offices or events') and the opening sentence is long, but no sentence is wasteful overall.

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 three-parameter, read-only, no-output-schema pricing tool, the description covers what is priced, what comes back, currency and inclusions, rush range, deadline behavior, and where to route everything else. An agent has everything needed 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 coverage is 100%, so the baseline applies; the description still adds a concrete example input showing how category and quantity combine, and reinforces that needed_by is a filter rather than a display option. The box-of-100 nuance is left entirely to 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 gives a specific verb plus return content ('Instant all-in price ... and ready-by date') and names the exact four product families covered, so an agent can match a request without opening the enum. It also explicitly contrasts itself with request_quote, which handles other custom print/merch.

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 when someone wants these printed or priced' sets the trigger, 'Pass the deadline to see options that make it' sets the behavioral tip, and 'Other custom print and merch goes through request_quote' names the alternative and the condition that selects it. There is nothing left to infer.

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?

Goes well past the annotations (readOnlyHint=false, destructiveHint=false) by disclosing the outputs: per-line match level (exact, spec, similar, needs_detail, no_match), all-in SGD price with 9% GST and Singapore delivery included, ready-by date, a total for priced lines, and a clarify list. It also implies persistence by reference to a list_id, which is consistent with readOnlyHint=false — no contradiction.

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 purpose, then behavior, then the decision rule, then an example — the ordering is right and every sentence carries information. It is a single dense paragraph, though, and the return-value details could be split for faster scanning.

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 return contract itself (match levels, all-in pricing with GST and delivery, ready-by date, totals, clarify list) and covers the escalation path to request_quote. Combined with a fully documented 6-parameter schema, nothing an agent needs to invoke or interpret it 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%, so the baseline is 3; the description adds value by restating the two accepted line shapes (a plain string like '3 x HDMI cable 5m' or an object with item, quantity, category, brand, model, specs) and supplying a concrete example input. It stops short of explaining how the string parser resolves quantities or how needed_by interacts with ready-by dates, so it is not a full 5.

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 — 'Price a whole shopping list or RFQ in one call: many line items' — and contrasts that batch scope with the single-item pricing siblings (quote_office_supplies, quote_event_print) and with request_quote for a firm quote. An agent can tell which tool handles a multi-line list versus a single item or a binding quote 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 routing: 'Never invent prices for unpriced lines: ask what clarify lists, or convert the list to a firm quote with request_quote (pass list_id).' That names the alternative and the exact handoff parameter, and the 'needs_detail/no_match' handling tells the agent what to do when pricing fails.

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 annotations (readOnly, idempotent, non-destructive), the description discloses that prices are all-in SGD including 9% GST and Singapore delivery, that options carry confidence levels (exact/spec/similar), that vague requests return match 'needs_detail', and that the agent must never invent a price. These are meaningful behavioral traits an agent needs.

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 front-loaded with the purpose and price semantics, then spec guidance, then fallback, with an example at the end. It is long and dense, and repeats some category enumerations already present in the schema enum, but the length is largely justified by the tool's 31-category scope and nested specs.

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 explains what the result includes: price, ready-by date, confidence, makes_deadline, and the needs_detail structure with what to ask the buyer. It also covers the no-match fallback, making it complete for an agent to call 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%, so the baseline is 3, but the description adds real value by mapping key specs to categories (e.g., cables need connector at each end + length; UPS needs VA rating; ink/toner needs printer brand + cartridge code + colour). It also explains that item is the buyer's own words and that structured fields improve matching, going beyond the already-descriptive 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 opens with a specific verb-and-resource: 'Current all-in SGD price ... and ready-by date for office, IT and electronics supplies.' It immediately distinguishes this quoting tool from siblings like quote_list and quote_event_print by naming the exact product scope.

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 explicitly tells the agent to pass known structured fields and the buyer's own wording, describes the 'needs_detail' flow for vague requests, and names the alternative tool request_quote with the exact category to use when nothing matches. This is clear when/when-not/alternative 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?

Adds substantial lifecycle context beyond the annotations: the tool returns a reference only, the firm price and date arrive by email usually same business day, nothing is charged until buyer approval, and delivery is Singapore only. It does not explain why destructiveHint=true or what state a submission mutates, nor whether resubmitting the same request creates duplicates (idempotentHint=false), leaving a small gap against the annotation profile.

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 routing lead the text before the use-case catalogue, and the closing example is compact. The middle sentence packs many product categories into one long clause, which is dense but each clause does narrow eligibility for an agent deciding whether to call this or an instant-quote sibling.

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 an 11-parameter, non-idempotent submission tool with no output schema, the description covers the important unknowns: what comes back (a reference), how the real answer is delivered (email, same business day), billing safety, and geographic scope. Minor omissions remain around what quantity/category imply for list requests and how duplicates are handled.

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 already 100%, so the baseline is 3, but the description adds genuine routing semantics: items and list_id are the list path, category/quantity/description are the single-item path, and items must have 'the same line items you gave quote_list'. The concrete example input {"items":["3 x HDMI cable 5m"],...} also disambiguates the anyOf string-or-object array shape.

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 ('submit a request for a firm quote') and immediately differentiates itself from siblings by naming quote_list and quote_office_supplies as the paths it does NOT cover. An agent can tell what this tool is for 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 enumerates the two calling modes (single item via category/description/quantity, or a list via items/list_id) and then enumerates the use cases that trigger it: items not matched by quote_office_supplies, custom event print and merch, unusual specs, deadlines faster than instant options. Alternatives and the conditions selecting them are named rather than inferred.

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?

The description says 'Opening the form changes nothing,' which directly conflicts with the annotation readOnlyHint=false. Although the tool defers mutation to request_quote, the no-side-effect claim is not compatible with the structured annotation declaring the tool is not read-only.

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 key purpose and distinction from request_quote are front-loaded, and the example input is useful. It is somewhat long and repeats return-value details that the output schema likely covers, but the information is mostly relevant.

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

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

Given the output schema and annotations, the description provides ample context: when to call it, what business_id to use, what prefill values do, and what the return contains. An agent has enough information to invoke it correctly aside from the annotation inconsistency.

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 parameter meanings are already well documented. The description reinforces how items, needed_by, and delivery_area prefill the form and provides an example input, but adds limited 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?

The description states a specific action and resource: opening the Get Quote form for the Singapore Buying Desk and prefilling buyer item lines. It clearly distinguishes this from submission by noting that submitting calls request_quote.

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 explicitly says ChatGPT calls this from the Get Quote button and gives the exact business_id context. It also distinguishes this prefill/open step from the actual quote submission handled by request_quote.

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 open-world, so safety is covered; the description goes well past that by disclosing ambiguity handling (up to 3 candidates), mismatch warnings for block/street/floor, the 'unknown' fallback for building type, data provenance (OneMap/SLA, LTA, HDB via data.gov.sg), and latency-relevant detail about what the normalized result contains. These are behavioral traits an agent could not infer from the schema.

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

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

It is front-loaded with the 'Use when' trigger and then the return contract, and there is no filler. The main weakness is that the opening sentence is a long enumerated run-on listing many question types, which could have been a compact bulleted list for faster scanning.

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 only one parameter, so the description must carry the return contract itself, and it does: normalized block/street/postal/unit, coordinates, district, HDB town, two nearest MRT/LRT stations with distance and walking time, building type, and delivery note. Combined with the ambiguity and mismatch caveats, an agent has everything needed to call it and interpret the result.

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 'query' parameter is already well documented in the schema, so the schema carries most of the burden. The description adds a concrete worked example, {"query":"570151"}, which anchors the expected format and implicitly confirms that a bare postal code is acceptable input.

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 title and first sentence state a specific verb and resource: resolve a Singapore address, postal code, unit number, or building name into a normalized address with enrichment. It also enumerates the exact facts it can answer (building type, HDB/condo/commercial classification, MRT proximity, district, delivery notes), so an agent can distinguish it from every sibling, which are all quote/order/weather utilities with no overlap.

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 opens with an explicit, trigger-style 'Use when the user gives or asks about...' clause and then lists concrete question shapes (what postal code is this, is it an HDB block, how far is the MRT, what a courier needs), so an agent knows exactly which user utterances should route here. It also states a hard scope exclusion, 'Singapore only', which prevents misuse for other geographies.

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, closed-world behavior, so the safety profile needs no repetition. The description adds real value beyond them by enumerating the returned statuses (received, acknowledged, quoted, closed), the timestamps, reply-by time, history and firm quote — important since there is no output schema.

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

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

Two sentences plus an example, with purpose front-loaded and return contents following naturally. Nothing is redundant 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?

For a single-parameter read tool with no output schema, the description covers both the required input shape (with example) and the full set of returned fields, so an agent has everything needed to call it and interpret 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 coverage is 100% and the schema already defines the reference format, so the baseline is 3. The description adds a worked example ('{"reference":"Q-ABC123"}'), giving the agent a ready-to-adapt invocation, which lifts it above 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 specific verb and resource ('Check the status of a custom quote request or order by its reference') and scopes it to a single lookup. An agent can tell it apart from request_quote or quote_list 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 description makes clear this is the lookup path keyed on a reference and includes a concrete example input. It does not explicitly say when-not to use it or name sibling alternatives, 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 readOnly/idempotent/non-destructive, and the description adds real value: weekends and public holidays are skipped, observed Monday holidays included, and answers carry as_of plus the official source. It does not say what happens for dates outside the 2026–2027 window or on invalid input, which keeps it from 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?

Front-loads the resource, then packs the mode logic into one dense but readable passage, ending with a concrete example input. Slightly run-on, 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?

For a read-only, no-output-schema lookup tool, the description covers data source, coverage years, weekend/holiday skipping, all four calling modes, and the shape of the answer (as_of, source). Nothing needed 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?

Schema coverage is 100%, so individual parameters are already documented; the description goes further by explaining how parameters compose (date alone vs. with add vs. with to) and that the start date is not counted. That compositional meaning genuinely exceeds 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 the specific resource (Singapore public holidays and working days, MOM data) and enumerates the four query modes, so an agent can tell exactly what it computes. No sibling covers this domain, and the 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?

Explicitly maps each argument combination to an outcome: date alone for a yes/no check, from+add for offsetting, from+to for counting between dates, year for listing holidays. This is a complete when-to-use guide with no inference required.

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, and non-destructive, so safety is covered. The description adds non-obvious operational context the agent cannot get elsewhere: refresh cadence ('fetched about every 30 minutes') and that each part carries as_of and the official source, which tells the agent how to judge data staleness.

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-loads the resource and freshness, then the payload contents, then the selector parameter. Every sentence carries information; the trailing example input is mild redundancy given the schema already shows the enum and default.

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 compensates by naming the returned sections, their fields, and the as_of/source metadata. For a zero-required-parameter read-only tool this is close to fully sufficient; only exact field-level shapes are left implicit, which is reasonable.

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 enum parameter already documents each value and the default, so the description largely restates what the schema provides. The one small addition is the framing of 'psi' as haze/air-quality readings, but that meaning is already present in the schema's parameter description.

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 and verb ('Latest NEA readings for Singapore') and enumerates exactly what is returned: 24-hour weather forecast fields by region/period and 24-hour PSI/PM2.5 with the air quality descriptor. No sibling in the list covers weather or air quality, so there is no ambiguity to resolve.

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 clear context for when to use each mode ('weather' for forecast, 'psi' for haze/air-quality) and states the default when omitted, plus a concrete example input. There are no competing sibling tools, so the absence of explicit exclusions is not a meaningful gap.

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 annotations, the description provides critical behavior not in the schema, such as returning the 'best 1 to 3 matches', providing a 'source_url and last_checked' timestamp, and labeling uncertain agency suggestions as 'guesses'.

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?

While all information is present, the definition is overly verbose. It lists nearly every possible covered topic (passports, GST, HDB, vehicles, etc.) in a dense paragraph, sacrificing conciseness for comprehensive coverage.

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

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

Given the wide range of topics it covers (from taxes to public housing to customs), the definition is remarkably complete. It defines the output format (1-3 matches), the limitations of the data, and explicitly states its 'read-only' nature and coverage limitations.

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

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

The input schema description is already very rich, providing multiple detailed examples of valid task strings. The description reiterates the 'task' nature but does not add semantic depth or constraints beyond what is provided in the schema or annotations.

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 purpose is perfectly clear: providing instructions on how to execute errands or government processes. It immediately establishes the specific geographical scope (Singapore) and the intended audience.

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

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

The description explicitly sets boundaries by stating it is 'Singapore only' and excludes general recommendations (restaurants/sights). It clearly defines when it is appropriate—when an official process or specific task needs to be researched.

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