Singapore Buying Desk (Connective Labs)

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 does add real value by naming the returned sections (specs needed to price, instant-price flags, operator details), but there is no output schema and the phrasing of the last two clauses is too vague to tell an agent what it actually receives.

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 with the verb and resource front-loaded, but it is a comma-heavy run-on whose tail ('then event print and merch categories, which ones get an instant price, and the operator details') is ambiguous and could be tightened into a clean list of returned sections.

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 no-parameter read tool whose annotations already carry the safety profile, the description gives an adequate picture of what the listing contains. The lack of an output schema means the description ideally would pin down the returned structure more concretely, which it only partially does.

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 there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-related 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?

States a specific verb (list) and resource (categories the Singapore Buying Desk quotes), and its content scope separates it from the sibling quote_* tools that actually produce prices. The trailing fragments ('which ones get an instant price, and the operator details') blur the boundary slightly, but the core purpose is unmistakable.

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 only implied: an enumeration tool naturally precedes the quote_* siblings, but the description never says 'call this before request_quote' or names an alternative. No when-not guidance either, so an agent must infer the 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 only declare readOnlyHint and openWorldHint, so the description carries the rest of the burden. It discloses that the price is all-in (GST and Singapore delivery included, SGD) and that same-day to 5-day rush is available, which is genuinely useful context beyond the annotations. It does not discuss rate limits or pagination, but for a read-only quote endpoint that is a minor omission.

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 value (instant all-in price and ready-by date) before category detail, and every clause adds information. It is denser than needed in the first sentence, 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 no output schema, the description nonetheless tells the agent what comes back (all-in price in SGD plus a ready-by date). Combined with the clear scope boundary against request_quote, nothing an agent needs to select or invoke this tool 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?

With 67% schema coverage, the description adds real meaning: it clarifies that needed_by drives rush-option selection ('Pass the deadline to see options that make it') and lists the category values in prose, reinforcing the enum. Quantity semantics are left to the schema's own note, so it goes slightly beyond baseline but not fully.

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 (instant all-in price and ready-by date for event print/merch) and enumerates the exact product categories covered. It explicitly names request_quote as the handler for everything outside that scope, so an agent can distinguish it from siblings 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 the trigger ('Use when someone wants these printed or priced'), the key action ('Pass the deadline to see options that make it'), and an explicit exclusion routing other custom print/merch to request_quote. When-to-use and when-not-to-use are both 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/idempotent/non-destructive, and the description adds real behavioral context: prices are all-in SGD with 9% GST and Singapore delivery, and unpriced lines must be surfaced rather than fabricated. It does not discuss rate limits, batch cost, or failure modes for a 50-line call.

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 purpose and return shape before the edge-case rule, and most clauses earn their place. The final sentence is dense and slightly run-on, packing the anti-fabrication rule and the request_quote escalation into one string.

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 takes on the burden and discharges it: it enumerates the per-line returns (match level, all-in SGD price, ready-by date), the aggregate total, and the clarify list. An agent knows what it will get back and when to escalate.

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 every parameter is already documented there. The description restates the string-vs-object line format ('item, quantity, category, brand, model, specs') without adding syntax or precedence rules 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 ('price a whole shopping list or RFQ in one call') and scopes it to many line items across office/IT supplies and event print, which cleanly separates it from the single-item siblings quote_office_supplies and quote_event_print.

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: use this for bulk lists, and 'convert the list to a firm quote with request_quote (pass list_id)' names the alternative plus the parameter to thread. It also states the negative case ('Never invent prices for unpriced lines') and what to do instead.

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?

Without output schema, the description carries the burden and does so well: it specifies the exact price semantics (9% GST + Singapore delivery included), the confidence tiers (exact/spec/similar, with differences listed for similar), the no-match behavior ('needs_detail' plus what to ask), and the hard rule to never invent a price. The annotations (readOnlyHint, openWorldHint=false) already establish safety and closed-world scope; the description adds the pricing and matching behavior on top. It doesn't cover rate limits or latency, but that's minor for a read-only quote 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 long and dense, but the upfront sentence delivers the core value first (all-in price + ready-by date + scope) before the enumeration and per-category spec list. The spec guidance is genuinely useful and not padded, though the length is at the upper end for a tool description. It earns most of its words.

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

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

