2ools

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

The description discloses what the tool does not do: 'does not read or import local files and does not start work or a build.' This clarifies side effects and non-actions, complementing the annotations (idempotent, non-destructive).

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 concise, two sentences, with no unnecessary words. It is well-structured and focused on the essential information.

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

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

The description gives enough context: what it does, when to call, and what it avoids. Since no output schema is provided, explaining return values is not required. The description is complete for the tool's intended use.

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

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

The schema already provides full descriptions for both parameters (project_id and approval). The description adds context about the one-time choice but does not significantly enhance parameter understanding beyond the schema coverage, so baseline 3 is appropriate.

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

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

The description clearly states the tool records a one-time choice to use a client with a specific project. It uses a specific verb ('Record') and resource ('choice'), distinguishing it from sibling tools like listing or updating projects.

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 explicit guidance on when to call: 'Call only after the person approves in the inline card or explicitly in chat.' This gives a clear condition and prerequisite, effectively guiding usage.

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 idempotentHint=true and destructiveHint=true, but the description adds that every action is 'revision checked' and that cancellation requires explicit confirmation. This goes beyond the annotations by providing operational context on safety and prerequisites. No contradiction with annotations; it reinforces and extends them.

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

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

The description is two sentences, front-loaded with the most critical constraint (app-only, hidden from the model) and then behavioral notes. It is concise and uses words efficiently, though it omits essential detail. It earns a 4 for structure, not 5 because it sacrifices clarity for brevity.

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

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

Despite the rich oneOf schema with three distinct action types and several required fields, the description does not explain any of them. There is no output schema, so the agent has no idea what the tool returns. While the 'hidden from the model' note might imply the agent shouldn't call it, the definition is still expected to be self-contained. The missing explanations of actions and parameters make it incomplete for any agent that might need to use 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?

Schema description coverage is 0%, and the description provides absolutely no information about the 'project_id' or 'change' parameters, nor the underlying action variants, expected_revision, idempotency_key, or confirm fields. The schema itself has no descriptions, so the agent has no assistance in understanding parameter semantics. The description fails to compensate for the total lack of schema 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?

The description states it's an app-only route for an authenticated person's explicit click in the native Project OS panel, and that it acts on a task (implied by name/title). However, it doesn't enumerate the concrete actions (answer, park, continue, cancel) that the schema defines, nor does it specify the resource being acted upon beyond the generic 'task'. It's clear in context but lacks precision in defining the operational scope.

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

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

The description explicitly says 'Hidden from the model', which is a direct instruction that the model should not call this tool. This is a clear exclusion and guides the agent to avoid using it. It does not mention alternatives or when-not-to-use beyond this, but the hidden directive is strong enough. Not a full 5 because it doesn't elaborate on alternative tools or conditions.

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 indicate the tool is not read-only, not open-world, not idempotent, and not destructive. The description adds value by explaining that the comment is attributable and does not modify or approve, which clarifies the mutation's scope. However, it lacks details on whether it always succeeds, errors for invalid versions, or requires special permissions. With annotations covering the basic safety profile, the description provides some additional behavioral context but not comprehensive transparency.

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

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

The description is a single sentence with a clarifying follow-up sentence, both concise and front-loaded with the core purpose. It wastes no words and is easy to scan. It could slightly benefit from mentioning parameter parameters, but remains efficient.

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

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

Given the tool has 9 parameters (4 required), no output schema, and annotations lacking details, the description is insufficient. It does not explain the return value (e.g., feedback ID), behavior on duplicate idempotency_key, or how reply_to_feedback_id works. The context signals of high parameter count and low schema coverage demand a richer 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 coverage is 44% (4 of 9 parameters have descriptions). The description does not mention any parameters, so it adds no value beyond the schema. For the parameters without schema descriptions (x, y, page, label, reply_to_feedback_id), the description provides no guidance. Since coverage is low, a score of 3 is appropriate because the description fails to compensate for undocumented parameters.

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

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

The description clearly states 'Add an attributable review comment to a saved project version' with a specific verb and resource. It also distinguishes from sibling tools like 'add_project_pin' and 'approve_version' by explicitly noting it does not modify or approve. However, it does not explicitly differentiate from other feedback-related tools like 'resolve_project_feedback' or 'list_project_feedback'.

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

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

The description provides some context by stating it 'does not modify source or approve the version', which helps the agent understand it is for commenting only. However, there is no explicit guidance on when to use this versus alternatives (e.g., 'add_project_pin' for non-attributable notes or 'resolve_project_feedback' for marking issues), and no mention of prerequisites like requiring a saved project version.

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 indicate readOnlyHint=false and destructiveHint=false, so the description adding 'Add' is consistent but adds little. The description does not disclose required permissions, side effects (e.g., does it overwrite or create duplicates?), or behavior with respect to the idempotency_key (which is self-described in schema). The 'safe' qualifier for links is vague. Overall, the description provides minimal behavioral context beyond what annotations already imply.

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

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

The description is a single sentence, making it concise and front-loaded with the action. However, it is too brief to cover essential details. While every word serves a purpose, the brevity compromises clarity for a non-trivial tool with nine parameters. A slightly longer description with parameter context would improve it.

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

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

Given the tool has 9 parameters, no output schema, and complex behavior (idempotency, positioning, surfaces), the description is far from complete. It neither explains return values nor guides parameter usage. An agent lacks essential context to invoke the tool reliably, especially without output schema to infer results.

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 only 11% schema description coverage, the description should compensate by explaining key parameters. It mentions 'note or safe http(s) link' which covers kind and url, leaving seven other parameters (x, y, label, surface, project_id, version_id, idempotency_key) unexplained. The idempotency_key description exists only in schema, not in the tool description. This is insufficient for an agent to correctly construct calls.

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

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

The description clearly states the tool adds an 'attributable note or safe http(s) link' to a project workspace. It identifies the key resource (pin) and the two kinds (note, link), which aligns with the 'kind' enum. It is specific enough to distinguish from siblings like 'remove_project_pin' or 'list_project_pins' by stating the action is addition, though it could better clarify what 'attributable' means.

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

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

No guidance is given on when to use this tool versus siblings or alternatives. It does not mention prerequisites (e.g., need for a valid project_id), conditions for safe use, or when not to use it. The agent receives no help in deciding between this and related tools like 'add_project_feedback' or 'remove_project_pin'.

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?

It adds meaningful behavioral guardrails beyond annotations: 'Idempotently', 'when safe', and 'never double-dispatch' clarify concurrency and persistence behavior, which the raw idempotentHint does not fully express. It does not fully describe side effects, but destructiveHint and readOnlyHint already cover some of the behavioral surface.

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

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

The description is a single dense sentence and the primary action appears first. It could be clearer by unpacking terms like 'dependency-ready safe-auto plan step', but it avoids redundancy and stays appropriately short.

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 action with strong annotations, this is mostly sufficient. However, the description leaves 'safe' and 'dependency-ready' undefined, and since there is no output schema, an agent may still be unsure what a successful no-op, queued dispatch, or blocked attempt returns.

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 project_id is already described in the schema with 'Exact project whose saved Agent Mode should advance', so schema coverage is effectively 100%. The description adds no extra parameter semantics, which is acceptable but provides no additional value beyond the schema.

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

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

