ContextLayer

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'accept' but does not clarify the effect (e.g., adding the user to the organization), whether the invite is consumed, or if any permissions are required. Accepting is a mutating operation, yet no such detail is given.

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, compact sentence with no filler. It is front-loaded with the action and includes the essential qualifier. 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's simplicity (one parameter, no output schema, no annotations), the description covers the core action and input adequately. However, it lacks post-conditions such as what happens after acceptance and whether the user must be the invitee. This is a minor but notable gap for a state-changing tool.

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

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

The schema already describes org_name fully (100% coverage), and the description merely restates 'by organization name' without adding new meaning. No extra guidance is provided on exact matching, case sensitivity, or how to obtain the organization name.

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

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

The description clearly specifies the verb 'Accept', the resource ('pending organization invite'), and the input criterion ('by organization name'). This distinguishes it from sibling tools like invite_user (which sends invites) and list_pending_invites (which only lists them).

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

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

The description implies usage by describing the action itself, but it does not explicitly state when to use this tool versus alternatives. It does not mention prerequisites such as having a pending invite or needing to list invites first. No exclusions or alternative tool references 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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It does explain the side effect (agents working on blocked tasks get warned) and the conceptual effect (dependency edge). Yet it fails to mention reversibility, permissions, or behavior on duplicate dependencies—important for a mutating tool. It adds some context beyond the schema but not comprehensive.

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 long, front-loaded with the action, and every sentence carries purpose or usage context. No redundant phrasing 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 simple tool with only three parameters and no output schema, the description covers the core purpose, usage context, and a behavioral consequence. It omits edge-case behavior (e.g., duplicate dependencies, validation), but these are not essential for a tool this simple. Overall, it provides enough context for an agent to select and 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% for all three parameters, so the schema already documents each parameter clearly. The description adds marginal value by rephrasing the dependency direction ('task is blocked by another task'), but it does not introduce new semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb phrase ('Add a dependency between tasks') and clearly identifies the resource and action. It distinguishes itself from sibling tools like remove_task_dependency by explicitly stating the 'Add' intent and elaborating on the dependency semantics ('blocked by' / 'relates to').

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 explicit context for when to use the tool: 'Use this to express that a task is blocked by another task... or relates to it.' It also explains the benefit (prevents context contamination). However, it does not explicitly mention when not to use it or contrast with similar tools (e.g., remove_task_dependency), lacking clear 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but does not disclose whether adding is idempotent, what happens if the user is already a team member, whether permissions are required, or what the return value indicates. This is a significant gap for a mutation tool.

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

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

The description is two short sentences, front-loaded with the core action. The second sentence efficiently explains how to identify the team and user without redundancy. Every clause contributes 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?

There is no output schema or annotations, and the description does not mention return values, error conditions, or prerequisites. For a mutation that adds a member, the agent is left unaware of expected outcomes or failure modes. The description is minimal and missing critical context for a complete 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?

The input schema has 100% description coverage, so the baseline is 3. The description's phrase 'find the team by name or ID, and the user by name or email' essentially mirrors the schema's parameter descriptions and adds little new semantic value. No extra syntax, constraints, or examples 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 a specific verb and resources: 'Add a member to a team' clearly states the action and target. It distinguishes from siblings like 'remove_team_member' and 'invite_user' by explicitly indicating adding an existing member to an existing team. The additional sentence about finding the team by name or ID and the user by name or email further clarifies 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 provides no guidance on when to use this tool versus alternatives such as 'invite_user' for new users. It does not mention exclusions or prerequisites, and the only additional information is about parameter identification rather than usage context. No explicit or implicit usage scenarios are given.

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

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

No annotations are provided, so the description carries the burden. It discloses key side effects: the user is added to the task's assignees and linked in the knowledge graph. However, it omits potential error conditions, permission requirements, or idempotency behavior.

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

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

Two concise sentences front-loaded with the action, followed by the effect. No wasted words; every clause 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 simple 2-param tool with no output schema, the description covers the action, identification method, and side effects (assignees update and knowledge graph linkage). Minor gaps like error handling do not significantly detract from 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 coverage is 100% with clear descriptions for both parameters ('User name or email to assign' and 'Task ID'). The description reinforces the 'user' parameter with 'by name or email' but adds no additional parameter-level semantics 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 states the action: assign a user to a task, with the method (by name or email). It distinguishes itself from siblings like unassign_task (opposite) and link_task_session (different relation).

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

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

The description implies when to use the tool (when assigning a user to a task) but provides no explicit alternatives or exclusions. It does not mention related tools like unassign_task or prerequisites for assignment.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds the admin-only permission constraint, but does not describe side effects, return value, duplicate handling, or other behavioral details, leaving gaps.

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 unnecessary words. It efficiently conveys the action, resource, and a key constraint.

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 schema and admin-only note cover the basics, but the lack of an output schema and any mention of the success response, errors, or uniqueness constraints leaves some contextual gaps for a create 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 input schema already has 100% description coverage for all parameters, including a useful reference to list_positions for permission keys. The tool description itself adds no parameter-specific meaning, 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 uses a specific verb ('Create') and resource ('job position/title'), and adds the 'admin only' scope. This clearly distinguishes it from sibling tools like update_position and delete_position.

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 use it (creating a position) and includes the admin-only prerequisite. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses one behavioral trait: 'You will be added as the project owner.' However, it does not mention any side effects, permissions required, or post-creation state beyond ownership. This is a useful but limited disclosure.

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

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

The description is two sentences: the first defines the core action, the second adds a relevant outcome. It is front-loaded and every word earns its place 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?

For a simple create operation with only two parameters and no output schema, the description is sufficiently complete. It identifies the resource and the side effect (ownership). It could mention that the project is created immediately or any required prerequisites, but given the low complexity, the current description is adequate.

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

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

Schema description coverage is 100%, with both 'name' and 'description' already described accurately in the input schema. The description adds no additional meaning about the parameters, such as naming constraints or uniqueness, so it does not elevate beyond the baseline.

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

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

The description clearly states the action ('Create a new project') and the resource ('project') with a specific context ('in your organization'). It distinguishes itself from sibling tools like 'create_task' and 'create_team' by focusing on projects. The added detail about becoming the project owner further clarifies the 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 implies the tool is for creating new projects but does not explicitly state when to use it versus alternatives like 'update_project' or 'delete_project'. There are no exclusions or alternative guidance, though the verb 'create' for a project is fairly 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses key non-obvious traits: automatic migration of non-completed tasks from the previous sprint and the special first-use initialization (Sprint 0/1). However, it does not mention prerequisites like requiring exactly one of project_id/project_name, or any side effects on the previous sprint.

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, with two sentences that first state the core action and then the behavioral details. No unnecessary words or repetition of schema 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 is fairly complete for a simple creation tool but fails to explicitly state that a project must be identified via project_id or project_name, and how the tool resolves when both or neither are provided. Given the optional schema, this is a notable gap.

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

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

The input schema provides descriptions for all four parameters, so the baseline is 3. The description adds nothing beyond the schema regarding parameter usage, selection, or validation.

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

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

The description clearly states the action ('Create a new sprint') and the target ('for a project'), and adds a distinguishing behavior (task migration) that differentiates it from sibling tools like move_task_to_sprint. The verb and resource 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 description implies usage context through the migration behavior but does not explicitly explain when to choose this over alternatives such as move_task_to_sprint or list_sprints. No exclusions or when-not guidance is provided beyond the inherent behavior.

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?

There are no annotations, so the description must fully disclose behavior. It only says 'Create a new task' and mentions tasks can be assigned and linked, but does not describe side effects, return values, permission requirements, or failure modes. This is insufficient for a mutation tool with no safety 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 long and front-loads the core purpose in the first sentence. The second sentence provides useful context without any 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?

For a create tool with 12 parameters and no output schema, the description is quite sparse. It lacks high-level details such as default behaviors, resolution rules, or what happens after creation. However, the comprehensive schema compensates for many param-level details, making the description minimally viable.

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% description coverage for all parameters, so the description need not repeat parameter details. The description adds minimal extra meaning beyond the schema, such as the capability to link to sessions, but overall it does not significantly enhance 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 explicitly states 'Create a new task in a project,' which clearly identifies the action, resource, and scope. It also differentiates from sibling tools like assign_task and add_task_dependency by focusing on creation rather than assignment or dependency management.

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 this tool is for creating tasks, but it does not explicitly mention when to choose it over alternatives or provide exclusions. Sibling tools like assign_task and link_task_session suggest related operations, but the description does not address when to use them 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?

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the user will be added as team lead, which is a non-obvious side effect. However, it doesn't mention permissions, reversibility, or any return details, so it is informative but not comprehensive.

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

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

