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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: required permission (accounts:manage) and visibility scope, plus clarification that the project is auto-determined. It does not, however, describe side effects such as cascading deletion or irreversibility details.

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

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

The description is short, front-loaded with the core action, and structured as purpose, permission requirement, endpoint, and project clarification. Every line adds relevant information, though the endpoint line is somewhat redundant with the schema's path structure.

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 destructive delete tool whose annotations already carry the safety profile, the description supplies the key missing context: permission requirement and automatic project scoping. It lacks any note on what happens to the deleted account's associated data, but that is a minor gap given the basic operation and no output schema.

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

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

Schema description coverage is 0%, so the description must compensate for the single required parameter accountId. It clarifies that projectId is not needed (useful negative information) but never explains what accountId represents or its format. The schema itself only enforces a non-empty string, leaving the parameter largely undocumented.

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 (平台账号), clearly distinguishing it from sibling account tools like anon_get_accounts and anon_patch_accounts_account_id. An agent can identify the operation and target without opening the schema.

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

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

Provides prerequisite conditions (accounts:manage permission, visibility scope) but does not state when to use this tool versus alternatives (e.g., anon_delete_members_user_id or other delete tools). Usage is only implied by the name and permission note.

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 readOnlyHint=false, but the description goes further by disclosing the cascade effect (all confirmation records are destroyed too) and the auth requirement (announcement:manage). Those are exactly the kinds of consequences an agent needs before issuing an irreversible call, and they are not derivable from the annotations.

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

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

Four short sentences, no filler: purpose, permission, side effect, endpoint/parameter note. Front-loaded with the action and consequence, with the mechanical details (endpoint, project inference) trailing.

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 destructive delete with no output schema and a fully-covered annotation set, the description supplies everything relevant: what is deleted, what else is deleted, what permission is required, and which parameters are/are not expected.

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 0%, so the description must carry the load; it does so by clarifying that only announcementId is supplied and the project is inferred from the API key, explicitly forbidding a projectId the agent might otherwise invent. It adds no detail about the announcementId value format itself, but that is largely self-evident from the name.

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?

Precise verb+resource ('删除公告') plus a scope detail — it also deletes all confirmation records — that an agent would not learn from the name alone. An agent can tell this apart from anon_patch_announcements_announcement_id and anon_post_announcements_announcement_id_confirm 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?

States a concrete gating prerequisite (announcement:manage permission) that tells the agent when this call will succeed, which is real usage context. It stops short of naming alternatives or when-not-to-use conditions relative to the PATCH/POST announcement siblings.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds a critical side effect the annotations cannot express: deletion cascades to revoke all API keys issued by the tool. It also discloses the auth requirement and the implicit project scoping.

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: action, permission and cascade consequence first, then the raw endpoint, then the scoping note. Every line earns its place and the disruptive consequence 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 destructive one-parameter tool with full annotation coverage and no output schema, the description supplies the action, the auth prerequisite, the cascading side effect, and the project-scoping rule. Nothing an agent needs to call it safely is 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 0% and the only parameter (toolId) carries no format detail, so the description must compensate. It does so partially by explaining why projectId is absent (project inferred from the API key), which clarifies the shape of the required path argument, though it adds nothing on toolId itself.

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 and resource ('删除自定义工具' / delete custom tool) and is clearly distinguishable from the sibling read/create/update variants (anon_get_custom_tools, anon_post_custom_tools, anon_patch_custom_tools_tool_id). It even supplies the underlying DELETE route, leaving no ambiguity about the operation.

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 states the required permission scope ('需 tools:manage 权限') and clarifies that projectId must not be supplied because the project is derived from the API key, which is exactly the kind of precondition an agent needs. What is missing is explicit when-to-use vs. when-not / alternative guidance, but the operational context 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 flag destructiveHint=true and readOnlyHint=false, and the description adds substantive context beyond them: the required permission scopes, the 403 outcome when deleting another user's entry, and that the project is derived from the API key. This is exactly the auth/error context an agent needs for a destructive mutation.

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 verb, then permission semantics, then the route; every sentence carries information. Slightly dense with the permission branches but no wasted 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 one-param destructive delete with no output schema, the description covers purpose, authorization, scoping, and failure behavior. It omits return/confirmation semantics, which is minor given the tool's simplicity.

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 0%, so the description carries the burden and does explain that projectId must NOT be supplied (project comes from the API key), adding real meaning about path scope. It gives no format/example for txId itself, so not a 5.

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 ('删除账目' / delete a finance entry) plus the exact HTTP route DELETE /api/projects/{id}/finance/{txId}. This clearly distinguishes it from siblings like anon_patch_finance_tx_id and anon_get_finance.

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 concrete authorization rules: needs finance:manage or finance:add, managers can delete any entry, add-level users can only delete their own, others get 403. This effectively defines when the call succeeds. It does not name a sibling alternative (e.g., patch to modify instead of delete), so it stops short of a 5.

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

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

Annotations already flag destructiveHint=true, but the description goes further by disclosing the cascade side effects: photo original/preview storage objects and File documents are also deleted. That is exactly the 'what gets destroyed' context an agent needs before calling a non-idempotent delete, plus the permission requirement.

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

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

Front-loaded with the action and permission requirement, then cascade behavior, then routing. Efficient overall, though interleaving the raw HTTP route between behavioral facts is slightly less scannable.

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 nested-schema, no-output-schema delete, the definition covers purpose, authorization, cascade destruction, and project scoping. The main gap is itemId semantics, which the nested schema does not fill in either.

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

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

Schema description coverage is 0%, so the description carries the load. It usefully explains that projectId is not needed because the project is derived from the API key, but it never describes the one real parameter, itemId (format, source, constraints). Partial compensation only.

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 ('删除失物' / delete lost item) and the HTTP route makes the operation unambiguous against siblings like anon_get_lostfound_item_id, anon_patch_lostfound_item_id, and anon_post_lostfound.

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 supplies a genuine prerequisite (lostfound:manage permission) but never states when to choose this delete over alternatives such as anon_patch_lostfound_item_id for updates or a status change. Usage is implied by the verb rather than explained.

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, readOnlyHint=false and idempotentHint=false. Beyond that, the description adds genuine behavioral context: it is a cascade delete that also destroys all versions and files, and it requires materials:manage authorization. That scope-of-destruction detail is not available in the annotations.

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

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

Front-loaded with the action, followed by permission requirement, deletion scope, and endpoint. Every sentence carries information and there is no filler. Slightly dense with four clauses but still efficient.

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

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

For a single-parameter destructive tool with no output schema and annotations that already flag the safety profile, the description covers the essentials: what is destroyed, the permission gate, and the fact that no projectId is needed. Nothing critical is missing, though confirmation/irreversibility is only implied.

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 exists with 0% schema description coverage, so the description must compensate. It does so by giving the endpoint template showing resourceId in the path and explicitly stating the project is derived from the API key and projectId must NOT be passed — useful negative guidance. It still does not describe resourceId's format, keeping it from a 5.

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

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

The description states a specific verb and resource (删除资源 = delete resource) and adds that it removes the resource together with all its versions and files, which sharpens the scope. The embedded DELETE endpoint confirms the target. It does not explicitly name a sibling to distinguish from, so 4 rather than 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?

It provides a real prerequisite — the materials:manage permission — which helps an agent know when it is allowed to call this. However, it gives no explicit when-to-use/when-not guidance and does not point to alternatives such as anon_patch_materials_resource_id or anon_get_materials_resource_id for non-delete needs.

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 destructive=true and idempotent=false, so the safety profile is covered. The description adds real value beyond that: the required scope (materials:manage), the specific 400 failure condition, and that the project is derived from the API key. It stops short of describing the success response.

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

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

Front-loaded with the action and permission, then the failure condition and path. The raw DELETE URL is mildly redundant with the tool name but useful for grounding. No filler sentences.

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 destructive endpoint with no output schema, the description covers the key decision inputs: permission, blocking condition, and identifier resolution. The only notable omission is what a successful delete returns, which is minor given the destructive annotation.

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 0% and the sole param typeId is undocumented in the schema. The description clarifies that no projectId is needed (resolved from the API key) and shows the path shape, but gives no semantics for typeId itself (source, format, where to obtain it).

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

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

States a specific verb (删除/delete) and resource (资源类型/resource type), and the sibling set makes the distinction meaningful versus anon_delete_materials_resource_id (deletes a resource, not a type) and anon_patch_materials_types_type_id. An agent can select this correctly without opening the schema.

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

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

Adds concrete preconditions: requires materials:manage permission and returns 400 if the type still has resources, which tells the agent to empty the type first. It does not explicitly route to alternatives (e.g., patch or list types), so it falls short of a 5.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely non-structured context: the member:manage authorization requirement, the self-removal prohibition, and that the project scope is inferred from the API key. It does not address reversibility or error 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?

Terse and front-loaded: the action, the permission requirement, and the self-removal constraint come first, followed by the endpoint and the project-scoping clarification. Every sentence carries information and there is no filler.

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

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

For a destructive single-parameter delete with no output schema, the definition covers the essentials: what is removed, the auth requirement, the self-removal guard, and the project-scoping assumption. Only the userId semantics and any failure/idempotency nuance remain 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 description coverage is 0% for the single nested path.userId parameter, so the description must carry the load. It usefully clarifies that no projectId is expected (project inferred from the API key) and shows userId in the path template, but it never explains what userId represents or its format.

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 gives a specific verb and resource ("移除成员" / remove member) and pins it to a concrete endpoint (DELETE /api/projects/{id}/members/{userId}), which cleanly separates it from the sibling anon_patch_members_user_id (update) and the other delete tools. An agent can identify the operation without opening the schema.

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

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

It states the required permission (member:manage) and an explicit precondition/restriction (cannot remove yourself), which tells the agent when the call is valid. It does not name an alternative tool or describe failure/fallback paths, so it stops 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 destructiveHint=true and non-idempotent behavior, so safety is covered. The description adds genuinely useful context beyond annotations: the required project:manage permission and the fact that the target project is derived from the API key rather than supplied. It stops short of describing cascade effects of deletion.

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

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

