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

No annotations are provided, so the description carries the full burden. It says 'Trigger the Jobber OAuth login flow' but doesn't disclose what happens after triggering—whether it returns a URL, redirects, sets a token, or requires user interaction. For an auth flow, this is a significant gap.

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 short sentence that is front-loaded with the action verb and resource. No wasted 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 tool with no parameters and no output schema, the description is minimal. However, an auth flow typically has side effects (tokens, sessions, redirects) that are not disclosed. The description doesn't explain what the agent should expect after calling it, which is critical 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?

The tool has zero parameters, so the schema is trivially complete. The description doesn't need to explain parameters, and the baseline for 0 params is 4. It correctly implies no input is 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?

The description states a specific verb ('Trigger') and resource ('Jobber OAuth login flow'), making it clear this tool initiates authentication. It doesn't explicitly distinguish from siblings like auth_status or logout, but the action is distinct enough that an agent can infer the purpose.

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 this is the entry point for OAuth login, but it doesn't state when to use it versus auth_status or logout. There's no explicit guidance on prerequisites (e.g., needing a redirect URI or prior setup) or when this should be called before other 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?

No annotations are provided, so the description carries the full burden. It states that the tool checks authentication and token expiry, implying a read-only status check. However, it does not explicitly disclose side effects, whether it makes network calls, or whether it requires prior authentication. The behavioral traits are partially disclosed but not fully.

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 a single, concise sentence that is front-loaded with the core action and resource. Every word is meaningful and there is no redundancy or fluff. It is optimally sized for a simple status check tool.

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 the tool's simplicity (no parameters, no output schema), the description provides the essential information: it checks auth status and token expiry. However, it does not specify the return format (e.g., boolean, timestamp) or whether the token expiry is a timestamp or relative time. This leaves some ambiguity for an agent deciding how to parse the result.

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 has zero parameters and the schema is empty (100% coverage). The baseline for zero parameters is 4, and the description adds no parameter-specific details because none exist. It appropriately explains the purpose without needing to document parameters.

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 verb 'Check' and the resource 'connector is authenticated with Jobber', plus the additional detail of token expiration. It is distinct from siblings like 'authenticate' (which performs auth) and 'logout' (which terminates it). The purpose is 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?

The usage is implied: use this when you need to know authentication status or token expiry. However, there is no explicit guidance on when to use this versus alternatives, nor any exclusions or prerequisites. It does not mention that it is a read-only operation or that it does not trigger authentication.

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 the agent knows this is a safe, read-only operation with an open world (results may change). The description adds the 'bounded page' behavior and the 'selecting approved line items' purpose, which are useful. However, it does not disclose details like whether the catalog is filtered by default, how 'approved' is determined, or what happens when the cursor is invalid. With annotations covering the safety profile, a 3 is appropriate.

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 a single, concise sentence that front-loads the core action ('List a bounded page') and includes the purpose ('for selecting approved line items'). Every word earns its place; no filler or repetition of schema 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?

