Interbang

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

Annotations only provide readOnlyHint=false, so the description must add behavioral context. It does add the draft constraint and the return of a new taskId, but it does not explain side effects, error behavior, or what happens if the use case is not in PREPARING 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 concise and well-structured: one sentence for the main action and parameters, one for the return value, and one for the constraint. 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?

Covers the core purpose, return value, and key constraint, but for an 8-parameter tool with no schema descriptions, it leaves many parameter meanings undefined and does not address error conditions or edge cases. It is minimally viable but has clear gaps.

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

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

Schema description coverage is 0%, so the description should compensate by explaining parameter meanings. It merely lists the optional parameters without defining them, repeating information already in the schema (names and types), and adds no semantic value beyond required/optional status, which the schema already encodes.

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?

Clearly states it adds a task to a use case, with a specific verb and resource. It distinguishes itself from sibling tools like add_use_case and update_task, and includes the required title and the PREPARING draft constraint.

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 key when-not condition ('Only works on use cases of PREPARING drafts') that helps select the tool. However, it does not explicitly name alternatives (e.g., update_task for modifying tasks) or describe when to prefer other 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?

Beyond the readOnlyHint=false annotation, the description discloses a state constraint ('Only works on PREPARING drafts') and a key behavioral output ('Returns the new useCaseId'). This adds useful context, though it doesn't detail failure behavior or side effects for non-PREPARING drafts.

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 the core action, and every sentence adds value: purpose, grouping semantics, return value, and state constraint. 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?

Given the tool's simplicity, no output schema, and minimal annotations, the description covers the essential aspects: action, key parameters, return value, and precondition. It doesn't explain domain terms like 'UT' or handle all edge cases, but it is sufficient for an agent to invoke the tool correctly in most scenarios.

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

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

With 0% schema description coverage, the description must compensate. It clarifies that title is required and description optional, and 'a draft UT' implies utId's role. However, it doesn't explain the expected format, constraints, or how utId relates to the 'draft UT' beyond implication, leaving some gaps.

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

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

The description uses a specific verb and resource: 'Add a use case to a draft UT's scenario', making the tool's function immediately clear. It also distinguishes from sibling tools by noting 'Use cases group related tasks' and 'Returns the new useCaseId to use with add_task', positioning it as a prerequisite parent-creation 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?

It provides clear when-to-use context: the tool works only on PREPARING drafts, and the returned useCaseId links to add_task workflow. It doesn't explicitly name alternative tools for other states (e.g., update_use_case), so it lacks full exclusion guidance, but the constraints are strongly 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 readOnlyHint=true. The description adds behavioral context: defaults `against` to the previous round, requires the later round as utId, and enumerates comparison dimensions. No contradictions.

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

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

Two sentences, front-loaded with the operation, followed by usage parameter guidance. No redundant phrasing.

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

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

Given no output schema, the description compensates by listing the metrics and change categories returned. Covers core behavior and default logic in enough detail for an agent to select and invoke it.

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

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

Schema already describes both parameters (100% coverage). The description adds practical semantics: which round to pass as utId and how `against` defaults. This goes beyond the schema's literal definitions.

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 it compares two rounds of the same UT, listing specific metrics (success-rate, duration, rating deltas) and problem/bug movement. This clearly distinguishes it from sibling tools like get_ut or 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?

Provides explicit use context: 'Use it when asked to compare rounds or see what changed across iterations.' Also explains argument direction and default behavior. However, it does not mention when not to use it or name alternatives, so it falls just short of full marks.

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

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