Front-loaded with the action, then permission, endpoint, and a useful scoping note. Compact and well-ordered; the raw endpoint line is slightly redundant but still informative.

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 destructive mutation whose annotations already flag destructiveness, the description covers purpose, auth, and project scoping. Without an output schema it omits any return/confirmation detail, but that is minor for a delete endpoint.

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

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

Schema description coverage is 0%, so the burden falls on the description. It clarifies a non-obvious scoping point (no projectId needed, project auto-determined), which is valuable, but does not document the milestoneId parameter itself beyond what its name implies.

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 opens with a specific verb+resource (删除里程碑) and disambiguates it from siblings like anon_patch_milestones_milestone_id and anon_post_milestones. An agent can immediately tell this is the deletion operation on milestones specifically.

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 states the required permission (project:manage) which acts as a prerequisite, and clarifies the project scoping, but gives no explicit when-to-use/when-not or alternative routing. Usage is only implied by the verb.

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 idempotentHint=false, but the description adds context the annotations cannot: the required permission scope, the guard that deletion is refused while items remain, and that the project is inferred from the API key. It does not state irreversibility or what happens to nested references, so not 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?

Front-loaded with the action, then permission, then failure condition, then endpoint — every line carries information and there is no filler. Slightly terse spacing between clauses, but nothing 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?

For a destructive mutation with a single path parameter and no output schema, the description covers authorization, the rejection rule, and project scoping, which is most of what an agent needs to call it safely. Missing only value-format detail for catId and confirmation that the deletion is irreversible.

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

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

Schema description coverage is 0% and the single nested catId parameter has no format guidance (ID vs. name, source of the value); the description only implies it belongs to the path. It does usefully clarify that no projectId is required because the project is derived from the API key, which compensates partially.

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 ('删除实物分类' / delete physical category), which is distinguishable from sibling operations like anon_delete_physical_items_item_id or anon_delete_materials_types_type_id. It does not explicitly contrast with those siblings, so it stops short of a 5.

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

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

Gives the permission precondition (materials:manage) and an explicit refusal condition (rejects deletion when the category still contains items), which is real when-to-use/when-it-fails guidance. It never points to an alternative action (e.g., deleting or reassigning items first), so no exclusion routing.

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

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

Annotations already declare destructiveHint=true, so the safety profile is known, but the description adds real value beyond them: the required materials:manage permission and the cascading deletion of the item's change logs, which is a non-obvious side effect. It stops short of stating irreversibility or return 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?

Four short sentences, all front-loaded: purpose, permission, side effect, then route. Nothing redundant; the DELETE line anchors the agent to the exact endpoint.

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 destructive single-parameter delete with no output schema, the description covers permission, cascading scope, and path derivation, leaving little an agent needs before calling. It could note irreversibility, but the essentials are present.

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

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

Schema description coverage is 0%, so the description carries the burden. It clarifies that the project is derived from the API key and projectId must not be passed, which is useful routing context, but itemId itself is only referenced via the route template with no format or source guidance.

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 (delete) plus the exact resource (a physical/materials item addressed by itemId), and the appended DELETE route removes any ambiguity. An agent can distinguish it from anon_patch_physical_items_item_id and anon_delete_physical_categories_cat_id 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?

Usage is implied by the verb/resource and the stated materials:manage permission requirement, but the description never says when to prefer this over the patch/update sibling or when deletion is inappropriate. No explicit when-not guidance is given.

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

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

The description adds real behavioral context beyond annotations (permission requirement, removal from qqGroups, auto-unbind on the QQ side, project inferred from the key). But it explicitly claims the operation is idempotent ('幂等') while the annotation declares idempotentHint=false, a direct contradiction on that flag. Contradicting a structured annotation caps this dimension despite the otherwise rich disclosure.

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?

Purpose is front-loaded in the first clause, followed by permission, side effects and the HTTP route. Dense and mostly waste-free, though the route line partially duplicates what the tool name already encodes.

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 destructive mutation with no output schema, the description covers the essentials an agent needs: required permission, what is mutated, idempotency behavior, project resolution, and an independent auto-unbind condition. Its only completeness failure is that the stated idempotency conflicts with the annotations.

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

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

Schema description coverage is 0% for the single nested groupOpenId parameter, so the description must compensate. It clarifies that the project component of the path is derived from the API key and need not be passed, which resolves a real ambiguity, but it adds no meaning about the groupOpenId value itself (format/origin).

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: unbind ('解绑') a project's QQ group by groupOpenId, matching the DELETE route shown. The action is clearly distinct from the PATCH sibling anon_patch_qq_binding_group_open_id, though the description never names or contrasts a sibling explicitly, which keeps it from 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?

Provides useful preconditions (requires project:manage permission, project resolved from the API key so no projectId is passed) and describes an alternate trigger path (auto-unbind on GROUP_DEL_ROBOT). However it gives no explicit when-to-use vs when-not guidance and does not mention the PATCH binding sibling as an 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?

Even though annotations already declare destructiveHint=true and idempotentHint=false, the description adds real behavioral context beyond them: the required scope (role:manage), the 409 failure mode when the role is still in use, and that the project is inferred from the API key so no projectId is needed.

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, front-loaded sentences: action, permission, failure mode, endpoint plus the explicit note that projectId is not needed. Nothing is 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?

With no output schema, the description covers the operation, authorization requirement, conflict behavior, and path binding well. Only the roleName value format is left unaddressed, which is minor for this destructive single-param tool.

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

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

Schema description coverage is 0% for a single nested path param, so the description has to compensate. It shows roleName's position in the URL template and clarifies that projectId is intentionally absent, but never states roleName's expected format or source.

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 (删除角色 / delete a role) and pins the exact endpoint and path shape, making it trivially distinguishable from patch_roles_role_name and the other delete_* siblings.

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 clear preconditions for use: the caller needs role:manage permission, and it will fail with 409 if members still reference the role. It does not explicitly route against alternatives such as patch_roles_role_name, so it stops just short of a 5.

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

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

Annotations already flag destructiveHint=true, but the description goes well beyond them: it names the permission scope, enumerates exactly what is destroyed (storage objects, File documents, big-screen share documents), and documents the 409 execution-lock behavior. This is exactly the extra context a destructive tool needs.

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

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

Front-loaded with purpose, then permission, cascade scope, and the 409 constraint in tight successive sentences. The trailing raw endpoint line is somewhat redundant but does anchor the HTTP semantics, so it is not wasted 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?

For a destructive, no-output-schema, single-parameter tool, the definition covers the safety profile, cascade side effects, permission requirement, and failure mode. The only material gap is that the rid parameter's meaning and format are 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 coverage is 0% and the single path parameter 'rid' is never explained in either the schema or the description, so the agent must infer it means rundown id. The description does add useful scoping information (projectId is auto-derived from the API key and must not be passed), which partially compensates, but not enough to lift this above baseline.

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

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

States a specific verb (删除/delete) and resource (Rundown), and immediately distinguishes itself from sibling delete tools by disclosing that it cascades into materials, File documents, and screen-share documents. An agent can tell this apart from anon_delete_stage_rundowns_rid_items_item_id without opening the schema.

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

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

Gives a clear precondition (requires tools:manage permission) and an explicit when-not condition (deletion is rejected with 409 while the rundown is executing). It does not name a specific alternative sibling for the non-cascading case, so it falls 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 declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds genuinely new behavior: cascade cleanup of the item's attachment files, the tools:manage permission gate, and a 409 conflict during execution — all beyond what annotations 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 action and constraint, then supplies the endpoint and the projectId note. Slightly redundant with 删除节目 appearing twice, but otherwise tight and every sentence 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 destructive mutation with no output schema, the description covers permissions, cascade side effects, and the conflict condition — the essentials an agent needs. Minor gaps remain (no statement about the delete response or impact on remaining item ordering), but the safety-critical facts are present.

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

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

Schema description coverage is 0% for a single nested path parameter, so the description must carry the load. The endpoint template shows where rid and itemId sit, and it usefully explains that projectId is derived from the API key and need not be passed — good context, but the meaning/format of rid and itemId themselves is left to 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+resource (删除节目 / delete a rundown item) and the exact endpoint, so it is distinguishable from the sibling anon_patch_stage_rundowns_rid_items_item_id and the collection-level anon_delete_stage_rundowns_rid. It does not explicitly contrast itself with the nearest sibling, so it falls 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?

Provides a clear precondition (需要 tools:manage 权限) and an explicit when-not (执行中禁止编排变更, returns 409), which is real guidance. However, it never names the alternative tool for editing an item (anon_patch_stage_rundowns_rid_items_item_id) or states when to prefer deletion over it, so usage is only partly covered.

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, readOnlyHint=false, idempotentHint=false, so safety is largely covered. The description adds non-annotation context: the required tools:manage permission and the fact that projectId is auto-derived from the API key, which is useful operational detail.

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, front-loaded lines leading with the action, then the permission requirement, endpoint, and the projectId note. No wasted prose; the structure is efficient and scannable.

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 destructive delete with annotations already covering the safety profile and no output schema needed, the description supplies the key missing pieces: permission requirement and project scope resolution. It is adequately complete, with only sid semantics 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 coverage is 0% and the sole parameter is a nested path object with sid. The description partially compensates by showing the endpoint and clarifying that no projectId need be passed, but it never explains what sid identifies or its format, leaving the parameter under-specified.

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?

"删除报名批次" gives a specific verb (delete) and resource (signup batch), and the endpoint path confirms the scope. It is distinguishable from the item-level sibling delete tools by the '批次/batch' framing, though it does not explicitly name or contrast those siblings.

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 states a real prerequisite (requires tools:manage permission), which is genuine routing context. However, it gives no guidance on when to use this delete versus anon_patch_stage_signups_sid (update), anon_get_stage_signups_sid (read), or the item-level deletes; 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the required auth scope (tools:manage) and the fact that the project is inferred from the API key rather than passed in.

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

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

Three short sentences, front-loaded with the action and permission requirement, followed by the concrete endpoint and the projectId clarification. No filler, though the raw path restates what the name already encodes.

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 destructive, non-idempotent mutation with no output schema and 0%-covered nested parameters, the description covers permission and project scoping but omits what exactly is destroyed (e.g., whether an attached review or child data goes with the item) and any return/confirmation behavior. Adequate but with clear gaps.

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

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

