Interbang

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

The annotations already signal mutation via readOnlyHint=false, and the description adds useful behavioral context: the operation is limited to PREPARING drafts and returns a new taskId. It does not describe error behavior or side effects beyond task creation, but for a create operation the added constraints are meaningful.

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

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

The description is a single dense sentence that front-loads the core action and then efficiently packages required fields, optional fields, return value, and a state constraint. No filler or redundant explanation.

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 8-parameter tool with no output schema, the description supplies the expected return value (new taskId), the required/optional split, and a critical state restriction. It is slightly incomplete because parameter semantics are thin and it does not explain what happens if the use case is not PREPARING, but the essential invocation requirements are present.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only enumerates field names already present in the schema and restates that title is required, without explaining what successCriteria, observationPoints, probingQuestions, or the boolean flags actually mean. An agent must rely on naming conventions rather than concrete guidance.

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

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

The description states a clear action ('Add a task') and the target resource ('to a use case'), with a helpful summary of required/optional fields and return value. It does not explicitly contrast with update_task or delete_task, but the create operation is distinct enough from the sibling names that an agent can tell it apart.

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 a clear contextual constraint: 'Only works on use cases of PREPARING drafts.' This tells the agent when the tool can be used and implicitly when it cannot. It does not name alternative tools for other workflows, so it lacks explicit when-not-to-use routing, but the guidance is stronger than mere implication.

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

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

The annotation readOnlyHint=false already signals a mutation, but the description adds valuable behavioral details: it explicitly says 'Add', discloses the return of a new useCaseId, and states the draft-state restriction. These go beyond the minimal annotation and help the agent predict 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?

Three sentences with no redundancy. The main action, required parameters, return value, and a precondition are all presented efficiently, with the most critical information 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 covers the essential aspects: what it does, what inputs are needed, what it returns, and a key operational constraint. It doesn't dive into error scenarios or undo behavior, but for a straightforward add-operation with sibling tools providing context, this 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 0%, so the description must clarify parameters. It explains that title is required and description optional, and implies utId identifies the target UT. However, it does not define 'UT', 'scenario', or any format constraints, leaving some ambiguity that the schema does not resolve.

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

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

