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

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so the bar is lower; the description still adds real behavioral detail by naming the two layers probed, the conditional hub fetch, and that it reports the failing layer plus remediation. The trailing 'Read-only' restates readOnlyHint, which is unnecessary but harmless.

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 zero waste, front-loading what is checked before how failures are reported. 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?

There is no output schema, so the description carries the burden of describing returns; it does so partially by saying it reports the failing layer and what to do about it, but does not indicate the response shape or how success is signaled. Adequate for a no-arg diagnostic, though not exhaustive.

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 misleading hints about inputs are present.

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 (checks the bridge connection, fetches a hub's appointments page) and clearly positions itself as a two-layer diagnostic, which cleanly distinguishes it from the sibling list_* tools. The conditional 'if a hub is configured' also conveys scope precisely.

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 the diagnostic framing rather than stated: an agent can infer this is the connectivity-verification tool, but the description never says when to reach for it versus the sibling list_* tools (e.g. 'run this first if a list call fails'). No exclusions or prerequisites 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, idempotentHint and openWorldHint, so the safety profile is covered and 'Read-only.' adds nothing. The description does add genuine behavior beyond that: the Today/Upcoming/Past grouping, the field set carried per visit, and the quirk that `time` is null when a provider hides times.

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 resource and grouping, then the per-visit fields, the null-time caveat, and the range filter — four tight, information-dense sentences. Only the trailing 'Read-only.' is dead weight because the annotations already say it.

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-shape burden and mostly meets it: grouping, per-record fields, and the brief-vs-full distinction (delegated to the schema). It stops short of stating result limits, ordering within groups, or unchanged behavior when both date bounds are omitted.

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 start, end, hub and view, including the inclusive-range semantics and the brief/full output formats. The description's '`start`/`end` keep only visits dated in that inclusive range' largely restates the schema and it says nothing about the hub parameter, so 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 resource and scope: 'Scheduled visits from a provider's Jobber Client Hub, grouped Today / Upcoming / Past.' The resource (visits) is clearly distinct from the sibling list tools (invoices, quotes, work requests), so an agent can route correctly 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?

Usage is only implied by the resource name; there is no explicit when-to-use, when-not, or pointer to alternatives such as jobber_read_page or jobber_list_hubs for other data. The 'start'/'end' filtering note hints at one use case but does not frame it against alternatives.

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 and idempotent behavior. The description adds important behavioral details beyond that: hub ids are never returned because they are credentials, and each business has its own hub with no combined view. This is consistent with annotations and provides security-relevant context.

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 three sentences, each serving a purpose: what it lists, scope limitations, and security behavior. The first sentence could be more active ('Lists...') but the structure is front-loaded and free of 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 zero-parameter read-only tool without an output schema, the description covers what is returned (labels, default), what is never returned (hub ids), and scope boundaries. It is sufficient for an agent to call this tool 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?

With zero parameters and an empty input schema, the baseline is 4. The description does not need to add parameter details, and it does not attempt to.

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 lists provider hubs configured for this server, by label, and identifies the default. It differentiates from siblings that operate on appointments, invoices, quotes, and work requests, and explicitly excludes returning hub ids.

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 implies usage for retrieving hub configuration but does not explicitly say when to use this tool versus alternatives. The note about no combined view across providers provides a contextual constraint, but no named alternative or explicit 'use this when' 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 and idempotentHint, so 'Read-only; this cannot pay anything' is partly redundant, though it usefully clarifies the financial scope. The genuinely additive content is the prompt-injection warning about third-party-authored text and the explanation that `details` is kept raw because its rows vary by invoice state — context no annotation supplies.

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 what the resource is, then the record shape, then the safety/trust caveat. Each sentence contributes something distinct and there is 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?

With no output schema, the description does the right work by describing the returned fields, the section grouping, and the untrusted-content caveat. It omits ordering, pagination or result-size behavior, which matters for a list tool against an open-world source (openWorldHint=true).

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 `view` description already spells out the brief line format, so the schema carries the parameter burden. The description adds framing about why `details` appears raw, but nothing about `hub` semantics or defaults beyond what the schema states — 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?

The description names the resource concretely ('Invoices a provider has sent through Jobber') and enumerates what each record carries (number, subject, list section, raw `details` rows), which separates it from siblings like jobber_list_quotes and jobber_list_appointments. It never explicitly contrasts itself with those siblings, so it stops short of a 5.

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: the tool lists invoices and the description notes the records are grouped by section. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling for filtered or paged needs (e.g. jobber_read_page for large result sets), leaving the agent to infer 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 declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is already covered; the description adds non-obvious context instead of repeating it. It discloses a capability limit (no approvals) and, notably, a trust boundary — returned text is third-party authored and untrusted, to be treated as data. Pagination and result-size behavior are the main remaining gaps, and there is no output schema to cover them.

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 the tool returns, then the capability boundary, then the security caveat. Every sentence adds information an agent could act on, with no restatement of the title or 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 one-parameter read tool with full annotations and no output schema, the description does the necessary work: it names the return shape, rules out mutations, and flags untrusted content. Only the absence of any paging or volume expectation keeps it from being fully 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?

There is a single optional parameter (hub) with 100% schema coverage and an enum, and the description says nothing about it. With schema coverage this high, the schema carries the semantics and a baseline 3 is appropriate — the description neither adds nor detracts.

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 identifies the resource concretely ("Quotes a provider has sent through Jobber") and enumerates the returned fields (number, subject, section/approval state, raw metadata rows), so an agent knows what comes back. It lacks an explicit list verb and does not name a sibling, but the resource makes the list-style operation inferable.

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: read this to see quotes a provider has sent. The one explicit boundary, "approving a quote is not possible through this server," tells the agent what it cannot do but not which sibling to pick instead (e.g. jobber_read_page for full details) or when quotes are preferable to invoices or work requests.

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 openWorldHint, and the description usefully reinforces read-only while adding genuinely new context: the returned text is third-party authored and untrusted, so it must be treated as data. That prompt-injection warning is valuable safety information an agent cannot get from annotations. It does not describe pagination or volume 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 tight sentences: the resource and scope come first, then the safety caveat. No filler, no restatement of the title, and every clause carries information an agent needs.

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-only list tool with full schema coverage, the description covers what it returns at a reasonable level and flags the untrusted-content risk. Return shape is described only loosely ('metadata rows'), but with no output schema that is a minor gap rather than a blocker.

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?

Only one optional parameter, and schema description coverage is 100%, so the schema already explains the hub label and the 'omit when only one is configured' rule. The description adds nothing parameter-specific, so 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?

Names a specific resource (work requests raised through a provider's Jobber Client Hub) and says what comes back (current section/state plus metadata rows). It is clearly distinct from the sibling list tools by domain (appointments, invoices, quotes), though it never explicitly contrasts with them and frames the tool as a noun phrase rather than an action.

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 scope: read work requests you have raised with a provider. There is no explicit when-to-use versus when-not guidance, no mention of alternatives such as jobber_read_page for detail retrieval, and no stated prerequisites. Adequate but inference-based.

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 provides crucial operational behavior beyond hints, specifically warning that the returned text is untrusted and authored by third parties. It also specifies that the tool refuses certain routes, adding critical context for the agent's decision-making.

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 definition is highly efficient. It front-loads the core function and quickly transitions into scoping, usage criteria, and limitations without unnecessary jargon. Every sentence provides essential decision-making value.

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 that this tool has multiple parameters and a complex domain scope, the description is exceptionally complete. It covers what it is, what it can do, what it refuses, and the nature of the output data, leaving minimal ambiguity for the agent.

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?

Although the schema coverage is 100%, the description adds significant semantic meaning by providing specific usage examples for the path parameter (e.g., 'invoices/150208512'). This clarifies how to structure the path beyond the regex provided in 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 clearly defines the action ('Fetch a read page') and the specific resource types it targets (appointments, invoices, quotes, work_requests). It explicitly separates itself from list-only tools by describing detail page usage.

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 provides excellent guidelines for usage: use it for detail pages or when list tools fail, and explicitly states when not to use it by refusing other hub routes like logout or payment pages.

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