Schema description coverage is 0% and the single parameter is a nested object with two required fields (sid, itemId). The description never explains what sid or itemId denote — it only clarifies that projectId is unnecessary, which is not one of the required parameters. The URL template hints at their roles but adds little beyond the schema's own structure.

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 verb+resource is explicit (删除报名节目 = delete a signup item), and the embedded DELETE path disambiguates the exact sub-resource from siblings like anon_delete_stage_signups_sid (whole signup) and anon_delete_stage_signups_sid_items_item_id_review. It does not, however, explicitly name those alternatives.

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 states a precondition — requires tools:manage permission — and clarifies that projectId must not be supplied because the API key determines the project. That is useful routing context, but there is no explicit when-to-use / when-not-to-use guidance versus the parent signup deletion or the review deletion.

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 real context the annotations do not carry: the tools:manage permission requirement, the no-op/idempotent return when no vote exists, and that the project is derived from the API key. However, the statement '没有本人投票则幂等返回' (idempotent return) directly conflicts with the annotation idempotentHint=false, muddying retry-safety behavior for the agent.

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 sentences that are front-loaded with the action, then permission, idempotency, endpoint, and the projectId note. No filler; 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?

For a single-path-param destructive delete with no output schema, the description covers the essentials: scope (own vote), auth (tools:manage), idempotency behavior, and the projectId auto-resolution. Only the idempotency/annotation mismatch and undefined path params keep it from being fully complete.

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

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

