workiz

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

Annotations already declare destructiveHint=true, and the 'WRITE:' prefix is consistent with that — no contradiction. The description adds the underlying REST endpoint (POST /lead/activate/{UUID}/), but says nothing about permission requirements, reversibility, or what happens to the lead's history. With annotations covering the safety profile, this is adequate but thin.

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 compact fragments, front-loaded with the WRITE classification followed by the action and the endpoint. No filler whatsoever.

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 state-change tool with an annotation covering the safety profile, the description supplies enough to call it correctly. It could still note whether the reactivation is reversible or what the lead returns to, which keeps it from a 5.

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 a single required uuid parameter fully documented ('The lead's UUID (e.g. XYZ56X)'). The description only echoes the UUID via the endpoint path and adds no format or sourcing guidance, so the baseline 3 applies.

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

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

States a specific verb and state transition — 'change a lost lead back to active' — which is clear and distinguishable from siblings like workiz_mark_lead_lost (the inverse) and workiz_update_lead (general edit). It never names 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?

The phrasing 'change a lost lead back to active' implies when to use it (a lead currently in lost state), but there are no explicit exclusions, prerequisites, or pointers to alternatives such as workiz_update_lead. Usage is only implied.

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 'WRITE:' prefix makes the mutation semantics explicit and 'Reversible with workiz_unassign_job' adds real behavioral value beyond the destructiveHint annotation — an agent learns the change can be undone and how. It does not cover permission requirements or failure behavior, but for a two-parameter write the disclosure is solid and does not contradict the annotation.

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 fragments, front-loaded with the operation type and the core action; no filler, and every clause (reversal path, endpoint) 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?

For a simple two-required-parameter write with no output schema, the definition covers purpose, reversibility, and endpoint. It omits only peripheral details such as error behavior or prerequisites, which is acceptable at this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents both UUID and User, including the exact-name format and a pointer to workiz_list_team. The description's '(by name)' merely echoes the schema, so 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?

States a specific verb (assign) plus resource (a team member, by name, to a job) and even names the exact API operation (POST /job/assign/). It is trivially distinguishable from siblings such as workiz_unassign_job, which it explicitly references.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for its place in the workflow by naming the inverse operation (workiz_unassign_job) for reversal, and the by-name constraint tells the agent when it needs the team-list tool first. It stops short of explicit when-to-use/when-not-to-use conditions versus alternatives like workiz_update_job.

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?

Adds the WRITE marker and says it's reversible via workiz_unassign_lead, which is useful beyond the destructiveHint annotation. However, destructiveHint=true suggests an impact the description doesn't reconcile (assign is framed as reversible rather than destructive), and it doesn't note auth/permission requirements.

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, front-loaded fragments: action, reversibility, endpoint. No filler.

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

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

For a two-param write tool with full schema coverage and no output schema, the description covers what, how to reverse, and the endpoint. It's nearly complete, missing only error/permission behavior.

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 the schema already documents that User is a name and UUID is the lead's UUID. The description adds only the parenthetical '(by name)', which lightly reinforces the schema's guidance but adds little else.

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 (assign) and resource (a team member to a lead), with the write marking up front. It clearly distinguishes from sibling workiz_assign_job by naming the lead 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?

Gives clear context (write operation) and names the reversal alternative workiz_unassign_lead. It doesn't explicitly state when to prefer this over alternatives like workiz_update_lead, but the implied usage is clear.

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 only carry destructiveHint=true; the description adds material context beyond that by labeling it a WRITE with no API undo and stating the conversion cannot be reversed. It also discloses the return payload (UUID and link), though it omits side effects on the source lead and any permission requirements.

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-loads the most decision-relevant fact ('WRITE (no API undo)') and packs purpose, irreversibility, and return value into two tight sentences with 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 usefully names what is returned (UUID and link) and flags the irreversible mutation, which is the key risk. It stops short of noting lead-state side effects or auth/permission needs, but is otherwise sufficient for a one-parameter 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 100% for the single required UUID parameter, so the schema documents the input fully. The description adds no format or constraint detail beyond that, making the baseline 3 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?

States a specific verb and resource ('convert a lead into a job') and clarifies the mechanism ('creates a new job from the lead'), which distinguishes it from siblings like workiz_create_job and workiz_create_lead without opening their schemas.

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 use case (you have an existing lead you want to promote), but it never explicitly states when to use this over workiz_create_job or workiz_activate_lead, nor any prerequisites such as the lead needing a particular status.

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 only supply destructiveHint=true, leaving the description to carry the behavioral load. It does so by marking the operation as a WRITE and disclosing the return payload (new job's UUID, ClientId, app link), which is genuinely valuable since there is no output schema. It omits any mention of permissions, validation failures, or side effects on existing clients.

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, front-loaded sentences: verb+scope, then return values, then endpoint. Nothing is padded, though the trailing 'Workiz: POST /job/create/.' endpoint line contributes little to an agent deciding or invoking the 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?

For a 25-parameter creation tool with no output schema and only a destructiveHint annotation, the description covers the essential missing pieces: it declares the write nature and the return payload. It does not note that all 25 parameters are optional or warn about any required minimum input, which is a minor 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 all 25 parameters are already documented in the schema, which sets the baseline at 3. The description's field groupings (schedule, client contact and address, type, source, notes) add light organizational framing but no format or constraint 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?

States a specific verb and resource ('create a new job') and enumerates the data domains it accepts (schedule, client contact/address, type, source, notes), so the agent knows exactly what the tool produces. It does not differentiate itself from the sibling workiz_create_lead or workiz_convert_lead_to_job, which could also result in a job-like record.

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 when-to-use guidance is given. With siblings like workiz_create_lead and workiz_convert_lead_to_job present, the description never states the condition under which a caller should create a job directly rather than create or convert a lead. Usage is only implied by the name.

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 only supply destructiveHint=true, and the description's 'WRITE:' label is consistent with that. It adds useful detail by disclosing the return values (UUID, ClientId, app link) and the underlying endpoint (POST /lead/create/), but says nothing about auth requirements or the notable fact that none of the 25 fields are mandatory.

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

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

Two short, front-loaded sentences with the mutation flag first and return values last. The trailing API endpoint is marginal for an agent but cheap and does add a small amount of provenance.

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 compensates for the absent output schema by naming the return fields, which is good. However, for a 25-parameter tool with zero required fields and only a destructiveHint annotation, it omits minimum viable field combinations and any warning about duplicate-client creation, which an agent would need.

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 25 parameters are already documented in the schema. The description's grouped summary ('client contact and address, requested time, job type, source, notes') adds framing but no syntax, format, or constraint detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('create a new lead'), enumerates the content it carries (client contact and address, requested time, job type, source, notes), and names the return values. An agent can distinguish it from workiz_create_job and workiz_convert_lead_to_job by the resource name alone.

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 'WRITE:' prefix signals a mutation, but there is no statement of when to use this tool rather than workiz_create_job, workiz_convert_lead_to_job, or workiz_update_lead. No prerequisites or context are given, leaving routing entirely to inference.

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, so the safety profile is covered. The description adds genuine value beyond that by enumerating the fields returned (useful since there is no output schema) and confirming the read semantics with the GET endpoint. It says nothing about invalid-UUID or not-found behavior, which keeps 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?

One dense, front-loaded sentence that leads with the action and then lists outputs; the trailing API path is minor extra, but it is compact and confirms the read operation. No 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?

With no output schema, the description compensates by summarizing the returned fields, and the single required parameter is fully documented in the schema. Remaining gaps (not-found/error behavior, whether notes/tags are ever omitted) are minor for a simple single-record read.

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 parameter and schema coverage is 100%: the schema already defines 'uuid' with a concrete example (XYZ56X). The description adds only the fact that the lookup is keyed by UUID, which the schema already conveys, 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 verb and resource ('Fetch one job by UUID') and then enumerates the returned payload (schedule, status, client contact/address, totals, amount due, notes, tags, team). This clearly separates it from workiz_list_jobs and workiz_get_lead without needing to open 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?

The 'by UUID' phrasing implies you need a known job identifier, which implicitly routes single-record lookups here rather than to list_jobs, but no when-to-use/when-not statement or named alternative is given. Usage is inferable, not explicit.

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, so safety is covered. The description goes beyond that by enumerating which fields the record contains and citing the underlying endpoint (GET /lead/get/{UUID}/), which adds real context about the response 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?

A single front-loaded sentence enumerates returned fields efficiently, followed by a short endpoint reference. The endpoint line is mildly redundant but aids API mapping, so it still earns most of its space.

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 compensates by listing the fields returned, and it names the UUID lookup and underlying API path. It is essentially complete for a simple one-parameter read, missing only error/not-found behavior.

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 parameter with 100% schema description coverage, so the schema already documents the uuid fully (including an example). The description adds no format or constraint detail beyond 'by UUID', so the baseline 3 applies.

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

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

States a specific verb and resource ('Fetch one lead by UUID') and explicitly scopes to a single record, distinguishing it from siblings like workiz_list_leads. The listed fields (schedule, status, contact, address, source, notes, team) further pin down what entity is retrieved.

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 'by UUID' phrasing implies the retrieval-by-identifier use case, but there is no explicit when-to-use vs workiz_list_leads or the update/convert siblings, and no prerequisites or exclusions are stated. Usage is inferable but not guided.

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?

readOnlyHint=true already establishes this is a safe read, so the description's burden is lower. It adds the underlying endpoint (GET /team/get/{USER_ID}) and the set of fields returned, which is useful, but says nothing about auth, rate limits, or error behavior on an unknown 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?

One compact sentence with the field list front-loaded, followed by the endpoint reference. No filler, though the endpoint line is mostly duplicative metadata 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?

With only one parameter and no output schema, the description compensates well by enumerating the returned fields. The remaining gap is the absence of any guidance on failure modes or follow-up tools, which is minor for a simple read.

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 single parameter is documented in the schema as the user's id from workiz_list_team. The description adds no syntax, format, or validation detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (fetch) and resource (one team member) and enumerates the returned fields (name, role, field-tech flag, email, service areas, skills, active status). The singular framing implicitly distinguishes it from the sibling workiz_list_team, though it never names the alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'by user id' and the schema hint that the id comes from workiz_list_team, but there is no explicit when-to-use statement, no prerequisites, and no named alternatives. An agent can infer the workflow but must do so itself.

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 readOnlyHint annotation already establishes this as a safe read operation. The description adds the important behavioral constraint that only FUTURE time off is returned, but it does not describe pagination, return format, or authentication requirements.

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 followed by the API endpoint. It is appropriately sized and contains no redundant or wasted text.

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 tool with one required parameter and no output schema, the description covers the key scope and distinction. It could be slightly richer about return contents, but it is sufficient 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?

Schema description coverage is 100%, so the sole user_name parameter is already fully documented. The description adds only the phrase 'by their name', which does not provide meaning 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?

States a specific verb (List), resource (time off), scope limited to one team member, and a temporal constraint (FUTURE). This distinguishes it from the sibling workiz_list_time_off, which presumably lists time off more broadly.

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 the tool by requiring a team member name, but it does not explicitly state when to choose it over workiz_list_time_off or workiz_get_team_member, nor does it provide exclusions.

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

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

Annotations already declare readOnlyHint=true. The description adds useful behavioral context beyond annotations: sorting order, the default 14-day range, a page-size cap of 100, and the underlying endpoint. It omits auth or rate-limit details, but coverage is solid for a read-only list 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?

Three sentences, front-loaded with purpose and sorting, followed by filters/paging/default behavior and then an endpoint reference. Mostly efficient, though the endpoint mention is optional detail that could be trimmed without losing agent-relevant meaning.

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 still conveys core list semantics: sorting, filtering, paging, and the default date window. It does not describe the response shape, but for a read-only list tool with complete parameter documentation, it is largely 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?

Schema description coverage is 100%, so all five parameters are fully documented in the input schema. The description restates filters and paging but adds no syntax or format details beyond what the schema already provides, warranting the baseline score.

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 ('List') and resource ('jobs'), and adds the sort order (JobDateTime descending). It does not explicitly differentiate from sibling tools like get_job (single job) or list_leads (different resource), so sibling distinction is left implicit.

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?

Describes filtering options (start date, open-only, status) and paging with offset/records, and notes the default 14-day window when start_date is omitted. It provides clear invocation context but does not say when to prefer or avoid this tool versus alternatives like get_job or list_leads.

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, so the safety profile is covered. The description adds one genuinely new behavioral fact not in the schema (default sort order, most recent first) plus the underlying endpoint. The 'max 100' cap and record defaults are already repeated verbatim in the schema, so the net new value is modest.

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 compact sentence with the core purpose and sort behavior front-loaded, followed by filters and paging. Dense but readable; the trailing API endpoint is arguably padding for an agent that never sees raw HTTP, costing it a perfect score.

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 five-parameter read tool with no output schema, the description covers filtering and paging adequately but says nothing about the shape or fields of the returned lead records. Minimal-viable rather than complete given the absence of an 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%, so all five parameters already carry documented semantics including defaults for only_open and start_date. The description adds no syntax, format, or interaction detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ('List leads') and adds scope details (sorted by LeadDateTime descending), which is clearly distinct from siblings like workiz_list_jobs or workiz_list_team. However it never names an alternative or explicitly contrasts itself with them, so it stops short of full sibling differentiation.

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 enumerates available filters and paging mechanics but gives no guidance on when to use this tool versus workiz_get_lead (single record) or workiz_list_jobs. It reads as a capability list rather than usage direction, with no prerequisites or exclusions stated.

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, so the safety profile is covered. The description adds value by revealing it returns only active members and by enumerating the returned fields, but says nothing about pagination, result size limits, or required auth scope for a read-only listing.

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 front-loaded sentences plus a compact endpoint reference. Every clause earns its place: purpose and returned fields first, usage hint second, API mapping last.

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 usefully compensates by enumerating the returned fields (id, name, role, field tech flag, email, service areas, skills). The only gap is the absence of any note on result size or pagination behavior for accounts with many team members.

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 no parameter semantics to explain and the baseline of 4 applies. The description instead spends its space on the returned fields, which is the more useful information here.

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 and resource ('List the account's active team members') and enumerates the returned fields, which distinguishes it cleanly from the singular sibling workiz_get_team_member. The 'active' scope qualifier and endpoint reference (GET /team/all/) make the intent 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?

'Use the name to assign people to jobs or leads' hints at downstream usage, which implies this is a lookup tool for assignment flows. However, it never states when to prefer this over workiz_get_team_member or whether results should be cached, so usage is only implied rather than explicit.

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?

readOnlyHint=true already covers the safety profile, so the bar is lower. The description adds genuinely new context: the future-only time window, the returned fields, and the 'Entire Business' sentinel value for company-wide closures — all useful given there is no output schema.

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?

Four short clauses, each load-bearing: scope, return shape, sentinel value, parameter behavior, usage hint, and the underlying endpoint. Front-loaded with the most important constraint (FUTURE) first.

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 correctly compensates by naming the returned fields and the company-wide sentinel. Nothing critical is missing for a read-only list tool, though ordering and pagination behavior are unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single all parameter is already documented in the schema, including the default. The description restates the same semantics without adding syntax or edge-case detail, 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 verb and resource (list time off) with an explicit scope qualifier — FUTURE only — and names the returned fields (start, end, userName). This distinguishes it from the sibling workiz_get_user_time_off, which is a per-user retrieval rather than an upcoming-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?

'Useful before scheduling' gives a concrete usage context, and the all=true sentence clarifies the main branching decision. It does not, however, explicitly name alternatives or state when not to use the tool.

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

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

Annotations only declare destructiveHint=true; the description adds that the action is reversible and names the restoring tool, which is genuine context beyond the annotation. It also exposes the underlying endpoint, but does not state side effects on related records or required permissions.

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 terse fragments, front-loaded with the operation class and action, no filler. Every element (WRITE marker, action, reversal, endpoint) contributes 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 single-parameter mutation with no output schema and annotations covering the destructive flag, the description supplies the key missing facts: it is a write and it is reversible. Minor gap is absence of any note on side effects to linked jobs or lead status transitions.

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 parameter (uuid) and schema description coverage is 100%, so the schema already documents it fully. The description adds no format or identifier guidance, leaving the baseline 3 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?

States a specific verb+resource ('mark a lead as lost') and immediately signals the operation class with the 'WRITE:' prefix. It also names the sibling that undoes it (workiz_activate_lead), so the agent can distinguish this from related lead tools without opening a 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 reversal path via workiz_activate_lead is given, which implies when this tool is appropriate versus its counterpart. However, there is no explicit when-to-use or when-not-to-use guidance (e.g. disqualification criteria), so usage must be inferred.

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 only declare destructiveHint=true; the description adds meaningful context beyond that: it is a write operation, it is reversible via workiz_assign_job (softening the destructive hint), and it maps to the specific endpoint POST /job/unassign/. It does not describe failure modes or whether the job record is otherwise altered, so it is not exhaustive.

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 filler, and the WRITE marker is front-loaded so the operation type is the first thing the agent sees.

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 two-parameter write tool with full schema coverage and no output schema, the description supplies operation type, reversibility, sibling routing, and endpoint. Only minor behavioral details (error behavior when the member is not assigned) are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both UUID and User (including the exact-name requirement and the pointer to workiz_list_team). The description only repeats 'by name', adding no new syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('remove a team member from a job') with an explicit WRITE marker. It also distinguishes itself from the sibling workiz_assign_job by naming it as the inverse operation, so an agent can tell the pair apart without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to workiz_assign_job as the reverse action, which tells the agent when this tool is the right one to undo an assignment. It does not state exclusions or prerequisites (e.g. what happens if the member is not currently assigned), so it stops short of a full 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?

Annotations already give destructiveHint=true, so the safety profile is covered; the description adds real value beyond that by flagging the operation as a WRITE and, crucially, stating that the effect is reversible via workiz_assign_lead. It stops short of noting permission requirements or behavior when the member isn't assigned.

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 terse fragments: operation class, action, reversal path, endpoint. Zero filler and the most important information (WRITE, reversibility) is front-loaded.

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-param destructive tool with no output schema and annotations already declaring destructiveness, the description covers what's needed: what it removes, how to undo it, and the underlying endpoint. Minor gaps remain around permissions and the no-op/error case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both UUID and User are already documented with examples and the 'by name' constraint. The description's parenthetical '(by name)' merely echoes the schema's User description, adding no new format or validation detail. Baseline 3 applies.

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

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

States a specific verb and resource ('remove a team member from a lead') with the WRITE: prefix signalling the operation class. It also names the sibling it pairs with (workiz_assign_lead), which separates it from workiz_unassign_job and the assign_* family without opening a 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?

'Reversible with workiz_assign_lead' gives a clear routing rule for undoing the action, and the header declares when to expect a write. It doesn't spell out prerequisites (e.g. the member must currently be assigned) or an explicit when-not, so it falls just short of 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?

Annotations already declare destructiveHint=true, and the description's 'WRITE:' prefix is consistent with that. It adds genuinely useful behavior beyond the annotations: the partial-update contract ('Only the fields you pass are sent') and the backing endpoint (POST /job/update/). It stops short of describing auth requirements or reversibility.

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 tightly packed sentences with zero filler, front-loaded with the WRITE marker and the resource, closing with the endpoint. 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 27-parameter mutation tool with no output schema, the description covers what can be changed, the partial-update semantics, and the target endpoint. It omits permission/auth requirements and behavioral notes on how updates interact with existing values, but nothing essential for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds value by grouping the 27 parameters into functional clusters (status/sub-status, reschedule, contact, address, type, source, notes, tags) and naming the exact reschedule fields. This helps an agent navigate a large flat schema, though it does not add format details 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?

States a specific verb (update) and resource (an existing job), then enumerates the exact field groups that can change and names the concrete API fields for rescheduling. The word 'existing' plus the field list cleanly separates it from workiz_create_job and workiz_update_lead.

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: an agent can infer this is the tool for modifying an existing job, and 'Only the fields you pass are sent' signals partial-update semantics. However, there is no explicit when-to-use/when-not guidance and no mention of prerequisites or the alternative tool to reach for a full replacement.

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 destructiveHint=true, so the risk profile is partly conveyed. The description adds the genuinely useful partial-update semantics (omitted fields are untouched), which is behavioral context beyond the annotations, but it says nothing about overwrite risk, permission requirements, or what an update returns.

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 well-formed sentence with a WRITE prefix that front-loads the mutation semantics, followed by a terse endpoint note. Nothing is wasted; the endpoint reference is the only slightly extraneous element.

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 26-parameter mutation tool that is fully schema-documented with a required UUID and no output schema, the description covers purpose and the partial-update contract. What is missing — failure behavior on a bad UUID, permission needs, whether LeadDateTime changes have side effects — is secondary but not irrelevant.

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 26 parameters are already documented in the schema with examples. The description only groups them into loose categories (contact, address, type, source, notes, tags), adding marginal meaning over the schema's own field descriptions. 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?

States a specific verb (update) and resource (an existing lead), then enumerates the field families it can change (status, schedule, contact, address, type, source, notes, tags). This is enough to distinguish it from workiz_create_lead, workiz_get_lead, and workiz_update_job 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?

The partial-update contract ('Only the fields you pass are sent') tells the agent how to invoke it, but there is no guidance on when to reach for this tool versus siblings such as workiz_assign_lead, workiz_mark_lead_lost, or workiz_convert_lead_to_job, all of which also mutate a lead. Usage is implied rather than stated.

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