Fieldwire MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, but the description adds real value the annotations lack: the no-retry guarantee, the duplicate-creation risk, the recommended verification step, and the creator-defaults-to-owner behavior. It stops short of covering permissions/auth or a returned 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 tightly packed paragraph that front-loads the write nature and duplicate risk before the endpoint. Dense but nearly every clause carries actionable information; the trailing URL is the only near-redundant 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 15-param mutation with no output schema, the description covers the highest-risk behavior (non-idempotency, duplicates), defaults, and id-resolution helpers, while the schema handles per-param detail. Auth/permission expectations are the main remaining gap.

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

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

Schema description coverage is 100%, so the schema already documents all 15 params, including the required flags and the creator_user_id default that the description restates. The description only adds marginal cross-references (fieldwire_list_project_users), so this sits at the schema-driven 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?

Opens with 'WRITE: creates a new task in a project', a specific verb+resource, and the write framing cleanly separates it from fieldwire_update_task and the read-only list/get siblings. The endpoint path adds precise 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?

Explicitly states the tool is sent once and never retried, and prescribes recovery: check fieldwire_list_tasks before re-creating to avoid duplicates. It also names required params and routes the agent to fieldwire_list_project_users for id lookup.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: the result is scoped to the calling token's account and is served from the account host (a different host than project endpoints), which matters for routing.

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 dense sentence that front-loads the resource identity and then lists the returned fields and endpoint. No wasted words, though the module enumeration is long enough that it could be trimmed; still well structured and information-dense.

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 present, the description carries the return-value burden and does so by listing the fields the caller receives plus the host to call. For a zero-parameter read tool that is complete enough to invoke and interpret correctly.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There are no inputs whose semantics could be ambiguous, and the description correctly spends its budget describing the payload instead.

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

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

Names a specific resource (the Fieldwire account bound to the current API token) and enumerates the returned surface: id, company name/address, enabled modules, owner. This clearly separates it from siblings like fieldwire_list_account_users or fieldwire_list_projects, which cover related but different resources.

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 endpoint for resolving the token's own account context, but the description never says when to reach for this versus fieldwire_get_project or the account-users listing, nor does it name any alternative. Adequate but leaves routing 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description genuinely adds the return-scope constraint (header data only, no filled-in values), but says nothing about auth, errors, or missing-form behavior, so it adds modest context rather than rich behavior.

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?

Extremely tight: one scoping sentence plus the endpoint. The scope qualifier is front-loaded. The endpoint string is low-value redundancy but costs little.

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-item read with no output schema, the description tells the agent what comes back (headers, not values) and annotations cover safety, which is enough to call it correctly. Missing only error/not-found behavior to be fully complete.

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

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

Schema coverage is 100% with both UUID parameters fully documented, so the schema carries the parameter burden. The REST path echoes that project_id and id identify the resource but adds no format or constraint detail 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 and resource ('get ... one form by id') and scopes the payload ('header data only, not the filled-in values'). This implicitly distinguishes it from fieldwire_get_form_full, but the sibling is never named, so the differentiation is inferential rather than explicit.

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 'header data only, not the filled-in values' clause hints that get_form_full is the alternative when full values are needed, but it never states when to pick this tool or when-not to. Usage is implied rather than directed.

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, destructiveHint=false and openWorldHint, so safety is covered. The description adds a non-obvious behavioral trait — this is an asynchronous two-step job requiring polling with a jid and retry on 'pending' — which goes beyond what the structured fields convey.

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 return content, then the two-step procedure, then the endpoint — logical order with no filler. Slightly dense but every sentence carries invocation-relevant 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?

No output schema exists, yet the description describes the returned structure (sections, inputs, filled-in values) and the async retrieval protocol, which is the key thing an agent needs to call it correctly. Minor gaps around error/retry limits remain but are not 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?

Schema description coverage is 100%, so the schema already documents jid, form_id and project_id. The description reinforces the jid lifecycle (omit to start, resend to poll), aligning with the schema but adding no syntax or constraints beyond it. Baseline 3 applies.

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

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