With 0% schema description coverage the description must compensate, and it does clarify that projectId is intentionally omitted ('无需传 projectId'). It leaves the two actual path params sid and itemId (stage-signup id, item id) undefined, though their meaning is largely inferable from the URL.

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: '撤回本人投票' (withdraw one's own vote) for the stage-signup item review. It is distinguishable from the sibling anon_put_stage_signups_sid_items_item_id_review (which submits the vote) and from anon_delete_stage_signups_sid_items_item_id (which removes the item). It does not, however, explicitly name those siblings to disambiguate.

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 the precondition '需 tools:manage 权限' and the self-only scope ('本人投票'), which tells the agent when the call is valid. It stops short of naming alternatives (e.g., using the PUT review endpoint to submit rather than withdraw a vote) or stating when not to use it.

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, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds real value beyond that: the project:manage permission requirement and the cascade that associated milestones become unassociated. It does not state irreversibility or effects on stage rundowns/signups, so it stops 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?

The purpose is front-loaded, followed by permission, cascade, return format and the auth note, with the raw method/path appended for reference. Sentences are short and mostly earn their place; the endpoint line is somewhat redundant with the operation already stated.

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 destructive delete with no output schema, the description covers permission, the milestone cascade and that the response mirrors the GET stage list, which is enough to act. It omits whether the delete is reversible and whether related rundowns/signups are also affected, leaving a small 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 0%, so the description must carry the load. It explains the non-obvious detail that the project is inferred from the API key and therefore no projectId should be passed, which clarifies why only stageId is present in the nested path object. It does not further describe the stageId value itself.

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 (删除项目阶段 / delete a project stage) and even the HTTP operation DELETE /api/projects/{id}/stages/{stageId}, making it unambiguously distinct from the sibling anon_get_stages, anon_post_stages and anon_patch_stages_stage_id. An agent can tell what this does without opening the schema.

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

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

Usage is implied by the delete verb and the stated project:manage requirement, which tells the agent a permissioned context is needed. However, no alternatives are named (e.g. when to reorder/reassign a stage versus delete it) and there is no explicit when-not-to-use guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered. The description adds value the annotations cannot: the required permission scope (todo:manage) and the scoping behavior (project auto-derived from the API key), both of which affect whether the call will succeed.

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 compact lines: verb+resource first, then permission, then endpoint, then scoping note. Every sentence is relevant, though restating the HTTP path partially duplicates the tool name.

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

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

For a one-parameter delete with no output schema, the description covers purpose, prerequisite permission, and project scoping. It omits the return/deletion semantics (e.g., what else is destroyed), but the robust destructive/reset annotations leave little uncovered.

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

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

Schema description coverage is 0%, so the description carries some burden. It usefully explains that no projectId is needed because the project is derived from the API key, but it says nothing about the meaning or format of the one actual parameter (todoId), which the schema documents only as a minLength-1 string.

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 (删除/delete) and resource (待办/todo), and the embedded endpoint DELETE /api/projects/{id}/todos/{todoId} pins down exactly which object is removed. An agent can distinguish it from the sibling patch_todos_todo_id and post_todos_todo_id_complete 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?

Gives a concrete prerequisite (需 todo:manage 权限) and clarifies that the project scope comes from the API key, which is genuinely useful context for invoking it. It does not, however, state when to prefer this over the sibling delete/completion tools or any exclusion conditions, so 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 destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the required permission scope and the fact that the target project is inferred from the API key, which prevents a likely caller mistake.

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 lines with no filler: action, permission requirement, then endpoint/scoping. Every sentence carries information, though the endpoint restatement is somewhat redundant with the tool name.

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

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

For a single-param destructive delete with annotations carrying the safety profile and no output schema, the description covers action, auth, and scoping. The only material gap is that it never explains how to obtain the mid value.

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

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

Schema description coverage is 0% and there is one nested parameter (path.mid), so the schema alone leaves mid undefined. The description compensates partially by showing the DELETE template with {mid} and explaining that projectId is implicit, indicating mid is a module identifier drawn from the path, but it never defines what a module id is or where to obtain it.

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

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

States a specific verb (删除/delete) and resource (任务模块/work module) plus the exact HTTP route, so the agent knows precisely what is destroyed. It doesn't explicitly contrast with sibling deletes like anon_delete_milestones or anon_patch_work_modules_mid, 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?

Adds the precondition that work:manage permission is required and clarifies that projectId must not be supplied, which is real usage guidance. However, it never states when to prefer this over other work-module operations (patch/post variants) or any when-not-to-use condition.

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

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

The annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context beyond them: the calling authorization model, the visibility-scope filter, the super-admin exemption, and the guarantee that ciphertext/plaintext secrets are excluded. That is meaningful disclosure of what is and isn't returned.

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

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

Front-loaded with the purpose, then permissions/visibility, then the endpoint and the projectId clarification. Each sentence carries information; only the raw endpoint line is somewhat redundant given the tool context.

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 needn't explain return values, and the annotations cover the safety profile. It supplies permissions, visibility scoping, and secret-exclusion context, which is enough for an agent to invoke it correctly; the platform filter is left 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?

Top-level schema coverage is 0% (the wrapping `query` object has no description), though the nested `platform` field is documented in the schema. The description does not mention the platform filter, but it does clarify that projectId is auto-derived and must not be passed, which is genuine parameter-level value. 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+resource ("列出平台账号" / list platform accounts) up front, making the read intent unambiguous. The scope qualifier (visibility check) further sharpens it. It does not explicitly name the write siblings (anon_post_accounts, anon_patch/delete_accounts), but the get/list framing is clear enough to distinguish 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?

States the eligible caller (project members) and the visibility scoping behavior, which implies when the tool is appropriate. However, it gives no explicit when-to-use vs. alternative guidance (e.g., when to use this versus patching or a per-account get). 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 establish readOnly/idempotent/non-destructive/openWorld, so safety is covered; the description adds real behavior beyond that: results are ordered by creation time descending, gated items are filtered by permission point (or project:manage), and the project is derived from the API key rather than supplied. It stops short of describing pagination mechanics or return shape.

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

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

Roughly three short sentences, purpose front-loaded, then scope, then visibility rules; the raw endpoint string is mildly redundant but the rest earns its place with no padding.

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 covers the essentials an agent needs: what it returns, auth requirement, ordering, and permission-gated filtering. Parameter details live in the schema, so the omission there is acceptable, though pagination behavior could be clearer.

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

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

The description mentions no parameters at all, and the schema leaf nodes (limit/before/sourceType) carry their own descriptions, so the description adds no syntax or meaning of its own. The only tie-in is the ordering statement, which loosely supports the 'before' cursor without explaining it.

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

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

The description opens with a concrete verb+resource ('列出项目动态' / list project activities) and pins it to an exact endpoint (GET /api/projects/{id}/activities). The scope is clear, but it does not name or contrast any sibling (e.g. dashboard actions or todos feeds), leaving differentiation to the agent.

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 states the membership prerequisite ('需项目成员身份') and the permissionGate visibility rule, which implies usage context, but gives no explicit when-to-use / when-not guidance or named alternatives despite a large sibling toolset. Usage is therefore inferred 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 readOnly, idempotent, non-destructive, and openWorld. The description usefully adds behavior beyond that: pinned-first ordering, publish-time descending sort, filtering to the caller's visible scope, and that total reflects the visible count. It does not cover pagination defaults or rate limits, keeping it short of a 5.

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

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

Roughly three compact sentences plus the endpoint path, with the core action and constraints front-loaded and zero filler. Every clause (membership, ordering, visibility, total semantics, project auto-detection) carries distinct 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 read-only listing endpoint with annotations covering the safety profile and no output schema, the description supplies membership requirements, sort/filter semantics, and the project-resolution rule. The only material gap is pagination/expired-filter behavior, which lives partly in the schema rather than the description.

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

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

Schema description coverage is reported at 0% for the (nested) parameters, and the description adds nothing about page, limit, or includeExpired — it doesn't even mention the expired-announcement toggle or the 50-item cap. The parameter burden is therefore not compensated in the description text.

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 (公告) plus the backing endpoint GET /api/projects/{id}/announcements. An agent can immediately distinguish this list operation from siblings such as anon_post_announcements, anon_delete_announcements_announcement_id, or anon_get_announcements_announcement_id_confirmations.

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 a real prerequisite ('需项目成员身份') and clarifies that projectId is not needed because the API key determines the project, which prevents a wasted call. However, it never states when to pick this tool over the per-announcement or confirmation endpoints, so selection guidance 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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds meaningful context beyond them: the required announcement:manage permission, that results are split into confirmed/unconfirmed groups for all project members, and that projectId is auto-derived from the API key. It does not mention pagination or result size, keeping it at a 4.

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 compact sentences with the purpose front-loaded, followed by permission, return structure, and the endpoint. Efficient, though the raw endpoint path and the projectId clarification could be folded together.

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 describing the return shape (two groups of members) and the permission requirement. It leaves the announcementId semantics and any pagination behavior unaddressed, but is otherwise complete for calling the tool correctly.

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

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

Schema description coverage is 0% for a single nested announcementId parameter, so the description must carry the burden. It helpfully clarifies what is NOT needed (projectId is auto-determined from the API key) but never explains the announcementId value or format beyond its position in the URL path.

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 ('查看公告确认情况' = view announcement confirmation status) and distinguishes itself from the sibling list tool (anon_get_announcements) and the confirm action (anon_post_announcements_announcement_id_confirm). An agent can identify this as the read-only status query without opening the schema.

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

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

Provides a permission prerequisite ('需 announcement:manage 权限') which is useful gating context, but gives no explicit when-to-use/when-not guidance or named alternatives. Usage is only implied by the read-only nature and the permission requirement.

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 readOnly/idempotent/openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are sorted by createdAt ascending, deactivated creators render as "未知用户", and no projectId is required because the project is inferred from the API key.

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

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

Front-loaded with the purpose, then ordering/edge-case, then auth note. Fairly tight, though the raw URL path restates information that adds little beyond the tool name.

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

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

There is no output schema, so the description carries the return-value burden and does so adequately: ordering, the deactivated-creator fallback, and access scope are all disclosed. For a zero-param list tool this is 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?

The tool takes zero parameters, so per the baseline this scores 4. The description reinforces this by explicitly stating no projectId needs to be passed, which preempts an agent from inventing a parameter.

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

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

The description opens with a specific verb+resource ("列出自定义工具" / list custom tools) and the URL path confirms the exact endpoint. It clearly distinguishes this read/list operation from the sibling write operations (anon_post_custom_tools, anon_patch_custom_tools_tool_id, anon_delete_custom_tools_tool_id).

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 states who may access (project members) and that the project is auto-determined by the API key, which is useful context. However, it never explicitly routes the agent (e.g., "use post_custom_tools to create one"); the usage is only implied by the operation being a listing.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds real context beyond them: the membership/auth requirement and permission-based output trimming (summary.modules.finance is null without finance permission). That tells the agent why fields may be absent. It stops short of describing cost, caching, or the full module set returned.

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 purpose, then the prerequisite, then the permission-trimming behavior, then the endpoint and the projectId warning. Nearly every sentence carries information; the raw GET path line is the only mildly 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?

There is no output schema, so the description carries the return-shape burden and does partially deliver by naming summary.modules.finance and its null-on-no-permission behavior. Yet it leaves the aggregate contents and the distinction from anon_get_dashboard_summary unexplained, which an agent needs to choose 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 only parameter (nested query.scheduleDays, defaulting to the preferred scheduleRange with a max of 30) is never mentioned in the description, and the reported schema description coverage is 0%. With low coverage the description is expected to compensate and it does not.

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

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

States a specific verb and resource ('获取工作台聚合数据') plus the scope of the payload ('聚合首屏数据'), so an agent knows this returns a composed first-screen view. However it never distinguishes itself from the very close sibling anon_get_dashboard_summary, leaving overlap unresolved.

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 two useful conditions: project membership is required, and projectId must NOT be passed because the project is derived from the API key. But it offers no when-to-use guidance versus siblings such as get_dashboard_summary, get_dashboard_my_actions, get_dashboard_schedule or get_dashboard_preferences.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds valuable behavioral detail beyond that: the result set composition (assigned unfinished todos + unconfirmed onsite tasks) and the exact sort order (overdue first, then ascending dueAt, undated last). It stops short of describing the response shape, but ordering semantics is meaningful added context.

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

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

Front-loads the purpose, then constraints, then the endpoint path. The added 'no need to pass projectId' line is slightly redundant with the empty schema but earns its place by explaining scoping. Generally tight 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?

For a read-only, zero-parameter list endpoint with no output schema, the description covers content, ordering, and auth prerequisites adequately. It could be stronger by explicitly contrasting with the other dashboard/todos endpoints, 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?

With zero parameters, the baseline is 4. The description further clarifies that no projectId is needed because the project is derived from the current API key, which is exactly the kind of implicit-scoping detail that matters for a parameterless endpoint.

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 pair ('获取本人待行动项' – get my pending action items) and enumerates exactly what it returns: incomplete todos assigned to me plus unconfirmed onsite tasks. It does not name or distinguish itself from siblings like anon_get_dashboard or anon_get_dashboard_summary, so an agent must still infer which dashboard endpoint to pick.

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 a prerequisite ('需项目成员身份' – requires project membership), which is useful context. However there is no explicit statement of when to prefer this over anon_get_dashboard, anon_get_dashboard_summary, or anon_get_todos, so 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 readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely non-structural context: the project-member authorization requirement and the fallback semantics when no record exists (defaultView resolving to project/personal by permission), which an agent could not infer from the empty 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?

Three short lines: purpose first, then precondition/behavior, then the endpoint and the projectId note. Every sentence carries information and nothing is repeated from the schema or annotations.

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

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

For a zero-parameter, no-output-schema GET, the description covers the operation, the auth requirement, the default-value behavior, and the implicit project scoping. The only gap is that the shape of the returned preferences object is never hinted at, which matters slightly since no output schema exists.

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 the baseline is 4. The description goes slightly further by explaining that no projectId is needed because the project is inferred from the API key, preempting a likely agent mistake, but there are no other parameters to 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?

The description states a specific verb and resource ("获取工作台偏好") and pairs it with the concrete endpoint GET /api/projects/{id}/dashboard/preferences, so the operation is unambiguous. It is not confused with siblings like anon_get_dashboard_summary or anon_get_dashboard_my_actions, though it never explicitly contrasts itself with the PATCH counterpart or those dashboard reads.

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 a prerequisite ("需项目成员身份") and the context that the project is derived from the API key, which is useful for calling it correctly. However it never says when an agent should read these preferences rather than call anon_patch_dashboard_preferences to modify them, or when this is preferable to anon_get_dashboard_summary.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds two valuable non-structural facts: caller must be a project member, and the project is resolved automatically from the API key so no projectId is passed. Rate limits and return shape remain unstated.

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 clauses: purpose, auth requirement, endpoint/scope clarification. Every sentence carries information; only the raw endpoint string is arguably redundant with the tool name.

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

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

For a simple single-parameter read tool with annotations covering the safety profile and no output schema, the description covers purpose, auth, and the scoping rule. It could hint at what a "schedule group" contains, but nothing essential to correct invocation 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?

The only schema parameter (days, default 7, max 30) already carries its own description and constraints, so the schema does the heavy lifting. The description adds meaning only for the absent projectId (auto-determined), not for the days parameter. 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+resource ("获取日程分组") and includes the concrete endpoint GET /api/projects/{id}/dashboard/schedule. The schedule resource is distinguishable from dashboard siblings like anon_get_dashboard_summary and anon_get_dashboard_my_actions, though it never explicitly contrasts itself with them.

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

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

It gives a prerequisite ("需项目成员身份" – requires project member identity), which is real usage signal, but offers no when-to-use vs when-to-use-an-alternative guidance and no exclusions. 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 establish the safe-read profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description nonetheless adds two behavioral facts not in the annotations: a member-identity authorization requirement and that the project scope is auto-resolved from the API key rather than passed in.

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 lines: purpose first, then the access precondition, then the endpoint and the no-projectId clarification. Nothing is padded and every sentence 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 no-parameter, read-only tool whose safety profile is fully covered by annotations, the description supplies the key operational facts (auth requirement, implicit project scope). The only gap is that with no output schema it doesn't hint at what the 'summary' contains, but that is a minor omission.

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

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

There are zero parameters, so the baseline is 4. The description goes slightly beyond by explaining why none are needed (the project is inferred from the API key), which preempts an agent from searching for a projectId argument.

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 gives a specific verb+resource ('获取仪表盘汇总' / get dashboard summary) and pins the exact endpoint, so the agent knows what it does. However, it never distinguishes itself from the very close sibling anon_get_dashboard (or anon_get_dashboard_my_actions / anon_get_dashboard_schedule), leaving the agent to guess which dashboard endpoint to pick.

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 states a real usage precondition ('需项目成员身份' – requires project membership) and clarifies the project is derived from the API key, which is useful context. But it offers no explicit when-to-use/when-not guidance relative to the other dashboard-family tools, so selection remains 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 readOnly/idempotent/non-destructive, yet the description adds substantive behavior: role-based visibility (finance:manage / project:manage see everything, finance:add sees only their own entries with summary=null), descending creation-time ordering, and that the project is derived from the API key. This is exactly the extra context annotations cannot 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-loaded with the purpose, then permission semantics, ordering, endpoint, and the no-projectId note. Every sentence carries information, though the permission branch is dense and could be slightly tighter.

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

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

For a zero-param read tool with no output schema, the description covers authorization, role-dependent data visibility, the null-summary edge case, sort order, and the endpoint/project resolution. An agent has everything needed to call it and interpret the result 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 the baseline is 4. The description usefully clarifies that no projectId is needed because it is auto-determined from the API key, which prevents an agent from trying to supply it despite the path template.

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 transactions and summary) on a concrete endpoint, and the scope is explicit. It does not, however, differentiate itself from the very similar sibling anon_get_finance_export, so an agent must infer the boundary.

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 tells who may call it ("任一项目成员可用") and what different roles see, which implicitly sets usage context. It never states when to choose this over anon_get_finance_export or anon_post_finance, so no explicit when-to-use / when-not guidance is given.

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

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

