Lie Detector Test

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

Annotations indicate readOnlyHint and openWorldHint. Description adds that offices are found with address, prices, and a booking link, complementing the annotations without 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?

Two sentences with essential information front-loaded. No extraneous details.

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 no output schema, the description adequately covers returns (address, prices, booking link). For a search tool with two simple parameters, this is sufficient.

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 describes two parameters with descriptions. The description adds context on allowable search terms (city, state, country) and the default limit, enhancing semantic understanding.

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 the tool finds polygraph test offices near a place, provides search criteria, and lists return fields. It distinguishes from sibling tools that handle booking, pricing, and service info.

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 specifies when to use (find offices) and limits search to specific countries. It does not explicitly exclude other uses but provides clear context.

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=true, so safety is covered. The description goes beyond that usefully by disclosing what is returned ('status and location') and interpreting the 'request' status value, which an agent could not infer from annotations 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?

Two tight sentences: purpose and expected output first, then the status interpretation. No filler and nothing buried.

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 supplies the essentials: the reference lookup, the return shape, and the meaning of a key status value. Minor gap is that no other status values are enumerated.

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

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

Schema coverage is 100% and the schema already documents booking_reference with the identical example. The description repeats the format rather than adding new semantics such as case sensitivity or format rules, so it sits at the 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+resource: 'Check the status of an existing booking or appointment request by its reference.' This is clearly distinguishable from the sibling 'start_booking', but the description never names that sibling or otherwise explicitly contrasts itself.

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

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

Usage is implied by 'existing booking' (i.e. use after a booking exists, not to create one), but no explicit when-to-use/when-not or prerequisites, and no reference to alternatives such as start_booking or get_pricing.

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 and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious business context: the tiers returned and the payment flow (no booking fee, nothing paid online, client pays the examiner directly once accepted), which the agent cannot get from annotations or 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, front-loaded with the core action and followed by return/payment detail; no filler. The payment clause is slightly long but carries information the agent cannot otherwise obtain, so it 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?

There is no output schema, so the description must characterize the return value itself, and it does: it names the three price tiers and explains the payment arrangement. For a one-parameter read-only lookup, nothing an agent needs in order to call and 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% and the single 'query' parameter is documented with concrete examples (city, state/region, country). The description adds only the phrase 'for a location', which does not extend the schema's semantics, 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 and resource ('Get polygraph examination pricing') plus the scope ('for a location'), and enumerates what is returned. It is easy to distinguish from find_offices, get_booking_status, and start_booking by name and job, though it never explicitly names those siblings.

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 agent can infer this is the pricing lookup step before start_booking, but the description never says when to call it versus get_service_info or find_offices, nor does it state prerequisites. The implied context is reasonable but no explicit routing guidance is 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=true and openWorldHint=false, so the safety and scope profile is covered structurally. The description's enumeration of topics tells the agent what content comes back, but adds nothing about format, length, or whether content is static versus dynamic — reasonable but not rich beyond the annotations.

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

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

A single front-loaded sentence naming the resource followed by the topic list, plus a short no-argument note. The topic enumeration is informative but slightly list-heavy; every item does correspond to a plausible user question, so little is wasted.

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

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

For a no-argument, read-only info tool with annotations carrying the safety profile and no output schema required, the description covers what the agent needs to select and call it. The only missing piece is routing guidance relative to get_pricing and find_offices.

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?

Zero parameters, so the baseline is 4. The description reinforces this explicitly with 'Takes no arguments,' removing any doubt that the agent should call it bare with no payload.

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 ('Get general information') and resource (the lie detector test service), then enumerates the covered topics: offerings, booking, payment, service area, and post-booking. This is clear on its own, but it never explicitly distinguishes itself from siblings like get_pricing and find_offices, which overlap with the 'how payment works' and 'service area' topics it claims.

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 agent can infer this is the orientation/FAQ tool to call before start_booking, but the description never says so or names alternatives. It does add 'Takes no arguments,' which signals a safe first call, yet there are no explicit when-to-use or when-not-to-use rules against the four sibling tools.

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: nothing is paid online, no booking fee, the examiner contacts the person and agrees date/payment/cancellation terms, and payment goes directly to the examiner. It also discloses the return payload (booking reference, office, page link) and a security constraint about not putting contact details in a URL — none of which the annotations convey.

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

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

Front-loads the core action, then cost, then the usage restriction, then the return value. Every sentence carries information, though it is on the denser side for a single tool call.

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 explains what comes back (booking reference, office, page link) and what the person can do with it. Combined with the payment and consent framing, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description only lightly reinforces 'location' and contact details via the URL warning; it adds no new field-level semantics. 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: sends a free appointment request directly to the examiner covering the chosen location. It's immediately distinguishable from its read-only siblings (find_offices, get_pricing, get_booking_status, get_service_info) because it is clearly the one that creates a request.

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 constrains use: 'Only use this when the person has asked you to send the request with these details.' That is a clear precondition. It does not name which sibling to use instead when the person is just browsing, so it falls short of the top band.

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