States a specific verb+resource and detail level: 'A form with its sections, inputs and filled-in values.' The 'full' framing implies richer data than the sibling fieldwire_get_form, but it never names that sibling, so the differentiation is left to inference.

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 strong procedural guidance for this specific tool: call without jid to start the job, then poll with the returned jid, treating 'pending' as not-ready. It covers how to invoke but not when to prefer this over fieldwire_get_form or fieldwire_list_forms, and states no 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /api/v3/projects/{id}) and, more usefully, the concrete set of fields returned, which is meaningful 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?

Two compact sentences, front-loaded with the resource and scope, followed by the endpoint. No filler and nothing repeated from the title.

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 enumeration of returned fields compensates well, and annotations carry the safety semantics. It could be slightly more complete by noting error behavior for an unknown id or pointing to the list tool, but for a single-parameter read it is close to sufficient.

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?

Single parameter with 100% schema description coverage: the schema documents the UUID pattern and cross-references fieldwire_list_projects. The description's phrase 'by id' adds nothing beyond that, 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?

The description names a specific verb+resource ('One project by id') and enumerates the returned fields (name, code, address, time zone, currency, plan, features, owner email), which clearly separates it from the list/count siblings. It stops short of naming fieldwire_list_projects as the counterpart, so it is not a perfect 5.

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

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

Usage is only implied: 'by id' signals this is the single-record lookup rather than a listing, and the schema hint points at fieldwire_list_projects. There is no explicit when-to-use/when-not statement or named alternative in the description 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that all fields are returned and gives the REST path, but adds little else beyond the structured metadata.

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 sentences, front-loaded with the purpose. The endpoint path is mildly redundant but inexpensive and useful for cross-referencing with the API.

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

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

With no output schema, the description carries some burden for describing the return, and 'with all its fields' is only a minimal gesture at that. Annotations cover safety, but expansion of what 'all its fields' means 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 description coverage is 100%, so both UUID parameters are fully documented in the schema. The description only restates the by-id lookup and adds no format or constraint detail, 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 ('One task by id') and the endpoint. It is clearly distinguishable from fieldwire_list_tasks by the singular scope, though it never names the sibling 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?

No when-to-use or when-not-to-use guidance; the agent must infer that this is the single-item counterpart of fieldwire_list_tasks. No prerequisites or conditions are 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 cover the safety profile (readOnly, non-destructive, openWorld), so the bar is lower. The description adds real value beyond them by disclosing the returned field set and the host constraint ('GET /account/users on the account host'), which matters given the account-vs-project host split. Pagination on a potentially large account-wide list is not addressed.

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 compact sentences, each earning its place: the first defines the result set and fields, the second justifies the call, the third pins the endpoint. Nothing is redundant or buried.

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

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

With no output schema, the description carries the return-value burden and does so by listing the fields. Annotations cover the safety profile. The only gap is pagination/volume behavior for an account-wide list, which is not mentioned.

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 per the rubric the baseline is 4. The description correctly implies no filtering is possible, and there are no parameters to mis-document.

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

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

States a specific resource (account users) and enumerates what each entry contains (name, company, email, role, project count), plus the scope caveat that project-invited users are included. This implicitly separates it from fieldwire_list_project_users, though the sibling is never named.

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

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

Usage is only implied: 'User ids are what tasks use for owner and assignees' hints at why an agent would fetch this list, but there is no explicit when-to-use, when-not, or pointer to fieldwire_list_project_users as the narrower alternative.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the endpoint path and field set but says nothing about pagination behaviour or default page size, which lives only in the 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?

Two compact sentences, with the payload contents and the filter stated up front and the endpoint last. No redundant or ceremonial 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?

With no output schema, the description usefully enumerates the returned fields and the endpoint, which is the key missing context. It still leaves pagination flow (using last_synced_at across calls) unstated in prose, a minor gap for a 5-parameter list 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%, with kind, state, per_page, project_id and the last_synced_at cursor all documented in-schema. The description's 'Filter by kind' adds no semantics beyond that, 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 ('attached in a project') and enumerates the returned fields (id, name, kind, size, capture time, file URLs), plus the underlying endpoint. It is unmistakably the attachment lister, though it never explicitly contrasts itself with sibling list tools like list_sheets or list_floorplans.

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?