The annotations already cover safety (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: the required finance:manage permission, the exact filter semantics for the target member, the response media type, UTF-8 BOM, Content-Disposition: attachment, and the full column list. It also clarifies that projectId must not be passed because the project derives from the API key — a non-obvious constraint.

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 dense but front-loaded, opening with the action and permission, then filter semantics, then response format. The column enumeration is long but pays for itself by telling the caller what the CSV will contain. No sentence is pure filler, though the endpoint/URL restatement is slightly 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?

With no output schema, the description compensates fully by specifying the response content type, encoding, disposition header, and exact columns. Permission needs, scoping rules, and the auto-derived project are all covered, so nothing an agent needs to call this correctly 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?

There is a single userId parameter whose schema description covers its default and membership requirement, but the tool description adds the crucial behavioral meaning of that parameter — it selects the member whose related ledger entries are exported (as payer or split participant). That is real semantic value beyond the schema's field-level text.

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

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

The description states a specific verb (导出/export) and resource (账目 CSV / finance ledger), and its scope ('导出目标成员相关账目') clearly distinguishes it from the sibling anon_get_finance, which is the non-export listing endpoint. An agent can identify the tool's job without opening the schema.

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

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

It gives concrete preconditions (需 finance:manage 权限) and defines exactly which entries are exported (payer, empty splitAmong, or member in splitAmong) plus the sort order, so the agent knows the situation this tool fits. It stops short of naming when to prefer it over anon_get_finance (JSON list vs CSV download), so it isn't a full when/when-not statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond restating the endpoint – it does not disclose the response shape (status code, body, uptime) or whether it requires auth, which is the only real value it could add.

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 lines, purpose front-loaded, zero waste. Nothing to trim.

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 parameterless probe whose safety profile is already carried by annotations and which has no output schema, the definition is essentially complete. It could optionally note what the health payload reports, but nothing required to invoke it correctly 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?

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. No parameter information is needed.

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

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

"健康检查" (health check) is a specific verb+resource that clearly identifies this as a service-availability probe, and the endpoint mapping (GET /api/health) reinforces it. It's distinguishable from the CRUD-heavy siblings at a glance, though it's terse and lacks any elaboration.

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

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

Usage is only implied by the name "health check" – an agent can reasonably infer it's for verifying service liveness, but there is no explicit when-to-use statement or contrast with any alternative diagnostic 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 already declare the safe read profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description still adds real behavior: results sorted by foundAt descending and capped at 200 records. It also notes the project is derived from the API key, which prevents the agent from inventing a projectId argument.

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

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

Front-loaded with the resource, access rule, ordering and row cap in the first sentence, followed by the endpoint and key-resolution note. Dense and efficient; the raw HTTP method/path line adds orientation value but is marginally redundant 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 no output schema and a low-complexity read endpoint, the description supplies the ordering and 200-row cap needed to reason about results, plus the auth/identity rule. It stops short of describing return fields, but for a list tool with read-only annotations that gap 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?

Top-level schema description coverage is 0%, and the description adds no explanation of the q or status filters, so it does not compensate for the coverage gap. It does add one useful parameter-adjacent fact — that projectId must NOT be supplied — though the nested q/status descriptions are left to carry filter 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?

States a concrete verb+resource: list lost-and-found items, matching the plural list endpoint as opposed to the singular anon_get_lostfound_item_id sibling. The plural-vs-singular resource is implied by the name rather than spelled out, so it does not fully differentiate from siblings in text, but the purpose is unambiguous.

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

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

Provides an access prerequisite ('project members can view') and implicitly scopes the call to the caller's own project via API key, but never states when to use this list endpoint versus anon_get_lostfound_item_id, anon_get_lostfound_share, or anon_post_lostfound. Usage context is implied, 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavioral facts: view permission is limited to project members, auth is via the current API key, and the project scope is inferred rather than passed. It does not describe error behavior for missing/nonexistent items.

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 lines: purpose, permission scope, endpoint plus scoping note. No filler, nothing repeated from structured fields.

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

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

For a single-parameter read tool with no output schema and full annotation coverage, the description supplies the access rule, the endpoint shape, and the project-scoping behavior an agent needs to call it correctly. Return payload details are not given, but that is acceptable given the tool's simplicity.

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 0% and the only parameter is a nested path.itemId, so the description must compensate. It does: the REST path template reveals itemId's role and explicitly states projectId is auto-resolved from the API key and must not be passed, preventing a common mistake.

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: retrieve a lost-and-found item's detail ('获取失物详情'), which cleanly differs from the sibling list tool anon_get_lostfound and the photo endpoint. It does not explicitly name those siblings to disambiguate, 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 access context ('项目成员可查看' – project members can view) but no explicit when-to-use or when-not-to-use guidance relative to anon_get_lostfound or anon_get_lostfound_item_id_photo. 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 cover read-only/idempotent/non-destructive, yet the description still adds real behavioral context: WebP preview is preferred over the original when available, a 404 is returned when no photo exists, and the project scope is derived from the API key rather than a parameter. These are return/error and auth-scope facts not in the annotations.

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

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

Front-loaded with the core purpose, then permission, return behavior, and scope note in compact form. No wasted sentences, though the raw route line and projectId caveat are somewhat procedural rather than essential.

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 1-parameter GET with annotations present and no output schema, the description covers the essentials: what is returned (WebP vs original), the 404 case, and auth/scope. Only the itemId semantics and response content-type remain 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 description coverage is 0% for the single itemId parameter, so the schema gives no semantics. The description partially compensates by embedding {itemId} in the route template and clarifying that projectId is not needed, but it never explains what itemId is or its format, leaving a real gap.

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 ('获取失物照片' / get the lost-found item's photo) and even gives the underlying route. It is clearly distinguishable from the sibling anon_get_lostfound_item_id (item detail) and anon_get_lostfound (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?

It gives a permission precondition ('项目成员可读' – readable by project members) which helps an agent know it is an authorized read, but it names no alternative or when-to-use/when-not condition relative to the sibling item/material preview tools. 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?

Reveals behavior well beyond the annotations: that this nominally read-only call lazily CREATES a share document, that the default state is enabled=false with a random token, and that repeated GETs return the same token (idempotent). It also gives the permission requirement and the public page URL format. This is exactly the kind of side-effect disclosure annotations cannot 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-loaded with purpose, then permission, then the lazy-creation caveat, then the endpoint. Every line adds information, though the raw 'GET /api/projects/{id}/lostfound/share' line is somewhat redundant against the tool name.

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

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

For a no-param GET with no output schema, the description covers the permission gate, the side effect, the token stability guarantee, and what the public URL looks like - everything an agent needs to call and interpret it 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?

Zero parameters, so the baseline is 4. The description usefully clarifies that no projectId should be passed because the project is derived from the current API key, preventing an agent from inventing a parameter.

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

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

States a specific verb+resource: retrieve the lost-and-found public share info. The GET verb and '获取...分享信息' clearly distinguishes it from the sibling anon_put_lostfound_share, though it doesn't name that sibling explicitly. An agent can tell what it returns (share config + token).

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?

Discloses the required 'lostfound:manage' permission, which is useful usage context. However it never states when to call this versus anon_put_lostfound_share (which mutates the same share config) or anon_get_lostfound, leaving selection to be inferred from the verb.

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 readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuinely non-structured context: callers must be project members, results are scoped by visibility (which overrides permission points), and the project is auto-derived from the API key so projectId must not be passed. That is real behavioral value beyond the annotations.

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

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

Three tight sentences/segments with the purpose front-loaded, followed by access constraint and the endpoint. No filler, though the embedded HTTP path is somewhat redundant with the tool name.

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

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

For a read-only list tool whose annotations carry the safety profile and which has no output schema, the description covers permissions, scope semantics, and project auto-detection adequately. It still omits pagination/result-set limits and any guidance on the optional type filter, so it is only minimally 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 reported at 0% for the single optional query parameter, so the description is expected to compensate. It says nothing about the query object or its typeId filter (resources by type), leaving the only input entirely unelaborated in the prose.

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 ('列出资源' = list materials) and gives the underlying endpoint GET /api/projects/{id}/materials. It is clearly distinguishable from the singular anon_get_materials_resource_id and the type-listing anon_get_materials_types, though it never names those siblings 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?

Adds an access condition ('项目成员可用') and a scoping rule (only visible-scope resources are returned, visible scope outranks permission points), which orients the agent. However, it never states when to prefer this tool over siblings like anon_get_materials_resource_id for a single item, so usage remains 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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds genuinely non-structured behavior: the membership requirement, the exact 403 failure mode under visibility filtering, and the fact that project scope is derived from the API key. It stops short of describing the returned payload 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?

Front-loads the purpose, then access/error behavior, then the endpoint and the projectId note. Four compact clauses with no filler; the raw endpoint string is the only mildly 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 read-only single-resource fetch with no output schema, the description covers what an agent must know to call it and what failure to expect (403). The main omission is any hint of what the response contains, which is acceptable absent an output schema but would help.

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

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

Schema description coverage is 0% for the single nested resourceId parameter, and the description does not define its format. It does add one meaningful parameter clarifier — that projectId must NOT be supplied because the project is resolved from the API key — which compensates partly but leaves resourceId semantics to inference.

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 resource detail) and grounds it with the concrete endpoint GET /api/projects/{id}/materials/{resourceId}. It is distinguishable from the list tool (anon_get_materials) and the preview/versions siblings by being the single-resource detail fetch, though it never names those alternatives 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?

Gives real access context — project members may call it, and a 403 is returned when the resource is filtered out by visibility scope — but provides no explicit when-to-use guidance versus anon_get_materials_resource_id_preview or anon_get_materials_resource_id_versions. Usage is implied by the resource-detail framing 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: the auth/visibility requirement, the content-negotiation outcome (image/webp when a thumbnail exists, raw stream for whitelisted inline MIME types, 404 otherwise). That tells the agent exactly what it will get back and when it fails.

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

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

Front-loaded with the action and the fallback chain, then auth, then the route. Every clause carries information. The raw 'GET /api/projects/...' line is the one mildly redundant element given the tool name already encodes the path.

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, and the description fully compensates by enumerating the three possible response outcomes and the 404 case. Combined with the stated authorization precondition, an agent has everything needed to call and interpret the result.

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

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

Schema coverage is 0% for the single nested resourceId parameter, so the description must carry the load. It clarifies that the project is derived from the API key and that projectId must not be passed — useful — but gives no format or semantics for resourceId itself beyond the URL template. Partial compensation only.

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: 'preview the latest version of a resource'. The 'latest version' scoping distinguishes it from the sibling anon_get_materials_resource_id_versions_version_preview, which targets a specified version. An agent can select correctly without opening the schema.

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

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

Gives clear usage conditions: project membership plus visibility-scope check, and 'takes the latest version' which implicitly routes away from the version-specific preview sibling. It never explicitly names that alternative or states exclusions, so it stops short of a 5.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds real context beyond them: the visibility/auth precondition, the descending-version-number sort order, and the fact that the project is derived from the API key. Sort order and the auto-scoped project are non-obvious behaviors not encoded 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?

Front-loaded with the action word, then constraints in terse fragments with no filler. Every sentence carries information; the endpoint line is the only mildly redundant element given the name already encodes the path.

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, and the description compensates by stating the ordering of returned versions and the auth/visibility gate. Missing pagination behavior and any return-field detail keeps it from full completeness, but it covers what an agent needs to invoke it 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?

One parameter at 0% schema description coverage; the description clarifies the project need not be passed (it comes from the API key), which is useful negative guidance. But it never explains the single path.resourceId parameter's meaning or format, so the schema's only parameter remains semantically thin.

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 versions) and pins the exact endpoint, making it distinguishable from the write sibling anon_post_materials_resource_id_versions and the download/preview variants. It does not explicitly name those siblings, so it stops short of the top mark.

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 a prerequisite ('项目成员且通过可见范围校验' – must be a project member passing visibility scope), which is genuine usage context. However it never states when to prefer this over the version_download or version_preview siblings, leaving the choice implicit.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the response is served as an attachment via Content-Disposition, and access is gated on project membership plus visibility scope. It does not cover error or missing-file behavior, which keeps this from 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?