The description discloses important behavioral traits beyond the annotation readOnlyHint=false: the UT is created as a PREPARING draft with an empty scenario, it must be built out via other tools, and it defaults to the personal workspace unless a workspaceId is provided. This adds useful context about the tool's behavior, though it does not mention permissions or error cases.

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 purpose ('Create a usability test as a PREPARING draft'). It efficiently packs required/optional fields, the empty scenario workflow, and workspace defaults without any redundant 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 create tool with 5 parameters, no output schema, and minimal annotations, the description covers the main workflow, the draft state, and workspace targeting. It lacks return value details and potential error conditions, but overall it provides enough context for an agent to use the tool correctly in a typical flow.

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 low (20% – only workspaceId has a description). The description adds that title is required and the others are optional, and recommends using list_workspaces to get workspaceId. However, it does not explain the meaning of background, hypotheses, or recruitmentCriteria beyond their names, so the added parameter semantics are limited.

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 usability test') and the specific state ('PREPARING draft'), with required and optional fields. It distinguishes itself from sibling tools like add_use_case and add_task by explaining that the newly created UT starts with an empty scenario and needs to be built out, 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 clear workflow context: create the draft, then build it with add_use_case / add_task, then a person reviews and starts sessions. It also gives guidance on workspace targeting (defaults to personal, use workspaceId from list_workspaces for team workspaces). However, it does not explicitly state when not to use this tool (e.g., for updating existing UTs), so it falls short of a 5.

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

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

Annotations already mark destructiveHint=true, but the description adds critical detail: the action is irreversible ('gone for good') and advises double-checking taskId. This significantly exceeds the annotation alone and prepares the agent for consequences.

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 deliver all essential information without fluff. The destructive warning is front-loaded, and the restriction on PREPARING drafts is clearly stated.

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

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

For a single-parameter destructive action with no output schema, the description covers irreversibility, prerequisite, status restriction, and caution. It is fully self-sufficient for an agent to execute safely.

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?

Although schema coverage is 0%, the description explicitly mentions taskId and its source ('from get_ut'), providing meaning beyond the bare schema. It also warns to double-check it, adding practical guidance for 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?

The description clearly states the verb ('Delete') and resource ('a task from a draft UT'), with the additional constraint 'Only works on tasks of PREPARING drafts.' This distinguishes it from siblings like delete_use_case and 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?

The description specifies the precondition (task must be in a PREPARING draft) and recommends fetching taskId via get_ut before calling. It doesn't name an alternative for non-PREPARING drafts, but the context is clear enough for 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?

Beyond the destructiveHint=true annotation, the description discloses irreversibility, cascading deletion of all tasks, and the PREPARING draft state requirement. This gives the agent critical safety context for a destructive 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 three concise sentences, front-loaded with the action and scope, followed by safety caveats and alternative. Every sentence adds value with no redundancy.

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

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

For a one-parameter delete tool, the description covers the essential aspects: what is deleted, side effects, preconditions, and state restrictions. The output schema is absent but not needed for a deletion operation, and sibling tools provide additional 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?

Although the schema only defines useCaseId as a string with no description, the description tells the agent to verify the useCaseId and its associated task list via get_ut, adding meaning to the parameter. Since there is only one parameter, this is sufficient.

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

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

The description clearly states the action (delete) and target (use case from a draft UT), and specifies scope (including every task inside it). It also distinguishes itself from the sibling delete_task by explicitly noting when to use the alternative.

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

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

It provides explicit guidance: prefer delete_task for single task removal, check useCaseId and task list from get_ut before calling, and only works on PREPARING drafts. This gives clear when-to-use and when-not-to-use instructions.

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 a safe read operation. The description adds value by specifying the exact content (account email, scopes 'ut:read / ut:write', and workspace count) that the returned report contains, going beyond the annotation's generic hint.

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 information is front-loaded: the first sentence states what it reports, the second sentence gives the recommended use. 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?

Since there is no output schema, the description appropriately explains the return content (email, scopes, workspace count) and the use case. It could elaborate on the exact meaning of 'how many workspaces it can read' or potential auth edge cases, but for a parameterless read-only tool, it is substantially complete.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The description reinforces that no input is needed ('this connection'), and baseline for parameterless tools is 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 uses the specific verb 'Reports' and clearly states the resource ('this connection') and the exact data returned (email, scopes, workspace count). It distinguishes this tool from the sibling tools, which focus on tasks, use cases, and sessions, by focusing on access/permission info.

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,' providing a clear use-case. It doesn't list alternatives or exclusions, but given the unique purpose among siblings, this context 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 already declare readOnlyHint=true, so the description does not need to restate safety. It adds value by specifying the return content categories, which helps the agent predict behavior. However, it does not mention potential limitations, errors, or prerequisites beyond the schema. Given the annotation coverage, a 4 is appropriate.

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

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

