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

With no annotations, the description carries the behavioral transparency burden. It does disclose the core side effect: a new client is created and the created client is returned with an ID. However, it omits other relevant behaviors such as duplicate handling, idempotency, permission requirements, or failure behavior. This is adequate but not thorough.

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, well-structured sentence with no filler. The primary action is front-loaded, and the return behavior is stated efficiently. Every word 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?

For a create operation with no annotations and no output schema, the description is reasonably complete: it states the action and the core return value. However, it could be more complete by noting required fields behavior, potential duplicate-client risks, or any external constraints. The 100% schema coverage mitigates but does not fully eliminate this 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 already documents all 10 parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter-level meaning, but none is needed because the schema coverage is complete.

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 action ('Create'), the target resource ('a new client'), and the platform ('Jobber'). It also specifies the return value, which unambiguously distinguishes it from sibling tools like jobber_list_clients and jobber_create_job.

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 gives no guidance on when to use this tool versus alternatives. For example, it does not suggest checking existing clients with jobber_list_clients before creating, nor does it mention when a client should be created vs. updated. The usage context is only implied by the tool name and basic action.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the creation action and some invoice features, but does not disclose possible side effects (e.g., sending the invoice to the client), required permissions, behavior on failure, or idempotency. Significant behavioral ambiguity remains for a mutation tool.

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

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

A single, front-loaded sentence that states the action and key capabilities with no filler. Every clause carries information, making it efficiently scannable for an agent.

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 create tool with 8 parameters, no output schema, and no annotations, the description is too sparse. It does not mention what the tool returns (e.g., invoice ID), prerequisites beyond clientId, or behavior on error conditions. An agent would need more context to reliably handle invocation outcomes.

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 some meaning by calling out 'custom line items, due dates, and optional deposit', but these directly mirror the schema properties lineItems, dueDate, and depositAmount. It does not clarify format, relationships, or constraints beyond what the schema already states.

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: 'Create an invoice in Jobber'. It also scopes the target to 'a client or job' and lists supported features. This clearly differentiates it from sibling tools like jobber_list_invoices or jobber_create_quote, even without explicitly naming them.

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 its use case: when you need to create an invoice for a client or job. It does not provide explicit when-not-to-use guidance or mention alternatives such as jobber_create_quote for quotes. The context is clear but no exclusions or sibling comparisons 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?

With no annotations, the description carries full burden for behavioral disclosure, but it only says a job is created. It does not describe side effects, whether scheduling is involved, response behavior, required permissions, or any confirmation/error semantics. The line-items note is the only extra behavioral context beyond the verb 'Create'.

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 with no filler. Core purpose is front-loaded, and the line-items instruction is a useful, economical addition. Every word 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?