Two short sentences with no filler. The description is front-loaded with the primary action and follows with the key side effect.

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

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

For a simple create operation with no output schema and full schema coverage, the description effectively conveys the essential behavior. It might be slightly thin on return behavior or prerequisites, but it's sufficient for an agent to invoke it correctly. The side effect of becoming team lead adds valuable 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 100%, covering 'name', 'objectives', and 'description' with clear descriptions. The tool description doesn't add parameter-specific details, which is acceptable given the schema's completeness, so baseline 3 applies.

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

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

The description clearly states the tool creates a new team in the user's organization, using the verb 'create' and resource 'team'. It is distinguished from siblings like update_team, delete_team, and add_team_member by its focus on creation. The additional note about being added as team lead further clarifies the tool's role.

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 a new team is needed, with no explicit alternatives or exclusions. It provides clear context by scoping the operation to 'your organization' and noting the creator becomes team lead, but it doesn't name sibling tools like add_team_member for comparison. This is clear context without exclusions, meriting a 4.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It adds the critical trait of permanence ('This permanently removes the document'), but it does not mention permissions, effects on linked data, or behavior for non-existent IDs. Partial disclosure.

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

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

Two short sentences with zero wasted words. The first sentence states the action, the second adds the key caveat of permanence. Well-structured and easy to parse.

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

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

For a simple single-parameter delete tool with no output schema and no annotations, the description covers the essential purpose and permanence. However, it could still benefit from a note about idempotency or errors, but those are not critical for successful 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?

The schema already fully describes document_id ('Document ID to delete'), and the description adds no extra meaning beyond the action. Since schema description coverage is 100%, the baseline of 3 applies.

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

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

The description clearly states a specific action ('Delete a document') and a specific resource ('from the knowledge base'), distinguishing it from sibling delete_* tools like delete_task or delete_team. It is unambiguous and immediately understandable.

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

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

The description implies when to use the tool: whenever a document needs to be permanently removed. It does not explicitly exclude alternatives or mention 'when not to use', but for a delete operation no other tool is a viable substitute. Clear context with no exclusions.

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

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

With no annotations, the description bears the full burden. It discloses two important behaviors: the deletion is permanent (irreversible) and limited to admins. However, it does not mention potential side effects such as what happens to tasks or members associated with the position, nor error handling if no match is 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 exactly two sentences and every word earns its place. It front-loads the core action and permission, then provides lookup guidance without any redundant information.

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

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

For a simple delete tool, the description covers the essential context: what it does, admin requirement, and how to identify the target. It lacks edge-case handling (e.g., both params provided) and return behavior, but these are minor for a delete operation. With no output schema, slightly more detail would be ideal, but the description is still 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?

Schema coverage is 100%, so the parameters are already documented. The description adds that you can 'find by title or ID', reinforcing the mutually exclusive nature hinted at in the schema. However, it does not clarify which parameter takes precedence if both are provided, nor does it state that at least one is required.

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 'delete' and the resource 'position', with the qualifier 'permanently' indicating scope. It also distinguishes itself from sibling delete tools by specifying the 'position' resource, making it unambiguous what this tool operates on.

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 specifies an 'admin only' restriction, providing a clear prerequisite for use. It does not explicitly compare alternatives, but the resource name 'position' clearly implies when to use this tool versus deleting other entities like projects or teams.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: the deletion is permanent (irreversible) and restricted to admins. However, it does not mention potential side effects such as cascading deletions of associated tasks/documents, nor does it describe any response or error behavior.

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

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

The description is a single front-loaded sentence that efficiently conveys the action, permission level, and identification methods. 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?

Despite having no output schema and no annotations, the description covers the essential aspects for a simple delete operation: what is deleted, that it is permanent, who can perform it, and how to identify the target. This is sufficient for most use cases, though it lacks details on consequences to related data.

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

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

The input schema already provides 100% coverage with descriptive text for both parameters. The description only adds a brief 'Find by name or ID' clause that restates what the schema already conveys, so it adds no significant extra 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 clearly states the tool's action ('Delete a project permanently') and identifies the resource (project). It also adds the admin-only constraint, distinguishing it from other delete tools that target different resources. The verb and resource 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 description provides clear usage context by stating the admin-only requirement and the ability to find the project by name or ID. However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of full 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the permanent removal and the cascading effect on assignee links, which are important behavioral consequences beyond just 'delete task'. This is concise but informative, revealing destructive scope without unnecessary detail.

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

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

The description is extremely concise at two short sentences, immediately front-loading the core action and key consequence. Every word contributes: 'permanently' signals irreversibility, and 'all assignee links are removed' clarifies scope without redundancy.

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

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

For a simple tool with one parameter and no output schema, the description is complete. It explains what gets deleted, the permanent nature, and the cascading effect on links. No additional return value explanation is necessary as the schema and semantics are straightforward.

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

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

The input schema already describes the single parameter task_id as 'Task ID to delete' with 100% coverage. The description adds no additional parameter-level semantics beyond what's in the schema, but it does clarify the behavioral effect on the task entity, which is sufficient for a simple one-parameter tool.

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 'Delete a task permanently' with the specific resource (task) and a key nuance (permanently), which distinguishes it from update or unassign operations. It also notes the additional scope of removing assignee links, further differentiating it from simpler delete 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 when to use this tool (when you want to permanently remove a task) but does not explicitly contrast it with alternatives like update_task or unassign_task. It gives no explicit exclusions or 'when not to use' guidance, though the phrase 'permanently' offers a caution about its irreversible nature.

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

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

No annotations are provided, so the description carries the full burden of disclosure. It does state that the deletion is permanent (irreversible), which is a critical behavioral trait, and that admin permission is required. However, it omits potential cascading effects (e.g., what happens to linked projects, tasks, members) and does not clarify error behavior if both or neither name/ID are 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?

The description is a single sentence of 9 words, front-loaded with the action 'Delete a team permanently'. It includes only essential information—permission level and identification method—with no redundant or filler content.

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

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

For a simple two-parameter delete tool, the description covers the core operation, permission, and identification. However, it lacks details about return values, error conditions, and potential side effects, which matters because there is no output schema or annotation to fill those 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 input schema already fully documents both parameters: team_id and team_name, each described as optional if the other is provided. The description's 'Find by name or ID' merely summarizes this without adding new semantics. With 100% schema coverage, the baseline 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 a specific verb 'Delete', identifies the resource 'team', and adds key qualifiers 'permanently' and 'admin only'. It clearly distinguishes from sibling delete tools (e.g., delete_document, delete_project) by naming 'team' and from update_team by using the delete verb.

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 the operation is admin-only, giving a clear when-not condition (non-admins should not use). It also tells the agent that the team can be found by name or ID, providing practical usage context. However, it does not mention alternative tools or contrast with update_team for cases where a soft delete might be 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?