'Filter by kind' is the only usage instruction and it explains how to narrow results, not when this tool is the right choice versus list_sheets/list_floorplans. Usage is implied by the resource name rather than 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, openWorldHint=true and destructiveHint=false, covering the safety profile. The description adds the GET endpoint and the existence of filtering/expansion options, but does not disclose pagination defaults, the deleted-state semantics, or rate limits beyond what the schema says.

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 compact clauses: what is returned, how to filter, and the endpoint. Front-loaded and free of filler, though the telegraphic fragment style gives it slightly less polish than a fully formed sentence would.

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 helpfully enumerates the returned fields and the pagination/expansion hooks (with_current_sheet, cursor param in schema). For a read-only list endpoint this is close to complete; only explicit paging behavior is left implicit.

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 (tag, state, per_page, name_contains, updated_after, last_synced_at, with_current_sheet) is already documented in the schema. The description only restates the filter categories and with_current_sheet, adding no syntax or format detail beyond structured data, 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 the resource ('Plans (floorplans) of a project') and enumerates the returned fields (id, name, description, folder, sheet count), which is more specific than a bare 'list plans'. It does not explicitly differentiate itself from the closely related sibling fieldwire_list_sheets, 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?

Gives filtering guidance ('Filter by name, tag or dates') and explains the with_current_sheet toggle, which implies usage. However there is no explicit when-to-use / when-not-to-use statement or routing to an alternative tool, so usage remains 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.

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-structured context: the Business-plan requirement and the underlying endpoint. Pagination behavior is implied only by the schema's cursor parameter, so it is not fully disclosed.

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 resource and returned fields, then the prerequisite, then the alternative, then the endpoint. Very little waste, though the trailing raw endpoint is of marginal value to 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?

There is no output schema, and the description compensates by enumerating the returned fields (id, name, template, status, owner, dates). Combined with full schema coverage for inputs, an agent has enough to call it correctly; only pagination semantics remain implicit.

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 ten parameters are already documented in the schema, including the state enum and the last_synced_at cursor. The description adds no parameter-level 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?

Names a specific verb (list) and resource (forms), and immediately disambiguates the resource with parenthetical examples (inspections, daily reports, checklists). It also lists the returned fields, so an agent knows exactly what this tool yields versus a single-form fetch.

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 fieldwire_get_form_full for filled-in values, which is the key alternative in the sibling set. It also states the Business-plan prerequisite. It does not give when-not conditions beyond that, but the routing advice 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the returned field set, and says nothing about paging behavior, auth requirements, or result size limits beyond what the schema's cursor param already states.

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 with no filler: resource and fields, then the id's purpose, then the route. Slightly telegraphic ('Form templates of a project: ...') but every clause carries information.

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

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

Without an output schema the description carries the return-value burden, and it names the fields an agent will receive. Combined with the fully documented schema for filtering and pagination, an agent has enough to call it correctly, though the lack of contrast with fieldwire_list_forms leaves a small routing 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 five params (state, per_page, project_id, name_contains, last_synced_at) are already documented in the schema, including the Fieldwire-Filter header detail. The description adds no syntax or semantic 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?

Names the resource (form templates), scopes it to a project, and lists the fields returned (id, name, version, publish state), plus the underlying endpoint. It is clearly distinguishable from fieldwire_list_forms (form instances) by the 'template' framing, though it never explicitly contrasts the two.

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 phrase 'Use the id to filter forms' hints at the downstream purpose of the returned ids, but there is no statement of when to use this tool versus siblings like fieldwire_list_forms or fieldwire_get_form, nor any exclusion guidance. 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the response shape and the underlying GET endpoint, but nothing on pagination behavior, filters, or permissions beyond what the schema and annotations already state.

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 with zero waste: resource first, then the relation to tasks, then the endpoint. Nothing redundant.

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

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