Front-loads the action ('下载指定版本原文件') and then layers access, response, and endpoint details in short clauses. The raw HTTP path is somewhat redundant with the tool name but is compact and harmless.

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 explains what the caller receives (a downloadable attachment) and what authorization is required, plus the implicit project scoping. Only failure modes and any pagination/size limits are unaddressed, which is a minor gap for a download endpoint.

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

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

The schema has 0% description coverage and a nested path object, so the description must compensate. It clarifies that resourceId identifies the material and version selects the version, and that no projectId is required, but it adds no format, bounds, or validation detail beyond what the schema implies.

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: download the original file for a specified material version ('下载指定版本原文件'), which is enough to separate it from the preview siblings by the word '原文件'. It does not name those siblings, so an agent must infer the download-vs-preview distinction, but the purpose itself 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?

Gives an access prerequisite ('项目成员且通过可见范围校验') and notes the project is derived from the API key, so no projectId is needed. However, it never states when to prefer this tool over anon_get_materials_resource_id_versions_version_preview or anon_get_materials_resource_id_versions, leaving the choice implied rather than 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?

Annotations already declare this read-only, idempotent, non-destructive. The description adds real behavioral detail beyond that: the different response media types, the inline mime whitelist, and the 404 fallback. It omits actual size limits and whether thumbnails are generated on demand.

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 purpose, then the three response branches, then the path and implicit project note. Dense but every sentence carries distinct information; the raw endpoint line is slightly 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?

For a single-param read tool with no output schema, it covers what an agent needs: the permission gate, the implicit project, and the three possible responses. Missing only numeric limits for inline previews and thumbnail availability.

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 0%, but schema descriptions carry no param info; the description supplies meaningful semantics anyway: the project is inferred from the API key, which is genuinely non-obvious. It does not explain resourceId or version formats, so it only partly compensates for the coverage gap.

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: previews a version of a material resource, with the content-type outcome spelled out. It does not name siblings like anon_get_materials_resource_id_versions_version_download, but the endpoint line disambiguates the operation.

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?

Explains the resolution logic (thumbnail vs inline whitelist vs 404) and states the permission gate, so the agent knows when a 404 is expected. It never points to the sibling download endpoint as the alternative for non-previewable files.

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 readOnly, idempotent and non-destructive, but the description adds real behavioral context beyond them: results are filtered to the caller's visible scope (仅返回可见范围内的类型) and the project is auto-derived from the API key. That visibility-filtering and auth detail is genuinely useful.

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 lines, front-loaded with the purpose followed by the endpoint and the projectId clarification. Every line carries information; minimal waste.

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

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

For a zero-parameter read-only list tool with no output schema, the description covers purpose, access scope, visibility filtering, and project resolution. Return shape is unspecified, but nothing critical to invoking it correctly 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?

The tool takes zero parameters, so the baseline is 4. The description usefully confirms no projectId is required because it is inferred from the API key, which preempts a likely agent assumption.

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 material types) and names the exact endpoint, so an agent can tell it apart from anon_get_materials (which lists resources) and anon_post_materials_types. It does not explicitly name a sibling, so it falls short of full 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?

Gives an access condition (项目成员可用 - available to project members) but offers no when-to-use vs alternatives guidance and never mentions the related type-management tools. 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-obvious behaviour on top: the project-membership auth requirement, the automatic API-key-based scoping (no projectId), and the date-ascending sort order.

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?

Very compact and front-loaded: the operation is named first, then constraints. The endpoint line is mildly redundant with the name but still useful for resource identification. Little waste overall.

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

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

For a simple list tool with no output schema, the description covers access, scope, and ordering, which is most of what an agent needs. It does not describe the shape of a returned milestone, and the purpose of the from/to filters 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?

Reported schema description coverage is 0%, though the nested from/to properties do carry inline descriptions in the schema. The description itself adds nothing about the from/to date filtering, only clarifying that projectId is intentionally absent, so it only partially compensates.

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

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

The description states a specific verb+resource (列出里程碑 / list milestones) and the underlying endpoint, so an agent immediately knows this is a read-list operation. It is distinguishable from siblings like anon_post_milestones and anon_patch_milestones_milestone_id, though it never names them 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?

It supplies a useful prerequisite (需项目成员身份) and clarifies that the project scope is derived from the API key rather than a parameter, which heads off a likely agent error. However, it gives no explicit guidance on when to prefer this over sibling milestone tools or any 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 declare readOnly/idempotent/safe, and the description adds substantial behavioral context: incident visibility is permission-gated (work:manage vs. normal members), infections, rundown windows (±24h, ≤5), emergency items capped at ≤5, and myPermissions driving frontend visibility. This goes well beyond the annotations.

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

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

The description front-loads the purpose and systematically describes each aggregate section, but it is long and dense, mixing many sub-fields in one paragraph. It earns its place given the tool's complexity, though it could be more scannable.

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 and a zero-param interface, the description must carry the full burden of explaining the aggregate shape, which it does by enumerating myModules, emergency, contacts, incidents, rundowns, and myPermissions. Minor gaps remain around response format and ordering, but it is largely complete for 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?

No parameters and schema coverage is 100%, so baseline is 4. The description explicitly notes the project is determined by the API key and no projectId is needed, which is useful added context despite the zero-param schema.

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

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

The description clearly states this is an aggregate endpoint for '现场模式' (onsite mode) scoped to project members, with a GET path. It distinguishes itself from siblings like anon_get_onsite_incidents by aggregating multiple sub-resources, though the exact meaning of '现场模式' is assumed rather than defined.

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

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

The description implies usage (aggregating onsite data) but gives no explicit when-to-use versus alternatives such as anon_get_onsite_incidents or anon_get_dashboard. The permission-based filtering of incidents and rundowns hints at behavioral expectations, but no guidance distinguishes this tool from other aggregate endpoints.

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 safety (readOnly, idempotent, non-destructive). The description adds genuinely useful behavior beyond them: permission-scoped visibility, reverse-chronological ordering, and a hard 50-item cap — critical for interpreting results. It stops short of pagination details, so not 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?

Front-loads the action, then permission scope, ordering, limit, endpoint, and the no-projectId note. Every sentence 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?

For a zero-param, annotation-backed read tool with no output schema, the description covers purpose, permissions, ordering, limit, and auth source. A note on response shape or pagination would make it fully complete, but nothing essential is missing to call it 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?

Zero parameters, so the baseline is 4. The description adds important context beyond the empty schema by explaining that the project is inferred from the current API key (no projectId needed) and by documenting the endpoint path.

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 (列出现场异常 = list onsite incidents) and clearly distinguishes the sibling family: there is anon_get_onsite (onsite overview) versus this incidents list, plus anon_post_onsite_incidents for creation. The purpose is unmistakable.

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?

