Sapien Solutions

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses that content is anonymized and returns only title/summary/links, and that full text lives elsewhere, but says nothing about list size, pagination, ordering, or caching. With a rich output schema present, the remaining omission is moderate rather than critical.

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

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

Two short sentences with zero filler; the primary content description is front-loaded and the follow-up action (read_page) comes second. Every clause earns its place.

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

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

With an output schema present, the description need not explain return values, and with zero parameters there is no input surface to document, so the remaining burden is light. It covers transparency ('anonymized') and the handoff to read_page; only list-level behaviors like pagination are unaddressed.

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 (empty object schema, additionalProperties false), so there is no parameter meaning to convey and the baseline of 4 applies. Nothing in the description misrepresents the parameterless interface.

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 resource (anonymized case studies) and enumerates the returned fields (title, summary, links), which lets an agent distinguish it from sibling 'company' or 'service_area'. It also explicitly routes deep-dive reading to read_page, giving sibling differentiation. It stops short of a 5 only because 'case studies' largely restates the tool name.

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 clearly names the alternative and the condition that selects it: fetch this list for summaries, then 'Use read_page for the full text.' What's missing is an explicit statement of when this tool is the right first step (e.g., browsing/listing) versus when it should be skipped, so it is clear context without full exclusions.

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 implicitly signals a safe, static read by describing informational content, but never states that it is read-only, whether it is cacheable, or what the response shape looks like beyond the section list. Adequate for a zero-risk info tool, but thin on disclosure.

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, no filler, with the content inventory first and the call-ordering imperative at the end. Every clause maps to real returned content.

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?

An output schema exists, so return values do not need spelling out, and with no parameters the calling contract is trivially complete. The content enumeration plus the "call first" cue is enough for an agent to use it correctly, though a hint about the intended orientation workflow would round it out.

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 declares zero parameters, which is the baseline-4 case; there is no parameter meaning to add. Nothing in the description contradicts or complicates the empty parameter set.

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 exact content the tool returns: company identity, four lines of work, locations, engagement process, and contact routes. It is easy to distinguish from siblings like case_studies, service_area, or request_inquiry, though it encapsulates the purpose as a content inventory rather than a crisp verb+resource phrase.

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?

"Call this first" gives explicit sequencing guidance that no sibling provides, which is genuinely useful for an agent orienting itself. It does not name conditions for avoiding it or point to alternative tools, so it stops short of full when/when-not coverage.

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, the description carries the full behavioral burden. It does disclose the return format (markdown) and that the whole page is returned ('full text'), which implicitly addresses truncation, but it says nothing about auth requirements, error behavior for an unknown path, or whether boilerplate/navigation is included.

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 that leads with the return type and the input selector. It is efficient, with only mild overlap between the description's path example and the schema's identical example.

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?

An output schema exists, so return values need no elaboration, and the description covers the one input's semantics. The remaining gap is routing context relative to the sibling page tools, which matters more here than for a leaf utility.

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 only one parameter exists, so the schema already documents 'path' fully. The description's example value ('/how-we-work') reinforces the expected format but adds nothing the schema does not already state.

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 verb and resource ('The full text of one page of our site as markdown, by its path') and even shows the path format. It does not, however, distinguish this generic page reader from siblings like company, service_area, or case_studies, which likely return the same kind of page content.

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 and no mention of alternatives. An agent cannot tell from the description whether read_page is the general entry point or a fallback when the section-specific siblings (company, service_area, case_studies) do not apply.

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, the description carries the full disclosure burden, and it does add real context: submissions are routed by email to the practitioners, not a generic inbox. However, it says nothing about confirmation, storage, failure modes, or rate limits, and its claim that the tool 'needs' name, email/phone, and need conflicts with the schema, which marks zero required parameters.

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

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

Three short sentences with the purpose front-loaded and no padding. The informal phrasing ('Send us an inquiry') is slightly less precise than it could be, but nothing 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?

An output schema exists, so return values need not be explained, and the schema covers all parameters. What is missing is what happens after submission and an accurate statement of constraints, since the description's implied required fields disagree with the schema's zero-required configuration.

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 the schema already documents all six fields, including the mutually-exclusive email/phone rule and the enumerated lines of work. The description only restates a subset ('name, an email or a phone, and what they need') and none of the optional fields, so it adds nothing beyond schema 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 concrete verb and resource ('Send us an inquiry') plus the delivery mechanism ('reaches the people who do the work, by email'), which is enough to distinguish it from read-oriented siblings like read_page, case_studies, and company. It never names a sibling explicitly, so it falls short of the 5 benchmark.

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 rather than stated: the agent can infer this is the contact/submission path, and the sentence about required inputs gives a shape for invocation. There is no explicit when-to-use, when-not-to-use, or reference to an alternative sibling 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 are provided, so the description carries the full behavioral burden. It discloses the shape of the result (coverage determined per place and per line of work), which is useful context beyond the schema, but says nothing about prerequisites, whether this is a read-only lookup, or any limits. For a low-risk query tool this is only partially sufficient.

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 short — two sentences with no filler — but the structure is back-to-front: it leads with an awkward return-value clause and buries the actionable instruction second. The opening sentence is grammatically fragmentary, which costs readability at the exact point where clarity matters most.

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?

The tool is simple (one fully documented parameter, an output schema that presumably explains the coverage result), so a terse description is defensible. However, the concept of 'per line of work' is never explained, and the purpose phrasing is ambiguous enough that an agent cannot be fully confident about what it is calling. Adequate but with clear gaps.

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 with 100% schema description coverage, so the schema already fully documents the accepted location formats. The description's 'town, county, state or address' merely restates that list (and omits ZIP code) without adding syntax, normalization, or ambiguity-resolution guidance. 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?

The description conveys the domain meaning of the tool (on-site vs remote coverage, per line of work) but never states the action verb — an agent must infer that this is a lookup/check rather than a write. It distinguishes itself from siblings by topic (location coverage), which is better than a tautology, but the phrasing 'Whether we work on site or remotely for a place' reads as a return-value statement rather than a purpose statement.

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?

'Give a town, county, state or address' is input formatting guidance, not when-to-use guidance. There is no mention of the alternatives among siblings (request_inquiry, company, read_page) or of any condition that would select this tool over them. The agent is left to infer the trigger scenario entirely.

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