There is no output schema, and the description compensates by naming the returned fields; pagination and filtering are fully covered by the schema. Adequate for a simple read-only list tool, though a note on pagination semantics in prose would make it 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 the schema already documents state, per_page, project_id and the last_synced_at cursor in detail. The description adds no parameter-level semantics (no mention of the state filter or cursor), 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 clear resource and scope ('Locations of a project') and adds useful detail: the returned fields (id, name, parent location_id) and the relationship that tasks carry a location_id. It distinguishes itself from task/floorplan siblings, though the verb is only implied by the name/title rather than the description text.

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

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

Usage is implied by the task-to-location relationship ('Tasks carry a location_id'), which hints at why an agent would fetch locations, but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings such as list_floorplans.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavioral context the annotations cannot: results are scoped to the token's user and to the region chosen at login, plus the underlying GET /api/v3/projects endpoint.

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

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

Two sentences, front-loaded with the resource and scope, then filters, then the key downstream hint and endpoint. Every clause carries information; 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 enumerates the returned fields (id, name, code, address, time zone, plan, archive state) and states the access scope. Pagination behavior is only implied through the schema's cursor parameter rather than the description, which is the main remaining gap.

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

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

Schema description coverage is 100%, so all eight parameters are already documented in the schema including the enum, pagination cursor, and date bounds. The description's 'Filter by name, code, archive state or update time' only summarizes what the schema already states, adding no new syntax or 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?