The description states a specific action ('Add a use case to a draft UT's scenario'), identifies required and optional fields (title required, description optional), and explains the conceptual purpose (grouping related tasks). This clearly differentiates it from update_use_case (modification vs. addition) and other siblings.

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

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

Provides a clear precondition ('Only works on PREPARING drafts') and explicit workflow guidance (returns useCaseId to use with add_task). It does not name alternative tools or state when not to use it, but the context and precondition are sufficient for a competent agent.

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

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

Annotations already mark readOnlyHint=true, and the description adds useful behavioral context: comparisons are per use-case and per-task, deltas are reported for specific metrics, and problems/bugs are categorized as fixed/new/persisting. It also discloses the non-obvious default behavior for the against parameter.

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

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

Three sentences with a clear front-loaded purpose, followed by parameter orientation and an explicit when-to-use trigger. Every sentence earns its place and there is no filler or redundant restatement.

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 fully covers what the comparison includes, how to orient the parameters, and when to invoke the tool. Even without an output schema, it names the returned dimensions sufficiently for an agent to know what to expect.

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

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

Schema coverage is 100%, so the schema already fully documents both parameters. The description restates the 'later round' guidance and the default behavior of against, adding clarity but no substantive new information 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 opens with a specific verb and resource: 'Compares two rounds of the same UT' and enumerates the exact deltas covered (success-rate, duration, rating) plus bug movement categories. This clearly distinguishes it from other UT-related tools and removes ambiguity about what the tool does.

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

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

'Use it when asked to compare rounds or see what changed across iterations' provides an explicit trigger, and the instruction to pass the later round as utId clarifies orientation. It does not explicitly name alternatives, but no sibling appears to offer the same comparison, so the guidance is clear enough.

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?

Beyond readOnlyHint=false, the description reveals that the created UT is a PREPARING draft with an empty scenario, defaults to the personal workspace, and requires team membership for team workspaces. This adds useful behavioral context beyond the annotations.

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

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

Three dense sentences with no filler. The core action and state are front-loaded, and the workflow guidance and workspace rule each add distinct 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 create tool with minimal schema, no output schema, and one required parameter, the description covers the draft state, subsequent build steps, and workspace targeting. A minor gap is that it does not mention what the response returns, such as the new UT id needed for follow-up add_use_case/add_task calls.

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

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

Schema coverage is low, but the description names all five parameters, indicates that title is required and the others are optional, and gives workspaceId meaningful context: it defaults to the personal workspace and can come from list_workspaces. It does not deeply define background/hypotheses/recruitmentCriteria, but their names and optional status are sufficient.

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

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

States a specific action — 'Create a usability test as a PREPARING draft' — and clarifies that it starts with an empty scenario. This clearly distinguishes it from update_ut, add_use_case, and add_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?

The description gives a clear workflow: create the draft, build it out with add_use_case/add_task, then have a person review it before sessions start. It also explains when to pass workspaceId and where to get it. It does not explicitly mention 'use update_ut for existing tests,' but the lifecycle is implied.

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

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

Annotations already mark destructiveHint=true, and the description reinforces this by stating the deletion is irreversible and 'the task and its fields are gone for good.' It adds a practical caution to verify the taskId before calling, which is valuable guidance for a destructive action. There is no contradiction with the annotations.

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

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

The description is two sentences long and front-loads the core action with no wasted words. It efficiently covers the target, irreversibility, ID sourcing, and the PREPARING-draft 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?

For a one-parameter destructive tool with no output schema, the description is complete enough for safe invocation. It explains what is deleted, from what object, under what status condition, and how to get the required ID. The lack of a return-value description does not hinder correct 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 input schema only provides 'taskId' as a string with no description, so schema coverage is 0%. The description compensates by indicating that taskId comes from get_ut and should be double-checked before deletion. It does not fully explain what a task is, but for a single-parameter tool this is adequate.

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

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

The description states a specific verb and resource: 'Delete a task from a draft UT.' It also adds the scope limitation 'Only works on tasks of PREPARING drafts,' which helps distinguish it from sibling tools like update_task, add_task, and delete_use_case.

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

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

The description gives a clear condition for use: only tasks of PREPARING drafts can be deleted. It also advises the agent to double-check the taskId and tells it where to obtain that ID (from get_ut), which is a useful prerequisite. It does not explicitly name alternative tools, but the operational constraint is clear.

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

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

Annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral context: irreversibility, cascade deletion of all tasks inside the use case, and the PREPARING-state restriction. This exceeds what annotations alone convey.

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

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

Three sentences, each earning its place: main action and scope, risk warning with precondition, and routing to the correct alternative. No redundancy or filler.

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

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

For a destructive single-parameter operation, the description covers what is deleted, the irreversible nature, the prerequisite verification step, the draft-state constraint, and the alternative tool. Nothing needed for correct invocation is missing.

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

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

The schema has 0% description coverage and only a bare 'useCaseId' string property. The description compensates by instructing the agent to check that ID and its task list via get_ut before invoking, adding practical semantics to the single parameter.

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

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

Description states a specific action ('Delete a use case from a draft UT') and adds scope ('including every task inside it'). It clearly differentiates from the sibling delete_task by name and semantic 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?

Provides explicit when-to-use and when-not-to-use guidance: prefer delete_task for single-task removal, verify the useCaseId and task list from get_ut before calling, and only call on PREPARING drafts. This leaves no ambiguity about selection.

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

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

Annotations already mark the tool as readOnlyHint, and the description adds meaningful detail about what is reported: the authenticated email, ut:read/ut:write scopes, and workspace read capacity. This gives the agent a clear picture of the tool's behavior beyond the annotation alone.

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

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

The description is two sentences with no filler. It front-loads the core report content and immediately follows with the intended use case, making every word valuable.

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

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

For a zero-parameter, read-only introspection tool with no output schema, the description fully explains what the agent will receive and why it might call the tool. Nothing essential is missing.

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

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

The input schema has no parameters, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, this is a solid score; the description appropriately focuses on outputs instead.

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

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

The description uses the specific verb 'Reports' and names exact outputs: the authenticated account email, granted scopes, and workspace read count. This makes the tool's purpose unmistakable and distinguishes it from sibling tools focused on tasks, use cases, or workspaces.

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

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

The description explicitly says 'Use it to check what this connection is allowed to do,' giving an agent a clear trigger for invoking the tool. It does not explicitly mention alternatives or exclusions, but the use case is well defined and self-contained.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation, and the description is consistent with that. The description adds detail about the returned analytics categories but does not provide additional behavioral context such as response format, pagination, or permission requirements. With the safety profile covered by annotations, 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 one sentence with the main action front-loaded and the output components contained in a parenthetical list. Every phrase carries information and there is no filler or duplicated schema 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?

The tool is simple: one required parameter, a read-only annotation, and a description of the returned analytics categories. Since there is no output schema, the description covers the response at a useful level of detail. It could be more complete by noting how this report differs from sibling tools, but nothing essential is missing for invoking it.

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

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

With 0% schema description coverage, the description shoulders the burden of interpreting the single utId parameter. Calling the target 'a UT' makes clear that utId is the UT identifier. It does not specify format or retrieval source, but for a single, self-explanatory parameter this is sufficient guidance.

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

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

The description names a specific action and resource ('Returns the quantitative analytics for a UT') and enumerates the main content categories (counts, success distribution, duration stats, variant info), so its purpose is clear. It does not explicitly distinguish itself from siblings like get_ut, get_transcript, or compare_rounds, though the quantitative angle makes it distinguishable.

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

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

The intended use is implied: call this when you need quantitative analytics for a UT. There is no explicit when-to-use/when-not-to-use guidance or reference to alternative sibling tools, so the agent must infer selection criteria from the tool name and purpose.

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

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

The readOnlyHint annotation already covers safety, and the description adds useful context about what content is returned. However, it does not clarify the behavior of the includeFullTranscript parameter, nor does it describe any limits or response-shaping nuances, so it provides only modest behavioral detail beyond the annotation.

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

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

The description is one front-loaded sentence with a clear verb and resource, followed by a concise list of included content. There is 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?

With no output schema and zero schema parameter coverage, the description should carry more weight. It does not explain the key optional parameter includeFullTranscript, which materially changes what is returned, leaving an agent without enough information to invoke the tool correctly in all cases.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It fails to explain includeFullTranscript entirely, and sessionId's semantics are only implicit. The listed return contents provide some context but do not clarify parameter usage or allowed values.

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

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

The description states a specific verb ('Returns') and resource ('one session') and enumerates the contents (UT context, notes, task measurements, linked transcript excerpts). This distinguishes it from sibling tools like get_transcript by making clear it returns a broader session snapshot, not just transcript data.

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

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

The description implies this tool is appropriate when a full session overview is needed, especially compared to a transcript-only tool, but it never explicitly names alternatives or states when not to use this tool. The usage context is clear enough to infer, but exclusions and sibling comparisons are absent.

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

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

Annotations already declare readOnlyHint=true, and the description goes further by specifying the transcript includes all segments, speakers, and timestamps. This adds behavioral context about the output beyond the annotation, though it does not cover pagination, limits, 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, efficient sentence that front-loads the core purpose and includes the most important output details. There is no repetition of schema or annotation information and no wasted words.

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

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

For a read-only tool with one simple parameter and no output schema, the description covers the essential behavior and return contents. It is only slightly incomplete because it does not suggest how to obtain the sessionId or explicitly route the agent away from sibling tools like get_session.

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

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

Schema description coverage is 0%, and the description does not explain the sessionId parameter beyond implying it identifies the session. It does not clarify the expected format, how to obtain it, or any constraints, so the description fails to compensate for the schema's lack of 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 uses a specific verb ('Returns'), names the resource ('full transcript'), and specifies the scope ('for a session') plus content details (all segments, speakers, timestamps). This clearly distinguishes it from sibling tools like get_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 makes it clear what the tool returns, so an agent can infer when to use it for transcript retrieval. However, it does not explicitly state when to use this tool instead of alternatives such as get_session, nor does it provide exclusion criteria.

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 readOnlyHint=true, the safety profile is already covered, and the description adds meaningful behavioral context by detailing the output components and the presence of reusable IDs. It doesn't mention potential response size or the effect of includeFullTranscript, but this is beyond the annotation coverage and mostly a parameter concern.

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: the first front-loads the tool's purpose and output contents, the second explains how to use the output. 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 adequately covers what is returned and how the output feeds into editing, which is useful. However, with no output schema and no parameter explanations, the missing includeFullTranscript semantics leave a notable gap for a tool that returns an aggregate structure.

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

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

Schema description coverage is 0%, so the description must document parameters. It never explains includeFullTranscript, and only indirectly hints at transcript excerpts. utId is self-explanatory, but the boolean parameter's behavior is left completely ambiguous.

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

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

Description states a specific verb and resource: 'Returns everything about one UT' and enumerates the exact content (scenario, quantitative results, sessions with notes and transcript excerpts). This clearly distinguishes it from sibling tools like list_uts, get_session, and get_quantitative_report.

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

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

It provides clear context that this is the one-UT deep retrieval tool and explicitly says to pass the returned scenario/use-case/task IDs to add_task/update_task when editing a draft. It doesn't mention alternatives or exclusions, but the usage context is unambiguous.

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

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

Annotations already provide readOnlyHint: true, so the safety profile is covered. The description adds the scope detail ('every workspace you can access'), which is useful behavioral context, but it does not disclose pagination, ordering, or default limit behavior beyond the schema's parameter constraints.

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

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

Two sentences, zero filler. The primary purpose and scope are front-loaded, and the optional filter is mentioned in a separate second sentence. 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 list tool with two optional parameters and no required inputs, the description covers the core use case and the status filter. Missing details include what the response looks like (field structure) and the behavior of the limit parameter, which could affect how an agent calls the tool 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 0%, so the description must compensate. It does clarify the status parameter by naming it as an optional filter and enumerating its values, which matches the schema enum. However, the limit parameter is completely unaddressed, leaving its purpose and behavior unspecified.

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

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

States a specific verb ('Lists') and a precise resource ('usability tests') with a clear scope ('across every workspace you can access'). It also implies a distinct role from siblings by calling itself 'the usual starting point for finding a UT', which differentiates it from get_ut and other 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?

Explicitly frames the tool as the default entry point for locating a UT ('the usual starting point'), giving clear when-to-use guidance. It does not explicitly state when to prefer alternatives like get_ut, but the contrast is implied and sufficient for a listing 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?

The annotations already declare readOnlyHint=true, and the description adds useful behavioral detail: the response includes the user's role per workspace and that only MEMBER or OWNER roles allow writes. This goes beyond the annotation without contradicting 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?

Two sentences, no filler. The first sentence states the action and output, and the second explains why it matters in relation to sibling tools. Every clause 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 zero-parameter list tool with a readOnlyHint, the description is complete: it covers purpose, return content (workspaces plus role), scope (workspaces you belong to), and the practical use case for navigating other tools. No output schema exists, but the description supplies the key return semantics.

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 baseline is 4. The description does not need to explain parameters; it adds relevant context about workspace reachability and write permissions instead.

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

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

The description opens with a specific verb and object: 'Lists every workspace you belong to, with your role in each.' It clearly identifies the resource (workspaces) and adds scoping (belong to), distinguishing it from list_uts and other tool-specific siblings.

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

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

It gives explicit context for when to use the tool: to discover which workspaces the other tools can reach and which ones are writable. It does not name a specific sibling alternative or state when not to use it, but for a zero-parameter discovery tool that is sufficient.

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

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

Annotations declare readOnlyHint=true, so no contradiction. The description adds useful behavioral context beyond annotations: it notes results are limited to notes the user can read (permission filtering), returns up to 200 matches, and includes use-case context in results for grouping. It could mention ordering or pagination, but for a read-only search tool this is solid.

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 and front-loaded: the first sentence states the core action and scope, and the second efficiently packs filter semantics, a result cap, and the result context. Every sentence earns its place with no filler.

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

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

For a read-only search tool with optional filters and no output schema, the description covers the essential behavior: what it searches, what filters exist, result limits, and result context. A minor gap is that it doesn't state default behavior when no filters are provided (e.g., whether it returns all accessible notes) or define the result order/grouping format explicitly.

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

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

Schema description coverage is 0%, but the description compensates by explaining the key meaning of each filter: query is substring and case-insensitive, tag is restricted to an enum, and the IDs are provided as optional filters. It does not elaborate on utId/sessionId/useCaseId semantics beyond naming them, but the context of searching notes with use-case context makes the meaning reasonably inferable.

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 verb and resource ('Searches notes you can read') and enumerates the available filters, which distinguishes it from the list/get siblings like get_session or get_quantitative_report. The wording 'Searches notes you can read' also clarifies the access scope, making the tool's 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 lists all filter dimensions and notes the 200-match cap, giving clear conditions for invocation. It doesn't explicitly contrast with sibling tools or state when NOT to use it, but the specificity of filters and the note about grouping findings per use case imply its intended usage context enough to earn 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?

Annotations already indicate the tool mutates (readOnlyHint=false) and is idempotent (idempotentHint=true). The description adds useful behavioral context beyond those annotations by constraining the operation to PREPARING drafts and clarifying the partial-update nature of passing one or both guide fields.

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 and front-loaded, with every sentence earning its place. It states the core action first, then gives the domain clarification, the parameters to pass, and the critical state restriction, with no filler.

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

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

For a simple three-parameter mutation tool with no output schema, this description is complete enough for correct invocation. It covers purpose, parameter semantics, state constraints, and how this tool differs from task-related siblings, leaving no critical gap.

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

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

Schema description coverage is 0%, so the description carries the full explanatory burden. It compensates well by defining openingGuide and closingGuide semantically (moderator's intro and wrap-up script) and by indicating optionality. utId is not explicitly described, but it is clearly implied by 'a draft UT's' and is the only required parameter in 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 opens with a specific verb and resource: 'Set a draft UT's scenario opening and/or closing guide.' It then explains the domain with concrete detail (moderator's intro and wrap-up script, session-level framing, not a task) and states the valid state (PREPARING drafts), making it clearly distinguishable from sibling tools like update_task and update_use_case.

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

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

It tells the agent exactly when to use the tool: only on PREPARING drafts, and exactly how to use it: pass openingGuide and/or closingGuide. It also gives an exclusion by clarifying this is not a task but session-level framing, guiding the agent away from task-related sibling tools.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true, so the description does not need to repeat those. It adds valuable behavioral context by specifying the draft status constraint and listing exactly which fields are updatable, which implies other fields are immutatable. This enriches the agent's understanding beyond the annotations without contradicting them.

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

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

The description is two compact sentences with no fluff. The first sentence front-loads the action and the full field list; the second sentence states the condition. Every word earns its place, and the structure makes it easy to scan.

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

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

Given there is no output schema and the tool is a focused update operation, the description covers the essential information: what fields can be updated and the precondition. It does not mention error behavior or return values, but that is secondary for an update tool, and the idempotent hint provides some side-effect assurance. Overall, it is complete enough for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It lists every updatable parameter (title, successCriteria, instruction, observationPoints[], probingQuestions[], observerMeasurementEnabled, participantRatingEnabled) and clarifies they can be updated 'any of' individually or together, which directly informs how to use the parameters. Though it does not elaborate on each field's meaning, the names are largely self-explanatory, and the listing is sufficient for correct usage.

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 specific verb 'update', the resource 'task in a draft UT', and enumerates the exact fields it can modify. The added constraint 'Only works on tasks of PREPARING drafts' clearly differentiates it from sibling tools like add_task and delete_task, leaving no ambiguity about what it does.

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 an explicit condition for use: 'Only works on tasks of PREPARING drafts.' This tells the agent when this tool is applicable and implicitly when it is not. It does not name alternative tools for other task states, but the condition is clear enough for an agent to decide.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true. The description adds the meaningful constraint that only PREPARING draft use cases can be updatedational context by stating that use cases group related tasks. This goes beyond the annotations without contradicting them.

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

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

The description is two sentences with no filler. The core action and constraints are front-loaded, and the extra context about use cases grouping related tasks is brief and relevant.

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 update tool with annotations covering safety and idempotence, the description covers the essential constraint (PREPARING drafts), the updatable fields, and the resource type. It does not describe return values, but no output schema exists and updates typically do not require extensive return documentation. Overall, it is nearly complete for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that title and description are the updatable fields and that useCaseId identifies the target use case, but it does not describe the ID format, whether at least one field must be provided, or whether omitted fields remain unchanged. Some meaning is added, but not full compensation.

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

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

The description states a specific verb ('Update'), a specific resource ('use case in a draft UT'), and the exact fields that can be changed ('title, description'). It also distinguishes itself from siblings like add_use_case and delete_use_case by focusing on modification of existing use cases.

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 an explicit applicable condition: 'Only works on use cases of PREPARING drafts.' This tells the agent when the tool is valid and indirectly when it is not. It does not explicitly name alternative tools for non-PREPARING drafts, but the condition is clear enough.

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

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

Annotations already signal mutation (readOnlyHint=false) and idempotency, so the description's added value is the PREPARING-only constraint and the explicit statement that status cannot be changed. These are meaningful behavioral disclosures, though it doesn't describe failure behavior or whether updates are partial.

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. The core purpose and field list come first, and the critical scope restriction follows immediately. No filler or repetition of the schema.

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

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

For an update tool with no output schema, the description covers the main invocation decision: what can be updated, on which state, and what cannot be done. It is missing minor operational details such as error behavior and success response, but the provided constraints make the tool safely callable.

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

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

With 0% schema description coverage, the description carries the parameter burden. It lists the four updatable fields and says 'any of' them can be set, which maps directly to the optional properties and clarifies partial updates. However, it does not define what each field means or any value constraints, so it only partially compensates for the bare schema.

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

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

The description names a concrete action ('Update'), a specific resource ('a draft UT'), and the exact metadata fields affected. It also draws a clear boundary against status changes and non-draft UTs, so it is not confused with create_ut, get_ut, or list_uts.

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

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

It explicitly states when the tool applies ('Only works on PREPARING drafts') and when it does not ('cannot change status or edit UTs that are already running or finished'). It does not name a specific alternative tool for status changes or completed UTs, so it stops short of a full 5.

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