Western Reporting Services

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered. The description adds that this is a single independent firm's static profile (since 1990), which is modest but relevant context; it says nothing about caching, auth, or freshness, but little more is needed for a read-only constant-data lookup.

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 tight sentence with no filler, front-loading the returned fields and appending identifying context about the firm. Slightly list-heavy, but every element 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 no output schema, the description usefully enumerates what comes back, which is exactly the missing structured information. The only real gap is the absence of routing guidance against siblings like wrs_list_services.

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 there is nothing for the description to disambiguate; baseline 4 applies. The enumeration of returned fields is a bonus, not a parameter concern.

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

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

The description names the exact entity (Western Reporting Services, a Las Vegas court reporting firm) and enumerates the facts the tool surfaces (name, legal name, address, phone, fax, service area, portal, hours, services). An agent can tell it apart from wrs_list_services or wrs_glossary_term, though it never states the operation ('returns'/'retrieves') explicitly.

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 any sibling tool, even though wrs_list_services and wrs_search are obvious overlaps for the 'services' field it returns. The agent must infer that this is the static company-profile lookup.

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 readOnlyHint=true already covering the safety profile, the description goes further by disclosing the actual payload: Markdown body, URL, dates and a legal-source note. Since there is no output schema, this return-shape disclosure is the only place an agent learns what comes back. It stops short of pagination or size limits, but nothing misleads.

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 dense sentences with the return contents front-loaded and the required input handled second. No filler, no restatement of the tool name.

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

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

For a two-parameter read tool with no output schema, the description supplies exactly the missing piece: what the returned Markdown contains. The language parameter and its default are left entirely to the schema, which is acceptable given 100% coverage, but a note on translation behavior would close the remaining gap.

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 both slug and language are already fully documented in the schema (including the enum and the translated-slug caveat). The description only adds the provenance of the slug value, which is minor beyond the schema's own example. 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+resource: retrieve ONE guide in full, and enumerates the content shape (sections, checklist, common questions). 'One guide in full' implicitly contrasts with wrs_list_guides, so an agent can tell the two apart 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?

'Pass the slug from wrs_list_guides or wrs_search' tells the agent the prerequisite discovery step, which is genuine usage context. However, it never states when NOT to use this tool, nor contrasts the retrieval semantics against siblings beyond the implied slug source.

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 genuinely useful behavior beyond that: matching is by term, alias, or a 'close contains-match', which tells the agent to expect fuzzy results. It says nothing about what happens on no match or the shape of the returned entry.

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

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

One sentence with the core purpose front-loaded, then the matching note. The parenthetical example list is long but earns its place by scoping the domain. No filler or repetition.

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

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

For a one-parameter, read-only lookup with no output schema, the description covers purpose, domain, and input matching. The only real gap is the no-match/empty-result behavior, which matters because 'contains-match' implies possible misses or false positives.

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 only says 'The term to define.' The description adds meaning by stating that aliases and partial/close matches are accepted inputs, which directly informs what string the agent should pass. That is real added value above the schema's baseline.

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

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

The description gives a specific verb-and-resource ('Plain-English definition of a court reporting or deposition term') and anchors the domain with concrete examples (appearance fee, errata sheet, stenotype, 30(b)(6)). It is clearly distinguishable from generic siblings like wrs_search or wrs_get_guide 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?

It implies when the tool applies (a terminology lookup) and describes the matching modes, but never states when NOT to use it or names an alternative such as wrs_search for broader queries. Usage is inferable rather than prescribed.

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 safety is covered; the description adds real value beyond that by describing the returned record shape (slug, title, description, published/updated dates, FACTS sourcing flag) and the availability of translated witness guides. It does not discuss pagination or result-size behavior, keeping it short of 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?

Two sentences, front-loaded with the resource and its metadata before the language note. The first sentence is dense with an enumerated field list, but every element is informative and nothing is redundant.

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, read-only, single-optional-parameter index tool with no output schema, the description supplies the returned fields, the language variants and their scope, and the domain context (Nevada practice, FACTS rules) an agent needs. Nothing required 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 coverage is 100% and the enum is already documented, so the baseline is 3. The description goes further by explaining the semantics behind the values: non-English codes apply specifically to translated witness guides, and the parameter is passed to 'list those' rather than to translate any guide.

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

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

The description names a specific resource (the firm's long-form guides on depositions and Nevada court reporting) and explicitly frames the tool as an 'Index', which cleanly separates it from the singular wrs_get_guide sibling. It even enumerates the metadata each entry carries (slug, title, description, dates, FACTS sourcing flag), so the agent knows exactly what kind of listing this is.

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 gives one concrete usage rule — pass language to retrieve translated witness guides — but never states when to choose this index over wrs_get_guide or wrs_search, nor any exclusions. Usage is implied (browse the catalog first) rather than spelled out.

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 safety is covered. The description adds useful return-shape context ('a summary and the page URL' per service) that no output schema provides. It does not discuss ordering or pagination, but for a small static catalog that is minor.

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, front-loaded with the resource and its full scope. The parenthetical enumeration is long but earns its place as concrete scope evidence rather than 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 carries the return-value burden and does so at a high level (summary + page URL). Combined with the annotations, an agent has enough to call it correctly; only ordering/details of each summary are absent.

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 no parameters, which is the baseline-4 case. The description correctly implies a zero-argument catalog call with no filtering options to document.

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?

Names a specific verb (list) plus resource (services) and scopes it to 'every service Western Reporting Services offers', so it is clearly distinguished from the sibling catalog tools (list_guides, glossary_term, business_facts). The parenthetical enumeration of service categories makes the scope 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?

Usage is implied – this is a browse-all catalog call – but the description never states when to prefer it over wrs_search, wrs_business_facts, or the other list_* siblings. No exclusions or alternate paths are 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 safety is covered. The description adds real value beyond that by disclosing which fields are searched and that results include a URL and snippet, though it says nothing about ranking, match quality, or behavior when no results are found.

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, front-loaded with what is searched, then what is returned, then the follow-up tool. No filler.

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

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

For a read-only search tool with no output schema, the description supplies the missing return-shape information (URL plus snippet) and the escalation path to wrs_get_guide. Nothing essential for correct invocation is absent.

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%, including examples for query, a range/default for limit, and the enum plus default behavior for language. The description adds no parameter-level detail 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 (keyword search) and the exact resources searched (guide titles, section headings, body text, glossary terms). It also names the sibling wrs_get_guide, making it easy to distinguish from 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?

Explicitly routes the agent: 'Use wrs_get_guide for the full text of a match,' which clarifies the search-then-fetch workflow. It does not, however, say when to prefer this over sibling wrs_glossary_term or wrs_list_guides, so exclusions are incomplete.

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