Names a specific verb and resource ('Projects the token's user can access'), defines the scope (token user, region chosen at login), enumerates the returned fields, and lists the filter dimensions. It is clearly distinguishable from the singular sibling fieldwire_get_project.

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 for use via the filter list and an explicit downstream instruction: 'Use the id in every other tool.' It does not state when to prefer this over fieldwire_get_project or other list tools, so it falls short of full when/when-not 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the cross-reference that the returned id feeds task owner_user_id/user_ids and cites the underlying GET path, but says nothing about pagination, result caps, or required project 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 short sentences with no filler; the returned-fields list and the filter capability come before the endpoint path. Slightly abrupt/fragmented phrasing ('Users on one project with...') but every sentence carries information an agent can act on.

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 helpfully enumerates the returned user fields and the id's downstream meaning, which is the main thing an agent needs. Missing pagination/ordering behavior keeps it short of complete for a 5-parameter listing 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 coverage is only 40% — company_contains, last_name_contains and first_name_contains carry no schema description. The description partially compensates by saying it filters by email, name and company, which maps those parameters to the 'contains' semantics, but it adds no format, matching-case, or combination behavior.

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 clear resource and scope — 'Users on one project' — plus the fields returned (name, company, job title, email, phone), so an agent knows exactly what it gets. It implicitly separates itself from fieldwire_list_account_users via 'one project', but never names that sibling as the account-wide alternative.

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?

Offers filtering guidance ('Filter by email, name or company') and a useful cross-tool note that the returned integer id is what tasks expect for owner_user_id/user_ids. There is no explicit when-to-use/when-not statement or routing to the account-level or team-level listing 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely non-schema context: the RFI-module prerequisite and the underlying GET endpoint, confirming this is a scoped read against a specific API path. It stops short of describing pagination mechanics or return volume.

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 returned fields, prerequisite, filter set and endpoint are packed into three short fragments with zero filler, and the resource definition is front-loaded. The telegraphic style is slightly terse but nothing is wasted.

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, enumerating the returned fields is exactly the right compensation, and the module requirement plus endpoint round out an agent's needs for a nine-parameter read tool. The pagination cursor workflow lives only in the schema, which is acceptable but leaves a small gap for first-time callers.

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 every one of the nine parameters is documented in the schema, so the schema carries the load. The description's filter summary (status, assignee, text, overdue, dates) restates parameters without adding format or interaction 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?

The description names the resource (RFIs of a project) and enumerates the returned fields (number, name, question, answer, status, assignee, due date), which makes the tool's data domain unambiguous. It doesn't explicitly state the verb 'list' in prose or contrast itself with the sibling listers like fieldwire_list_submittals, but the resource specificity is strong enough to separate it.

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?

'Needs the RFI module' states a real prerequisite, and 'Filter by status, assignee, text, overdue or dates' implies the read/search context. However, there is no when-to-use versus when-not-to-use guidance, no mention of the pagination workflow, and no routing to an alternative if the RFI module is absent.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set and the underlying endpoint path, which is useful context an agent cannot get from annotations, but says nothing about pagination behavior or 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 short, front-loaded fragments: resource then scope then endpoint. Slightly telegraphic, and the raw GET path is of marginal value to an agent, but nothing is wasted.

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 8 parameters and no output schema, the description helpfully enumerates the returned fields (id, name, file name, version, floorplan_id, file URLs) and the filtering dimensions. Pagination is handled entirely in the schema, so the omission is minor.

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 filter including state, per_page and the last_synced_at cursor is documented in the schema. The description's 'plan, folder, name or dates' adds no syntax or format detail beyond the schema, 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 concrete verb+resource (list sheets) and clarifies the domain term with '(plan versions)', which helps separate it from the sibling list_floorplans. It does not name any sibling tool explicitly, 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?

'Filter by plan, folder, name or dates' implies when the filters are useful, but that is closer to parameter summary than usage guidance. There is no statement of when to choose this over fieldwire_list_floorplans or other list endpoints, and no 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds the module-permission prerequisite and enumerates returned fields, which is useful since no output schema exists, but it omits pagination behavior and how filters combine.

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; the resource and returned fields come first, then the prerequisite, then filter options and the endpoint. Nothing is padded, though the endpoint path and 'key dates' are marginally low-value.

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

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

For a 9-parameter read tool with no output schema, the description covers the resource, a partial view of returned fields, the module prerequisite, and filter dimensions. Only pagination/return-shape detail is genuinely 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 coverage is 100%, so every parameter is already documented in the schema, including the cursor parameter last_synced_at and the enum values. The description restates the filterable dimensions (status, assignee, text, overdue, dates) without adding format or syntax detail beyond the schema, so baseline 3 applies.

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

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

Names the specific resource (submittals of a project) and enumerates the returned fields (number, name, status, revision, key dates), which distinguishes it from sibling list tools like fieldwire_list_rfis and fieldwire_list_forms. It reads as a noun phrase rather than an explicit verb, but the intent 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?

States the prerequisite ('Needs the submittals module') and the available filter dimensions, which is genuine usage context. However, it never says when to prefer this over alternatives or what happens if the module is unavailable, so guidance is 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds the response shape and the underlying GET endpoint, but says nothing about pagination behavior or rate limits that the cursor parameter 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?

A single front-loaded sentence plus the endpoint path, with no filler. It loses a point because 'state (empty/yes/no/not_applicable)' describes an output field but uses the same word as the input `state` parameter whose enum is active/deleted, which can momentarily blur which 'state' is meant.

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 naming the returned fields, and the schema covers the pagination cursor and filter parameters. It is complete enough to call correctly, though pagination flow is left entirely to 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 all four parameters (project_id, state, per_page, last_synced_at) are already documented in the schema. The description adds no parameter-level detail, which is the correct baseline when 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 names a specific verb+resource (list checklist items across all tasks in a project) and enumerates the returned fields (name, checked flag, state, task_id), so an agent knows exactly what comes back. It does not explicitly contrast itself with siblings like fieldwire_list_tasks, but the resource 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?

Usage is only implied: it scopes to 'all tasks in a project' and hints the task_id links items back to tasks, but there is no explicit when-to-use statement, no mention of prerequisites, and no routing away from alternatives such as fieldwire_list_tasks or fieldwire_get_task.

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, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely new context beyond that: the returned field set, the cross-tool id-resolution dependency, and the underlying GET endpoint, though it omits pagination behavior despite the last_synced_at cursor.

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?

It is compact and front-loads the resource, then fields, then filters, then id resolution. The fragments are dense and slightly list-like rather than prose, and the trailing raw endpoint is the weakest element, but nothing is wasted.

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 18 parameters, no output schema and a cursor parameter, the description usefully compensates by enumerating the returned fields and the filter surface. The main missing piece is pagination semantics around last_synced_at, which the schema hints at but the description never explains.

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 earns an extra point by mapping the UUID filter params to the sibling tools that produce them (statuses, teams, locations, project users), which the schema itself does not tell an agent.

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

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

The description names the resource (tasks, with synonyms punch items/issues) and its project scope, then enumerates the fields returned and the filters available, which makes the tool's job unambiguous against the single-task sibling fieldwire_get_task. It never uses an explicit verb, relying on the name, so it falls just short of the crispest tier.

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 concrete usage context: which filters exist and, importantly, which sibling tools to call to resolve status/team/location/user ids before invoking this one. It stops short of explicit when-not guidance (e.g., use fieldwire_get_task for a single item, or the pagination contract), so no 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 readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds the GET endpoint path and the shape of returned fields, which is useful context, but nothing about pagination, rate limits, or auth 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?

A compact two-sentence block that front-loads the resource and return fields, then tacks on the usage hint and endpoint. No wasted text, though the raw endpoint string adds little 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?

There is no output schema, so describing the returned fields (id, name, order, kind, default flag) is genuinely necessary and present. For a simple single-parameter read tool this is essentially complete, missing only minor operational 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?

With 100% schema description coverage, the single project_id parameter is fully documented in the schema. The description adds no meaning beyond the schema (it never mentions project_id), 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?

The description names the specific resource (task statuses of a project) and enumerates the returned fields (id, name, order, kind, default flag), so an agent knows exactly what it yields. It is clear but does not explicitly distinguish itself from siblings like fieldwire_list_tasks.

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 sentence 'Use the id as status_id on tasks' implies usage context, linking this lookup to task creation/updates, but there is no explicit when-to-use guidance or mention of alternative tools. 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond annotations by disclosing the return shape (id, name, handle) and the underlying endpoint, which is useful since no output schema exists.

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 sentences with the resource stated first, followed by the terminology clarification and endpoint. Zero filler; everything 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 read-only list tool with full schema coverage and clear annotations, the description is nearly complete: it gives the return fields and terminology. Only minor items like pagination behavior are absent, and those are already carried by the per_page/last_synced_at schema entries.

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 four parameters (project_id, state, per_page, last_synced_at) are fully documented in the schema itself. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

States a specific resource (teams of a project) and even enumerates the returned fields (id, name, handle), so the agent knows exactly what this returns. It also maps the Fieldwire terminology ('categories' on tasks) which aids disambiguation, though it never explicitly names a sibling tool to contrast against.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The terminology note ('tasks carry a team_id') hints at the domain but does not tell the agent under what condition this tool should be selected versus list_tasks or list_project_users.

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 mark this destructive and non-idempotent, and the description goes beyond them by disclosing partial-update semantics, that user_ids replaces the entire assignee list, that null clears eligible fields, and that the request is sent once and never retried. That last point is exactly the operational context an agent needs for a non-idempotent write, and it does not contradict the destructiveHint.

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 tightly packed sentences lead with the WRITE classification and the partial-update rule, then use cases, then the endpoint. No filler and nothing buried.

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 15-parameter partial-update tool the description covers the behaviors that matter most: what is replaced vs. cleared, safety exclusions, and retry policy. The only gap is what comes back after the update, which is not covered by an output schema but is also not stated here.

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 documented at the field level. The description's notes on list replacement and null-clearing restate what the schema already says for user_ids and the nullable fields, adding no new syntax or constraint detail. 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 and resource ('changes fields of one task') with scope qualifiers ('only the fields you pass'), and the PATCH endpoint confirms the partial-update semantics. An agent can distinguish this from fieldwire_create_task and fieldwire_get_task without inspecting 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?

Explicitly lists the intended use cases (status, owner, assignees, priority, dates) and gives one clear exclusion ('It does not delete the task'). It does not name alternative siblings for related operations, so it falls short of a full when/when-not/alternatives treatment.

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