The description clearly names the action ('re-evaluate and queue the next step') and the resource (the project's already approved Agent Mode plan), with a concrete outcome: safely advance a dependency-ready auto-plan step. It is distinguishable from siblings like run_project_agent, configure_project_agent_mode, and get_project_agent_mode.

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

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

The description gives context for when this should apply: on an already approved Agent, Engine, and provider, and only when safe and dependency-ready. However, it does not explicitly contrast with alternative tools like run_project_agent or dispatch-related siblings, nor state when those should be used instead.

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 non-readonly, destructive, and idempotent nature of the tool, so those baseline facts are covered. The description adds valuable context: it enforces policy (role and high-risk owner), rejects revision conflicts, preserves immutable history, returns an idempotent receipt plus canonical reread, and notes that 'Unknown future response kinds remain in Project OS' (likely indicating open-world behavior in responses). However, it doesn't describe what the 'destructive' effect is beyond 'preserves immutable history' – does it remove or alter something? It says 'rejects revision conflicts' implying no mutation on conflict, but the destructive annotation suggests it can overwrite or change an existing decision state. This ambiguity is worth flagging, so a 3 is appropriate.

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

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

The description is three sentences, front-loaded with the core purpose, then constraints, then mention of idempotent receipt and open-world note. Every sentence adds essential information: what it does, what it enforces, what it returns. No filler or redundancy. It is concise and structured.

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

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

Given the tool's complexity (9 params, 7 required, nested answer enum, 3 kinds of answers, multiple constraints like revision conflict and role enforcement), the description provides a solid high-level view but omits specifics like the behavior of supersedes_id, the exact meaning of 'canonical reread', and how conflicts are reported. There is no output schema, so the description should clarify what the return looks like – it mentions 'idempotent receipt plus canonical reread' which gives a hint but not a concrete shape. Overall, it's fairly complete for an agent to know the tool's role and constraints, but lacks operational details that an agent might need to construct a valid call (e.g., required fields and their exact types are in schema, but meaning is partially missing). Still, it's better than most, so a 4.

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 only 33% (3 out of 9 parameters have descriptions in the schema: note, confirm, risk_level). The description does not elaborate on parameters but the schema provides partial info: note is 'Durable human rationale', confirm is 'Explicit confirmation', risk_level is 'Optional chosen risk classification; high-risk decisions require the project owner.' The description reinforces that a durable note is required and that high-risk requires owner, adding context beyond the schema. However, parameters like project_id, decision_id, expected_revision, answer, idempotency_key, supersedes_id have no descriptions in the schema, and the description does not clarify their semantics (e.g., what supersedes_id does, what idempotency_key format, etc.). Since coverage is moderate and the description adds some value, a 4 is justified because it helps with the more critical params but leaves gaps.

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

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

The description clearly states the verb ('Accept or reject'), the specific resource ('one exact native-safe engineering decision at one exact project revision'), and lists key constraints (requires confirmation, durable note, enforces role/owner policy, rejects revision conflicts, preserves immutable history). It conveys a strong sense of what the tool does. However, it doesn't explicitly differentiate from siblings like list_project_engineering_decisions or decide_work_assignment, though the action of accepting/rejecting a decision is fairly distinct among the 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?

The description implies the usage context: this is for recording the outcome of an engineering decision that has been made, by authorized roles (project role, high-risk owner policy). It mentions prerequisites like 'explicit confirmation' and 'durable note'. It does not explicitly name alternatives (e.g., if you just need to view decisions use list_project_engineering_decisions, or if you need to create an assignment use decide_work_assignment), but the context is reasonably clear for an agent familiar with the domain. A clear when-not or explicit alternative is missing.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false. The description confirms idempotency and adds the effect 'make it current', which is a key behavioral trait beyond annotations. However, side effects on the previous current version are not disclosed.

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

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

The description is concise with two short, front-loaded sentences. No word wasted. However, the second sentence could be integrated with the first for even tighter structure. Still, it earns its place.

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

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

Given the tool is a simple mutation with few parameters and annotations covering idempotency and destructiveness, the description is minimally adequate. But it lacks context about what 'request_id' refers to, how to obtain it, and how this tool relates to the approval workflow (e.g., listing requests first). The absence of output schema increases the need for this context.

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

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

Schema description coverage is 0%, so the description must explain the two parameters. It does not mention 'request_id' (the required UUID for the approval request) or the optional 'note'. The agent receives no guidance on what these parameters represent or how to populate them.

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 it approves a 'pending immutable artifact version' and 'makes it current', using specific verb and resource. This distinguishes it from sibling 'approve_version' by specifying the artifact type and immutability.

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

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

The description implies the version must be pending, but does not explicitly state when to use this tool over sibling 'approve_version' or when not to use it. No alternative tools are mentioned. Usage guidance is minimal and 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 state destructiveHint=true and idempotentHint=true. The description adds valuable context about the authorization model ('separately delegated review authority') and explicitly clarifies side-effect boundaries (no publish, export, permission changes). This goes beyond the annotations by specifying what does NOT happen, which is helpful for an agent assessing risk.

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

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

Two sentences, no redundancy. The first sentence delivers the core action and authorization context; the second sentence clarifies exclusions. Every word earns its place. It is front-loaded and achieves maximum clarity with minimal text.

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

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

For a 4-parameter mutation tool with annotations, the description covers the operation, authorization, and what it does not do. However, it omits any indication of return value or result behavior (e.g., whether it returns the updated version). Given no output schema, a brief note on return could improve completeness. The idempotency hint is present in annotations but not explained in description, which could be relevant for repeated calls.

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

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

Schema coverage is 100% with clear descriptions for all four parameters. The description does not significantly add meaning beyond the schema—it mentions 'approve one saved version' but the schema already calls the candidate version 'saved'. The confirmation constant is self-evident. No parameter semantics are enriched beyond what the schema provides.

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

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

The description explicitly states the action: 'approve one saved version and make it the project's active version'. It also clarifies what it does not do ('Does not publish, export, or change project permissions'), which distinguishes it from siblings like 'approve_artifact_version' and export/publish tools. The verb 'approve' and resource 'version' are specific and unambiguous.

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

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

The phrase 'Use separately delegated review authority' hints at the prerequisite context, but does not explicitly state when to use or not use this tool. The exclusion list ('Does not publish, export...') implies alternatives exist, but no sibling tools are named. The guidance is implied rather than explicit, leaving room for agent misinterpretation.

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, openWorldHint=false. The description adds valuable context: it changes no source file, never falls back to another Engine, and requires explicit confirmation. This goes beyond the annotations by clarifying the non-destructive nature of the source files and the confirmation requirement, which is critical for a destructive operation. The description does not contradict annotations; it complements them.

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

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

The description is two sentences, front-loaded with the core action and purpose, then adds the critical safety and confirmation requirements. Every sentence earns its place: the first defines what it does, the second clarifies the non-destructive nature and the confirmation requirement. No wasted words.

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

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

Given the tool's complexity (5 required params, destructive annotation, no output schema), the description covers the essential context: what it does, the confirmation requirement, and the non-destructive nature of source files. It doesn't explain the return value or what happens after attachment, but with no output schema, that's less critical. The description is complete enough for an agent to call it correctly, though it could mention the expected_revision parameter's role more explicitly, but the schema covers that.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds context about the overall operation (e.g., 'exact opaque workspace', 'exact online 2ools Engine') but doesn't add per-parameter semantics beyond what the schema provides. The description mentions 'show the selected computer/workspace and obtain explicit confirmation' which relates to the confirm parameter, but the schema already explains that. Baseline 3 is appropriate.

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

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

The description clearly states the action (attach), the resource (one saved project), the target (one exact opaque workspace on one exact online 2ools Engine), and the purpose (grants future project work access to real source on that computer). It distinguishes itself from siblings like start_project_on_engine and get_project_engine_workspace by emphasizing the exactness and the attachment semantics.

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

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

The description provides clear context: it is owner-authorized, requires showing the selected computer/workspace and obtaining explicit confirmation, and it never falls back to another Engine. It doesn't explicitly name alternative tools for when not to use it, but the context of 'exact' and 'never falls back' implies a specific use case. The sibling list includes get_project_engine_workspace and start_project_on_engine, but the description doesn't explicitly contrast with them, so a 4 is appropriate.

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 indicate readOnlyHint=false and idempotentHint=true. The description adds value beyond this by explaining the asynchronous workflow: it queues a build and returns job_id, with a pointer to get_build for status and preview. This clarifies the non-blocking nature and the need to poll, which is behavior not apparent from annotations alone. No contradiction with annotations.

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

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

Two sentences with no wasted words. The primary action is front-loaded, and the second sentence explains the return values and the follow-up tool. It is efficient and well-structured.

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

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

For a tool with 16 parameters and a nested object, the description is minimal but captures the essential workflow: create project, queue build, retrieve IDs, poll get_build. It mentions the 'protected preview' concept and the async pattern. Given that the schema fully documents parameters, the description sufficiently covers the overall context for an agent to call 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 100%, so every parameter is individually documented. The description adds marginal meaning by calling the conversation_summary a 'structured conversation brief' (which clarifies the expected format) and by mentioning the return of project_id and job_id. Since the schema already does the heavy lifting, the description adds only a small increment, fitting the baseline 3.

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

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

The description clearly states the verb ('create'), the resource ('new 2ools project'), and the source ('structured conversation brief'). It also mentions queuing a durable build and returning IDs, which gives a specific, actionable purpose. It does not explicitly differentiate from sibling creation tools like refine_project or continue_project, but the phrase 'from a structured conversation brief' is distinctive enough to imply the primary creation entry point.

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: create a new project from a conversation brief. It recommends using get_build to check status, which is helpful follow-up guidance. However, it does not state when not to use this tool or mention alternatives such as refine_project or continue_project for existing projects. This is implied usage rather than explicit 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 and idempotentHint. The description adds value by explaining the idempotent behavior ('Completed, failed, stalled, and already-canceled runs keep their terminal truth') and the specific effect of closing durable run history. No contradiction with annotations.

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

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

Two sentences totaling 23 words, with the primary action ('Stop one queued or running Agent execution') front-loaded. No redundant content; every word contributes to the meaning.

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

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

Given 5 required parameters and no output schema, the description covers the core behavior and scope sufficiently. It lacks details on error handling or follow-up status, but the combination of annotations and description provides enough for an agent to decide to call 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?

Schema coverage is 100% with descriptive per-parameter text. The description adds no additional parameter semantics or elaboration beyond what the schema already provides for job_id, run_id, confirm, agent_id, and project_id.

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

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

The description uses a specific verb ('Stop') and a clear resource ('Agent execution' and 'durable run history'). It explicitly limits the action to 'queued or running' runs, which distinguishes it from sibling tools like cancel_build. The mention of terminal states adds precision.

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 correctly: use it only for queued or running Agent runs, and explicitly states that terminal runs (completed, failed, stalled, already-canceled) are unaffected, effectively telling when not to use it. It does not name direct alternatives like cancel_build, but the scope is unambiguous.

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 idempotentHint=true and destructiveHint=true, but the description adds meaningful behavioral guarantees beyond that: 'late Engine results are rejected', 'completed versions are never deleted', and 'immutable history remains'. These clarify exactly what the destructive action does and doesn't affect, which is valuable context for an agent weighing a destructive call.

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

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

Two sentences with zero wasted words. The first sentence front-loads the core purpose and the critical confirmation requirement; the second packs the idempotency, rejection of late results, non-destruction of versions, and the sibling alternative. Every phrase earns its place.

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

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

For a destructive, idempotent tool with no output schema, this description is exceptionally complete. It covers what gets canceled, the confirmation gate, the side effects (late results rejected), the guarantees (no deletion of completed versions, immutable history), and the sibling for a different execution type. An agent has everything needed to safely 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?

Schema description coverage is 100%, so each of the three parameters (job_id, reason, confirm) is already well-documented. The description reinforces the confirmation requirement ('after named explicit confirmation') but adds no new syntax, format, or relationship details beyond what the schema provides. Baseline 3 is appropriate since the schema carries the full parameter burden.

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 ('Cancel'), a precise resource ('one exact queued or running non-Agent 2ools build'), and scoping qualifiers ('exact', 'queued or running', 'non-Agent'). It immediately distinguishes itself from the sibling cancel_agent_run, making its purpose unambiguous without needing to open the schema.

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

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

It explicitly states that confirmation is required ('after named explicit confirmation'), notes that repeating cancellation is safe (idempotent usage), and clearly routes governed Agent execution to the sibling 'cancel_agent_run'. This gives the agent concrete when-to-use and when-not-to-use guidance, including an explicit alternative.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond these: ending the lease is a mutating action, and ambiguous external effects are never auto-retried, always waiting for reconciliation. This aligns with the idempotentHint and provides a critical operational rule not exposed by 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?

Two sentences, front-loaded with the primary purpose and followed by a single key behavioral rule. No wasted words; every sentence adds value. The structure is clean and easy to scan.

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

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

This is a complex tool with 13 parameters, no schema descriptions, no output schema, and sparse annotations. The description gives a high-level purpose and one behavioral rule, but fails to explain parameter semantics, what a checkpoint should contain, when to choose waiting vs blocked, or what the response looks like. For such a parameter-heavy tool, the description is not nearly sufficient for correct invocation.

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

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

With schema description coverage at 0%, the description bears full responsibility for explaining the 13 parameters. While it indirectly hints at disposition (waiting/blocked) and effect_state ('external effects'), it does not explicitly define session_id, checkpoint, idempotency_key, or the many metrics fields. The description provides almost no parameter-level guidance, leaving agents to guess the purpose and format of these inputs.

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

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

The description clearly states the tool's core action: 'End the current lease with a compact continuation checkpoint' and also covers alternate disposition states ('waiting or blocked'). This specific verb+resource construction sufficiently distinguishes it from sibling tools like heartbeat_work_session or submit_work_session, though it does not 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?

The description implies usage by saying 'or place work in an explicit waiting or blocked state', suggesting when to use different dispositions. The second sentence gives a rule: ambiguous external effects should wait for reconciliation and never be auto-retried, which is useful guidance. However, there is no explicit comparison to alternative tools or clear prerequisites for using this over siblings like continue_project or heartbeat_work_session.

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 important behavioral details beyond annotations: atomicity, a five-minute renewable lease, and an immutable budget snapshot. Annotations already provide idempotentHint=true, destructiveHint=false, which are consistent. The description enriches the agent's understanding of side effects and lifecycle.

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

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

The description is a single sentence, very concise (18 words), and front-loads the main action. However, it is so brief that it omits critical parameter information, slightly reducing its effectiveness. Still, it earns its place with no wasted words.

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

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

Given the three parameters, no output schema, and sparse annotations, the description is incomplete. It does not explain what the lease or budget snapshot entails, how the idempotency key works, or what happens if the assignment is already claimed. The agent would need to infer or discover these details, making the tool harder to use 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%, meaning the schema provides no parameter descriptions. The tool description does not explain any of the three parameters (assignment_id, idempotency_key, input_refs). It fails to compensate for the missing schema descriptions, leaving the agent to guess the purpose of each 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 uses a specific verb ('claim') and resource ('open assignment'), and clearly states the output (renewable lease and budget snapshot). It distinguishes from siblings like 'create_work_assignment' and 'decide_work_assignment' by focusing on claiming an existing assignment atomically.

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

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

No explicit guidance on when to use this tool versus alternatives. It does not state prerequisites (e.g., the assignment must exist and be open) or when not to use it. Usage context is only implied by the action description.

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 explicitly mark the tool as readOnlyHint: true, idempotentHint: true, destructiveHint: false, which already declare it as a safe, read-only, idempotent operation. The description does not contradict these and adds useful context: it reports lineage, review state, page diffs, byte sizes, and SHA-256, which helps the agent understand the behavior's scope. However, it does not mention rate limits, pagination, or performance for large comparisons, so it falls short of perfect transparency.

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

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

The description is a single, dense sentence that front-loads the core purpose ('Compare two saved versions in one project without returning source') and then lists all reported attributes. Every word carries information. No fluff. This is an example of excellent conciseness.

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

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

Given the tool has 3 well-documented parameters, no output schema, and rich annotations (readOnly, idempotent, non-destructive), the description covers what the tool does and what it reports. The agent can infer it returns a comparison summary. However, it could be slightly more complete by hinting at the exact output format (e.g., 'returns a diff object with ...') since there is no output schema. Still, for a comparison tool with good structured data, this is quite 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 input schema has 100% coverage with descriptions for project_id, left_version_id, and right_version_id. The schema already provides UUID format and a note that left is 'Earlier or baseline' and right is 'Later or candidate'. The description adds value by indicating the comparison is within one project and clarifies the output fields. Since all parameters are well-documented in the schema, the description provides a meaningful but not essential supplement, earning a 4.

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

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

The description clearly states the tool compares two saved versions in one project, specifies what it reports (lineage, review state, page additions/removals, byte sizes, SHA-256), and distinguishes itself by noting it does not return source. This is a specific verb+resource and differentiates from sibling tools like approve_version, list_artifacts, etc., though it could be sharper about excluding version export or diff tools.

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

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

The description implies this is for comparing saved versions without source, but does not explicitly state when to use this over alternatives like get_version or prepare_version_export. There is no mention of prerequisites (e.g., version IDs must exist), nor is there discussion of when not to use it. With 53 sibling tools including several version-related ones, explicit guidance would improve this dimension.

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 meaningful behavioral detail beyond the annotations: it explains what enabling Agent Mode does (person chooses agent/engine/provider, only reviewed safe-auto steps advance, limits are never widened). This complements the idempotentHint and non-destructive annotations without contradicting them.

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

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

Two sentences with no fluff. The primary action is front-loaded, and the governance constraints are described in a compact but precise way.

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

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

For a 9-parameter configuration tool with no output schema, the description is largely complete: the schema covers parameter semantics and annotations cover idempotency and safety. A minor gap is that it does not describe alternative tools or the exact behavior when Agent Mode is disabled, but the core agent decision is well supported.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds a little context by mentioning the person chooses one agent, engine, and provider, which maps to agent_id, engine_id, and provider, but it does not add substantial meaning beyond the schema.

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

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

The description names a specific verb ('turn on or off') and a specific resource ('the selected project's governed Agent Mode'), and the governance details distinguish it from sibling tools like advance_project_agent_mode or run_project_agent. It clearly states the scope and outcome of 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?

The description gives clear context for when to call this tool: to enable or disable governed Agent Mode for a project. It does not explicitly name alternatives or exclusion cases, but the action is distinct enough from the sibling tools that an agent can infer when it applies.

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, lowering the burden. The description adds value by disclosing that the tool opens a compact status/Continue/Open Project OS card on MCP Apps hosts and that the full Project OS belongs in the browser side panel, which is beyond what the 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?

The description is two sentences, front-loads the returned payload list, and uses the second sentence to clarify host-specific behavior and scope. It contains no filler and does not repeat schema or annotation 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?

Given no output schema, the description does well by listing what the tool returns and explaining the host-side card behavior. It is slightly incomplete because it does not address response_format explicitly or mention an alternative sibling tool, but for a simple read-only, idempotent tool these are minor 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?

The schema describes project_id but provides no description for response_format beyond its enum and default. The description adds only a hint of compactness and does not explain how response_format changes the returned output. With 50% schema coverage, the description partially compensates, but the response_format semantics remain 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?

The description names a specific action ('Return') and resource (one project's current Living Plan, next move, gaps, evidence, and receipt), making the tool's function clear. It also contrasts 'compact' output with 'full Project OS,' which helps differentiate scope, but it does not explicitly name or distinguish a sibling tool.

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

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

The description gives useful context by saying this returns a compact status rather than the full Project OS, implying when it might be used. However, it never states when to prefer continue_project over siblings like refresh_project_cockpit, get_project_context, or update_living_plan, nor does it provide any 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?

The description adds key behavioral traits beyond annotations: the preview is temporary (24-hour expiration), free, authless, and read-only. Annotations already cover idempotency (idempotentHint: true) and non-destructiveness (destructiveHint: false), but the description enriches this with usage constraints. No contradiction with annotations.

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

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

The description is three sentences with no waste. The first sentence states the core purpose, the second adds constraints (temporary, authless, expiration), and the third clarifies the prerequisite. Each sentence earns its place.

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

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

The description covers the tool's purpose, constraints, and prerequisite, but it omits the return value (likely a URL or identifier). Since there is no output schema, the description should ideally indicate what the agent receives after a successful call. The omission leaves a gap for an agent to understand the full interaction.

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

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

With 100% schema description coverage, the baseline is 3. The tool description adds minimal extra meaning beyond the schema—it reinforces that the HTML must be 'complete' and 'already created in this chat,' but does not provide new parameter-specific details. The schema already sufficiently describes each parameter.

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

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

The description clearly states the action (turn a standalone HTML document into a preview) and the resource (2ools preview). It distinguishes from siblings by specifying 'already created in this chat' and noting it does not generate the page, making it distinct from render_project_preview or similar tools.

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 explicitly instructs the user to write the HTML first before calling the tool, which is a clear prerequisite. However, it does not mention when not to use this tool or suggest alternatives, leaving some ambiguity for the agent.

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 idempotentHint=true, and the description adds meaningful detail that reusing the idempotency key returns the original result, implying a 'create or recover' behavior. This goes beyond the bare annotation and aligns with the idempotency hint, with no contradictions.

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

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

Two front-loaded sentences with no filler. The core purpose and idempotency behavior are stated efficiently, earning every word.

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 5 parameters and no output schema, the description covers the core behavior and idempotency but omits details about the optional 'page' parameter, return format, and error cases. It is sufficient for basic tool selection but not for fully anticipating edge cases.

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

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

Schema description coverage is 0%, so the description must compensate. It adds semantics for access ('public or code-protected') and idempotency_key (recovery behavior), but leaves 'page' unexplained and does not elaborate on project_id/version_id beyond what is obvious. Partial coverage at best.

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

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

The description uses a specific verb ('Create or recover') and resource ('durable public or code-protected link for one exact saved version'). It clearly differentiates from siblings like get_version_share_link (retrieval) and revoke_version_share_link (revocation), and specifies the exactness of the version.

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

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

The description provides clear context for when to use the tool: to create or recover a durable link for a specific saved version, with idempotency recovery. It does not explicitly mention alternatives or when-not-to-use, but the context is well-defined.

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 provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds 'durable' suggesting persistence, but does not elaborate on side effects, idempotency behavior, or what happens on retry. With annotations covering the safety profile, the description adds minimal extra behavioral context, so a score of 3 is appropriate.

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

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

The description is a single sentence that is concise and front-loaded with the core purpose. It wastes no words. However, it could be slightly expanded to include the project context or required parameters without becoming verbose. The structure is efficient but slightly under-informative for the tool's complexity.

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

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

Given the tool has 17 parameters, 4 required, nested objects, no output schema, and low schema coverage, the description is too sparse. It does not explain the return value (likely the created assignment ID or object), the meaning of the required parameters, or the overall workflow. The description is incomplete for an agent to fully understand the tool's usage and behavior.

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

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

Schema description coverage is only 6% (only one parameter, 'goal_id', has a description). The tool description mentions 'acceptance criteria' and 'hard step, time, and spend ceilings' which hint at parameters like 'acceptance_criteria', 'max_steps', 'max_minutes', 'max_spend_cents', but does not map them explicitly. With 17 parameters and low coverage, the description fails to compensate by explaining the meaning or purpose of key parameters, especially the required ones ('project_id', 'title', 'brief', 'idempotency_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?

The description clearly states the verb 'Create' and the resource 'assignment' (implied work assignment), and highlights key features: acceptance criteria and ceilings on steps, time, and spend. It distinguishes from sibling tools like 'claim_work_assignment' and 'decide_work_assignment' which are about claiming or deciding, not creating. However, it does not explicitly mention that the assignment is within a project, which is a crucial context given the required 'project_id' parameter.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are siblings like 'claim_work_assignment' and 'decide_work_assignment', but the description does not explain prerequisites, typical workflow, or exclusions. An agent would have to infer usage from context, which is insufficient.

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 indicate mutability (readOnlyHint=false), idempotency (idempotentHint=true), and non-destructiveness (destructiveHint=false). The description adds the authority requirement, which is a useful behavioral constraint. However, it does not disclose what other state changes occur or side effects (e.g., notifications). The description does not contradict annotations.

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

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

The description is extremely concise: two sentences with no filler. It quickly establishes the core purpose and a key prerequisite. Every phrase earns its place.

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

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

Given the tool has 4 parameters, no output schema, and performs a state-changing action, the description is too sparse. It does not explain the parameters (beyond decision), the expected return value, or how the idempotency key works. An agent would lack sufficient context to invoke this tool reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It only vaguely references the 'decision' parameter by mentioning 'complete or reopen'. The note, assignment_id, and idempotency_key parameters are completely unexplained. This is insufficient for an agent to use the tool correctly without inferring from names.

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

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

The description clearly states the tool completes or reopens submitted work, which is a specific verb-resource combination. The title 'Review submitted project work' provides context. However, it does not explicitly differentiate from siblings like 'approve_version' which might be confused for similar functionality on different entities.

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 mentions a prerequisite (delegated work-review authority), which is helpful. But it lacks explicit guidance on when to use this tool versus alternatives (e.g., approve_artifact_version for artifacts, or reject_version). No 'when not to use' or comparison with siblings is provided.

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 (readOnly=false, openWorldHint=true, idempotent=true, destructive=false) already cover the safety and side-effect profile. The description adds crucial behavioral context beyond annotations: it clarifies that queued does not mean working—the task becomes active only after the engine atomically claims it—and guarantees no fallback to alternate compute. This explains the dispatch lifecycle and strictness, providing significant 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?

The description is three sentences with no waste. The first sentence states the core purpose, the second explains the queued vs. active nuance, and the third enforces the no-fallback constraint. Every sentence earns its place and the most critical information 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 tool with 9 required parameters and no output schema, the description provides sufficient call-guidance: it explains the dispatch process, exact selection requirements, and activation semantics. It does not cover error handling (e.g., engine offline) or explicitly mention idempotency behavior (though the schema covers idempotency_key). Minor gaps, but overall complete for the core functionality.

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

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

Schema description coverage is 100%, so every parameter is already well-described. The tool description ties concepts together (e.g., 'revision-checked' maps to expected_revision, 'armed Agent' to agent_id, 'online Engine' to engine_id) but does not add new semantic detail beyond that already in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description uses specific verbs (reserve, queue) and identifies exact resources (Project OS task, armed Agent, online Engine, authenticated provider). It explicitly distinguishes itself from siblings by stating 'Never falls back to another computer, provider, hosted compute, or a parallel task,' and clarifies that selection is by the person. This is a precise, unambiguous purpose.

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

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

The description gives clear context: this tool is for exact, person-selected dispatch with no fallback, and explains the queued vs. active lifecycle. It implies when to use it (when exact selection is required) but does not explicitly name alternative tools or state 'use this instead of X.' The 'selected by the person' and 'Never falls back' constraints provide strong usage guidance without explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful behavioral context beyond that: it states that passwords, private credentials, billing instruments, and provider secrets are never returned. This sets accurate expectations about the response content and reinforces the safety of the operation. There is no contradiction with the annotations.

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

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

The description is two concise sentences: the first states the action and subject, and the second lists explicit exclusions. Every clause adds value and there is no unnecessary detail or repetition of schema or annotation 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 zero-parameter, read-only tool, the description is complete: it names what will be returned, clarifies the scope of the data, and explicitly lists what will never be returned. No output schema exists, but the description sufficiently sets expectations for the agent without requiring further context.

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

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

The tool has zero parameters and schema coverage is 100%, so parameter documentation is inherently satisfied. The description doesn't need to explain parameter semantics, and the baseline of 4 for zero-parameter tools is appropriate.

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

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

The description uses a specific verb ('Read') and identifies the exact resource: the authenticated person's 2ools profile, current account labels, and server-derived effective MCP scopes. This clearly distinguishes it from the sibling update_account_profile by framing it as a read operation and from the many project/work tools in the sibling list.

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

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

The description makes the usage context explicit: call this when you need the authenticated user's profile, account labels, or effective MCP scopes. It does not explicitly name an alternative or state when not to use it, but the read-only framing and the presence of update_account_profile as a sibling make the intended use clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying that raw prompts, tool arguments, credentials, and source bytes are not returned, and that run traces are 'redacted append-only' with 'immutable revision summaries'. This goes beyond the annotations' safety profile.

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

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

The description is a single sentence that efficiently states what the tool does and what it does not return. No extraneous words or filler. Every part earns its place.

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

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

For a read tool with two simple parameters and no output schema, the description covers the key data included and excluded. Minor gaps: it does not explain ordering of run traces or behavior when run_limit is exceeded, but overall it is sufficiently complete for an agent to understand the tool's scope.

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

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

Schema description coverage is 100%, so the input schema already documents both parameters. The description does not add any additional meaning or context for the parameters (e.g., how run_limit affects results or the format of agent_id). Baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Read' and lists the exact data returned (Limits, trigger, revision summaries, run traces) and explicitly states what is NOT returned. This clearly differentiates from sibling tools like 'list_project_agents' which list agents rather than inspect a single one.

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

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

The description provides no guidance on when to use this tool versus alternatives such as 'list_project_agents' to find an agent ID, or when to avoid it. The usage context is entirely implied by the tool name and siblings, placing the burden on the agent to infer.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds critical behavioral context: the tool is read-only ('Read ... without returning stored bytes'), works with immutable version histories, and explicitly excludes returning file bytes. This aligns perfectly with the annotations and provides the agent with a transparent understanding of boundaries.

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

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

The description is a single sentence, efficiently packing the core purpose, scope, and key constraint ('without returning stored bytes'). Every phrase earns its place without redundancy or fluff. It is front-loaded and highly scannable for an AI 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?

Given the tool has only 2 required UUID parameters, no output schema, and strong annotations, the description provides complete context. It specifies the exact information returned (version history, provenance, attribution, digests, review states) and the key exclusion (no bytes). An agent can confidently decide when to invoke this tool versus download-oriented or listing tools. No gaps are apparent.

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%, meaning neither parameter is described in the schema. The description compensates by clarifying that project_id and artifact_id identify the artifact whose metadata is returned. However, it could be more explicit about the roles of each parameter (e.g., 'artifact_id' might be a version ID vs. an artifact identifier). Adding a brief note on expected input format or scope would improve this.

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

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

The description uses a specific verb ('Read') and clearly identifies the resource as 'one artifact's immutable version history, provenance, attribution, digests, and review states.' It also explicitly states what the tool does NOT do ('without returning stored bytes'), which distinguishes it from download-focused tools like prepare_artifact_download. This provides a complete, unambiguous purpose that stands out among 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?

The description implies appropriate usage scenarios: when metadata about an artifact is needed without downloading its content. It contrasts with tools like prepare_artifact_download (which returns bytes) and list_artifacts (which lists multiple artifacts). However, it does not explicitly exclude usage in cases where the artifact ID is unknown, nor does it suggest alternatives like list_artifacts for discovery. Slight improvement needed for explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description adds value by specifying exactly what data is returned (status, progress, errors, etc.) and what is not (generated source code). This goes beyond annotations to set accurate agent expectations.

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

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

Two sentences with no redundancy. The first sentence front-loads the tool's purpose and outputs. The second sentence clarifies an important exclusion. Every phrase earns its place, and the structure is easy to scan.

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 tool with one well-documented parameter, annotated safety, and no output schema, the description fully covers what the agent needs: what it returns, what it excludes, and how to identify the build (via job_id from build_from_conversation). No gaps remain.

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

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

Schema coverage is 100% and the parameter description already states 'Build job ID returned by build_from_conversation'. The main description does not add further parameter details (e.g., format, validation). Baseline 3 is appropriate since the schema carries the burden.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource ('one build's current status, progress, errors, completed version IDs, and protected preview URLs'). It distinguishes itself from sibling tools like 'build_from_conversation' (creates a build) and 'cancel_build' (cancels a build) by focusing solely on retrieving build details. The explicit exclusion ('Does not return generated source code') further clarifies scope.

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

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

The description implies that the 'job_id' parameter is provided by 'build_from_conversation', but it does not explicitly state when to use this tool versus alternatives (e.g., after initiating a build). No direct guidance on prerequisites or comparison with siblings like 'list_build_systems' is given, leaving the agent to infer usage context.

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

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

Annotations already declare read-only, idempotent, and non-destructive. The description adds valuable context beyond that: it explains the lease-claim semantics (running appears only after atomically claiming), and clarifies that the tool returns claim, heartbeat, failure, and terminal state without client inference. This informs the agent about state-machine behavior and data completeness, which is not present in annotations.

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

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

Two sentences, no wasted words. The primary purpose and scope are front-loaded, followed by necessary state semantics. Every sentence adds value, making it ideal for quick agent parsing.

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 tool with one parameter, full schema coverage, strong annotations, and explicit return contents (claim, heartbeat, failure, terminal state), the description covers all the agent needs to call it correctly. No output schema exists, but the description enumerates what is returned, so completeness is high.

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

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

Schema coverage is 100% and the schema already documents job_id as 'Dispatch job ID returned by start_project_on_engine.' The description adds no extra meaning about the parameter—it only mentions 'exact Engine dispatch' but doesn't clarify format or constraints beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the verb 'Read' and the resource 'authoritative state of one exact Engine dispatch', and distinguishes it from other get_* tools by focusing on the exact dispatch state with specific state semantics (queued, running). This is precise and unambiguous.

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

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

The description implies usage (when you need the authoritative dispatch state), but it does not explicitly name alternatives or conditions for when to use this tool versus related getters like get_build or get_project_activity. No exclusions or alternative routing is provided.

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 set readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description need not restate those. The description adds value by disclosing that the tool excludes generated source code (a key behavioral constraint). The performance profile (read-only, safe, idempotent) is well-covered. No contradictions are present.

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

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

The description is two sentences, front-loading the primary purpose and then clarifying a key exclusion. Every sentence adds distinct value, and there is zero redundancy. The length is appropriate for the tool's complexity (one parameter, no output schema).

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

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

Given the annotations (readOnlyHint, idempotentHint, openWorldHint=false) and the output schema being absent, the major gap is that the description does not state the return format (e.g., is it JSON, does it include timestamps). This is acceptable because no output schema is declared; a brief hint about the return type or structure would push this to a 5. The description adequately covers purpose, scope, and an exclusion.

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

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

Schema description coverage is 100%, and the sole parameter 'project_id' is fully described in the schema with a UUID format and pattern. The description does not add additional meaning beyond what the schema provides (e.g., how to obtain the ID, or whether it refers to a current or archived project). Per the rubric, baseline 3 is correct when schema coverage is high.

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

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

The description clearly states the verb 'Get' and the specific resource '2ools project', and explicitly lists the four categories of data returned: brief, selected pages, active version, and compact version history. It also distinguishes itself from other 'get_project_*' siblings like get_project_activity or get_project_mission by detailing exactly what it retrieves.

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

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

The description implies this is the tool to use for a comprehensive snapshot of project metadata (brief, pages, version, version history). It does not explicitly state when not to use it or name alternatives, but given the many sibling tools that cover specific slices (get_project_context, get_project_discipline, get_project_mission), the explicit negative statement 'Does not return generated source code' helps agents avoid misusing it for code retrieval. A clear 'when-not' improves 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?

The annotations already establish read-only and idempotent behavior; the description adds value by disclosing an authorization-dependent behavior: non-managers only read active members and never receive pending invitations. This is meaningful nuance beyond the annotations, though error/not-found behavior is not covered.

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 concise sentences, each carrying necessary information. The purpose is front-loaded, and the non-manager behavior is an important addition without redundancy or 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 single-parameter, read-only tool with no output schema, the description sufficiently enumerates return concepts: role, owner, members, and pending invitations. It also flags the role-sensitive data availability. It could be more explicit about the exact response shape, but that is a minor gap given the overall 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?

The schema has zero description coverage, and the tool description never explains project_id, such as how to select it or that it identifies the project whose access is being read. The parameter name and UUID format are self-explanatory to a degree, but the description does not compensate for the missing schema documentation.

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

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

The description uses a clear verb ('Read') and a specific resource: the authenticated person's role plus project owner, members, and pending invitations. This scope sets it apart from the many generic get_project/sibling tools, so an agent can tell what it returns without inspecting the schema.

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

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

The description gives clear context for when this is the right call: you want access-related information for a project. It also adds a concrete exclusion by explaining that non-managers cannot receive pending-invite metadata, which guides downstream expectations, though it does not explicitly name alternative sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is clearly a safe, idempotent read operation. The description adds valuable context about attribution transparency (agents vs humans), which goes beyond annotations. No contradiction found.

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

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

The description is two sentences, front-loading the core action and scope in the first sentence, and adding a critical transparency note in the second. Every sentence adds value with zero redundancy.

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

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

Given the complexity (3 params, no output schema, rich sibling set), the description covers the core purpose and behavioral transparency well. It could add info about return format or default ordering to be fully complete, but the provided detail is sufficient for an agent to select this tool.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters (project_id, limit, cursor). The description adds no additional parameter-level detail beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Read' and the resource 'attributable project timeline', and specifies the scope across multiple activity types (human work, external MCP agents, builds, versions, feedback, workspace pins). This distinguishes it from sibling tools like get_project (general metadata) or list_project_agents (specific subset).

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 explicitly notes that 'Actor kind is explicit' and clarifies attribution rules (no false human identity for agents), which helps an agent decide when to use this vs. other timeline or listing tools. However, it does not explicitly state when NOT to use it or provide direct alternatives among 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 establish that the tool is read-only, idempotent, and non-destructive. The description adds meaningful context beyond annotations by explaining what the state is derived from and what the return fields will be, which is important because no output schema is provided.

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

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

Two sentences, with the core read operation front-loaded and the return payload listed as a compact sequence. There is no filler, tautology, or restating of 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, read-only tool with strong annotations and no output schema, this description is complete: it defines the source state, the purpose, and the exact return contents. An agent has enough information to decide when to call it and what to expect.

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

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

Schema coverage is 100 percent, so project_id is fully described with type, format, and required status. The description focuses on the operation and return semantics, so no additional parameter explanation 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?

States a specific read operation and a specific resource: the project-level autonomous coordination state, and lists concrete returned items such as progress, current work, next eligible safe step, and the reason for running or needing help. It is clear, but it does not explicitly differentiate itself from sibling getters like get_project_mission or get_project_context.

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 intended use case is reasonably clear: inspect project-level autonomous coordination state and understand the next safe action or why a human is needed. However, it does not explicitly state when not to use it or name an alternative 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?

The description goes beyond the annotations (which correctly indicate readOnly, idempotent, and not destructive) by detailing exactly what data is included and, crucially, what is excluded. It warns that imported input is immutable evidence and not an AI proposal or live filesystem sync, which are important behavioral traits. The description is fully consistent with the annotations, no contradiction.

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

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

The description is two sentences: the first explains what the tool does and lists the output components; the second clarifies key exclusions and data characteristics. Every sentence is purposeful and adds essential context without redundancy. It is front-loaded with the core action and resource, making it easy for an AI agent to quickly grasp the tool's role.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no nested objects), the description is complete. It fully documents what the tool returns, what it does not return, and the semantics of the optional parameters. The annotations provide additional behavioral safety cues. There are no obvious gaps in the information needed for correct invocation and understanding.

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

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

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining that include_governance_text is deprecated and will always be ignored, and by clarifying that include_project_input_files will include 'sanitized observed file contents' while manifest facts and provenance are always returned. This clarifies the behavioral impact of each parameter beyond the schema's basic type and description.

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 starts with a clear verb ('Read') and specifies the resource ('source-free operating packet'). It then enumerates the components returned (e.g., version metadata, project input, review attention, artifact index), making the purpose concrete. Among many sibling tools like get_project, get_project_activity, and get_project_mission, this description effectively distinguishes this tool as the one for reading a comprehensive operational snapshot.

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 explicitly states what is not returned ('private 2ools skills, prompts, routing, governance text, and generated version source are not returned'), which preempts misuse. It clarifies that imported input is immutable evidence, not an AI proposal or live filesystem sync, guiding the agent on the tool's limitations and appropriate use cases. This provides clear context for when to use this tool versus alternatives that might supply additional or different data.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds value by explaining that the status is 'computed from authoritative Project OS records, never editable checkboxes.' This clarifies the derived nature and the fact that output reflects system state rather than user-set flags. The description enriches behavioral understanding without contradicting annotations.

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

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

The description is two sentences, tightly packed with specific output elements and a key behavioral note. It is front-loaded with the action and result, and no sentence is wasted. It is an exemplary concise description.

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-only getter with no output schema, the description fully lists the returned components and clarifies the derived, non-editable nature. It covers the essential information an agent needs to understand what the tool returns and how it behaves. The absence of output schema is compensated by the detailed enumeration of result contents.

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, project_id, is not described in the tool description, and schema description coverage is 0%. While the parameter name and UUID type are self-evident, the description adds no additional semantics such as format hints, default behavior, or relationship to other fields. It relies entirely on the schema's basic type/pattern information.

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

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

The description explicitly states the tool 'Return derived direction, trade-off, evidence, and continuity status', making the purpose clear. It lists specific output components and contrasts with the sibling 'manage_project_discipline' by noting the status is not an editable checkbox. This clearly distinguishes it from other project-related getters.

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

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

The description implies the tool is for reading a computed discipline status rather than managing or editing it, but it does not explicitly state when to use this tool instead of alternatives like 'get_project' or 'manage_project_discipline'. No exclusions or alternative recommendations are named, so guidance is only contextual.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description adds valuable behavioral context: it guarantees privacy-safety, enumerates what is returned, and explicitly excludes source, paths, URLs, tokens, and secrets—going beyond the structured annotations.

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

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

The description is two sentences with no filler. The primary action is front-loaded, and the second sentence compactly covers both return content and explicit exclusions.

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-only tool with annotations covering safety and idempotency, the description provides a clear picture of purpose, return categories, and privacy boundaries. It does not describe behavior when no workspace is attached, but this is a minor gap for such a simple operation.

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

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

The schema has 100% description coverage for project_id ('Exact saved 2ools project'), so the baseline is 3. The tool description does not add any parameter-level detail beyond mentioning 'one project', so no extra value is provided here.

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

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

The description names a specific verb ('Read') and resource ('Engine workspace attached to one project'), and it differentiates the tool from siblings by explicitly stating what is returned and what is never returned. This makes the tool's role clear even among many project-related tools.

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

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

The description clearly implies the tool is for reading an Engine workspace's identity, readiness, and metadata while avoiding sensitive data. It does not explicitly name alternatives or state when not to use it, but the context is specific enough for an agent to select it appropriately.

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

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

Annotations already carry the full safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar for additional disclosure is lower. The description adds a genuinely valuable behavioral guarantee — 'Missing premium access is reported as a gap, never invented' — which tells the agent how the tool handles absent data. This exceeds what annotations provide and is consistent with them.

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

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

The core purpose is front-loaded in the opening clause, and the component list is packed into a single efficient sentence with zero filler. It is slightly dense as one long enumeration of ten items, which makes quick parsing harder, but every clause earns its place and there is no redundancy.

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

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

This is a complex read tool with no output schema, so the description carries the burden of explaining the return surface. It enumerates the dossier components but stops at naming them — it does not clarify what concepts, ranked outputs, or connector visibility actually contain, nor whether any state has meaning an agent must interpret. Adequate for agent invocation, but thin for the richness of the returned object.

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 per the rubric the description must compensate. In practice the single parameter (project_id) is fully self-explanatory from its name and the schema documents its UUID format precisely, so little compensation is needed. The description adds nothing about the parameter, but nothing meaningful is missing either — a fair baseline 3.

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

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

The description names a specific verb ('Return') and a specific resource (the versioned frontier-product research dossier), and enumerates the discrete components it returns. This clearly distinguishes it from generic get_project/get_project_context siblings, though it never names them explicitly. The purpose is unambiguous even without sibling differentiation.

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

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

The description gives no guidance on when to choose this tool over the many sibling get_* tools (get_project, get_project_context, get_project_access, etc.), nor does it reference its write counterpart update_project_intelligence. There is no when-to-use or when-not-to-use information; usage context would have to be inferred entirely from the tool 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 the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds context about the 'bounded canonical' nature and server-derived health, but does not discuss potential caveats like rate limits, error conditions, or edge cases in pagination. No contradiction with annotations detected.

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

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

The description is a single sentence that front-loads the main purpose and then efficiently lists the view options. It is somewhat dense with comma-separated items, but every phrase adds meaningful information without wasted words. The structure is acceptable given the need to summarize multiple view modes.

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

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

Given the tool has 4 parameters, no output schema, and multiple view modes, the description gives a useful high-level overview but omits important details: the exact shape of each view, how the default view works (though the schema sets default to 'contract'), and how pagination parameters (limit/cursor) apply across the paginated slices. It is adequate for a read-only tool with strong annotations but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It describes the view options semantically (e.g., 'active Goal Contract' likely maps to the 'contract' enum, 'goals', 'templates', 'scope-change', 'history'), and mentions 'paginated' and 'slice' which hint at limit/cursor usage. However, it does not explicitly map the items to the enum names, nor explain the 'server-derived health' and 'role capabilities' as being part of the contract view rather than separate views. This creates some ambiguity.

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

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

The description uses a specific verb ('Return') and clearly identifies the resource ('Project Mission') while enumerating the distinct view types (contract, goals, templates, scope-change, history). This sets it apart from siblings like get_project_context or get_project_activity, which cover different project aspects.

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

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

The description implies this is the tool for reading mission/goal stack data, but it does not explicitly state when to prefer it over alternatives or exclude other tools. The title reinforces the niche, but no direct comparison to sibling tools is provided.

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, so the description's safety profile is covered. The description adds valuable behavioral context by specifying it returns 'bounded progress and lease evidence' and explicitly lists what it does not return (prompts, credentials, source, paths, private transcripts). This goes beyond the schema and annotations without contradicting them.

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

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

The description is a single, front-loaded sentence that states the purpose and scope immediately, followed by a second sentence clarifying exclusions and return type. Every word contributes value, with no redundancy or 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 state retrieval tool with three optional parameters and no output schema, the description covers the key elements: what it returns (bounded progress and lease evidence), what it excludes, and the scope (states of a dispatch). The schema handles parameter semantics, so the description provides sufficient context for an agent to use the tool correctly, though it could hint at how to choose among the three identifiers.

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

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

Schema coverage is 100%: all three parameters have detailed descriptions in the schema (job_id, assignment_id, idempotency_key) with formats, patterns, and usage notes. The description itself does not add any parameter-specific meaning beyond the general 'one exact governed task dispatch', so it neither compensates nor detracts from the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Read') and a precise resource ('authoritative ... state of one exact governed Project OS task dispatch'), enumerating the exact states covered. This clearly distinguishes it from siblings like get_engine_dispatch and get_work_handoff by focusing on the dispatch record itself rather than engine-level or handoff data.

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 read-only usage by stating it 'Reads' and explicitly lists exclusions (no prompts, credentials, source, paths, or private model transcripts), which helps an agent know what this tool does not do. However, it does not explicitly state when to prefer this over alternatives like get_engine_dispatch or get_work_handoff, leaving some inference needed.

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

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds critical context: what is returned (policy, freshness, receipt, findings) and the important caveat that a pass never replaces human review. This goes beyond annotations and is not contradictory.

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

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

Two sentences with no fluff. The first sentence front-loads the action and output, the second adds a valuable caveat. Every word earns its place.

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

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

The description enumerates return contents and includes a critical caveat, while annotations cover safety. With no output schema, the description does a good job of setting expectations. Missing edge-case behavior (e.g., no gate found) is a minor gap.

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

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

The schema fully documents assignment_id with format and pattern, but description coverage is 0%. The description's 'task-bound' hints at the parameter's role but does not explicitly explain it. For a single, self-named parameter, schema and name are sufficient.

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

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

The description uses a specific verb 'Return' and resource 'task-bound Quality Gate policy, freshness, deterministic check receipt, and attached findings.' It clearly distinguishes from the sibling 'run_task_quality_gate' by emphasizing retrieval of current state rather than execution.

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 through the read-only 'Return' and the 'task-bound' scoping, but there is no explicit 'use when' or alternative comparison. The human review caveat is a limitation, not a directive on when to use the tool.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds valuable context beyond annotations, such as the fact that disabled shares return no URL and the notion of 'durable sharing state.' This provides additional behavioral clarity without contradicting any annotations.

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

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

The description is two short sentences, front-loaded with the core action and resource. No wasted words; every phrase adds meaning.

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

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

For a simple read-only tool with good annotations and a meaningful sibling set, the description is mostly complete. It covers the main return value (URL) and an edge case (disabled shares). However, the lack of any mention of the 'page' parameter and the absence of an output schema prevent a perfect score.

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 of explaining parameters, but it only mentions 'one exact saved version' implicitly mapping to version_id and project_id. The optional 'page' parameter is left completely unexplained, which is a significant gap given the low schema 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?

The description states a specific action ('Read') on a specific resource ('durable sharing state and current URL for one exact saved version'), making the purpose unmistakable. It also distinguishes itself from sibling tools like create_version_share_link and revoke_version_share_link by focusing on retrieval.

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

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

The use of 'Read' clearly implies this is for retrieving an existing share link rather than creating or revoking one, which is reinforced by sibling tool names. It does not explicitly name alternatives, but the context provides sufficient guidance for an agent to know when to choose this 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context by emphasizing 'immutable' and 'honestly labeled' signals, which tells agents that the receipt does not change and that the data distinguishes between observed and forecasted values. This goes beyond the annotation baseline.

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

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

The description is a single sentence, which is concise, but it contains an awkward typo ('2ools-forecast' instead of 'tools-forecast') and the phrase 'honestly labeled worker-reported or 2ools-forecast context signal' is clunky. While not verbose, the odd wording reduces clarity and polish.

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

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

The tool is simple with one parameter, good annotations, and no output schema. The description lists the key returned components (receipt, lineage, signal) but does not explain their format or provide any usage example. For a read tool, it is adequate but leaves gaps about the expected output structure or how the lineage relates to the assignment_id.

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

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

The input schema has only one parameter (assignment_id) with 0% description coverage. The description does not mention this parameter at all, nor does it explain how to find or use assignment_id. The parameter name is self-explanatory to some extent, but the description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the tool returns a specific resource: the current immutable context-handoff receipt, task lineage, and context signal. The verb 'Return' and the specific object distinguish it from other getter tools like get_project_context or get_task_quality_gate.

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

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

The description implies usage for retrieving handoff context but does not explicitly state when to use this tool over alternatives like prepare_work_handoff or get_project_context. There is no when/when-not guidance, though the context of 'current immutable' suggests it is for reading the latest handoff.

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 are sparse (readOnlyHint=false, etc.), so the description carries most transparency burden. It adds important context: the operation does not widen ceilings (step, time, spend). However, it does not disclose what happens on failure, whether the lease is extended by a fixed duration, or any side effects of repeated calls (idempotentHint=false). Some added value but incomplete.

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

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

The description is a single, front-loaded sentence that delivers the core purpose immediately. Every word adds value—'Renew', 'authenticated worker', 'active lease', and the constraint about ceilings. No redundant or filler content.

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

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

Given the complexity (15 parameters, no output schema, no param descriptions), the description is far from complete. It doesn't explain how to use parameters, what values to provide for checkpoint or handoff fields, or what the response looks like. Without an output schema, the agent needs behavioral details about return values or errors, which are entirely 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 15 parameters and 0% schema description coverage, the description should compensate by explaining key parameters or usage patterns. Instead, it only vaguely refers to 'active lease' and provides no information about parameters like 'checkpoint', 'used_steps', 'handoff_reason', etc. The agent is left to infer from parameter names, which is insufficient.

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

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

The description uses the specific verb 'Renew' and targets a clear resource: 'work-session lease'. It explicitly mentions constraints ('without widening its immutable step, time, or spend ceilings'), which distinguishes it from siblings like 'checkpoint_work_session' (saves state) and 'submit_work_session' (ends session). The purpose is unambiguous and differentiated.

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

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

The description implies usage for keeping an active lease alive ('Renew the authenticated worker's active lease'), providing clear context. However, it offers no explicit guidance on when not to use this tool (e.g., use 'checkpoint_work_session' to save progress, 'submit_work_session' to end) or alternatives. The usage is implied but lacks exclusions or comparisons.

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 indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write nature is known. The description adds valuable context: claim tokens are emailed by 2ools and never returned through MCP. This is a non-obvious side effect that helps the agent set correct expectations and avoid hunting for tokens in the 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?

Two sentences with zero filler. The core purpose is front-loaded, and the behavioral caveat (emailing tokens) is the only extra sentence. Essential information is packed efficiently.

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 an invite action with no output schema, the description covers the key aspects: who can be invited, the required ownership, the roles, and the token email behavior. It doesn't mention failure conditions or required permissions beyond ownership, but these are reasonably inferred. A very solid, complete description for the tool's complexity.

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

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

Schema description coverage is 50%, and the description clarifies the 'identity' parameter (existing username or email) and implicitly scopes 'project_id' to an owned project. However, it does not explain the optional 'version_id' parameter or its purpose, and the schema already documents that field. The description adds some meaning but does not fully compensate for the uncovered parameters.

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

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

States a specific action (invite), the target (existing username or email), the scope (one owned project), and the roles (collaborator or viewer). This clearly distinguishes it from siblings like remove_project_member, revoke_project_invite, and update_project_member_role without needing to open their schemas.

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

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

Mentions the prerequisite of owning the project, and implies it's for granting access, but does not explicitly state when to use vs. alternatives (e.g., 'use this to add a collaborator, not to change a role' or 'when the invite is not yet sent, use revoke_project_invite'). The guidance is implied but not explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and non-mutating. The description adds key behavioral context: 'Returns project/version identity and attribution, never generated source' — confirming it returns metadata but not the generated content itself. This goes beyond annotations.

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

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

Two sentences, zero wasted words. Front-loaded with purpose, immediately followed by return constraints. Every sentence adds value and is appropriately sized given the sibling list length and tool complexity.

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 tool with fully defined schema parameters and complete annotations, the description covers the key return semantics (identity/attribution, no source). Without an output schema, mentioning that it never returns generated source is helpful. Minor gap: could hint at ordering or pagination, but not critical given the limit parameter.

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

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

Schema coverage is 100%, and the description does not add meaning beyond the schema fields (limit, status). The baseline of 3 is appropriate since schema already documents parameters clearly. The description could hint at defaults or format, but it does not.

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

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

The description states a specific verb ('List') and resource ('approval requests'), and clarifies it deals with 'exact saved versions waiting for a separately delegated reviewer'. This distinguishes it clearly from siblings like list_artifact_approval_requests and approve_artifact_version.

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

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

The description implies usage for retrieving pending reviews via 'waiting for a separately delegated reviewer', but does not explicitly state when to use this tool versus alternatives like list_artifact_approval_requests or approve_version. It provides helpful context but lacks explicit when-not-to-use or alternative names.

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 idempotentHint=true, readOnlyHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds behavioral context by specifying the scoping constraint ('exact artifact versions') and the authority requirement, which are not in annotations. No contradictions.

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 concise sentences: front-loaded with purpose, then constraint. No wasted words.

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

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

With no output schema, the description should explain what the tool returns. It does not describe the response format (e.g., list of version IDs, metadata). However, for a simple listing tool with good annotations and two parameters, the description is mostly adequate except for the missing return value explanation.

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. However, the description only hints at filtering by approval status indirectly ('awaiting or carrying a human review decision') but does not explain the status parameter or project_id parameter. The enum and format in schema help, but the description adds no additional meaning for the parameters.

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

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

The description uses specific verbs ('List') and resources ('artifact versions awaiting or carrying a human review decision'), clearly distinguishing from sibling tools like 'list_approval_requests' (which likely lists all approval requests, not artifact-specific ones) and 'list_artifacts' (which lists artifacts themselves).

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 explicitly states a usage prerequisite ('Requires separately delegated artifact review authority'), which helps the agent determine if the tool is applicable. However, it does not indicate when to use this tool versus alternatives like 'approve_artifact_version' or 'reject_artifact_version'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not required to repeat safety traits. It adds value by clarifying that the tool returns only metadata (latest immutable versions) and not the stored bytes, which is a critical behavioral trait not captured by annotations.

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

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

The description is a single sentence of 13 words, front-loaded with the verb and resource. It contains no filler, directly conveys the essential information, and every word earns its place.

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

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

For a simple list tool with one parameter and no output schema, the description covers the core action and scope. However, it omits details about pagination, ordering, filtering, or the structure of the returned list (e.g., what fields are included). An agent may need to guess at the output format, which limits completeness.

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 undocumented parameter. The description does not mention 'project_id' at all, nor explain its role, format, or constraints. The schema provides a UUID pattern, but the description adds no semantic value for the parameter, leaving the agent without guidance on how to specify the project.

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

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

The description clearly states the action ('List'), the resource ('durable project artifacts'), and the scope ('each latest immutable version'). It also distinguishes itself from siblings by specifying 'without returning stored bytes', which contrasts with tools like 'get_artifact' or 'prepare_artifact_download' that likely return bytes.

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

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

The description provides clear context on what the tool does and does not return (no bytes), implying when to use it (when you need metadata only). However, it does not explicitly name alternative tools for byte retrieval, leaving the agent to infer from sibling names. Still, the context is sufficient for basic usage decisions.

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 indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that only custom systems created by the authenticated account are returned, and built-in systems are private and excluded. This adds behavioral context beyond annotations, but does not cover other behaviors like pagination, ordering, or error scenarios.

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

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

The description is two sentences, front-loaded with the main action and scope. The second sentence clarifies what is not returned. However, the typo '2ools' (likely meant 'tools') slightly reduces professionalism. No unnecessary words, earning a high score.

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

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

For a simple list tool with one optional parameter and no output schema, the description covers the source (authenticated account's custom systems), filter, and exclusions. However, it does not mention return format, pagination, or ordering, which are typical for list tools. Adequate but not fully comprehensive.

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

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

The schema description coverage is 100% for the single parameter (output_target with enum values). The description mentions 'compatible with an optional output target', which echoes the schema without adding new meaning. Baseline 3 is appropriate as the schema already provides sufficient 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 clearly states it lists custom build systems created by the authenticated account, with an optional filter by output target. It distinguishes from sibling tools (e.g., list_projects, list_artifacts) by specific resource and scope. The title and description align, providing a precise verb+resource combination.

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 explains when to use the optional filter (omit for all compatible systems), but does not explicitly state when to use this tool versus alternatives (e.g., other list tools). Usage context is implied by the resource name, but no exclusion criteria or best practices are provided.

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, and non-destructive behavior, but the description adds substantial behavioral context beyond that: it explicitly promises redacted labels, privacy-safe workspace handles, and the last observed timestamp, and it enumerates what the tool will never return (tokens, paths, repository URLs, SSH hosts, secrets, raw device labels). This gives an agent strong, safety-relevant expectations for side effects and data exposure before invocation.

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 compact: one sentence states purpose and one sentence states output/privacy guarantees, with the main purpose front-loaded. Every clause adds information. The typo in '2ools' and the minor mismatch with the title 'computers' keep it just short of excellent, but structurally it is well organized and free of 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 no-parameter, read-only listing tool with no output schema, the description covers what an agent needs: the purpose, the exact fields returned, and the sensitive data that will not be returned. It also includes relevant privacy scope. Nothing essential is missing for safe invocation, and the annotations cover the side-effect profile.

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

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

The tool has zero parameters and the input schema is empty, so there is no parameter space for the description to clarify. The schema coverage is 100% and no parameters exist, so the baseline of 4 applies; the description appropriately focuses on output semantics instead of parameter details.

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

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

The description clearly identifies the action ('List') and the resource ('connected 2ools Engines'), and it enumerates the specific fields returned. It differentiates from a generic listing by adding 'privacy-minimized' and 'for exact native dispatch', though it never names sibling tools like list_build_systems or get_engine_dispatch. The '2ools' typo slightly detracts, but the overall intent is unambiguous.

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

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

The phrase 'for exact native dispatch' implies a primary use case and signals that this listing exists to support dispatch, which is useful context. However, it provides no explicit when-to-use vs. alternative guidance, no mention of sibling tools, and no exclusions for scenarios such as needing more detailed engine state or dispatch execution. Usage guidance is implied rather than explicit.

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

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

The annotations already provide readOnlyHint true, idempotentHint true, and destructiveHint false, so the safety profile is clear. The description adds value by specifying it returns status and summary (not full Limits or run traces), which is helpful behavioral context 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 is two sentences, completely front-loaded with the core action, and every sentence adds distinct value (scope, limitations). No 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?

Given readable annotations, a single simple parameter, and no output schema, the description is nearly complete. It covers purpose, scope, and constraints. An explicit note about the return structure of 'status and summary' would push it to 5, but it is already sufficient.

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

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

Schema coverage is 100%, so the schema fully documents the project_id parameter with format and pattern. The description adds no additional meaning to the parameter beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states it lists 'built-in Agents assigned to one readable project' with a specific verb ('List') and resource ('Agents'). It distinguishes from sibling tools like list_artifacts or get_agent by scoping to the authorizing account's agents per project.

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

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

The description implies usage for exploring agent status and summary within a project, and tells what NOT to expect (full Limits or run traces), providing some when-not guidance. It does not explicitly name alternatives (e.g., get_agent for details of a specific agent), but the context is adequate for an agent.

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 mark it read-only, idempotent, and non-destructive. The description adds behavioral detail that it never returns secrets or internal prompts and that unknown future response kinds remain in Project OS, providing useful context 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?

Two sentences, front-loaded with the core purpose and field list, followed by a concise security note. No wasted words.

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

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

There is no output schema, so the description lists returned fields, which helps. However, it lacks details on pagination (limit) and state filtering, and does not explain the behavior of the state parameter. This makes it incomplete for an agent to fully understand how to use the parameters to get the desired results.

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

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

With schema description coverage at 0%, the description must explain parameters. It does not mention how 'limit' or 'state' affect results (e.g., state filters by pending/resolved/all), nor does it clarify the scope of project_id beyond being required. This is a significant 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?

The description clearly states the tool lists engineering decisions for a specific project, and enumerates the exact fields returned (canonical revision, category, risk, etc.), distinguishing it from the sibling 'answer_project_engineering_decision' which handles answering, not listing.

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 specifies that it operates on 'one exact project', implying a precise project_id is required. No explicit alternatives or when-not-to-use are given, but the context is clear and it's distinct from the sibling answer 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only, effect-free operation. The description adds that the feedback is 'page-anchored' and 'review feedback' with attribution – context beyond annotations. However, it does not disclose pagination, ordering, or error/edge-case behavior (e.g., what if the project has no versions). Annotations cover the core, so a 3 is appropriate.

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

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

The description is a single concise sentence that packs the key aspects: read-only, scoped to versions, anchored to pages, with explicit attribution. No filler, every word adds value.

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

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

For a 2-parameter tool with no output schema and full annotation coverage, the description provides sufficient context: the scope (project versions, page-anchored, attribution type). It misses only minor details like return format or whether it includes unresolved by default (the default for include_resolved is already in the schema). Only minor gaps remain, so a 4 fits.

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

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

Schema description coverage is 100%, meaning the schema already describes both parameters ('project_id' and 'include_resolved'). The description does not add additional meaning about these parameters beyond what the schema provides. Baseline 3 is correct.

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

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

The description uses specific verbs ('Read'), identifies the resource ('page-anchored review feedback for versions in a project'), and clarifies the attribution type ('explicit human or external-agent'). This clearly distinguishes it from siblings like add_project_feedback or resolve_project_feedback, which are write/update operations.

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

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

The description implies usage: use when you need to read feedback with explicit attribution. The sibling context includes add_project_feedback, resolve_project_feedback, and many read tools, but the description does not explicitly state when NOT to use this tool or name alternatives. Still, the differentiation is clear enough for an agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds minimal behavioral context beyond the annotation set, only specifying that outputs include 'explicit attribution'.

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

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

The description is a single, front-loaded sentence with no extraneous words. Every part of the sentence serves the purpose.

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 1 parameter and rich annotations, the description is adequate but incomplete. It does not mention return format (list of items), pagination, or that it returns all pins for the given project.

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 description does not explain the project_id parameter. The parameter name suggests it identifies the workspace, but no additional semantics or usage hints are provided.

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

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

The description uses the specific verb 'Read' and identifies the resource as 'shared workspace notes and http(s) links', clarifying what pins contain. This clearly distinguishes the tool from siblings like add_project_pin and remove_project_pin.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The agent must infer from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds useful behavioral context beyond annotations: it opens the native Project OS entry point, auto-continues the only saved project, shows an inline chooser when multiple are available, and returns compact metadata without generated source. This enriches the agent's understanding of what happens on invocation.

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 three sentences with no extraneous content. It front-loads the core purpose and adds concise behavioral notes. The phrase 'Open the native Project OS entry point' is somewhat redundant but not harmful; overall it is well-structured and efficient.

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

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

With no output schema, the description appropriately explains the return value ('compact metadata without generated source'). It covers key context: auth scope, behavior for one vs. multiple projects, and the read-only nature. Nothing critical for an agent to call this tool 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 schema documents the sole 'limit' parameter with a clear description ('Maximum projects to return') and 100% coverage. The description adds no additional details about the parameter (e.g., ordering, defaults) beyond what the schema provides. Baseline of 3 is appropriate given complete schema 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?

The description clearly states the verb 'list' and the resource 'recent 2ools projects' accessible to the authenticated account. It distinguishes from siblings like 'get_project' by focusing on listing multiple projects and explicitly notes that it returns compact metadata without generated source, which further differentiates it from tools that return full project data.

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

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

The description implies this is the entry point for browsing projects, but it does not explicitly explain when to use it versus alternatives like 'continue_project' or 'activate_project'. The behavior of auto-continuing or showing a chooser suggests it is for selection, but no direct comparison or exclusion is provided.

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 provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds some behavioral context by listing the types of work assignments included, but does not go beyond what annotations convey. It does not contradict annotations.

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

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

The description is a single sentence, concise and front-loaded with the verb 'List.' It efficiently lists the resource types without extraneous words, though it could be slightly more structured (e.g., separating filtering hints).

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

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

Given the tool has 2 parameters, no output schema, and annotations present, the description is incomplete. It fails to mention that project_id is required, that status can be used for filtering, or what the output format is (e.g., list of work assignments). The agent lacks key context for correct invocation.

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

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

Schema description coverage is 0% (no parameter descriptions in the schema). The description does not mention any parameters, including the required project_id or the optional status enum. It fails to add meaning beyond the schema's minimal type/format info, which is insufficient for a low-coverage scenario.

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

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

The description clearly states the verb ('List') and specifies the resource types: 'durable project work contracts, bounded attempts, leases, budgets, and result references.' This distinguishes it from sibling tools like create_work_assignment, claim_work_assignment, and decide_work_assignment by indicating exactly what is being listed.

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

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

The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions. It only states what is listed, leaving the agent to infer usage context without explicit direction.

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 signal idempotent and non-destructive behavior. The description adds meaningful behavioral specifics: self-acceptance of proposals is prohibited, and verifier definitions are purely descriptive and never execute arbitrary code. These are non-obvious constraints beyond the structured fields, and they don't contradict any annotations.

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

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

The description is compact at two sentences and front-loads the core actions. The second sentence adds useful governance context but is dense and contains a typo ('2ools'), which slightly reduces clarity. Overall, it earns its place without excessive verbiage.

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

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

This is a high-complexity tool with five distinct change types and no output schema. The description provides a useful high-level overview and policy reminders, but it doesn't explain prerequisites (e.g., project_id is required) or offer hints about constructing the change object. Given the rich schema, the description is a decent starting point but not a complete guide for correct invocation.

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

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

Schema description coverage is 0%, so the description carries a heavy burden. It maps the high-level actions (propose, version, attach) to the oneOf change variants, giving semantic scaffolding. However, it offers no field-level detail about project_id or the internal structure of the change object, leaving the agent to rely entirely on the schema for parameter meaning.

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 three concrete verb-resource pairs: propose a project trade-off, version an eval case or verifier definition, and attach an eval/verifier receipt. It clearly situates the tool in the project-discipline domain and differentiates it from read-only siblings like get_project_discipline, though it doesn't enumerate the exact action constants such as propose_decision or save_eval_case.

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

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

The description implies the tool is for recording discipline evidence but does not explicitly say when to prefer it over alternatives like add_project_feedback or manage_work_watchdog. It does supply practical governance constraints (agents cannot accept their own proposals; verifier definitions never execute code), which helps narrow appropriate use, but lacks explicit alternative 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 convey idempotent/destructive hints. The description adds valuable boundary context: it never answers for the user, approves risky actions, deploys, spends, sends externally, deletes data, or widens authority. This goes beyond annotation fields and helps the agent understand safety/scope constraints.

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

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

Two sentences, no filler. The first sentence front-loads the primary actions, the second adds useful boundary conditions. Every word earns its place.

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

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

Given the complex oneOf schema, two required parameters, and no output schema, the description is incomplete. It does not describe return values, side effects, what 'park' vs 'pause' means, error behavior, or prerequisites. The high-level scope is present, but not enough for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It vaguely maps to the 'change' parameter's actions (pause/park/resume/reprioritize/configure) but does not explain required fields like assignment_id, expected_revision, idempotency_key, or the configure policy structure. The description adds minimal value for 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 uses specific action verbs ('Pause, park, resume, or reprioritize', 'configure') tied to a clear resource ('one durable task', 'project Watchdog'), and distinguishes itself by listing excluded actions. This is a specific and differentiating purpose statement.

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 action list implies usage contexts, and the 'never' clause provides explicit exclusions (e.g., not for approving risky actions). However, it does not name sibling tools or give explicit 'when to use this instead' guidance, leaving usage to be inferred.

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

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

The description adds value beyond the readOnlyHint annotation by disclosing the 5-minute expiration and the privacy guarantee that stored bytes never enter MCP model output. These are not in the annotations and provide important behavioral context. No contradiction with annotations.

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

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

The description is two sentences with no wasted words. The primary purpose is front-loaded in the first sentence, and the secondary behavioral note is in the second. Every sentence adds unique 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?

Given the tool's simplicity (3 UUID params, no output schema, good annotations), the description adequately covers purpose, expiration, and a privacy guarantee. It does not describe the return format (the URL), which could be useful, but overall it is sufficient for an agent to understand and invoke 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?

The input schema has 0% description coverage for its three UUID parameters, and the tool description does not explain any parameter semantics. The parameter names ('project_id', 'artifact_id', 'artifact_version_id') are self-explanatory, but the description could clarify that the version must be immutable (hinted) or how to obtain these IDs. It does not compensate for the missing schema descriptions.

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

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

The description clearly states the tool creates a five-minute download URL for one immutable artifact version. It uses a specific verb ('prepare') and resource ('artifact download'), and distinguishes itself from siblings like 'prepare_artifact_upload' (upload direction) and 'get_artifact' (likely metadata retrieval).

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

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

The description implies use when an artifact version needs to be downloaded via a temporary URL, but it does not provide explicit guidance on when to avoid this tool (e.g., if the agent needs the artifact content directly in the model output) or mention alternative tools like 'get_artifact' for metadata. Usage context is clear but not contrasted with 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 indicate mutation (readOnlyHint=false) and non-destructive intent. The description adds behavioral details: URL expiry, exact bytes requirement, and the review lifecycle, which go beyond annotations. No contradiction exists.

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

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

Two sentences pack key purpose and behavioral constraints without extraneous detail. Every word earns its place.

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

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

Despite 10 parameters, no output schema, and complex behavioral context (review, URL expiry), the description omits what the tool returns, how to use the URL, parameter interactions, and error conditions. It is incomplete for an agent to correctly invoke the tool.

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

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

Schema description coverage is only 20% (2 of 10 parameters have descriptions). The description contributes no parameter-level meaning, leaving 8 undocumented parameters. With such low coverage, the description must compensate but fails to do so.

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

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

The description clearly states the tool creates a five-minute PUT URL for exact bytes, distinguishing it from sibling prepare_artifact_download. The verb 'create' and resource 'PUT URL' are specific, and the mention of external-agent review adds context.

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 explicitly notes that external-agent output always enters pending review and does not replace the current version before approval, providing clear context for when this tool is used. However, it does not explicitly state when not to use it or mention alternatives beyond sibling tools.

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