For a mutation with no annotations and no output schema, the description is minimal. It gives no return expectations, no guidance on required fields beyond what the schema already shows, and no notes about clientId sourcing. The schema compensates for parameter details, making it minimally viable, but the agent must infer broader context.

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 already provides 100% coverage with descriptions for all six parameters, so the baseline is 3. The description adds no new parameter meaning: 'Include line items for services or materials' restates the schema's lineItems description without providing formats, defaults, or interdependencies.

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 ('Create') and resource ('new job/work order in Jobber for a client'), making it clearly distinct from sibling tools like jobber_create_client and jobber_create_invoice. The client relationship and line items hint further prevent ambiguity with jobber_create_quote.

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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites such as obtaining clientId via jobber_list_clients (that hint lives only in the schema) or contrast with quote/invoice creation. The phrase 'for a client' weakly implies a prerequisite but is not actionable.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the operation creates a quote, but says nothing about whether the quote is saved as a draft, sent to the client, requires special permissions, or what the response contains.

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-loads the core purpose in one clear sentence. The second sentence adds a little parameter guidance, though it partly duplicates schema information and omits deposit.

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 create tool with fully documented parameters, this is minimally viable. However, with no output schema and no annotations, the description leaves out the behavior after creation, error cases, and whether existing client IDs are required prerequisites.

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 parameters. The description adds modest value by singling out title, line items, and the optional message, but it does not explain relationships, valid formats, or the deposit parameter.

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 a specific action and resource: 'Create a new quote in Jobber for a client.' This distinguishes it from sibling tools like jobber_create_job and jobber_list_quotes by naming the exact resource being created.

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 use when creating a quote for a client, and the 'for a client' phrasing suggests a client must exist. However, it does not explicitly discuss when to prefer this over alternatives like creating a job or invoice, nor does it state any prerequisites.

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 adds useful behavioral detail beyond the schema: the default range is today, period strings are convenience selectors, and explicit dates are an alternative. However, with no annotations, it leaves gaps such as timezone handling, whether startAt/endAt must be supplied together, pagination, and return shape.

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 the primary action front-loaded. It covers the default, the named period options, and the explicit-date alternative without filler or redundancy.

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 getter with 3 optional parameters and no output schema, the description provides the core invocation knowledge: what the tool returns conceptually, the default behavior, and the two filtering modes. It leaves a few edge-case clarifications unstated, but nothing that would prevent correct basic use.

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 already documents all three parameters, so the baseline is 3. The description restates the period values and the default and positions startAt/endAt as a custom range, but adds little beyond the schema's own descriptions.

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 the specific operation ('Get the schedule'), the resource ('upcoming visits/appointments'), and the source system ('from Jobber'). The note about defaulting to today and the period options further define scope, and no sibling tool covers schedule retrieval.

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?

Provides concrete selection guidance: use one of the named period values or supply explicit startAt/endAt dates, with today as the default. It does not explicitly name alternative sibling tools or exclusions, but the schedule resource is unique among the siblings, so the context is sufficient.

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 behavioral disclosure burden. It does disclose the returned fields and search filtering, which is useful. However, it omits pagination behavior, continuation semantics, and any caveats about result completeness or ordering. 'List' implies a read-only operation, but side-effect and safety traits are not explicitly stated.

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 two short sentences with no filler. The core action is front-loaded, followed by return-field details and search behavior. Every sentence 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?

For a simple, read-only list tool with fully documented optional parameters, the description provides the key return fields and search behavior. It lacks an explicit mention of pagination continuation, but the 'after' parameter schema already covers that. No output schema exists, so the stated return fields help fill that 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 description coverage is 100%, so the baseline is 3. The description repeats the search-by-name-or-company semantics already present in the schema and adds no meaning for the 'limit' or 'after' parameters. It provides no extra value beyond the structured parameter descriptions.

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 clients from Jobber.' It also states the returned fields (name, email, phone, billing address) and the optional search capability. This clearly distinguishes it from sibling tools focused on jobs, invoices, quotes, or schedule operations.

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: an agent should call this when it needs client records. However, the description gives no explicit guidance about when to prefer this tool over siblings, nor does it mention any exclusions or alternative tools. The resource name makes the use case fairly obvious, but routing guidance is minimal.

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 present, so the description bears full responsibility for behavior. It discloses the output fields and that filtering is possible, but it does not mention pagination behavior, the meaning of the `after` cursor, or any rate limits, leaving an agent to infer how the returned list is delivered.

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 two concise sentences, front-loading the core 'list invoices' purpose and important output fields before the optional filter detail. Every word 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?

For a simple optional-filter list tool, the description provides the essential purpose and visible output fields, while the schema covers parameter details. The absence of an output schema and any mention of pagination in the description leaves a small gap, but the tool is still callable.

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%: all three parameters are already fully described in the schema. The description only restates the status filter and its enum values, adding no new semantic detail beyond what the schema provides.

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?