Discloses permission-based visibility (work:manage/project:manage see all, ordinary members see only their own reports) and the ordering/limit, which tells the agent when the result may be incomplete relative to a manager's view. It doesn't explicitly name alternative tools, but the visibility caveat is real usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the API-key auth requirement and the non-obvious semantics of the returned 'permissions' field (intersection of key scopes and the holder's real-time role 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 clauses, front-loaded with the purpose, followed by the auth precondition and the permissions semantics. No filler, and the endpoint string is compact context.

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 burden of describing the return. It explains the permissions field but does not indicate what else the identity payload contains (e.g., key name, owner, role), leaving the response shape only partially characterized for a read tool.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing further the description could add on parameter semantics.

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

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

The description gives a specific verb and resource in Chinese: '查看当前 API 密钥身份' (view the current API key identity), which is a self-distinguishing purpose among mostly resource-scoped get_* siblings. It does not explicitly contrast itself with any alternative tool, 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?

It states the precondition '需 API 密钥调用' (requires an API key to call), which is real usage context. However, it gives no when-to-use/when-not guidance or routing relative to sibling endpoints like anon_get_accounts or anon_get_project, so 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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds genuinely non-obvious behavior: ascending 'order' sort, and that the first call lazily seeds six default categories when none exist. This seeding is the most important thing an agent should know and is not derivable from annotations or schema. It stops short of covering error/auth-failure behavior or return characteristics, hence not 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?

Purpose is front-loaded, followed by the two behavioral facts that matter (ordering, seeding); the parenthetical list of default categories is informative and compact. The raw endpoint line 'GET /api/projects/{id}/physical/categories' is largely redundant for MCP invocation and is the only wasted 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?

No output schema exists, and the description covers ordering and lazy-seeding well, but it never describes the shape of the returned categories (id/name/order) that a caller would likely need to feed into anon_delete_physical_categories_cat_id or the patch/reorder tools. For a 0-param read tool this is a minor but real 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?

With zero parameters, the baseline is 4, and the description earns it by explaining why: the project is auto-resolved from the current API key, so no projectId is needed. That clarifies the implicit invocation context that the empty schema cannot express. It does not describe how the implicit project scope could be overridden, so it stays at 4 rather than 5.

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 opening sentence states a specific verb+resource: '列出实物分类' (list physical categories). The resource noun is precise enough to distinguish it from siblings such as anon_get_physical_items (items, not categories), anon_post_physical_categories (create), and anon_patch_physical_categories_reorder/patch/delete — an agent can route correctly without opening any schema.

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

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

'项目成员可用' tells the agent the access condition (project members), which is useful context. However, there is no explicit when-to-use vs. when-not-to-use guidance and no named alternative (e.g., 'use get_physical_items for individual items'); usage is only implied by the resource 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 already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real value with the auth/scoping note that the project is derived from the API key and no projectId is needed. It says nothing about pagination or result limits, which is a gap for a list 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?

Three short lines, front-loaded with purpose, then access, then the filter list. The raw endpoint path is slightly redundant but not wasteful enough to harm the structure.

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 annotation coverage and no output schema, the description covers purpose, access, filters and the API-key scoping rule, which is the main thing an agent could get wrong (passing projectId). Only pagination/result-shape guidance is absent, 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?

Reported schema description coverage is 0% at the top level, so the description must carry weight; it does enumerate the filter/sort dimensions (category, status, responsible, tag) matching the nested query fields. However it adds no syntax, multi-value, or default details beyond the field names the schema already lists.

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 physical items) and names the filterable dimensions, which distinguishes it from siblings like anon_get_physical_summary and anon_get_physical_items_item_id. It does not explicitly name those siblings, so the differentiation is implicit rather than stated.

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 an access precondition and the supported filters imply the read/query use case, but there is no explicit when-to-use versus alternatives (e.g. summary vs. single item vs. categories). Usage is inferable but not spelled out.

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 readOnly/idempotent/non-destructive/openWorld, but the description adds genuine behavioral context beyond them: the auth requirement (project members only), the failure mode (404 on cross-project access), and the fact that the project is resolved from the API key and must not be passed. These are non-obvious operational facts.

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 lines: purpose, access/error semantics, then the endpoint and project-resolution note. Little waste, though the raw endpoint line partially duplicates information an agent can infer from the name.

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

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

With no output schema, the description should say something about what the returned item contains; it is silent on return shape. It does cover access, error behavior, and parameter context, so it is adequate but not complete for a get-by-id tool.

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

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

Schema description coverage is 0% and the single nested itemId parameter is undocumented in the schema, so the description carries the burden. It usefully clarifies what is NOT a parameter (projectId is derived from the API key) but never explains the itemId itself or its format. Partial compensation only.

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 (获取物资条目) and pins it to the concrete endpoint GET /api/projects/{id}/physical/items/{itemId}, which implicitly distinguishes single-item retrieval from the list sibling anon_get_physical_items. It does not name a sibling 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?

Provides useful context — available to project members, cross-project access returns 404 — which tells the agent when the call will succeed. However, it never states when to prefer this over anon_get_physical_items or the logs sibling; routing is left to inference from the path.

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 readOnly/idempotent/non-destructive/openWorld, so safety is covered; the description adds genuinely new behavioral context: reverse-chronological ordering, a hard cap of 100 entries, and the implicit-auth model. It stops short of 5 because it does not explain what happens beyond the 100-entry limit or 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?

Front-loads the purpose, then stacks permission, ordering, limit, endpoint, and the auth clarification in terse sentences with zero padding. Ideal for a list endpoint.

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 whose annotations already cover the safety profile and which has no output schema, the description supplies ordering, result cap, and auth context. Remaining gaps (pagination beyond 100, return shape) are minor but real.

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

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

Schema description coverage is 0% for the single itemId parameter, so the description must carry the burden. It helpfully clarifies that no projectId is required (auto-derived from the API key), but never explains what itemId refers to or its format, leaving the one real parameter only implicitly defined.

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 (物资变动日志/physical item change logs) scoped to a single item, which an agent can distinguish from the sibling anon_post_physical_items_item_id_log (which writes logs). It does not explicitly name the sibling to avoid, 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?

Adds a prerequisite ("项目成员可用" – available to project members) and clarifies that the project is derived from the API key rather than passed in. However it gives no explicit when-to-use guidance or comparison against alternatives such as anon_get_physical_items or the log-creation sibling, leaving usage 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful context beyond them: the return shape (totals + per-category aggregation) and the auth fact that the project is derived from the API key, so no projectId is needed.

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

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

Front-loaded with the purpose and return content, followed by a compact permission note and endpoint/auth line. The GET path is somewhat redundant technical noise but the text is otherwise tight and waste-free.

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

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

For a zero-parameter read-only summary with no output schema, the description explains the return contents (totals plus aggregated category metrics) and the auth model, which is enough for an agent to call it correctly. Slightly more detail on the aggregation granularity would complete it.

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?

Zero parameters, so the baseline is 4. The description also preempts a likely confusion by explaining that projectId is not required because the project is inferred from the API key, adding meaning over the (empty) 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?

Names a specific verb+resource ('实物清单汇总' / physical inventory summary) and states the exact aggregate output (totals plus per-category planned/in-stock/in-use/loss/item counts), which cleanly distinguishes it from sibling list tools like anon_get_physical_items and anon_get_physical_categories.

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 states the prerequisite that project members may use it ('项目成员可用'), which implies usage context, but it never explicitly says when to choose this summary over anon_get_physical_items or anon_get_physical_categories, nor any exclusions. 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 readOnly/idempotent/non-destructive and openWorld, so safety is covered. The description adds real value beyond that: authorization rules, the super-admin myRole value (「超级管理员」), and the fact that the target project is implicitly resolved. It stops short of describing the returned payload beyond that one field.

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?

Short and front-loaded: purpose first, then access rules, then the implicit-parameter note. The embedded 'GET /api/projects/{id}' restates the route and is mildly redundant, but it is brief and does no real harm.

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 no-param, read-only detail endpoint with annotations covering the safety profile and no output schema, the description supplies the essentials: what it returns in general, who can call it, and how the target is determined. Only the shape of the returned project object is left unspecified.

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

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

With zero parameters, the baseline is 4. The description actually earns it by explaining the missing projectId is deliberate — the project comes from the current API key — which resolves why the schema is empty rather than leaving it unexplained.

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 is the only project-detail getter among a large sibling set dominated by stage/todo/material/finance operations. It also preempts the biggest ambiguity by noting the project is derived from the API key, so an agent knows this needs no identifier.

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 a concrete access precondition (project members or super admins), which is genuinely useful guidance. However, it never states when to prefer this over related reads like anon_get_open_me or the mutation sibling anon_patch_project, so 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds real context beyond that: a membership/auth requirement, the status filter (only active and ignored surfaces), and the ordering rules (critical→warning→info, then most-recent detection).

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?

Purpose is front-loaded and the following sentences are compact and informative. The raw endpoint line (GET /api/projects/{id}/risks) is somewhat redundant given the surrounding prose, but it is a minor addition rather than 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 parameters, no output schema, and annotations covering the safety profile, the description supplies the remaining essentials: the returned status set, sort order, and auth requirement. It stops short of describing pagination or result shape, but that gap is limited for a zero-arg 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?

Zero parameters means the baseline is 4. The description reinforces this by explaining that the project is derived from the API key and no projectId should be passed, which meaningfully clarifies the absence of parameters rather than leaving it ambiguous.

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

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

The description clearly states the specific verb+resource (列出风险预警 / list risk warnings) and adds filter and sort semantics. It is distinguishable from the risk mutation siblings (evaluate/ignore/restore) by operation, but it never names an alternative, so the sibling differentiation is implicit 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?

It gives a prerequisite (需项目成员身份) and states what is returned (only active/ignored), which implies how to use it, but it never says when to choose this over anon_post_risks_evaluate or the ignore/restore tools. Usage is implied, 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds behavioral context beyond them: ascending sort by startAt/createdAt, the meaning of totalDurationMin, and that the project is auto-resolved from the API key so no projectId is needed.

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

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

Front-loaded with the core action, followed by scoping and field notes; every sentence carries information. Slightly dense with endpoint/field detail but no padding.

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

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

For a zero-param listing tool with readOnly annotations and no output schema, the description supplies permission, sort order, and a key field definition, which is largely sufficient. Return-shape detail is thin but acceptable given no output schema.

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

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

With zero parameters the baseline is 4. The description usefully explains why there are none, noting the project is automatically determined by the current API key, which preempts an agent hunting for a projectId parameter.

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

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

States a specific verb and resource ('列出 Rundown' / list Rundowns) and even names the endpoint. It is distinguishable from the sibling anon_get_stage_rundowns_rid in that this returns the collection, though it does not explicitly contrast 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?

Provides a permission condition ('项目成员可查看') but gives no explicit when-to-use guidance or comparison against the sibling list/get tools. Usage is only implied by the list semantics and the note about multiple rundowns per project.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real behavior beyond them: attachments are parsed into StageRundownAttachment, missing file ids are skipped, and cross-project rids return 404. It does not describe pagination or payload size, so not 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?

Purpose is front-loaded in the first clause, followed by tightly packed constraints (permissions, attachment handling, 404 rule, auth scoping). The embedded HTTP route line is slightly redundant but low-cost.

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 single-resource tool with no output schema, the description covers auth scoping, permission requirements, attachment processing, and error semantics well. Only the response shape (fields returned) is left implicit, which is acceptable given no output schema.

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

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

With 0% schema description coverage on the single nested 'rid' param, the description must compensate, and it does: it clarifies that rid is project-scoped, that cross-project rids 404, and that projectId is derived from the API key. It omits the rid's expected format, keeping it below 5.

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 (获取 Rundown 详情 = get Rundown details), which cleanly separates it from the list sibling anon_get_stage_rundowns by implying single-item retrieval. It does not explicitly name the sibling, so it falls 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?