For a read-only paginated list tool with no output schema, the description is adequate but not complete. It tells the agent the tool lists a bounded page of catalog items, but it does not describe the return shape (beyond the schema's next_cursor and returned_so_far hints), nor does it explain how 'approved' is determined or how to handle empty results. Given the openWorldHint and readOnlyHint annotations, the safety profile is covered, but the operational details are thin.

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 67%: cursor and returned_so_far have descriptions, while page_size has only a default and min/max. The description adds the concept of a 'bounded page' and 'selecting approved line items', which gives some context for why pagination exists. However, it does not explain the relationship between returned_so_far and cursor beyond what the schema already says, nor does it clarify the meaning of 'approved' in relation to parameters. Baseline 3 is fair since the schema covers most parameter semantics.

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 verb ('List'), a resource ('Jobber products and services'), and a scope ('bounded page', 'for selecting approved line items'). It is clear about what the tool does, though it does not explicitly differentiate from sibling tools like search_records or get_record. The phrase 'for selecting approved line items' adds useful context about its intended use.

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 context: it is for browsing a bounded page of catalog items, likely for selection workflows. However, it does not explicitly state when to use this tool versus alternatives like search_records or get_record, nor does it mention any exclusions or prerequisites. The pagination parameters imply iterative usage, but the description itself does not guide the agent on when to choose this tool over siblings.

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 the safety profile is covered. The description adds valuable behavioral detail about cursor mechanics, specifically that payments_cursor alone continues payments instead of fresh page, and that the response is paginated per section. This goes beyond the annotations and helps the agent anticipate results.

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. The primary purpose is front-loaded, and the second sentence addresses the only non-obvious usage pattern. Every word earns its place; the structure is ideal for an agent to parse quickly.

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?

Despite 10 parameters and no output schema, the description covers the key nuance (pagination continuation) and names all returned data types. It does not explicitly state that clients must be found via find_client first, but that is implied by the client_id parameter description in the schema. For the complexity level, it is sufficiently complete; an agent can invoke it correctly without missing critical details.

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 all parameters are documented individually. The description adds crucial context to the payments_cursor parameter, explaining its special dual role, and implies the other cursors are for standard paging. This enriches understanding beyond what the schema's per-field notes say, justifying a score above the baseline of 3.

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 returns a client's jobs, quotes, invoices, and payments — a specific verb and resource set that distinguishes it from siblings like jobs_summary or revenue_summary. It uses precise nouns and lists the four data sections, leaving no ambiguity about what the tool does.

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 provides explicit pagination usage, notably the special case for payments_cursor that returns only the payments section. It does not explicitly mention when to prefer alternative tools (e.g., jobs_summary for aggregate data), but the focus on a client's history implies its niche. The cursor guidance is actionable and clear enough for an agent to know when to invoke this pattern.

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 the safety profile is covered. The description adds context about what is returned ('contact info and addresses'), but it does not disclose behavioral details such as matching behavior, pagination semantics beyond schema hints, or any open-world implications. This is acceptable but not rich.

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 a single, efficient sentence with no filler. It front-loads the core action and searchable fields, and every word contributes to understanding the tool's purpose. It is appropriately sized for a simple search operation.

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 straightforward search tool with four well-documented parameters and read-only/open-world annotations, the description covers the essential behavioral outcome ('Returns contact info and addresses'). It lacks detail on the exact return structure, but there is no output schema and the simple nature of the tool makes this a minor gap. The pagination parameters are already adequately described in the schema.

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 baseline is 3. The description adds meaning to search_term by naming the accepted search fields, but it does not expand on cursor, page_size, or returned_so_far, which the schema already documents well. No additional parameter context is needed beyond 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 names a specific action ('Search Jobber clients') and the searchable fields ('by name, email, or phone'), which clearly identifies the tool's purpose. It does not explicitly distinguish itself from sibling tools like search_records or get_record, but it is clear enough to avoid significant ambiguity.

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 this is for looking up clients, but it does not state when to choose this over alternatives such as search_records, get_record, or catalog_search. There are no explicit exclusions or routing guidance, leaving the agent to infer the appropriate 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 the agent knows it is a safe read operation. The description adds valuable context: entries are already redacted before being read, which is a behavioral trait not visible in the schema or annotations. It also states the log covers every tool call, success or error, which sets expectations about content. This goes beyond the annotations without contradicting 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 sentences, each earning its place: the first states the resource and scope, the second gives the use case, and the third discloses redaction behavior. It is front-loaded with the core purpose and contains zero 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 list tool with 100% schema coverage and no output schema, the description covers the essential context: what the log contains, why you'd use it, and a key behavioral caveat (redaction). It doesn't describe the return format, but since there is no output schema and the tool is a simple list, the description is nearly complete. The only minor gap is not mentioning pagination behavior beyond the offset parameter, which the schema already documents.

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 four parameters (limit, offset, date_to, date_from) with descriptions. The tool description adds no additional parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.

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 verb ('Read'), a specific resource ('this server's own local audit log'), and the scope ('every tool call, success or error'). It also distinguishes itself from the sibling tools by clarifying it is about the connector's own activity, not client data. This is clear and 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?

The description says it is 'useful for reviewing what this connector has done,' which gives clear context for when to use it. It doesn't explicitly name alternatives or exclusions, but the sibling list shows many data-oriented tools, and the description's emphasis on 'this server's own local audit log' implies it is not for querying business data. A clear context is provided, though no explicit when-not-to-use guidance.

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 description does not need to restate read-only behavior. It does add useful context that the result contains workflow fields, but it does not disclose auth needs, error behavior, or what happens for a missing or invalid record_id.

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 a single, front-loaded sentence with no filler. It states the verb, resource, supported types, and purpose without losing conciseness.

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 readOnly and openWorld annotations, the description is mostly complete: it names the entity types, the singular fetch semantics, and the nature of the returned fields. It does not enumerate workflow fields or error cases, but no output schema exists and the description is sufficient for selecting and invoking the tool.

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. It restates the record_type enum and says 'one' record, but it never explains record_id semantics, the relationship between record_type and record_id, or the expected format. The schema's property names and enum values are doing nearly all the work.

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 precise fetch operation: get one Jobber entity across seven enumerated types, and it explains that the result includes workflow fields for preparing a safe change. This clearly distinguishes it from sibling list/search tools like search_records and find_client.

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 the usage context – fetching a single record before making a change – but it does not explicitly state when to prefer this over find_client, search_records, or get_audit_log, nor does it name any exclusions. The context is clear, but alternatives are not discussed.

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 and openWorldHint annotations already covering safety and pagination exposure, the description adds useful grouping and date-filter behavior. However, it does not disclose that counts and totals are computed only over jobs scanned in the current page (page_size 'Max jobs to scan'), which could mislead an agent about whether totals are global.

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 communicates the resource, grouping, filter semantics, and output shape with no filler. 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?

The description captures the core purpose, the critical date-field clarification, and the output shape (counts and totals per status). It omits pagination mechanics, but the schema's parameter descriptions fill most of that gap; the lack of an output schema is partially mitigated by the stated counts/totals.

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% with detailed parameter descriptions for cursor, page_size, and returned_so_far. The description adds value beyond the schema by specifying that date_from/date_to refer to job creation date, not scheduling or completion date, which is absent from the parameter docs.

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 verb ('Return') and resource ('Jobber jobs'), then defines the aggregation ('grouped by status') and output ('counts and totals per status'). This clearly differentiates it from report siblings like revenue_summary or schedule_lookup.

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 clarifies that filtering is by job creation date, not scheduling or completion date, which tells the agent when the date parameters are applicable. However, it does not mention alternative tools or provide when-not-to-use conditions, so it stops short of a 5.

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 burden of behavior disclosure. It does this well: it says the action is 'best-effort,' explicitly clarifies that local tokens are always cleared even if remote revocation fails, and names the underlying mutation. This is strong behavioral transparency, especially for a mutating/session-changing operation.

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, front-loaded with the primary purpose and then the nuance about best-effort revocation. It earns its place, though the parenthetical could have been a separate sentence for readability. It is still concise and well structured.

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 tool with no output schema, the description covers the key aspects: what it does and what happens on failure. It could mention what the response looks like, but since there is no output schema, adding the response format would be helpful. The core behavior is fully covered though.

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 has zero parameters, so there are no parameter semantics to add beyond the schema. The description appropriately notes what is cleared and the mutation used, but with no parameters there's nothing more to explain. Baseline is a 3 here since schema coverage is 100% and no parameters exist.

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 verb and resource: 'Log out of Jobber,' with an explicit mechanism (the appDisconnect mutation). The title 'logout' is expanded into a full statement of what happens, so an agent knows the tool's function, and it is clearly distinct from siblings like authenticate and auth_status.

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 a clear context: use this when ending an authenticated session. It doesn't explicitly state when not to use it or name alternatives (e.g., 'if you need to check authentication state, use auth_status'), but for a logout tool the usage context is fairly evident. The description could have been clearer about whether it is the only way to deauthenticate or if there is another related flow.

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, which the description does not contradict. The description adds meaningful behavioral context: it returns oldest first, includes the total owed for the page at the top, and instructs to use total_count/next_cursor for pagination. These details go beyond the annotations and help the agent understand the output structure and pagination workflow.

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 a single, efficient sentence. It front-loads the core purpose (return overdue invoices oldest first) and then adds the pagination and summary details, with no wasted words. Every phrase contributes essential 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?

For a paginated list tool without an output schema, the description covers the key aspects: what it returns (unpaid overdue invoices), ordering (oldest first), the summary total, and how to paginate via total_count/next_cursor. It does not specify invoice fields, but given the absence of an output schema, this is an acceptable level of completeness for an agent to successfully call the tool.

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 input schema provides full descriptions for all three parameters (cursor, page_size, returned_so_far), so the baseline is 3. The description adds minimal extra meaning—mostly referencing pagination variables (total_count/next_cursor) but not directly enriching parameter understanding. It gives slight context on how the parameters interact with pagination, but not enough to raise the score above 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 explicitly states the action 'Return' and the specific resource 'unpaid Jobber invoices past their due date', with clear ordering ('oldest first') and a summarized total. This clearly distinguishes it from sibling tools like quotes_outstanding (quotes) and jobs_summary (jobs), so an agent can identify it without opening the 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?

The description implies usage when overdue invoices are needed, but it does not explicitly mention when to use it over alternatives or when not to use it. There is no comparison to sibling tools or exclusions. The clear purpose helps, but explicit guidance is missing.

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 the safety profile is covered. The description adds inclusion/exclusion context (quote age, amounts, approved-not-converted exclusion), but does not disclose pagination behavior or response format, which would be useful. No contradiction with 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?

Two sentences with no wasted words. The core action and inclusion criteria are front-loaded, with the exclusion as a clarifying second sentence.

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 paginated read tool with no output schema, the description explains what will be returned (quotes with age and amounts) and its scope. It does not explicitly mention pagination, but the schema's cursor and returned_so_far descriptions cover that. The lack of an output schema is partly mitigated by the high-level return description.

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 three parameters (cursor, page_size, returned_so_far) are documented in the input schema. The description does not add any parameter-specific meaning beyond what the schema provides, hence baseline 3.

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 verb ('Return') and resource ('Jobber quotes awaiting client response'), and specifies the included data (quote age and amounts) and an exclusion (approved-but-not-converted). This clearly distinguishes it from siblings like overdue_invoices or requests_inbox.

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?

No explicit when-to-use or alternative routing is provided. The description implies usage for retrieving outstanding quotes, but does not mention when to prefer this over related tools like requests_inbox or get_record. The exclusion clause provides definitional clarity, not usage guidance.

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 the description does not need to disclose those. It adds the 'new' and 'unscheduled' scoping, which gives some behavioral framing. However, it does not mention that the tool returns two separate lists (new_requests and unscheduled_requests) or that pagination requires cursors, both of which are implied by the schema parameters. This goes slightly beyond annotations and adds a high-level scope, but leaves an agent inferring the dual-section output.

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 a single clear sentence with no filler. It front-loads the verb and key qualifiers ('new and unscheduled') and is quotable in a tool list. It says exactly what the tool does without wasting tokens.

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?

This tool has 5 parameters, a two-section output (evident from the schema), and no output schema. The description does not tell the agent about the pagination fields, that two sections are returned, or how to interpret next_cursor. It only says 'return new and unscheduled' which is too terse for a legitimate agented invoker to correctly handle pagination without reading the schema and guessing. For paginated tools, the absence of return-shape or pagination notes is a substantial 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?

The schema description coverage is 100%, so all five parameters already have precise semantics (cursor paths, 'echo back' requirements, page_size limits). The description adds no information about parameters; it merely names the resource categories. At 100% coverage the baseline is 3, and the description neither raises nor lowers it.

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 uses a specific verb ('Return') and scope ('new and unscheduled Jobber requests'), which clearly suggests a read-only request inbox. It doesn't explicitly differentiate from sibling tools like 'search_records' or 'schedule_lookup', but the resource and 'unscheduled' qualifier make the purpose evident enough without opening the 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?

No guidance is given about when to use this tool vs. alternatives. The description is purely a statement of functionality with no context on filtering, period, or comparisons to siblings such as 'jobs_summary' or 'schedule_lookup'. An agent cannot tell if this is the right high-level entry point or if another tool would be more appropriate for e.g. all jobs or revenue queries.

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 annotations indicate readOnlyHint=true and openWorldHint=true, which already signal that this tool is non-destructive and may return partial results. The description adds behavioral clarity by specifying that only paid invoices are included and that results are grouped, which is useful context. However, it doesn't mention pagination behavior (via cursor, page_size, returned_so_far) that the schema implies.

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 a single concise sentence that captures the core functionality without excess. It could be improved by front-loading the key filter ('paid') but it is already clear and efficient.

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 the tool's complexity (5 parameters, pagination, grouping), the description is insufficient. It doesn't explain the pagination mechanism (how cursor and returned_so_far work together), the meaning of 'totals' (are they per group or overall?), or the output format (no output schema). The annotations provide some safety context, but the description leaves gaps that could lead to incorrect 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?

The schema has 100% parameter coverage, so each parameter is already described in the schema (e.g., date_from/date_to as ISO 8601, cursor for pagination). The description doesn't add any new meaning to the parameters; it only mentions the date range implicitly via the tool's purpose. Thus, the baseline of 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 clearly states the verb ('Return') and the resource ('paid Jobber invoices'), and specifies the grouping ('by month and by quarter') and that totals are included. However, it doesn't explicitly distinguish it from sibling tools like 'jobs_summary' or 'overdue_invoices', but the grouping detail helps differentiate it from a plain invoice list.

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 provides no guidance on when to use this tool versus alternatives like 'jobs_summary' or 'overdue_invoices'. It only states what it returns, not the context in which it is appropriate. For example, it doesn't mention that it only covers paid invoices, which is a key differentiator from a general revenue report.

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 the read-only nature is covered. The description adds one useful behavioral detail: that days are grouped by the server's local calendar day unless a timezone is supplied. However, it omits pagination behavior (hinted by cursor and returned_so_far params) and the exact output shape. With annotations present, a score of 3 is appropriate because it adds some value but not rich behavioral 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 a single sentence that front-loads the action and resource, then specifies the grouping behavior. There is zero waste; every clause carries meaning. It is concise and structured effectively.

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 carry the burden of explaining the return format. It states results are 'grouped by day' but does not detail whether the response contains a list of day objects, each with items, or a flat list with day labels. It also omits any mention of pagination (even though params like cursor, page_size, and returned_so_far imply it) and does not describe what 'visits and assessments' entails. For a tool with 6 parameters and no output schema, these gaps are significant.

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 every parameter is already explained in the input schema. The tool description emphasizes timezone grouping, but that detail is also present in the schema's timezone parameter description ('to group days by; defaults to the server's local timezone'). The description adds marginal value beyond the schema, so baseline 3 is warranted.

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 identifies the specific verb ('Return'), the exact resource ('Jobber visits and assessments'), and a defining constraint (date range, grouped by day). This distinguishes it from sibling tools like jobs_summary (summary statistics) or search_records (general search) without needing to open the 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?

No explicit guidance on when to use this tool versus alternatives. While the description implies use for date-range schedule queries, it never mentions when not to use it or points to other tools for different needs (e.g., summaries, single records). An agent must infer usage from the resource type, which is insufficient given the number of 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?

Annotations already carry readOnlyHint and openWorldHint, so the safety profile is covered. The description only adds the vague phrase 'fixed reviewed queries' and 'bounded', which neither clarifies the actual constraints nor discloses pagination or result set behavior beyond what the annotations suggest that results are not complete.

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 short and front-loaded with the primary action. However, the second sentence about 'Use get_record before any write' is not about search_records and adds little value, making its inclusion a slight waste.

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?

This is a 5-parameter tool with pagination, enums, and no output schema. The description fails to explain the pagination contract (cursor, returned_so_far) or the nature of 'fixed reviewed queries' vs. arbitrary search, so an agent would struggle to correctly construct a first call or continue pagination.

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 schema description coverage at only 40%, the description carries a heavy burden to explain 5 parameters, but it provides almost no parameter-level meaning. It never explains search_term, cursor, page_size, returned_so_far, or record_type semantics, leaving the agent to guess how to construct a query.

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 search over a 'bounded' Jobber record type, which is more specific than a bare name. However, 'fixed reviewed queries' is ambiguous and the description does not clearly distinguish this from sibling tools like find_client or catalog_search; it leaves an agent guessing about what is it about the 'fixed' queries.

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 says 'Use get_record before any write', but this is a workflow note unrelated to using search_records itself. It does not state when to choose this tool over find_client, catalog_search, or other sibling search tools, nor does it mention exclusions or 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?

The annotations already provide readOnlyHint and openWorldHint, so the description only needs to add context beyond that. It adds the 'available for assignment' constraint, which clarifies returned records. It omits return format and pagination behavior, which is acceptable given 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?

The description is a single, front-loaded sentence with no filler or redundant clauses. Every part contributes purpose: the verb, resource, and the scope qualifier are all essential. No unnecessary 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 read-only, list, paginated data-tool with optional parameters, the description, annotations, and schema together provide enough context. It omits output format, but given the simple nature and existing annotations, this is not a major gap. A description might benefit from mentioning pagination explicitly, but it isn't critical.

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 description adds no meaning for cursor or page_size. The schema covers cursor but leaves page_size without any description. Since schema coverage is only 50%, the description should compensate for the missing parameter semantics, but it does not.

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 uses a specific verb and resource: 'List Jobber team members available for assignment.' It clearly distinguishes itself from sibling tools, none of which mention team members. The qualification 'available for assignment' adds useful scope, leaving no ambiguity about what the tool returns.

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 when to use this tool (to get assignable team members) but does not explicitly state when not to use it or name alternatives. The sibling list does not contain an obvious competing tool, so misuse risk is low, but there is no explicit routing.

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