The description is a single, front-loaded sentence that lists key information without wasted words. It is optimally concise for the tool's simplicity.

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 (one parameter), the readOnly annotation, and the absence of an output schema, the description provides a solid summary of what the tool returns. It does not detail error cases or the exact structure of the analytics, but it is sufficient for a simple retrieval tool.

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

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

Schema coverage is 0% and the description does little to explain the utId parameter beyond implying that it identifies a UT. It does not clarify the format, where to obtain the ID, or any constraints. The parameter name is somewhat self-explanatory, but the description does not compensate for the missing schema descriptions.

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

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

The description clearly states the tool returns quantitative analytics for a UT and enumerates specific content (overall counts, per-task success distribution, duration stats, variant info). This specific verb+resource combination distinguishes it from siblings like get_transcript or get_ut.

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 purpose implies when to use the tool (when quantitative analytics are needed), but it does not explicitly mention alternatives or exclusions. Sibling tools exist for other purposes (e.g., get_transcript), but no comparative guidance is provided. This is adequate but below 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 readOnlyHint=true, the safety profile is covered. The description adds value by listing the components of the return payload, but it doesn't disclose the behavior of includeFullTranscript or other potential edge cases. Still, it provides useful context 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 a single, well-structured sentence that is front-loaded with the core action. Every word earns its place, and it is easy to scan.

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

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

The description gives a good overview but omits details about the includeFullTranscript flag and return structure. With no output schema, these gaps make the description slightly incomplete for full 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?

Schema description coverage is 0%, and the description does not explain the parameters. It mentions 'everything' but does not clarify sessionId's role or the effect of includeFullTranscript. The description fails to compensate for the missing parameter details.

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

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

The description clearly states the tool's purpose: 'Returns everything about one session' and enumerates the specific content areas (UT context, notes, task measurements, transcript excerpts). This distinguishes it from sibling tools like get_transcript and get_ut, which are more narrowly scoped.

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 a comprehensive session fetch, providing clear context for when to use it (when you need a full picture of a session). It doesn't explicitly mention alternatives or exclusions, but the 'everything' wording sets expectations relative to more targeted sibling tools.

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

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

Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds detail about the return content (segments, speakers, timestamps) but not behavioral traits like pagination, ordering, or errors. Meets the baseline 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 a single, front-loaded sentence that conveys all key information without fluff. Every word adds value.

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

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

For a simple one-parameter getter with read-only annotations, the description fully explains the return value and scope. No output schema exists, so describing the segments/speakers/timestamps is sufficient.

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

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

Schema description coverage is 0%, and the description only indirectly references the sessionId by saying 'for a session'. It does not explain the parameter format, origin, or required nature, leaving the schema to carry the sole responsibility.

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 precisely states the tool returns the full transcript for a session, including segments, speakers, and timestamps. This distinguishes it from sibling tools like get_session or compare_rounds.

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

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

The description implies usage when you need a session transcript, but provides no explicit guidance on when to use this tool versus alternatives like get_session or search_notes. There are no exclusions or alternative tool mentions.

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's 'Returns' aligns with that. It adds behavioral details about the output structure (scenario use-case and task ids) and the inclusion of transcript excerpts. It doesn't contradict annotations, and provides useful context beyond the structured 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?

Two concise sentences, with the core purpose front-loaded. Every sentence adds value: the first describes the return content, the second explains a downstream use of 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?

Given the lack of an output schema, the description adequately enumerates what the tool returns and includes practical guidance for editing. It does not explain the includeFullTranscript parameter or potential response size, but for a read-only getter with two self-explanatory parameters, it covers the essentials 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?

Schema description coverage is 0%, so the description must compensate for explaining utId and includeFullTranscript. It does not explicitly describe either parameter, though 'one UT' implicitly refers to utId and 'transcript excerpts' hints at includeFullTranscript. The parameter names are self-explanatory, but the description adds minimal semantic value to the schema.

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

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

The description clearly states the tool returns everything about one UT, enumerating the specific components (scenario, quantitative results, sessions with notes and transcript excerpts) and distinct resource ('one UT'). This distinguishes it from sibling tools like get_session or 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?