For a 7-param, no-output-schema read-only quoting tool, the description is complete: it defines what the tool returns, the input it expects, the confidence model for results, the vague-input handling path, and the fallback to request_quote when nothing matches. An agent has everything needed to call it, interpret the result, and act on 'needs_detail'. Nothing essential 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 schema already documents each parameter. The description adds value beyond that by prescribing per-category key specs (cables: connector at each end + length in metres; adapters: from + to; memory cards: card type + capacity; flash drives: capacity + connector; SSD/HDD: capacity + internal/external; UPS: VA rating or model; ink/toner: printer brand + cartridge code + colour; mice/keyboards: model or wired/wireless; monitors: size in inches; switches: port count). This is actionable guidance that improves match quality, exceeding the baseline 3 despite full schema coverage.

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 precise statement of what the tool returns: a current all-in SGD price (including 9% GST and Singapore delivery) and a ready-by date for office/IT/electronics supplies. It enumerates the supported categories and scopes the result to Singapore, distinguishing it clearly from the other quote_* siblings (quote_event_print, quote_list, 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 tells the agent to 'Pass category, brand, model, specs, quantity and needed_by whenever you know them, plus the buyer's own words in item.' It also handles the vague-request case: if the result has match 'needs_detail', ask the buyer and call again. And it routes to the alternative sibling: 'if nothing matches, call request_quote with category office-it-supplies.' Nothing 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 cover the safety profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description adds workflow context they do not: a reference is returned, the firm price and date arrive by contact email usually the same business day, nothing is charged until the buyer approves, and delivery is Singapore-only. That is genuinely useful post-submission behavior. It stops short of five because it does not address whether resubmitting duplicates a request, even though idempotentHint=false.

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 core purpose in the first sentence, then adds usage, return behavior, charging, and geography in a tight paragraph. Long but nearly every sentence carries information an agent needs; only the sibling enumeration borders on list-like density.

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 mutation tool with no output schema, the description covers the input modes, what is returned (a reference), how the firm quote reaches the buyer, cost implications, and the Singapore-only constraint. What remains unexplained is mostly handled by the high-coverage schema, so it is complete enough 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 description coverage is 91%, so the baseline is 3 and the schema already documents most fields. The description adds routing meaning the schema lacks on its own: items must be "the same line items you gave quote_list," list_id comes from quote_list, and category/quantity/description are single-item-only, which clarifies the mutually exclusive modes.

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 contrasts its scope with siblings: it covers what quote_office_supplies doesn't match, plus custom print/merch and orders for instantly priced items. An agent can tell it apart from quote_list, quote_office_supplies, and quote_event_print 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?

Explicit about the two invocation modes (single item vs whole list) and which field selects each. It enumerates the concrete situations that route here: unmatched office/IT items, custom event print and merch, unusual specs, deadlines faster than any instant option, and orders of instantly priced items. Nothing 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, idempotentHint and destructiveHint=false, so safety is covered; the description adds real value by clarifying 'Opening the form changes nothing', which confirms the no-side-effect behavior and defines the boundary with request_quote. It does not describe the returned form payload, but an output schema exists to carry that.

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 are front-loaded with the purpose and then the invocation/behavior, with no filler. The parentheticals (entity name, business_id slug) are dense but justified for disambiguation.

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 rich annotations, a full output schema, and 100% parameter coverage, the description only needs to add routing and behavior — which it does: purpose, trigger, no-op confirmation, and the hand-off to request_quote. 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% and the descriptions are rich (regex-style examples, spec field lists, enums-by-example), so the schema does the heavy lifting. The description restates the business_id source already in the schema and only loosely gestures at the items prefill behavior, adding little beyond structured data. 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 ('Open the Get Quote form for the Singapore Buying Desk'), names the exact business entity, and explicitly distinguishes itself from the sibling that actually submits ('submitting it calls request_quote'). An agent can tell it apart from request_quote 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?

Gives the exact trigger ('ChatGPT calls this from the Get Quote button with the business_id from the business feed') and names the alternative action and when it applies (submitting calls request_quote). Both the when-to-use condition and the responsibility boundary are 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 read-only, idempotent and open-world, and the description adds substantial behavior beyond them: up to 3 candidates on ambiguous input, explicit mismatch warnings for block/street/floor, 'unknown' fallback for the delivery note, and named upstream data sources (OneMap/SLA, LTA, HDB). This is unusually thorough for a lookup 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?

Front-loaded with the trigger condition, then a dense but justified enumeration of return fields. The long return list is warranted because there is no output schema, though the prose runs as one block and could be broken into 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?

With no output schema, the description takes on the burden of describing the response (normalized address, coordinates, district/HDB town, two nearest stations with distance and walk time, building type, delivery note) and does so completely, including the ambiguity and mismatch behaviors an agent must handle.

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?

There is a single parameter and schema description coverage is 100%, so the schema already carries accepted forms and examples. The description restates the same input shapes ('as the user wrote it', abbreviations) without adding syntax or constraints the schema lacks, 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?

States a specific verb+resource (resolve/look up a Singapore address, postal code or building) and pins the scope with 'Singapore only'. The sibling list contains no overlapping tool, so differentiation is not an issue and the purpose is unmistakable.

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?

Opens with a rich trigger list ('Use when the user gives or asks about a Singapore postal code, block and street, unit number, or building or place name') plus concrete question archetypes the tool answers. It never names a fallback alternative for non-Singapore or multi-location inputs, only the 'Singapore only' 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 that the lookup spans both quote requests and orders, but says nothing about auth needs, rate limits, or lookup-failure behavior. Modest added value on top of 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?

A single front-loaded sentence with no wasted words. It is sized correctly for a one-parameter read tool, though it is minimal enough that it could have afforded one more clarifying clause.

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-parameter read operation with annotations covering the safety profile and no output schema required in the description, this is nearly complete. The only shortfall is the absence of any lookup-failure or result-shape context.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter. 'By its reference' does give the parameter's semantic role, but it adds no format, type, or example detail. Adequate but thin given the zero coverage.

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 clear verb+resource ('Check the status of a custom quote request or order') and names the lookup key ('by its reference'), which separates it from the list-type siblings like quote_list. It could be sharper about the odd mismatch between the tool name (rush_order_status) and the quoted breadth (quote requests AND orders).

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 implies the usage precondition (you must have a reference) but never says when to pick this over quote_list or request_quote, nor any exclusions. That is the same level of guidance as the MID calibration example, which scored 2.

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 (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: returns 1-3 matches with source_url and last_checked, discloses uncertainty by flagging guesswork for uncovered tasks, and explains agent-vs-user hand-off. This is rich disclosure layered on top of 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?

Front-loads the use case and the return contract before the long coverage inventory, and the inventory does earn its place for retrieval routing. However, the mid-section is a dense run-on list that would read better as bullets, costing some scannability.

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 full burden and does so: it specifies the returned fields (source_url, last_checked), the match count (1-3), the 'not covered' behavior, and the guess-labelling. Nothing material is missing for correct invocation.

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 shows example task strings, so baseline is 3. The description adds value by enumerating the domains of valid tasks (passports, tax, work passes, HDB, etc.), which helps an agent frame the free-text 'task' argument correctly, though it does not define syntax beyond that.

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 function (find how to get a Singapore errand/government process done) and enumerates the exact domain coverage, so an agent can tell it apart from the quote/address siblings at a glance. The scope is bounded (Singapore only) and the output shape (best 1-3 matches) is named.

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 who it is for (residents, employers, visitors), what it returns, and gives clear exclusions: 'Singapore only; not for other countries, and not for recommendations such as restaurants or sights.' The alternative-use boundary is stated rather than inferred.

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