Description opens with a specific verb and resource ('List invoices from Jobber') and enumerates the returned fields (amount, payment status, client info), making its purpose unmistakable and clearly distinct from sibling list tools like jobber_list_clients or jobber_list_jobs.

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 clearly implies this is the tool for retrieving invoice data and optionally narrowing by status, and the sibling list makes resource separation obvious. However, it does not explicitly state when to choose this over alternatives, 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 present, so the description carries the burden of behavioral disclosure. It correctly implies a read-only retrieval operation and mentions the returned data fields, but it does not describe pagination behavior, default status handling, or output structure beyond the listed fields.

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 and resource, then adds the filter capability with the exact allowed values. There is no redundant or filler content.

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

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

For a simple list operation with three optional parameters and no output schema, the description is adequately complete: it identifies the resource, returned fields, and filter options. Minor gaps like default pagination and implicit behavior when no status is supplied are secondary and largely covered by 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?

All three parameters have descriptions in the schema, so schema coverage is 100%. The description adds little beyond restating that status filtering is possible, but it does not need to compensate for any missing parameter documentation.

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 action ('List'), the resource ('jobs/work orders from Jobber'), and the included fields (status, client, schedule, totals), making it easy to distinguish from sibling tools that operate on clients, invoices, quotes, or that create/update jobs. The status filter list further clarifies scope.

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 clear context: use this tool to list Jobber jobs/work orders, optionally filtered by status. It does not explicitly name alternatives or state when not to use it, but the resource specificity makes the primary use case obvious among the listed 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation and the mention of returned fields adds context, but it does not explicitly state that no data is modified, nor does it describe pagination behavior, ordering, or scoping beyond the schema parameters.

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

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

The description is two sentences with zero wasted words. It front-loads the core purpose and return value, then adds filter detail, making it easy to scan and understand.

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 list tool with 100% schema coverage, the description is nearly complete: it names the output fields and filter options. However, it omits an explicit read-only confirmation and any detail about default pagination or ordering, which an agent might need given there is no output 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%, with all three parameters (after, limit, status) already documented. The description only reiterates the status filter and its allowed values, adding no new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses the specific verb 'List' with the resource 'quotes from Jobber' and specifies returned details ('totals, status, and client info'). It clearly differentiates from sibling list tools like jobber_list_jobs and jobber_list_invoices by naming the exact resource.

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/filtering quotes but does not explicitly state when to use this tool over alternatives or exclude other cases. No alternative tools or when-not-to-use conditions are mentioned, so the agent must infer usage from 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it only conveys that 'update' mutates state. It does not disclose whether status changes are reversible, whether transitions can skip stages or move backward, whether validation enforces the workflow order, or what the response looks like. The inclusion of 'cancelled' in the enum but not in the described workflow is unexplained, leaving a genuine ambiguity.

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 totaling ~22 words. The core action is front-loaded ('Update the status of a Jobber job'), followed by a compact workflow arrow. No filler, no repetition of schema field descriptions — every word 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?

For a simple 2-parameter tool with 100% schema coverage this is mostly adequate, but the description leaves a meaningful gap: it does not clarify whether the workflow permits skipped or backward transitions, and it fails to address the 'cancelled' enum value that sits outside the documented progression. An agent told to move a job to 'cancelled' would find no support in the description. No output schema exists to help fill the return-value 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 description coverage is 100%, so the baseline is 3. The description adds real value on top: the workflow chain gives ordering semantics to the status enum that the schema's flat enum list does not convey, telling the agent which statuses are meant to be used in sequence. The omission of 'cancelled' from the chain is a minor gap, but the added ordering meaning justifies a 4.

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: 'Update the status of a Jobber job.' This clearly distinguishes it from all siblings, which are list/create tools for other entities (clients, jobs, invoices, quotes) — none of which mutate job status. The workflow chain 'draft → active → completed → invoiced → archived' adds further specificity.

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 workflow sequence 'draft → active → completed → invoiced → archived' provides clear context that this tool is for advancing jobs through lifecycle stages. No explicit exclusions or alternative tools are named, but no sibling offers status updates, so the usage context is unambiguous enough. It stops short of stating transition rules (e.g., whether skipping stages is allowed).

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