The description gives a clear context: use when you need the full picture of a UT, and specifically provides downstream guidance to pass the resulting use-case/task IDs to add_task/update_task. It does not explicitly state exclusions or alternatives, but the context is clear enough for an agent to select it over more focused getters.

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. The description adds behavioral context by explicitly stating it spans 'every workspace you can access,' which clarifies scope. It also mentions the optional status filter behavior. No contradictions.

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

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

Two concise sentences; the main action and scope are front-loaded, with filter information following. 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 list tool with two optional params, the description covers purpose, scope, and filtering. It doesn't explain return format or limit behavior, but these are not critical given the tool's simplicity and readOnly annotation.

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

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

The schema has no descriptions (0% coverage). The description explains the status parameter with its allowed values, but does not mention the limit parameter or its default/pagination behavior. Thus, partial 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 clearly states the tool lists usability tests across all accessible workspaces, using a specific verb ('Lists') and resource ('usability tests'). It distinguishes from siblings like get_ut by noting it's the 'usual starting point for finding a UT.'

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 guidance that this is the default entry point for finding a UT, implying use before retrieving specific UT details. It does not explicitly name alternatives (e.g., get_ut) or exclusions, but the context 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 already declare readOnlyHint=true, which the description aligns with by saying 'Lists.' The description adds extra context beyond the annotation by explaining the role field and write access implications (MEMBER/OWNER), which is useful behavioral information not present in the schema or 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 exactly two sentences. The first states the core function, and the second provides crucial context about how the output relates to other tools. There is no wasted wording or redundant rephrasing 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 a zero-parameter, read-only list tool, the description covers the essential aspects: what is listed, what role info is included, and the practical purpose. It could mention the response format or any ordering/limitations, but given the simplicity, the description 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 tool has zero parameters, so the baseline for parameter semantics is 4. The description compensates by explaining what the list contains (workspaces and roles) and how to interpret it, which adds meaning beyond the empty input 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 ('Lists') and resource ('every workspace you belong to'), and adds the role detail ('with your role in each'). It also distinguishes itself from siblings by noting it shows which workspaces other tools can reach and which ones you can write 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?

It clearly states when to use the tool: 'use this to see which workspaces the other tools can reach — and which ones you can write to (MEMBER or OWNER).' This provides clear context, though it does not explicitly name alternative tools 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?

Annotations already declare readOnlyHint:true, and the description adds behavioral context: access is restricted to notes the user can read, the result set is capped at 200 matches, and returns carry use-case context for grouping. This goes beyond the annotation by disclosing the limit and permission scope.

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, no redundant phrasing. Every sentence adds value: first defines the action and scope, second lists filters and return behavior.

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 the essential return behavior (limit, context grouping) but doesn't detail the exact structure of returned notes beyond mentioning use-case context. Given no output schema and 5 optional parameters, a bit more specificity about fields or ordering would make it fully complete, but it's sufficient for an agent to invoke 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?

With 0% schema description coverage, the description compensates by enumerating all five parameters and explaining the semantics of 'query' (substring, case-insensitive) and 'tag' (with enum values). The identifier parameters ('utId', 'sessionId', 'useCaseId') are self-explanatory from their names, though not elaborated.

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 verb ('Searches') and resource ('notes you can read'), lists all filter parameters with specifics (e.g., 'substring, case-insensitive' for query, enum values for tag), and distinguishes itself from sibling tools which are mostly mutating or fetching specific entities.

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

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

The context clearly implies this tool is for searching/filtering notes, and sibling tools operate on different resources (tasks, UTs, sessions, workspaces) or perform mutations, so there's no ambiguity. However, it doesn't explicitly mention when-not to use this tool or name an alternative like some descriptions do.

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 idempotent (idempotentHint=true) and a write operation (readOnlyHint=false). The description adds the state constraint 'Only works on PREPARING drafts' and the clarification that this is session-level framing, which goes beyond annotations. It doesn't detail error behavior, but the key constraints are disclosed.

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

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

Two sentences, front-loaded with the action and target. Every sentence adds value: purpose, clarifying distinction, parameter guidance, and state constraint. No redundancy.

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

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