Provides a precondition ('项目成员可查看' – project members can view) and an edge-case rule (cross-project rid → 404), but never states when to use this vs anon_get_stage_rundowns or the patch/delete variants. Usage is implied rather than spelled out.

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

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

The description discloses an important side effect: the GET 'lazily creates the share document' (惰性创建分享文档后返回, initial enabled=false). That is a write to the environment, which directly contradicts the annotation readOnlyHint=true. Per the contradiction rule this is scored 1 and flagged.

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?

Dense and front-loaded: purpose, permission requirement, behavioral note, endpoint, and scoping note in order. Every sentence carries information; slightly fragmented by mixing Chinese prose with a raw endpoint line.

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, so the description should explain what is returned. It does reveal one key return value (initial enabled=false) and the permission requirement, but omits the rest of the share payload (e.g. link/token fields) an agent would need. Adequate but incomplete for a read-with-side-effect tool.

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

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

Schema description coverage is 0% and there is one nested 'rid' parameter, so the description must compensate. It adds meaningful path semantics (placing rid in the URL and stating the project is inferred from the API key, so no projectId is needed), but never explains what rid itself is. Partial compensation only.

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 ('获取大屏分享信息' / get screen-share info) and even pins the exact endpoint GET /api/projects/{id}/stage-rundowns/{rid}/screen-share. This clearly distinguishes it from the PUT sibling anon_put_stage_rundowns_rid_screen_share, though it never names that 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?

Provides a real prerequisite ('需 tools:manage 权限') and clarifies scoping ('项目由当前 API 密钥自动确定，无需传 projectId'), which is useful context. However it gives no when-to-use vs. alternatives guidance, e.g. it never points to the PUT sibling for enabling the share. 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 cover readOnly/idempotent/non-destructive safety, and the description adds real behavioral context beyond them: member-only access, stages sorted by ascending order, and the meaning of currentStageIndex (-1 when all complete). It also clarifies that the project is resolved from the API key, so no projectId is required.

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 content is dense and front-loaded: purpose, access, return semantics, then endpoint. The explicit 'GET /api/projects/{id}/stages' line is mildly redundant with the tool name but confirms the path; otherwise every sentence carries weight.

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 documenting the key return semantics (ordering and currentStageIndex). Combined with the access note and zero-parameter clarification, an agent has what it needs, though not every returned field is described.

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?

Zero parameters, so the baseline is 4. The description reinforces this by explaining that the project is auto-determined by the API key and no projectId should be passed, which prevents a caller from inventing a parameter.

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

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

States a specific verb and resource ('列出项目阶段' / list project stages), which is clearly distinguishable from siblings like anon_get_stage_signups or anon_get_stage_rundowns. It does not explicitly contrast itself with those siblings, 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?

'项目成员可访问' gives an access precondition, which is useful context. However there is no explicit when-to-use guidance or routing to alternatives such as anon_get_project or anon_get_stage_signups, leaving usage 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real context beyond that: sort order (startAt, createdAt ascending), member-level access, and that the project is derived from the API key rather than passed.

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 tight sentences, front-loaded with the action and scope before the endpoint and auth detail. No wasted prose, though the raw endpoint restates what the tool name already conveys.

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

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

For a zero-param read tool with full annotation coverage and no output schema, the description covers access, ordering, and scoping. It stops short of describing the returned batch structure, which is the only notable 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?

Zero parameters, so the baseline is 4. The description usefully explains the absence of a projectId by stating the project is auto-resolved from the current API key, removing ambiguity about how scoping works.

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 signup batches), with a concrete endpoint. This clearly distinguishes it from the singular sibling anon_get_stage_signups_sid, though it never names that 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?

'项目成员可查看' implies who may call it and hints at list-level usage, but it gives no explicit when-to-use or when-to-prefer-_sid guidance. 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 readOnly, idempotent, non-destructive and openWorld. The description adds genuinely new context beyond them: the project is auto-derived from the API key, so no projectId is required, and view permission is restricted to project members. It does not describe the returned detail shape, but with annotations covering the safety profile this is solid added value.

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

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

Front-loaded purpose in the first phrase, followed by permission, endpoint, and the projectId clarification. Efficient with little waste, though the raw endpoint path is somewhat redundant/noisy relative to the rest.

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 detail fetch whose safety profile is fully covered by annotations, the description covers purpose, permission, and auth routing. There is no output schema, so one could wish for a hint about what "details" contains, but nothing needed to invoke it correctly 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?

With 0% schema description coverage on a single required nested path param (sid), the description carries the burden. It clarifies the auth routing (no projectId needed) but never explains what sid identifies or its format; the meaning of sid is only inferable from the tool name. Adequate but not compensating for the coverage gap.

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 ("获取报名批次详情" / get signup batch details), with "详情" implying the single-item view and thereby distinguishing it in spirit from the sibling list tool anon_get_stage_signups. The explicit GET route reinforces that this retrieves one batch. It stops short of naming the sibling it is not, so not 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 an access condition (project members may view), which is useful context. However, it gives no explicit when-to-use vs the sibling anon_get_stage_signups (list) or when-not, leaving the agent to infer that this is for a single batch by sid.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful operational context: project-membership authorization and the fact that projectId is inferred from the API key, which prevents the agent from inventing a projectId argument. Pagination and result shape remain unstated.

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 lines, front-loaded with what the tool does, then prerequisites, capabilities, and the endpoint/auto-project note. No redundant filler; every sentence 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 read-only list tool with no output schema, the description covers purpose, auth requirement, filter/sort capability, and the auto-determined project scope. Missing pagination/limits and default sorting behavior, but nothing critical to correct invocation is 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?

The description summarizes the available filter/sort dimensions (category, assignee, status, sort), reinforcing what the schema's nested properties expose and signaling that these are optional query modifiers. It does not spell out the 'order' direction argument, so it stops short of full coverage.

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 (待办/todos) and even names the backing endpoint, so an agent can distinguish it from write siblings like anon_post_todos or anon_patch_todos_todo_id. The scope (list, with filter/sort) 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?

Gives the prerequisite ('需项目成员身份') and the supported operations (filter/sort), which tells the agent when this tool applies. However, it names no alternative (e.g., anon_get_todos_template_export) nor any exclusion condition, so routing among siblings is left 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the membership/auth requirement, which is real added context, but the offset definition ("offset = 原时间字段 − 项目锚点时间") reads like template/field semantics and is not clearly tied to this zero-parameter GET, adding ambiguity rather than clarity.

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 short and front-loads the purpose, then the auth requirement, then the endpoint. The offset sentence is of questionable relevance for a parameterless export and could be trimmed, but the overall structure is tight.

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, zero-parameter export with no output schema, the description adequately covers purpose, auth requirement, and the fact that the project is inferred from the API key. The main gap is not describing the export's format/contents, but annotations and simplicity keep this acceptable.

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 (empty schema, no required fields), so per calibration the baseline is 4. The description's offset formula does not correspond to any input parameter, so it neither helps nor meaningfully harms parameter understanding.

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

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

The description states a specific verb+resource ("导出待办模板" / export todo template) and clarifies that the project is auto-determined by the API key, which distinguishes it from tools that take an id. However, it never names its natural counterpart anon_post_todos_template_import, so sibling differentiation 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?

It gives a prerequisite ("需项目成员身份" / requires project membership) and states that no projectId needs to be passed, which is genuinely useful. But there is no explicit when-to-use vs. when-not guidance and no reference to the import sibling that would complete the export/import pairing.

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

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

The annotations already declare a safe read (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description still adds real context: deterministic ascending-by-creation-time ordering, the project-membership auth requirement, and the fact that the project is derived from the API key rather than passed in.

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?

Short and front-loaded with the list action, scope, ordering, and auth prerequisite. The opening 列出任务模块 slightly restates what the next sentence says more fully, but the endpoint path line is genuinely informative and nothing is padded.

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 parameterless read with no output schema, the description covers what is returned (all on-site task modules), the ordering, the auth requirement, and the implicit-project resolution. Nothing an agent needs to invoke it correctly 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?

With zero parameters the baseline is 4, and the description adds meaningful value by explaining that no projectId is needed because the project is auto-resolved from the API key – directly addressing the absence of any parameter in the empty 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 (现场任务模块) with the ordering scope (按创建时间升序) and endpoint path. It is clear on its own, but it never distinguishes itself from closely named siblings like anon_get_work_sheet, anon_post_work_modules, or anon_patch_work_modules_mid, so sibling 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?

The permission prerequisite (需项目成员身份) is a useful usage condition, but there is no explicit when-to-use guidance, no statement of when not to use it, and no named alternative among the many work-module/get siblings. Usage is only implied by the resource 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 already cover safety (readOnly, idempotent, non-destructive), but the description adds real behavioral detail beyond them: items are ordered ascending by startAt then createdAt, and an empty array is returned when there are no assignments. It also disambiguates the endpoint path and states the project is resolved from the API key rather than a parameter.

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

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

Front-loaded with the purpose, then ordering/empty-array semantics, then the endpoint and auth note. Information-dense and short, with only mild overlap between the first two sentences ('view own work sheet' repeated as 'own onsite work sheet').

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 compensates by describing the returned items (sort order, empty-array case), and it clarifies the auth model. For a zero-parameter read tool this is nearly complete; it could still name the user_id sibling to fully close the selection gap.

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

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

The tool takes zero parameters, so parameter semantics carry no burden and the baseline is 4. The description usefully reinforces this by explaining that projectId must not be passed because the project is derived from the current API key.

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 ('查看本人任务单' / view one's own work sheet) and scopes it to the '本人' (self) case, which implicitly separates it from the sibling anon_get_work_sheet_user_id. It never explicitly names that sibling, so the differentiation is inferable rather than stated.

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 establishes context (viewing one's own onsite work sheet as a project member, project inferred from the API key) but gives no explicit when-to-use rule or contrast with the user_id variant that appears in the sibling list. The agent must infer which of the two work-sheet tools to pick.

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