With no annotations provided, the description carries the full burden. It discloses the non-obvious behavioral trait of 'soft-delete' and the permission requirement (admin/owner only), which is valuable. However, it does not explain the consequences of soft-deletion (e.g., reversibility, effects on user's data).

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 communicates action, resource, and constraint without any fluff. 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 tool with one simple parameter and no output schema, the description covers the essential context: what it does, who can use it, and the soft-delete nature. It lacks details on post-deletion effects, but given the tool's simplicity, it is mostly 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 schema fully documents the single parameter 'user' as 'User name or email to delete'. The description adds minimal extra semantic value beyond restating the org scope and permission, so the baseline 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 action (soft-delete) and the target resource (a user from the organization), while also specifying the required role (admin/owner only). This distinguishes it from sibling tools like update_user or invite_user.

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 a clear prerequisite (admin/owner only) but does not differentiate from similar sibling tools like remove_user_from_org, nor does it explicitly state when to use this over alternatives. The usage context is implied by the role restriction.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It explicitly says that ending the session triggers context block generation, where activities are summarized and stored in the knowledge graph. This is meaningful behavioral context beyond the simple action of ending a session, though it does not mention other potential side effects like irreversibility or permission requirements.

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

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

The description is two sentences, with the primary purpose in the first sentence and a key side effect in the second. It is front-loaded, concise, and contains no extraneous 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 tool has no output schema, but the description explains the purpose and a significant side effect (context block generation). It provides enough context for an agent to decide when to use the tool and what to expect. It does not detail return values, but with no output schema declared, this is a minor gap given the tool's straightforward nature.

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

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

The input schema already provides descriptions for all three parameters (outcome, session_id, token_usage), achieving 100% schema coverage. The description does not add parameter-specific semantics beyond the overall context of summarizing activities, so the baseline 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 tool's function: 'End a work session.' It also adds a distinguishing detail about triggering context block generation, which sets it apart from sibling tools like 'start_session' or 'list_sessions'. The verb+resource combination 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 description implies the usage context: this should be called when a work session is being ended. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The guidance is present but implicit.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the tool returns metadata, not full content, which is a key behavioral trait. However, it omits details like default limit behavior or potential need for at least one filter, but these are partially covered by the schema.

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

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

The description is two sentences, front-loaded with the core action, and every word adds value. The first sentence states purpose and filters; the second explains return type and directs to an alternative. No waste or redundancy.

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

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

Given the absence of an output schema and annotations, the description could do more to explain the structure of the returned metadata or the behavior when no filters are provided. It points to get_document but doesn't specify how results are connected (e.g., document ID). This leaves gaps for an agent needing to invoke get_document after searching.

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

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

Schema description coverage is 100%, so the baseline is 3. The description lists 'category, tags, project, or free-text query' as filters, which maps to some parameters but omits team_name and limit. It adds no new semantic meaning beyond the schema, so a 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 tool 'Search documents in the organization's knowledge base,' using a specific verb and resource. It also distinguishes itself from the sibling get_document by noting it returns metadata, making its purpose 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 provides explicit guidance: 'Returns document metadata — use get_document to read the full content.' This directly tells the agent when to use this tool (for search/metadata) and when to use an alternative (for full content). This is a clear when/alternative directive.

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?

Although no annotations are provided, the description discloses key behaviors: intent analysis, graph traversal, semantic similarity, and automatic routing to multiple data sources. It does not describe output format or error handling, but as a retrieval tool the internal mechanism is well explained.

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 and front-loaded, stating the primary purpose first and then the routing mechanism. The optional scope sentence is additional but relevant. No fluff or repetition.

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 provides a solid overview of how the tool works and what it considers, which is sufficient for most use cases. It does not describe the exact return format, but with no output schema, this is a minor gap. The complexity of the knowledge graph is well addressed.

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 provides 100% coverage with detailed descriptions for all five parameters, so the baseline is 3. The description adds only a minor note about optionally narrowing scope, which is already reflected in the schema's optional flags and 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's function: 'Get intelligent context from the knowledge graph' with a specific verb and resource. It also distinguishes itself from siblings like get_context_routing by explaining the automatic routing mechanism and the data sources involved.

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 usage context: pass a query and the system routes automatically. It mentions optional narrowing by project name or session ID, which guides when to use scope parameters. However, it does not explicitly state when not to use this tool or alternative 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?

No annotations are provided, so the description carries the full burden. It discloses the possible return values ('keyword_llm', 'keyword_only', 'llm_only') but does not explicitly state that the operation is read-only or describe error/permission behavior. The verb 'get' implies non-mutating behavior, but more context could be added.

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

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

The description is a single, concise sentence that front-loads the action and resource, then lists the possible return values. Every word earns its place 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?

Given the zero parameters and absence of an output schema, the description provides all necessary information: what the tool does and what it returns. It is complete for a simple getter operation, though it could optionally mention that it has no side effects, but that is implicit.

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

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

The tool has zero parameters, so the description does not need to explain any parameter semantics. The description mentions the return values, which is sufficient for this zero-parameter tool, earning the baseline of 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 identifies the action ('Get') and the resource ('current context routing mode for the organization'), and specifies the exact return values. It distinguishes from sibling set_context_routing by focusing on retrieval of the current state.

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 usage is implied by the verb 'Get' and the resource description, but there is no explicit guidance about when to use this tool instead of alternatives like get_context or set_context_routing. No when-not or alternative names 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?

No annotations are provided, so the description carries the full burden. It discloses important behavior for binary documents: base64 encoding and the presence of a 'mime_type' field. While it doesn't mention error cases or authorization, the disclosed behavior goes beyond the bare schema and is valuable for an agent.

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

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

Two sentences, no fluff. The primary purpose is stated first, followed by usage flow and a specific edge case. Every sentence earns its place.

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

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

For a simple one-parameter getter with no output schema, the description explains the search-then-read workflow and the binary edge case. It could mention what happens if the document is not found, but the prerequisite of find_documents mitigates that gap. Overall, complete enough for its complexity.

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

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

Schema coverage is 100% with the parameter 'document_id' already described. The description adds minimal semantic value ('by its ID') and clarifies the binary encoding behavior, but the schema already does the heavy lifting. 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's function: 'Get the full content of a document by its ID.' It uses a specific verb ('get') and resource ('document'), and distinguishes it from the sibling tools 'find_documents' (search) and 'upload_document' by implying a read 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?

Explicitly provides usage guidance: 'Use find_documents first to search, then get_document to read the content.' This tells the agent exactly when to use this tool relative to its primary alternative. It also adds context for binary documents, which helps the agent know what to expect.

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

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

With no annotations, the description must disclose behavior. It mentions the types of data returned but doesn't specify defaults like recent_minutes=30, whether filters are exclusive/inclusive, or if there are limits on result sets. The read-only nature is implied but not explicitly stated, and return format is left ambiguous.

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

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

The description is a single, concise sentence that front-loads the core value ('see what's happening right now') and lists key content. No wasted words or redundant 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 tool is simple with no output schema and optional filters. The description gives a high-level summary and the schema covers parameters. However, it doesn't explain how the filtered activity is aggregated or whether results are grouped by type. For a multi-type data tool, a bit more context on output format would help.

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

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

The schema covers 100% of parameters with descriptions, including types and defaults. The tool description adds no parameter-level detail beyond the schema, so the baseline applies. Parameter meanings are clear from the schema alone.

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 provides a real-time overview of multiple activity types (sessions, events, traces, tasks). It distinguishes from siblings like list_sessions or get_session_details by aggregating multiple data types into a single live view, though it doesn't explicitly contrast with 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?

No guidance on when to use this tool vs other activity-related tools (get_session_details, list_sessions, log_trace, etc.). The description implies it's for a quick overview, but no exclusions or alternative suggestions 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?

No annotations are provided, so the description bears the burden. It indicates a read operation via 'Get' and lists the included statistics, which conveys the tool's non-mutating nature implicitly. However, it does not explicitly state that it is read-only or mention any access restrictions, but the absence of side-effect language and the getter pattern make this a minor gap.

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

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

The description is a single concise sentence that front-loads the purpose and lists the key outputs. Every word adds value, and there is no fluff or repetition. It is appropriately sized for such a simple tool.

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

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

The tool is simple (no params, no output schema), and the description covers the essential return categories. It lacks detailed field descriptions, such as what 'recent activity summary' includes, but given the simplicity, it is reasonably complete. The personal scope is clearly stated, so an agent can invoke it without confusion.

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 no parameters, and the input schema is an empty object with no description needed. Since there are no parameters, the description doesn't need to elaborate; the baseline of 4 applies because the schema and description align perfectly for a parameterless tool.

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 retrieves the user's personal activity statistics and enumerates the specific data points (total sessions, events, active days, projects worked on, recent activity summary). The verb 'Get' and the term 'personal' distinguish it from sibling tools like get_org_stats. This is a specific and 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 implies use when the agent needs the current user's own activity data, and the 'personal' qualifier contrasts with get_org_stats, which covers organization-level stats. There is no explicit when-not-to-use or alternative guidance, but the context is clear enough for a straightforward getter. A slightly stronger statement about when to choose this over get_org_stats would earn a 5.

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

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

With no annotations provided, the description carries the full transparency burden. It indicates a read operation ('Get') and describes output categories, but doesn't disclose potential caveats like data freshness, permission requirements, or aggregation details. The description is not misleading, but it adds limited behavioral context beyond the name.

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, front-loaded with the verb 'Get', and every word contributes substantive content. There is no fluff or repetition.

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 is brief but covers the core scope (organization statistics) with example categories. Since there is no output schema, the description should detail what is returned; it does so at a high level but leaves room for ambiguity about exact metrics and format. For a stateless read-only tool, this is 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 tool has zero parameters and an empty input schema, so the baseline is 4. The description adds no parameter-specific meaning since there are none, but it does enumerate the types of statistics returned, indirectly clarifying what the tool does.

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 retrieves organization statistics and lists example categories ('counts, engagement metrics, task velocity'), giving a specific verb and resource. It doesn't explicitly distinguish from siblings like get_my_stats or get_team_details, but the org-wide scope is implicit in the name.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as get_my_stats or get_team_details. It neither states when to choose org-level stats nor mentions any exclusions, leaving usage context implied at best.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool returns status and recent activity, but does not explicitly state that it is a read-only operation, nor does it disclose potential errors, permissions, or side effects. It lacks details on response format or limitations, leaving significant behavioral ambiguity.

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

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

The description is a single, concise sentence that immediately conveys the tool's purpose and a key usage detail. There is no filler, redundancy, or unnecessary jargon. Every word earns its place, and the structure is front-loaded with the core action and object.

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 (two optional parameters, no nested objects), but it lacks an output schema, and the description does not explain the structure of the returned status or recent activity. The description gives a high-level summary but leaves the agent guessing about the exact response fields. Given the simplicity, this is adequate but with clear room for more detail about output expectations.

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 descriptions of both parameters in the input schema already convey their optionality and mutual exclusivity. The tool description adds the phrase 'You can use either the project name or ID,' which reinforces the alternative relationship but does not add substantive new information. Schema coverage is 100%, so the baseline of 3 is appropriate; the description adds marginal value.

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 function: 'Get the current status of a project including recent activity.' It uses a specific verb ('Get') and identifies the resource (project status) and scope (including recent activity). However, it does not explicitly differentiate from sibling getter tools like get_team_details or get_live_activity, though the project-specific focus provides partial distinction.

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. It does not mention exclusions, prerequisites, or scenarios favoring this tool. The only usage hint is 'You can use either the project name or ID,' which is parameter guidance rather than high-level usage context. No mention of when not to use it or alternative tools is present.

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

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

No annotations are provided, so the description carries the full burden. It discloses access restrictions and the types of information returned. It does not mention potential errors or exact behavior beyond this, but it sufficiently covers the core behavioral aspects.

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 the core function front-loaded and the second sentence adding valuable access/context information. Every sentence earns its place with no filler or redundancy.

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

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

The description covers purpose, content, and authorization well for a simple single-parameter tool. However, with no output schema, it does not specify the exact return structure or possible pagination, leaving slight ambiguity about the full response shape.

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

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

The input schema already fully documents the single parameter session_id with a clear description, and the schema description coverage is 100%. The description adds no additional parameter-level detail, 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 retrieves full session details including all events/activities, who did what/when, and session block summary. This distinguishes it from sibling tools like list_sessions and get_live_activity by specifying the granular content returned.

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

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

It gives clear context for when to use the tool (to get comprehensive session details/logs) and includes access rules for admins versus members. However, it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations, the description carries the full burden. It discloses the nature of the returned data (members, projects, recent activity), implying a read-only operation. However, it does not mention error behavior, required permissions, or whether the tool might return partial or aggregated results, leaving some behavioral details undisclosed.

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 long, front-loaded with the main action, and contains no redundant information. 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 read-oriented tool with two parameters and no output schema, the description sufficiently covers the core information an agent needs: what the tool returns and how to specify the team. It lacks a bit of context about potential use cases or limitations, but overall it is complete enough for a tool of this complexity.

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

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

The input schema provides 100% coverage with descriptions for both parameters (team_id and team_name). The description reinforces that either can be used but adds no new semantic meaning beyond what the schema already states.

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

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

The description clearly states the tool's purpose: 'Get detailed information about a team' and enumerates specific content (members with roles, linked projects, recent activity). It is specific about the resource and the type of data returned, but it does not explicitly differentiate from sibling tools like list_teams, which likely serves a similar but shallower 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 provides no guidance on when to use this tool versus alternatives such as list_teams or get_project_status. The only usage instruction is 'Use team name or ID,' which is parameter selection, not contextual usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the permission requirement (admin/owner only), but it does not describe the effects of inviting (e.g., whether an email is sent, if the invite creates a pending state, or how duplicates are handled). This adds some behavioral context but leaves important aspects unstated.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds meaning, stating the action, target, and permission prerequisite 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?

The schema covers all parameters and the description gives the permission gate, but the tool lacks an output schema and the description does not mention expected outcomes, error conditions, or the broader invite lifecycle (e.g., how it relates to accept_org_invite). It is adequate but not rich.

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

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

Schema description coverage is 100%, so all six parameters (name, role, email, skills, positions, team_name) are already documented in the schema. The description text adds no additional parameter-level meaning, fitting the baseline for high 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 uses the specific verb 'Invite' and clearly identifies the resource: 'a new member to your organization'. This clearly distinguishes it from sibling tools like accept_org_invite (accepting an invite) and list_pending_invites (listing pending invites).

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 '(admin/owner only)', which gives a clear usage restriction and context. It does not mention alternatives or when not to use this tool, but it does clarify who may invoke it.

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

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

No annotations are provided, so description carries the burden. It discloses that this records a session-task connection in the knowledge graph, indicating a mutation. However, it omits details about idempotency, overwrite behavior, or prerequisites.

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 the primary action. No filler or redundant 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 tool with only two simple parameters and no output schema, this description captures purpose and effect adequately. Lacks edge-case behavior but sufficient for straightforward linking.

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 both task_id and session_id. The tool description adds no additional parameter semantics, 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?

Description uses specific verb 'Link' with clear resources 'work session' and 'task', stating the core action and its purpose. It distinguishes from sibling tools like start_session or assign_task by focusing on the session-task relationship.

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

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

Implies use when needing to associate a session with a task for knowledge graph purposes. No explicit exclusion or alternative comparisons, but the context is clear enough for this simple linking operation.

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

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

With no annotations, the description carries the full burden. It mentions 'Find both by name or ID,' which hints at resolution behavior, but it does not disclose side effects (e.g., whether it mutates the project or team), permission requirements, idempotency, or error behavior if entities are not found. This is a significant transparency gap for a write operation.

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

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

The description is a single, concise sentence with no filler. It front-loads the core action and then adds a brief note about resolution, making it efficient and easily scannable.

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

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

The tool is simple and the parameter schema is fully covered, but the description omits details about return values, error handling, and the exact effect of linking (e.g., whether it overwrites existing links). Given zero annotations and no output schema, the description is adequate but incomplete for an agent to fully anticipate the tool's behavior.

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

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

Schema coverage is 100% (by context signals), and the description adds the contextual hint that both team and project can be found by name or ID, which aligns with the optional params. However, it does not go beyond the schema to clarify precedence or validation behavior, so the baseline 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 tool's purpose: 'Link a project to a team.' The verb 'link' and the two resources specify the exact action. It also distinguishes from siblings like unlink_team_project and list_project_teams by the unique linking action.

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 associating an existing project with a team, but provides no explicit guidance on when to use this tool versus alternatives like update_project or create_project, nor does it mention exclusions or prerequisites. The context is otherwise clear from the name and 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?

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: visibility differs for admins vs. members. It also describes the return fields (name, email, role), which is beyond the schema. However, it does not explicitly confirm that the tool is read-only or mention pagination behavior, though 'List' implies safety.

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 every sentence earns its place. The first sentence states the function, and the second provides essential behavioral context without fluff.

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

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

For a simple list tool with no output schema, the description covers the main needed context: what it returns (name, email, role), the optional filter, and the visibility rule. It does not explain default limit behavior or error scenarios, but those are either in the schema or not critical for a read-only list. Overall, it is sufficiently complete 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 100%, so the baseline is 3. The description's mention of 'optionally filters by team' adds no new information beyond the schema's team_name description, and it does not elaborate on the limit parameter beyond what the schema says. The description adds minimal value 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 starts with 'List colleagues in your organization', a specific verb and resource that clearly distinguishes this tool from siblings like list_teams or list_project_members. It also enumerates the output fields (name, email, role) and the optional team filter, making the purpose 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 provides context on scoping (admins see all, members see their own teams) but does not explicitly state when to use this tool over alternatives or mention any exclusions. The team filter is a usage hint, but no alternative tools are referenced, so guidance is implied rather than explicit.

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

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

With no annotations, the description must carry safety and side-effect information. It states 'Returns unread notifications by default,' which adds a useful default filter, but it does not mention pagination, ordering, whether listing affects read status, or the response format. This is minimal but not misleading.

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 immediately conveys the action and scope. The list of examples adds value without bloat.

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 fully documented parameters, the description covers the core purpose and default behavior. However, it lacks any mention of return structure or when to prefer alternative tools, leaving some ambiguity about comprehensive usage.

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 both parameters (limit and unread_only) with clear descriptions and defaults, achieving 100% coverage. The description adds no additional parameter semantics beyond restating the unread default, so it does not exceed the schema baseline.

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

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

The description uses the specific verb 'List' with the resource 'your notifications' and enumerates examples (task assignments, status changes, sprint updates, invites), making the purpose immediately clear. It distinguishes from generic listing tools, though it doesn't explicitly distinguish from sibling 'list_pending_invites' for invites.

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 provided on when to use this tool versus alternatives like 'list_pending_invites' for invites or 'mark_notification_read' for marking. The description implies it is the general notification listing tool but doesn't state exclusions or recommended scenarios.

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

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

With no annotations, the description must convey behavior. It does disclose that only pending invites for the current user are returned, which is useful. However, it doesn't mention any prerequisites, authentication, or what fields are included in the response, which are minor gaps for a list operation.

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

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

The description is a single, compact sentence that front-loads the action ('List') and conveys all essential information with zero 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?

This is a very simple tool with no parameters, no output schema, and no annotations. The description provides sufficient context: it lists pending organization invites for the current user. Nothing else is needed for an AI agent to correctly invoke and understand 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?

The tool has zero parameters, and the schema coverage is 100% (vacuously). The baseline for zero parameters is 4, and there is nothing more the description needs to explain about 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 verb 'List' clearly indicates a read operation, and the resource 'pending organization invites' with scope 'for the current user' is specific and unambiguous. It distinguishes itself from sibling tools like accept_org_invite and invite_user.

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

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

The description clearly implies this tool is for viewing the current user's pending invites, which sets a clear usage context. It doesn't explicitly name alternatives or exclusions, but the simple list nature makes the appropriate use case evident.

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

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

With no annotations, the description must self-disclose whether the operation is safe. It implies a read-only listing and specifies the return includes member counts, but does not mention permissions, pagination, or any other behavioral details. This is adequate for a simple list but not fully transparent.

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

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

A single clear sentence with no fluff. It front-loads the action and resource, making it easy for an agent to quickly grasp the tool's 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?

Given the tool's simplicity (no params, no output schema), the description fully covers what the tool does and what it returns. The phrase 'with member counts' adequately indicates the output content.

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 accepts no parameters (empty schema), so there is nothing to explain. The description confirms that all positions are returned, matching the baseline for zero-parameter tools.

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

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

The description uses the specific verb 'List' with a clear resource ('all job positions/titles') and scope ('in your organization'), and adds 'with member counts' to specify the output. This distinguishes it from sibling tools like create_position, update_position, and delete_position.

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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It only states the function, leaving the agent to infer usage from context.

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

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

With no annotations, the description must communicate behavioral details. It clearly indicates a read-only list operation and defines the member composition, but it does not disclose what happens when neither project_id nor project_name is provided, or any other operational nuance.

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 consists of two concise sentences, with the first immediately stating the purpose and the second adding necessary scope. No filler or redundancy.

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

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

For a straightforward list tool with no output schema and optional parameters, the description covers the key aspect of what members are included. The parameter details are already in the schema, so the description is sufficiently complete for agent 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?

Both parameters already have descriptions in the schema, including that project_name is an alternative to project_id. The tool description adds no further parameter-level detail, so the baseline score of 3 for high schema coverage applies.

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

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

The description states a clear action ('List all members involved in a project') with a specific resource. It distinguishes this tool from siblings like list_project_teams by detailing that members include both session users and team-linked users.

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: when you need all members involved in a project. The explanation of what is included (session users and team-linked users) helps an agent select it over other list tools, but it does not explicitly mention alternatives or exclusion cases.

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

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

With no annotations, the description carries the full burden. It discloses that the tool returns all projects and requires no parameters, which implies a read-only operation. However, it does not mention pagination, result limits, any side effects, or the optional org_id parameter's effect, leaving some behavioral details undisclosed.

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, directly states purpose first, and contains no wasted words. It is appropriately sized for a simple list tool.

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

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

For a low-complexity list tool with no output schema and only one optional parameter, the description is adequate. It covers the core action and usage, though it could mention the optional org_id or clarify output behavior (e.g., 'returns a list of project summaries') to be more complete.

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

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

Schema description coverage is 100%, so the schema fully documents org_id. The description adds minimal semantic value beyond the schema, saying no parameters are needed (true for required parameters) but not explaining the optional org_id. Baseline 3 applies since schema handles the parameter documentation.

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

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

The description states the verb 'List' and resource 'projects', with clear scope ('in your organization'). It distinguishes from sibling list tools (e.g., list_tasks, list_sprints) by explicitly naming projects. The phrase 'see all your projects' reinforces the 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 clearly says no parameters are needed and instructs the agent to 'just call it'. This provides clear usage context. However, it does not explicitly mention when to use this tool over alternatives like get_project_status or list_project_teams, or any exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not explain how the tool behaves when neither project_id nor project_name is provided (both are optional in the schema), nor does it mention return format, error handling, or whether the project identifier is required for sensible results. This omitted behavior is a significant transparency gap.

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 directly states the tool's function without any filler. It is front-loaded and every word contributes meaningful information, making it optimally concise.

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 lack of output schema and annotations, the description is too sparse to be complete. It does not clarify the return value shape, the optionality of the project identifier, or how the two parameters interact. The tool has hidden complexity (both params nullable) that the description does not address, making it incomplete for reliable usage.

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 descriptions for both parameters, so the baseline is 3. The tool description adds the context that these parameters identify the project whose teams are sought, and the schema already notes project_name as an alternative to project_id. The description does not add further semantic detail beyond that, so it stays at the baseline.

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

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

The description 'List teams linked to a project' clearly identifies the action (list) and the resource (teams linked to a project), which distinguishes it from the sibling tool list_teams by specifying the project linkage. The verb is specific and the scope is unambiguous, so the tool's purpose is immediately clear.

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 should be used when the user needs to see teams connected to a specific project, but it does not explicitly state when to use it over alternatives like list_teams or link_team_project. There is no exclusions or comparative guidance, so usage context is only indirectly 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?

With no annotations, the description carries the burden of behavioral disclosure. It states what the tool returns (task type, status, event count) and that it lists 'recent' sessions, but it does not explicitly confirm it is read-only, explain the recency window, or disclose any side effects. The word 'list' implies safety, but the description lacks explicit reassurance.

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 and front-loaded: 'List your recent work sessions.' It uses three short sentences, each contributing meaningful information (action, optional filters, output fields) with no redundancy or fluff.

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

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

For a simple list tool with no output schema, the description covers the core purpose, filtering options, and a preview of returned fields. It lacks explicit mention of output format/pagination, but given the simplicity of the tool and the parameter descriptions in the schema, it is sufficiently complete for an agent to use it effectively.

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 each parameter already has a description (limit, project_id, project_name). The tool description adds little beyond referencing the filter capability, which is already in the schema. It does not provide additional context about parameter interactions or defaults beyond what the schema states.

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

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

The description clearly states a specific action ('List your recent work sessions') with a clear resource ('sessions') and distinguishes itself from sibling tools like get_session_details (singular) and start_session/end_session by the verb '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 implies usage for listing sessions and optionally filtering by project name or ID, but it does not explicitly mention when not to use this tool or provide alternatives (e.g., use get_session_details for a single session). The guidance is minimal and inferred from the verb and filters.

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

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

With no annotations, the description must disclose behavior, and it does mention the returned fields (sprint number, name, goal, status, task count). However, it lacks details on input requirements (e.g., must provide project_id or project_name), filtering limits, or whether it returns only current/completed sprints.

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 tight sentences: first states the purpose, second lists the returned fields. No filler or redundancy.

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

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

The description covers the output fields, which is important since no output schema exists. It lacks explicit notes on project identifier requirements or pagination, but for a low-complexity list tool with two optional parameters, it is reasonably complete.

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

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

Schema description coverage is 100% for both parameters (project_id and project_name), so the schema provides full meaning. The description adds no additional parameter insight beyond saying 'for a project', which is already implied by 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 states the tool lists sprints for a project, with a specific verb and resource. It differentiates from sibling list tools like list_projects and list_tasks by focusing on sprints and their attributes.

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

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

The description implies when to use it (to view sprints for a project) but does not explicitly mention alternatives or exclusion criteria. There is no guidance on when not to use this tool versus other list 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?

No annotations are provided, so the description carries the full burden. It mentions the output fields and the 'mine_only' filter, which implies user-scoped behavior, but it does not disclose default ordering, pagination behavior, or any authentication requirements. For a read-only list tool, this is adequate but not rich.

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 concise sentences, front-loaded with 'List tasks,' and each additional sentence adds value by listing filters and output fields. There is zero waste.

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

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

For a filtered-list tool with no output schema, the description adequately covers the available filters and output fields. It does not explicitly mention default limit or ordering, but the schema addresses the limit. The absence of an output schema is compensated for by listing the displayed fields, making it fairly complete.

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

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

Schema description coverage is 100%, with each parameter described directly in the schema. The description paraphrases the filters but adds no additional semantic nuance beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description starts with 'List tasks,' using a specific verb and resource. It clearly differentiates from sibling list_* tools by focusing on tasks and listing filter options and output fields, making it 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 provides clear context on when to use this tool (filtering tasks by project, status, sprint, or assignee), but it does not explicitly mention alternatives or when-not scenarios. Given the many list_* siblings, a 4 is appropriate for clear context without 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It does state the output fields (team name, member count, project count, description), which is useful. However, it does not mention any limitations such as pagination, ordering, or whether archived teams are included. It also does not explicitly confirm that this is a read-only operation, though 'List' implies it.

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 opens with the verb 'List' and immediately defines the resource and scope. It includes the key output fields without any extraneous words. Every word contributes useful information, making it highly 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's simplicity (no parameters, no output schema), the description is quite complete. It explains what the tool does and what data is returned. However, it omits any caveats (e.g., whether all teams are returned at once, or whether special permissions are required) that could be relevant for an agent. Overall, it's adequate for the tool's low 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 tool has 0 parameters, so there is no parameter semantics to explain. Per the rubric, a baseline of 4 applies when no parameters are present. The schema is empty, and the description correctly omits parameter details since none exist.

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 function: 'List all teams in your organization.' It specifies the resource (teams), the scope (all teams in org), and the returned fields (team name, member count, project count, description). This distinguishes it from sibling tools like list_project_teams, which focus on teams within a specific 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 phrase 'all teams in your organization' implies when to use this tool (for a broad org-wide listing) and indirectly suggests that for a single team, get_team_details might be more appropriate. However, no explicit alternatives or exclusions are mentioned, leaving some ambiguity for agents comparing 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?

With no annotations, the description carries the burden of disclosing behavior. It does disclose the auto-session behavior, which is useful. However, it omits what happens when neither project_id nor project_name is provided, and the simplification 'just pass project_name and content' neglects the required event_type, which could mislead the agent. There is 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 short and front-loaded with purpose, but the second sentence is partially inaccurate ('just pass project_name and content' while event_type is required). This reduces the reliability of the conciseness, making it less effective than a fully accurate brief 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?

The description covers the auto-session use case well but does not explain when to provide an explicit session_id, nor does it mention the required event_type parameter. With no output schema and six parameters, this is a moderate gap. It is sufficient for a simple logging tool but leaves key scenarios unaddressed.

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 baseline is 3. The description adds value by explaining the relationship between session_id and project_name, emphasizing the auto-session behavior. This goes beyond the individual schema descriptions, clarifying how the parameters interact.

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 function ('Log an activity or event') with a specific verb and resource. It implies distinction from sibling tools like log_trace by focusing on activities/events, but does not explicitly name alternatives. This is clear and somewhat differentiates.

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 concrete usage guidance: 'If no session_id is provided, a session is automatically created or reused for the project' and 'no need to start a session first.' This tells the agent when it can skip start_session. However, it gives a slightly misleading 'just pass project_name and content' instruction, ignoring the required event_type parameter, and does not mention when to use this tool over log_trace.

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

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

With no annotations provided, the description must disclose behavioral traits on its own. It adds 'High-frequency, no LLM processing,' which is useful, but it omits critical behavior such as whether the trace is persisted, what side effects occur (e.g., auto-linking session/task from schema), or any latency or failure semantics. The description is sparse for a logging tool that creates records.

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 short sentences that front-load the purpose and add a key behavioral trait. It is efficiently written without redundant words. A small deduction because 'granular' and 'high-frequency' are slightly vague, but overall 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?

The tool has 11 parameters, no output schema, and no annotations, so the description must provide more context. It fails to mention parameter relationships like auto-linking of session/task, when to use vs siblings, or expected return behavior. The current description is too sparse to fully guide an agent, especially with sibling tools like log_activity and log_traces_batch present.

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

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

Schema description coverage is 100%, so all 11 parameters are documented in the schema. The description adds no extra parameter information beyond what is already present. Baseline 3 is appropriate because the schema carries the semantic load, and the description does not clarify parameter usage (e.g., auto-resolution behavior of task_id/session_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+resource: 'Log a granular agent action trace,' which clearly states the tool's core purpose. It distinguishes from siblings like log_traces_batch by noting 'granular' and 'High-frequency,' implying this is for individual, low-overhead traces. However, it does not explicitly differentiate from log_activity, which is a nearby sibling.

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 is given about when to use this tool versus alternatives. The phrases 'High-frequency, no LLM processing' provide context but do not name alternative tools or describe conditions for choosing this over log_traces_batch or log_activity. An agent would be uncertain about when this is the appropriate logging call.

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

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

With no annotations provided, the description must carry the full behavioral burden. It only states 'Log multiple traces' with no details on idempotency, partial failure behavior, return values, or validation. The verb 'log' implies a write operation, but no side effects, error handling, or output expectations are disclosed, which is insufficient for a batch operation.

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

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

The description is a single, terse sentence of seven words, making it front-loaded and efficient. However, given the complexity of a nested batch operation, this brevity omits important context and appears under-specified. It is concise but not ideally structured to aid an agent in invoking the tool correctly.

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 features a rich nested schema and no output schema, so the description is responsible for providing usage context, batching behavior, and edge cases. It only offers a one-line summary, lacking information on when to choose this over 'log_trace,' how partial failures are handled, or any prerequisites. The description is incomplete for a potentially complex 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 already provides 100% coverage with detailed descriptions for the 'traces' parameter and its nested properties (e.g., 'Status: started, completed, failed'). The description 'Log multiple traces in a single batch' adds no new meaning beyond the parameter's existing description 'Array of traces to log in a single batch.' Since the schema does the heavy lifting, the 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 says 'Log multiple traces in a single batch,' which clearly identifies the action (log), the resource (traces), and the batch mode, distinguishing it from the sibling 'log_trace' tool by emphasizing 'multiple' and 'batch.' It does not explicitly contrast with 'log_trace' or 'log_activity,' but the name and phrasing convey the intended 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 offers no guidance on when to use this tool versus alternatives. It lacks any mention of batching rationale, performance considerations, or situations where 'log_trace' might be preferred. There is no exclusions or contextual advice, leaving the agent to infer 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?

No annotations are provided, so the description carries the full burden. It only states the action without disclosing idempotency, behavior when both or neither parameter is supplied, or whether it affects only the current user's notifications. This is a thin behavioral disclosure.

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

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

The description is a single, front-loaded sentence with no filler. It efficiently communicates the two modes and the target resource.

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 low complexity and complete schema, the description is adequate for basic use, but it leaves edge cases unaddressed (e.g., calling with neither parameter, or both). This is a gap for a tool with all-optional parameters.

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 provides complete descriptions for both parameters (notification_id and mark_all), covering 100% of the schema. The description adds no additional parameter context, but the schema already handles it, so the baseline 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 a specific verb ('mark') and resource ('notification') with the action 'as read', clearly distinguishing this mutation from the read-only list_notifications sibling. It also identifies two modes: single and bulk. This is 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 description implies when to use the tool (when you need to mark notifications read) but does not explicitly state exclusions or alternatives. It also does not clarify when to choose mark_all vs notification_id, though the schema fills this gap. There are no competing sibling tools for this action, so the context is clear.

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

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

No annotations are provided, so the description carries full burden. It doesn't disclose side effects, permission requirements, behavior when the target sprint is invalid, or reversibility. The description simply restates the action without additional behavioral context.

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

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

One sentence, front-loaded with verb and object, no redundant words. It is appropriately sized for the simplicity of the operation.

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 annotations and no output schema, the description leaves behavioral aspects uncovered. It doesn't explain parameter interactions (e.g., needing project_name with sprint_number) beyond the schema, nor what happens on success or failure.

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 descriptions already cover all parameters (100% coverage), so the description adds no significant new meaning. The phrase 'by number or ID' merely mirrors the existing sprint_number and sprint_id descriptions.

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

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

The description uses a specific verb ('Move') and identifies the resource ('a task to a different sprint'), making the tool's function immediately clear and distinct from sibling tools like assign_task or update_task.

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 implies the use case (moving a task between sprints) and hints at parameter selection ('by number or ID'), but doesn't explicitly state when to prefer this over alternatives or provide exclusions. The context is clear but lacks direct comparative 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and immediate effect, but does not mention prerequisites, reversibility, or consequences of removing a dependency. This is minimal transparency for a mutation-like tool.

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

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

The description is two short sentences, front-loaded with the main purpose ('Remove a dependency between tasks') and includes a clarifying effect. No unnecessary words or redundant details.

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 simple nature of the tool (two parameters, no output schema, no annotations), the description adequately covers the core purpose and effect. The schema fully documents parameters, so the description is largely complete for this straightforward operation, though it does not mention return values or error handling.

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

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

The input schema already describes both parameters with 100% coverage ('The task that was blocked' and 'The task that was blocking it'). The description does not add any additional parameter-level semantics, so the baseline score of 3 applies.

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

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

The description uses a specific verb 'remove' with the resource 'dependency between tasks' and explains the effect ('unblocks the task'), clearly distinguishing it from the sibling tool add_task_dependency.

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 of when to use the tool: when you need to unblock a task by removing a dependency. It does not explicitly mention alternatives or exclusions, but the purpose 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states that the tool 'removes' a member, implying a destructive action, but it does not disclose potential side effects, error conditions (e.g., team not found), permissions required, or irreversibility. This is a significant gap for a mutation tool.

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

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

The description is a single sentence that is concise and front-loaded. Every word contributes to the understanding: the action, the target, and the identification strategy. There is no unnecessary 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?

The tool is relatively simple with 3 parameters and no output schema. The description covers the core action and identification logic, but lacks important contextual details such as what happens if the team or user is not found, whether the removal is permanent, and any permission requirements. Without annotations, this makes the description minimally viable but not complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a summary of the parameter usage ('Find the team by name or ID, and the user by name or email'), reinforcing the schema but not introducing new semantic details. It also introduces slight ambiguity by implying both team_id and team_name are needed, while the schema marks them optional.

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 function: 'Remove a member from a team.' It uses a specific verb ('remove') and resource ('team member'), and the clarification about finding the team by name/ID and user by name/email distinguishes it from sibling tools like remove_user_from_org (which removes from the org) and add_team_member (which adds).

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 how to use the tool: identify the team by name or ID and the user by name or email. This gives practical guidance, though it does not explicitly state when not to use it or mention alternatives like remove_user_from_org. The context is clear enough for an agent to select it for team-level removals.

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

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

With no annotations, the description carries the full burden. It discloses two important behaviors: the account is not deleted, and admin/owner authorization is required. However, it does not mention potential side effects on the user's data, assignments, or memberships, which could be relevant for a mutation of this nature.

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

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

The description is a single, concise sentence that front-loads the core purpose and includes the two most critical behavioral constraints (no account deletion and admin/owner only). There is no wasted wording.

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

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

For a simple single-parameter operation with no output schema and no annotations, the description provides the essential context: what it does, what it does not do, and who can use it. It could be improved by noting whether the removal is reversible or affects the user's resources, but given the tool's simplicity, it is sufficiently 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 schema already provides 100% coverage for the single parameter 'user', describing it as 'User name or email to remove from the organization'. The description adds no additional parameter-specific information, so the baseline of 3 applies.

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

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

The description clearly states the action: remove a user from the organization, with the key distinction that the account is not deleted. This differentiates it from sibling tools like delete_user and remove_team_member, and it also specifies the permission requirement (Admin/owner only).

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

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

The description implies when to use this tool by stating it removes from the current organization without deleting the account, which implicitly contrasts with delete_user. It also sets the usage prerequisite of admin/owner. However, it does not explicitly name alternative tools or say 'use this instead of X', so it stops short of a full usage guideline.

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

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

No annotations are provided, so the description carries full responsibility. It adds minimal behavioral context (entities from activities) but does not disclose read-only nature, result ordering, pagination, or error handling. For a search tool, this is a notable gap.

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 clear, front-loaded sentences with no fluff. Every phrase contributes meaning, and the structure is easy to parse.

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 core purpose and scope, but with no output schema or annotations, it lacks details on return format, default limit behavior, and sorting. It is adequate for a simple search tool but leaves some gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a list of example entity types that align with the entity_type parameter, but does not add new semantic 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 clearly states the verb ('Search') and resource ('entities in the knowledge graph by name'), and provides a helpful list of entity types. It does not explicitly distinguish from sibling tools like find_documents, but the scope 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 context implies use when searching for entities by name from the user's activities, but there is no explicit when-to-use vs alternatives or exclusions. No alternative tools are named.

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

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

With no annotations, the description carries the disclosure burden. It mentions an admin requirement and the effect of setting the mode, but does not disclose potential side effects (e.g., impact on ongoing sessions, persistence, or whether the change is reversible). Adequate but not rich in behavioral context.

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

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

Two sentences, front-loaded with action, then requirements and options. Zero waste, every sentence earns its place.

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

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

For a simple one-parameter setter with no output schema, the description covers the purpose, requirement, and options. It could mention that the current mode can be checked via get_context_routing, but that is implied by the sibling list. Essentially complete for its 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 100%, so the param is fully documented in the schema. The description repeats the options with slightly different qualitative labels ('balanced' vs 'keyword + LLM fallback'), adding marginal value but not meaningfully improving 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 uses a specific verb ('Set') and resource ('context routing mode for the organization'), clearly distinguishing it from the sibling tool get_context_routing. It also enumerates the possible modes with qualitative labels, making the purpose 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 explicitly requires an admin role and explains the trade-offs of each mode (balanced, fastest, most accurate), helping the agent choose. It does not explicitly mention alternatives or when to use get_context_routing, but the context is clear enough for a simple setter.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions admin-only access and 'one step' (suggesting bulk operation), but it does not disclose what resources are created (teams, projects, links), whether changes are reversible, or any side effects. This is a significant gap for a setup tool that likely mutates organizational state.

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

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

The description is two short sentences that are front-loaded with the core purpose and usage context. Every word earns its place, 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?

Despite the tool's complexity (7 parameters including nested links/teams/projects, no output schema, no annotations), the description is minimal. It does not explain what 'set up' entails, what gets created, or the overall impact on the organization. This is inadequate for an agent to fully anticipate the tool's 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 100%, so all 7 parameters have descriptions in the schema. The tool description adds no parameter-level detail, but the schema already documents each field adequately. Baseline 3 is appropriate; no additional information is needed.

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

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

The description clearly states the tool's purpose: 'Set up your organization in one step' with an explicit admin-only restriction. It distinguishes from granular sibling tools like create_team/create_project by implying a bulk onboarding action, though it does not name 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 provides clear context for when to use this tool: 'Use this for onboarding.' It also specifies an access prerequisite ('admin only'). However, it does not explicitly mention exclusions or contrast with alternative tools, but the scenario 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?

With no annotations, the description carries the burden of disclosing behavior. It explains key side effects: binding to a project, creating an unbound session, and reusing an existing active session. It stops short of discussing permissions or failure modes, but covers core behavior well.

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 tightly packed into four purposeful sentences: core action, conditional project semantics, reuse behavior, and task type enumeration. No fluff, well-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?

The description is complete enough for an agent to select and invoke the tool correctly, covering parameters, behavior, and usage context. Minor gaps exist around return value and error conditions, but the tool's purpose is clearly conveyed.

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

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

The description adds meaning beyond the schema by clarifying that project_name and project_id are alternative ways to bind a session, and explicitly addresses the case when neither is provided. It also enumerates the allowed task_type values, supplementing 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 states the verb 'Start' and resource 'work session', and differentiates between project-bound and projectless sessions. It also mentions reuse of active sessions, distinguishing it from sibling tools like end_session.

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 when to use a project-bound session vs a projectless one, and notes the reuse behavior. It does not explicitly name alternative tools, but the conditions are stated sufficiently.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It simply states the action without detailing side effects, error conditions, permissions, or whether the operation is idempotent. For a mutation tool, this is insufficient.

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

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

The description is a single sentence with no wasted words. It is front-loaded with the action and resource, making it immediately understandable.

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 that this is a simple two-parameter tool with no output schema, the description covers the basic operation. However, it omits important contextual details such as whether the user must currently be an assignee, what the response contains, or any error scenarios. It is minimally viable but not complete for a mutation tool without annotations.

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

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

Schema coverage is 100%, so the parameters are already documented in the schema. The description adds no extra meaning beyond the schema, as it merely restates the operation without detailing parameter relationships or edge cases.

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 ('Remove') and resource ('a user from a task's assignees'), which is specific and unambiguous. It distinguishes itself from sibling tools like assign_task and remove_team_member by naming the exact 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 usage is implied by the name and description: you use this when you need to remove a user from a task's assignees. However, there is no explicit guidance on when to use this over alternatives like update_task, nor any mention of prerequisites or 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the action and lookup method, but does not disclose side effects, error behavior, permission requirements, or whether the operation is reversible. For a mutation tool, this is a significant gap.

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, consisting of two short sentences with no verbiage. It is front-loaded with the primary action and immediately follows with the lookup method. 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 simplicity of the tool, the description is minimal but inadequate. It does not state that both team and project identifiers are required, what happens if either entity is not found, or any side effects of unlinking. The lack of annotations and output schema make these gaps more impactful.

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 detailed descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds minimal context by noting 'Find both by name or ID,' which aligns with the parameter structure but does not clarify mutual exclusions or required combinations (e.g., that team_id and team_name are alternatives, not both required).

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 with a specific verb and resource: 'Unlink a project from a team.' It also mentions the method of identifying entities ('Find both by name or ID'), which helps distinguish it from the sibling tool 'link_team_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 when to use the tool (to remove a project from a team), but it does not explicitly state alternatives or exclusions. It lacks guidance on when to use this versus link_team_project, or what to do if the project is already unlinked.

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

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

With no annotations present, the description carries the burden of behavioral disclosure. It does provide the owner-only restriction, which is a meaningful behavioral trait. However, it does not explain whether updates are partial or full replacements, how missing fields are handled, or any permission/error implications. The schema shows all parameters are optional, but the description does not explicitly state that updating is cumulative or that only provided fields are changed.

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

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

The description is a single, concise sentence that front-loads the primary purpose ('Update your organization's details') and then lists the editable fields. There is no redundant or filler text; every part contributes to understanding the tool's function. This is an exemplary model of 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?

For an update tool with all-optional parameters and no output schema, the description is mostly complete. It identifies the target entity, the constraints (owner only), and the specific fields that can be modified. What it lacks is explicit behavioral context about partial updates or potential side effects, but given the simplicity of the tool and rich schema, the description covers the essential aspects well.

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 each parameter described (e.g., 'Organization name (optional)', 'Links as JSON array: [...]'). The description merely lists the same fields without adding new semantic meaning (e.g., formats, constraints, or relationships). Given the high schema coverage, the description adds no additional parameter-level value, so the 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 'Update' and the resource 'your organization's details', and enumerates the specific fields that can be modified (name, description, business model, objectives, custom context, links). This distinguishes it from sibling tools like setup_organization (creation) and get_org_stats (read-only), making the purpose 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 specifies an important usage condition: 'owner only'. This tells the agent when this tool is appropriate (only for organization owners) and implicitly warns against using it for non-owners. While it doesn't explicitly mention alternatives, the 'owner only' constraint provides clear context for when to use this tool versus other update or setup 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?

With no annotations, the description carries the full burden for behavioral disclosure. It adds the admin-only requirement and the flexible lookup mechanism, but does not disclose what happens when both position_id and position_title are provided, whether new_permissions replaces or merges existing permissions, or behavior on invalid/unknown positions. This is a partial disclosure for a mutation tool.

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

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

The description is one sentence plus a short lookup hint, concisely stating the action, scope, and permission requirement. Every phrase adds value with no redundant wording, making it easy to parse quickly.

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 optional parameters, no required fields, no output schema, and no annotations, the description is minimally sufficient: it communicates the core purpose, admin constraint, and lookup strategy. However, it lacks guidance on what happens if no fields are supplied, conflict handling for the two search parameters, and the exact return payload, leaving gaps for an agent to resolve.

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

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

The input schema already provides descriptions for all 5 parameters (100% coverage). The tool description adds the relationship between position_id and position_title ('Find by title or ID') and the admin restriction, contributing some extra meaning beyond the schema. It does not fully compensate for the ambiguity of optional fields when no updates 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 clearly states 'Update a position's title, description, or permissions', specifying the verb, resource, and exact fields. It also distinguishes from sibling tools like create_position, delete_position, and list_positions by focusing on mutation of an existing position.

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 usage context: it is for updating existing positions, restricted to admin users, and identifies a lookup method ('Find by title or ID'). However, it does not explicitly exclude scenarios where create_position or delete_position would be more appropriate, though these are implied by sibling 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only lists updateable fields and lookup methods, but omits important details like permissions, reversibility, error handling (e.g., project not found), and whether partial updates are allowed. This is a mutation tool, so more transparency is expected.

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, front-loaded with the action and resource, and contains no redundant or extraneous information. Every word contributes to understanding the tool's function.

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 relatively simple (5 optional parameters, no required fields, no output schema), and the description covers the core aspects: what it updates and how to identify the project. However, it does not disclose return values, error behavior, or handling of partial updates, which leaves some gaps for an agent invoking 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?

The schema already provides 100% parameter coverage with descriptions. The description adds the relationship between project_name and project_id ('Find by name or ID') and groups the updateable fields, but it does not add significant semantic detail beyond what the schema already states. This meets the baseline for well-documented schema.

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

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

The description clearly states the action ('Update') and the resource ('a project'), and specifies the exact fields affected ('name, description, or links'). It distinguishes this tool from create_project and delete_project by focusing on modification, and the 'Find by name or ID' clarifies the targeting mechanism.

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

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

The description implies when to use the tool (to update an existing project) and provides a usage hint ('Find by name or ID'), but it does not explicitly mention alternatives or when not to use it. It lacks explicit guidance such as 'to create a project, use create_project'.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It states that the tool updates fields, but it does not disclose side effects, whether partial updates are supported, permission requirements, or what happens to unspecified fields. The workflow movement note is more about usage than behavior, and no information about returns or destructive potential 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?

The description is two concise sentences, front-loaded with the core action. Every word adds value: the first sentence states the purpose, the second gives concrete usage examples. No unnecessary fluff or repetition.

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 having 9 parameters and no output schema, the description does not explain return values, error conditions, or partial update semantics. It gives a strong purpose and usage context but lacks the full contextual detail expected for a complex mutation tool. The schema covers parameter syntax, but behavioral completeness remains incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description restates some fields (status, title, etc.) but adds no new semantics beyond what the schema provides. It does not clarify relationships between team_id and team_name, nor edge-case behaviors for these 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 the action ('Update') and the resource ('task'), and enumerates the specific fields it modifies: status, title, description, priority, and team assignment. It also illustrates a typical workflow movement (todo -> in_progress -> done), which further clarifies its intended function and distinguishes it from sibling tools like assign_task or update_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 provides explicit use cases: moving tasks through the workflow and reassigning to a team. This gives clear context for when to use the tool, but it does not mention alternatives or when not to use it, such as using assign_task specifically for pure assignment without other updates.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the update action and lookup method, without revealing potential side effects, permission requirements, or return behavior. This is insufficient feedback for a mutation tool.

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

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

The description is a single, front-loaded sentence that conveys the action, target fields, and lookup method with no unnecessary words. It is maximally concise.

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 update tool with 5 optional parameters and no output schema, the description is moderately complete. It covers the core purpose and lookup method, but omits details about update semantics (e.g., whether fields overwrite entirely) and any prerequisites, which would be helpful given no annotations.

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

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

Schema description coverage is 100%, so the parameter descriptions already explain each field. The description adds a small clarification about finding by name or ID, which aligns with team_id and team_name, but does not add substantive 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 clearly states the specific action ('Update a team's name, description, or objectives') and identifies the resource (team). It distinguishes itself from sibling tools like update_org and update_task by focusing on team attributes.

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 updating team fields and mentions the lookup options (by name or ID), but it does not explicitly state when to use this tool over alternatives like create_team or provide exclusions. No alternative tools are referenced.

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

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

With no annotations, the description carries the full burden. It discloses the authorization requirement ('admin/owner only') and the action (update), which indicates a mutation. However, it does not mention whether updates are partial or full replacements (though the schema notes 'replaces existing' for skills/positions), reversibility, or error behavior. This is minimally transparent but not deeply descriptive.

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 conveys the action, target, fields, and permission with no superfluous words. Every element contributes meaning, making it highly efficient for an agent to parse.

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 (5 parameters, 1 required) and the rich schema descriptions, the description provides a clear action, target, and authorization. It lacks explicit return-value information, but that is not critical for an update tool without an output schema. The combination of schema and description is adequate for an agent to select 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?

Schema coverage is 100%, so the schema already describes all five parameters. The description adds no extra meaning beyond listing the fields (name, role, positions, skills), which maps directly to the parameters. It does include the admin/owner permission, which is relevant context for new_role, but not significant 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 uses a specific verb ('Update') and identifies the resource ('existing user') plus the fields affected ('name, role, positions, or skills'). This clearly distinguishes it from sibling tools like delete_user (deletion) and update_team (team updates). The parenthetical '(admin/owner only)' adds an important scope condition.

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 modifying user attributes and notes the admin/owner restriction, but it does not explicitly state when to use this versus alternatives like remove_user_from_org or update_org. No exclusions or alternative tool references are provided, leaving the agent to infer usage from context.

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