For a simple 3-parameter update tool with no output schema and good annotations, the description covers purpose, key parameters, and a state constraint. It doesn't describe return values or errors, but that is less critical given the simplicity and no output schema.

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

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

Schema has no descriptions (0% coverage), but the description defines openingGuide and closingGuide as the moderator's intro and wrap-up script. It implies utId is the draft UT ID, but doesn't explicitly describe it nor state that at least one guide must be passed. Partial compensation for the missing 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+resource: 'Set a draft UT's scenario opening and/or closing guide', and immediately clarifies it's the moderator's session-level framing, not a task. This distinguishes it clearly from siblings like update_task and update_ut.

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

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

It gives a clear precondition ('Only works on PREPARING drafts') and tells the user to 'Pass openingGuide and/or closingGuide'. It also explicitly says 'not a task' to steer away from task-level tools. It doesn't name alternatives, but the context 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 annotations (readOnlyHint=false, idempotentHint=true), it reveals the 'any of' partial update semantics and the PREPARING draft constraint. This adds useful behavioral context, though auth, return value, and error cases are not covered.

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

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

Two sentences, front-loaded with the action and resource, then the constraint. No wasted words, fully readable.

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 8 parameters, no output schema, and annotations present, the description covers purpose and a key constraint but omits behavior like return value, error conditions for non-PREPARING drafts, and confirmation of partial update semantics. 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?

With 0% schema description coverage, the description merely recites field names without explaining their meaning or format. It adds 'any of' to imply optionality, but the schema already marks fields as optional; deeper semantics are missing.

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 updates a task within a draft UT, lists the specific updatable fields, and differentiates from siblings by targeting task-level changes in PREPARING drafts, not UTs or scenarios.

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 notes it only works on tasks of PREPARING drafts, providing a clear prerequisite condition. It doesn't name alternatives, but the scope and context are clear enough for 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 declare readOnlyHint=false and idempotentHint=true, so the description does not need to repeat those. It adds valuable behavioral context by constraining to PREPARING drafts, which is not present in annotations. This goes beyond what structured data provides.

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 deliver the essential information: purpose, updatable fields, and a key constraint. No fluff, front-loaded with the action.

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 mutation tool with no output schema, the description covers the critical constraint (PREPARING drafts) and the scope. It lacks details on error behavior or response format, but these are not strictly necessary given the simplicity and presence of annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It lists 'title' and 'description' as updatable, which adds some meaning, but it fails to explain the role of 'useCaseId' (required, identifier) and does not clarify that at least one field should be provided. The partial coverage earns a middle score.

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 use case', specifying the action and resource. It distinguishes from sibling tools like update_ut and update_task by targeting use cases, and the mention of 'title, description' adds specific 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 provides clear context: it operates on use cases in a draft UT, and explicitly excludes non-PREPARING drafts with 'Only works on use cases of PREPARING drafts'. It does not name alternative tools, but the context is sufficient to infer when to use it over siblings.

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

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

Annotations already indicate write operation (readOnlyHint=false) and idempotency. The description adds important context about the draft state requirement and prohibition on status changes, which annotations do not cover. No contradiction with annotations.

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

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

Two sentences, no fluff. Front-loaded with the verb and resource, then states the key constraint. 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?

Given the simple parameter list (5 optional strings) and no output schema, the description covers the core behavior, draft-state restriction, and what cannot be changed. It does not explain partial update behavior explicitly, but 'any of' implies any combination. Lacks details on error scenarios, but not necessary for this complexity.

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

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

Schema coverage is 0%, so description must compensate. It lists all optional fields, and the term 'metadata' groups them, but does not explain each field's meaning or constraints beyond names. This is adequate but not rich; the param names are self-explanatory.

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 updates a draft UT's metadata, listing specific fields (title, background, hypotheses, recruitmentCriteria). It distinguishes from sibling tools by specifying it only works on PREPARING drafts and cannot change status.

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 usage restrictions ('Only works on PREPARING drafts; cannot change status or edit UTs that are already running or finished'), but does not name alternative tools. This provides clear when-not guidance, though no explicit alternatives are given.

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