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

Annotations already signal a write operation with destructiveHint true and readOnlyHint false. The description adds meaningful behavioral context by noting the contact is created for the signed-in user and that explicit user consent is required, which goes beyond the annotations.

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

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

The description is a single, front-loaded sentence with no filler. It states the core action first and then the usage condition, making it easy to parse quickly.

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

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

For a simple two-parameter create operation with annotations covering the safety profile, the description is largely sufficient. It does not mention return values or duplicate behavior, but no output schema exists and this omission is not critical for basic invocation.

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

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

The description provides no parameter-level guidance, and schema description coverage is 0%. The schema itself documents name and email with constraints, but the description does not compensate for the low coverage by explaining how the parameters should be supplied or what they represent beyond their names.

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

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

The description states a specific verb and resource: 'Add a contact for the signed-in user.' This clearly identifies the operation and scope, and distinguishes it from sibling tools like search_contacts and other read-oriented tools.

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

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

The description gives an explicit trigger: 'Call only after the user explicitly asks to save the contact.' This is a clear when-to-use and when-not-to-use statement, though it does not explicitly name alternative tools for related actions such as searching contacts.

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

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

Annotations are present but minimal (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds value beyond these by clarifying that the tool does not send messages or schedule a bot, and that it saves a 'manual' note, implying no auto-generation. It does not disclose overwriting behavior or error conditions, but the explicit side-effect exclusions are useful context not present in annotations.

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

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

The description is two concise sentences with no fluff. The primary action is front-loaded, and the clarifying negation follows briefly. Every word contributes to disambiguating the tool's scope. It is appropriately sized 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 tool's simplicity (2 required params, no output schema, minimal annotations), the description covers the core action and a key behavioral limitation. However, it omits crucial usage details like parameter semantics, whether it overwrites existing prep notes, and any validation (e.g., meeting must exist). Since schema coverage is 0%, these gaps make the description incomplete for an agent to call it correctly without extra reasoning.

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

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

Schema description coverage is 0%, so the description must carry the burden of explaining parameters. It only hints that meeting_id refers to a user-accessible meeting, but provides no detail on note_text content, format, or constraints beyond what the schema offers (min/max length). The description does not add meaningful semantic information for either parameter, leaving the agent to infer from names and context.

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 ('Save') and resource ('manual prep note') with a scope ('for a user-accessible meeting'), and explicitly contrasts with actions it does not perform ('does not send messages or schedule a bot'). This distinguishes it from related tools like get_meeting_prep and any messaging/scheduling tools, 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 gives context about when to use it (to save a manual prep note) and states exclusions (no messages, no bot scheduling), which indirectly steers away from certain tools. However, it does not explicitly name alternatives like get_meeting_prep for retrieval, nor does it mention prerequisites such as the meeting existing or being user-accessible. Guidance is implied rather than explicitly comparative.

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 that this is a mutating operation creating a task for the signed-in user, and it adds a consent boundary. With annotations all false and no output schema, it does not explain persistence, duplicate behavior, idempotency effects, or what happens after creation.

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

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

The description is two sentences with no filler. The primary purpose is front-loaded, and the usage guardrail is a separate, purposeful sentence that 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 mutating tool with no output schema, no useful annotation detail, and five parameters at 0% schema description coverage, this description is too thin. It leaves return behavior, differentiation from create_user_owned_task, and parameter semantics unaddressed.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it mentions none. Field names like title and description are somewhat self-explanatory, but status, due_date, priority, defaults, and required fields receive no explanatory context in the description.

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

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

The description states a specific action ('Create'), a specific resource ('Zero task'), and a clear user scope ('for the signed-in user'). It is distinguishable from read/list siblings, but it does not clarify how create_task differs from the similarly named sibling create_user_owned_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 an explicit trigger condition: 'Call only after the user explicitly asks to save the task.' This clearly prevents unsolicited creation. However, it provides no guidance on when to prefer this tool over create_user_owned_task or other creation-related 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 this is a mutating, non-idempotent operation. The description adds useful context that user consent is required and that the task is OpenClaw-compatible, but it does not disclose persistence behavior, ownership semantics, or side effects beyond creation.

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 very concise and front-loads the core purpose in the first sentence. The second sentence adds a key trigger condition. It is appropriately short, though the cryptic 'OpenClaw-compatible Zero task' phrasing sacrifices some explanatory 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?

Given five parameters, no output schema, and a sibling create_task that could be confused with this tool, the description is incomplete. It gives one useful usage condition but omits required field semantics, optional field behavior, ownership implications, and any differentiation from create_task.

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 by explaining parameter meaning, but it mentions no parameters at all. With five parameters including required title and description, plus optional status, due_date, and priority, the description provides zero guidance on how to fill them.

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

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

The description states a clear verb and resource: it creates a 'Zero task' and is tied to saving a task after user request. However, it does not explicitly differentiate itself from the sibling create_task or explain what 'Zero' means, so it is clear but not fully distinguishing.

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 an explicit usage condition: 'Call only after the user explicitly asks to save the task.' This gives clear context for when to invoke it, though it does not mention alternatives like create_task or state when not to use this tool.

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

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

Annotations already disclose destructiveHint and idempotentHint, so the basic safety profile is covered. The description adds a meaningful behavioral boundary—this is local to this MCP and has no effect on other ZeroHrs sessions—which is not evident from the annotations or schema.

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

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

Two short sentences carry all the necessary information, with the primary action front-loaded and the scope clarification immediately following. No filler or redundancy.

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

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

For a parameterless, outputless disconnect operation, the description plus annotations fully cover purpose, safety, and scope. Nothing an agent needs to call it correctly is missing.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter detail for the description to add. The no-parameter baseline applies here.

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

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

The description uses a specific verb and resource ('Remove the session saved by this local MCP') and explicitly distinguishes the tool's scope from other ZeroHrs sessions, matching the title's intent and differentiating it from broader logout tools.

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

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

It clearly states the operation's boundary ('does not revoke or sign out other ZeroHrs sessions'), so an agent knows this is for local disconnection only. It doesn't explicitly name an alternative tool like login, but the exclusions make the appropriate context clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond those annotations by specifying that the data is scoped to the signed-in user and is private, which implies authentication and user-specific 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?

A single, front-loaded sentence that states the action, resource, and scope with no filler. Every word adds value.

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

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

For a simple one-parameter getter with fully descriptive annotations and a complete input schema, the description sufficiently covers what is returned: a meeting record with private prep notes and people. No output schema exists, but the description summarizes the return content well enough for correct invocation.

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

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

Schema coverage is 100%, and the single parameter meeting_id is already described as 'Known Zero meeting id.' The description adds no additional parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get a meeting record' with the additional scope 'signed-in user's private prep notes and people.' This clearly distinguishes it from related tools like get_transcript or list_meetings by identifying its unique content and access 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 gives clear context for when to use this tool: whenever the agent needs the signed-in user's private meeting prep notes and people. It does not explicitly name alternatives or exclusions, but the phrasing makes the intended use unambiguous.

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

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

Annotations already declare the tool read-only, idempotent, non-destructive, and closed-world, so the description does not need to restate safety. It adds the signed-in-user scope and filter dimensions, but it does not disclose return values, ordering, or pagination behavior. No contradiction with annotations exists.

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

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

A single sentence that front-loads the operation, scope, and available filters with no filler or restated schema information. 'OpenClaw-compatible' is a compact compatibility qualifier rather than 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?

With five parameters, no output schema, and low schema coverage, the description omits too much: no return shape, no pagination details, and no disambiguation from list_meetings. The annotations cover the safety profile, but the definition is not complete enough for an agent to call the tool with confidence.

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 only documents after and before; query, limit, and status are undocumented, leaving 40% schema coverage. The description's mention of status/title/time filters helps map query to a title search and before/after to time bounds, but it does not explain limit or the exact boundary semantics, so it only partially compensates for the schema gap.

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

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

The description identifies a specific operation ('meeting lookup') and a clear scope ('for the signed-in user'), and names the available filter dimensions. It does not explicitly distinguish this tool from the similarly named sibling list_meetings, so the agent cannot fully separate the two from the description alone.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative tool is named. The 'signed-in user' phrase implies a scope, but it does not tell the agent to prefer this tool over list_meetings or search_transcripts in a given situation.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by stating that the tool returns only query-matched speaker blocks rather than the full transcript, and that tasks are optional. This goes beyond the annotations, though it does not detail error behavior or the effect of each boolean flag.

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, front-loaded with the core lookup action and without filler. The term 'OpenClaw-compatible' adds some context but is unexplained jargon, which slightly reduces clarity.

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 and four parameters, the description provides a useful high-level return shape but omits details about how the required include_turns and include_tasks booleans control the result, what happens when query is omitted, and how this tool differs from get_transcript or search_transcripts. These are notable gaps for an agent deciding how to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It maps query to 'query-matched speaker blocks', transcriptId to 'by id', and include_tasks to 'optional tasks', but it never explicitly mentions include_turns. An agent can infer that turns correspond to speaker blocks, but the mapping is not fully spelled out for all four parameters.

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

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

The description uses a specific verb ('lookup') and resource ('transcript by id'), and scopes the return payload to the summary, optional tasks, and query-matched speaker blocks. This content-based scoping distinguishes it from a full-transcript fetch such as the sibling get_transcript, even though that sibling is not named.

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

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

The description implies when the tool is appropriate: when you need a transcript by ID with summary, optional tasks, or filtered speaker blocks. However, it provides no explicit alternatives, exclusions, or guidance about when to prefer get_transcript or search_transcripts instead, leaving that to inference.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds useful context about user scoping and local-date semantics, but it does not disclose edge-case behavior such as what happens when no brief exists for the date or what the response contains.

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

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

The description is a single sentence with no filler. It front-loads the verb, resource, user scope, and date scope, making it easy to parse quickly.

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

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

For a simple read-only tool with one required parameter and strong annotations, the description is mostly sufficient: it identifies what is read, whose data is read, and for which date. It could be slightly more complete by describing the return value or handling of missing briefs, but these are minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. The phrase 'local calendar date' adds important semantic meaning beyond the schema's generic 'date' format and pattern, clearly indicating the local_date parameter's role and timezone-sensitive nature.

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

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

The description uses a specific verb ('Read') with a clear resource ('the signed-in user's Zero morning brief') and a precise scope ('one local calendar date'). It is immediately distinguishable from siblings like search_zero, get_transcript, or get_meeting_prep, so an agent can tell what this tool is for.

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

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

The phrase 'for one local calendar date' gives a clear condition for when to call this tool: when a specific dated brief is needed. It does not explicitly name alternatives or state when not to use this tool, so it misses the top score.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect profile. The description adds minimal behavioral context beyond annotations, namely the 'user-accessible' scoping qualifier. It does not address not-found behavior or return format, but with strong annotation coverage a 3 is appropriate.

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

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

A single sentence that immediately states the verb, resource, scope, and key parameter. There is zero filler, and the essential information is front-loaded. This is an example of efficient understated design.

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

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

For a simple, single-parameter getter with annotations covering safety and idempotence, the description plus schema is nearly sufficient. The only gaps are unstated behavior for missing/not-found tasks and any return value specifics, which are not covered by an output schema. Given the low complexity, this is adequately complete.

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

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

Schema description coverage is 100%; the parameter task_id is documented as 'Known Zero task id.' The description merely restates that lookup is by id, adding no further semantic detail beyond the schema. Thus the baseline of 3 applies.

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

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

The description uses a specific verb ('Get'), a resource ('Zero task'), and a unique identifier ('by id'), making the operation unambiguous. It clearly distinguishes itself from sibling list/creation tools like list_tasks and create_task by indicating it retrieves exactly one task. The qualifier 'user-accessible' adds precision about 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 conveys clear context: use this when you have a known task id and need a single Zero task. It does not explicitly state exclusions or name alternative tools for list/search scenarios, but the 'one... by id' phrasing implies the right situation. Sibling names provide additional context, so this is slightly above baseline.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context that "This never loads every transcript turn" and describes optional inclusion of tasks and query-matched blocks, but it does not disclose what the summary contains or mention any response limits beyond the schema.

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

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

The description is two sentences with the primary action front-loaded. It is concise, scannable, and every sentence adds value without redundancy.

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

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

For a 4-parameter tool with no output schema, the description covers the main purpose and two optional behaviors, but fails to explain turn_limit or define what the transcript summary includes. It is adequate for basic invocation but not fully complete.

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

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

Schema description coverage is only 25%, so the description must compensate. It indirectly explains include_tasks ("linked tasks") and turn_query ("query-matched speaker blocks with adjacent context"), but turn_limit is not mentioned or clarified, leaving a meaningful gap for agent understanding.

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

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

The description clearly states a specific action and resource: "Get a transcript summary by id." The word "summary" distinguishes this from list/search transcripts, though it does not explicitly name a sibling alternative for contrast.

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 clear this tool is for retrieving a single transcript summary when you have a transcript id, with optional extensions for tasks and query-matched speaker blocks. It does not explicitly state when to prefer list_transcripts or search_transcripts, but the "by id" context provides adequate guidance.

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

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

Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context by stating that it searches titles/summaries and does not return full turns. However, it does not disclose pagination, ordering, or how boundary parameters affect results.

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

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

A single sentence that states the action, scope, and an important limitation. Every word earns its place, with no filler or repetition. It is efficiently front-loaded with the core 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?

For a tool with 4 parameters and no output schema, this description is too thin. It does not explain limit semantics, the meaning of 'OpenClaw-compatible,' or how this tool differs from the sibling search_transcripts. An agent cannot fully determine correct invocation or tool selection from the provided information.

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

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

Schema descriptions cover after and before, but the required query parameter has no schema description and limit is entirely undocumented. The description clarifies that query searches titles and summaries, but it does not explain limit semantics or add anything beyond the schema for the boundary parameters. With 50% schema coverage, the description should compensate more but does not.

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

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

The description states a specific verb and resource: 'search across transcript titles and summaries' and adds the qualifier 'without full turns,' which distinguishes it from full-transcript retrieval. However, it does not explicitly differentiate from the sibling tool search_transcripts, leaving some ambiguity about what makes this tool unique.

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

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

The description gives no explicit when-to-use guidance or alternatives. The 'without full turns' phrase implies it is for metadata-level search, but there is no mention of using get_transcript for full transcripts or search_transcripts for a different search scope. An agent receives no routing guidance among the many 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful scoping detail that the search is limited to the signed-in user's tasks and covers title and description, but it does not disclose return format or pagination behavior beyond the existing 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 concise sentence that front-loads the action and scope. There is no filler or redundant restatement of the tool name, and every phrase adds useful information about what the tool searches.

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 search tool with four parameters, no output schema, and many siblings, the description gives only minimal context. It clarifies the search scope but does not explain when to prefer it over search_zero or list_tasks, nor does it describe the result shape or how after/before boundaries behave beyond the schema.

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

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

The input schema documents before and after as time boundaries, but q and limit lack descriptions. The description partially compensates by clarifying that the search targets task title and description, which gives meaning to q. However, limit and date-range usage are not elaborated, and schema coverage is only 50%.

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 ('search') and a specific resource ('the signed-in user's Zero task title and description'), so an agent can understand the core function. It does not explicitly differentiate this from sibling tools like search_zero or list_tasks, so it is clear but not fully distinguished.

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?

There is no guidance on when to use this tool versus alternatives such as search_zero, list_tasks, or search_transcripts. The description implies a search use case but does not state when it is the right choice or when another tool should be preferred.

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 this is a mutating, non-idempotent, non-destructive action, and the description's 'creation' is consistent with that. Beyond the annotations, the description adds only weak context ('manual', 'user-accessible') and does not explain effects, whether notes are appended or replaced, access requirements, or response 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 short sentence, which is structurally concise. However, the phrase 'OpenClaw-compatible' adds noise without contributing useful meaning, and the sentence is so terse that it sacrifices substance for brevity.

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

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

For a tool with two unnamed required parameters, no output schema, and several ambiguous sibling tools, this description is incomplete. An agent lacks enough information about parameter meaning, usage context, behavioral effects, and return value to confidently invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining meeting_id and note_text. It does not meaningfully explain either parameter beyond the obvious naming, nor does it mention constraints like note length or the need for the meeting to be accessible to the user.

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 verb ('creation') and a resource ('prep note for a user-accessible meeting'), so the basic action is identifiable. However, 'OpenClaw-compatible' is unexplained and the description does not distinguish this tool from the closely named sibling add_meeting_prep_note or replace_generated_prep_notes_for_meeting.

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 word 'manual' weakly implies use when a user is creating a note by hand rather than automatically generating one, and 'user-accessible meeting' hints at a permission condition. But the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternative sibling tools, so an agent cannot reliably choose between this and add_meeting_prep_note.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safety profile. The description adds the signed-in user's scope and filter options, but does not mention pagination, ordering, or default limit. This matches the expected baseline given annotation coverage.

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

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

One sentence, action first, filter options following, with no wasted words. The description is concise while still carrying the key information needed for selection and basic invocation.

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 five-parameter, all-optional listing tool with no output schema, the description covers purpose and the main filter semantics. The schema supplies after/before definitions and limit bounds, so together they support correct invocation. The only notable gap is the absence of explicit return-format or ordering details, which is minor given the tool's self-descriptive name.

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

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

Schema description coverage is only 40%, so the description compensates by linking q to 'title text,' after/before to 'time window,' and referencing status. This adds meaningful semantics for otherwise undocumented parameters. Limit remains unexplained, but its default/min/max in the schema provide mechanical constraints.

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

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

The description starts with a specific verb and resource: 'List the signed-in user's stored meetings.' It also states the optional filtering dimensions. This makes it clearly distinct from sibling tools like list_transcripts (different resource) and search tools (search vs. list).

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

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

It gives clear context: this tool lists the signed-in user's stored meetings, optionally filtered. It does not explicitly name alternatives or exclusions, but the boundary is obvious relative to the sibling list/search tools, so no misleading guidance is present.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations by scoping results to the signed-in user's tasks, indicating that q searches title and description, and that before/after narrow the result by time.

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

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

A single, tightly written sentence that front-loads the action and resource, then states search scope and optional time filtering. No filler or repetition.

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

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

For a read-only list/search tool with strong annotations and optional parameters, the description plus schema cover the core invocation details: what is searched, user scope, and time boundaries. It could mention return format or alternative use of search_zero, but these are not blocking for correct basic use.

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

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

The schema describes after and before as time boundaries but leaves q and limit undocumented. The description partly compensates by explaining that search is by title and description and that time windowing is optional, but it does not clarify limit behavior or the exact default semantics of q.

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 identifies a specific verb and resource: listing or searching the signed-in user's Zero tasks, with optional time narrowing. This clearly distinguishes it from create/update/get_task, though it does not explicitly contrast it with the sibling search_zero.

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

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

The description implies when to use the tool: when you need to list or search the signed-in user's tasks by title/description or within a time window. It provides no explicit guidance about when to prefer search_zero or other search alternatives, so the routing is left to inference.

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

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

Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds a key behavioral trait not present in annotations: it does not load transcript turns, indicating a lightweight operation. It also implies recency ordering. No contradiction with annotations.

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

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

The description is exactly two sentences, with the primary purpose front-loaded and no redundant phrasing. Every word contributes to clarity, making it efficient for an agent to parse quickly.

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

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

For a simple read-only list tool with three optional parameters and no output schema, the description covers the main purpose and parameter usage. It does not explicitly describe the return format or ordering, but these are minor given the tool's simplicity and the presence of annotations covering safety.

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

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

Schema descriptions already explain 'after' and 'before' as time boundaries, so the description's note about narrowing the time window adds marginal value. The limit parameter is self-explanatory when combined with its schema constraints. With schema coverage at 67%, the baseline is 3, and the description does not significantly enhance parameter understanding beyond the schema.

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

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

The description uses a specific verb ('List') and resource ('transcript records') with a distinguishing qualifier ('without loading transcript turns'), clearly differentiating it from tools like get_transcript. The tool name and title align well, leaving no ambiguity about the tool's core function.

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

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

The description implies use cases (listing metadata without turns) but does not explicitly name alternatives or state when not to use this tool. The instruction to 'use before or after' narrows the time window is parameter guidance, not tool-selection guidance. Usage context is implied rather than explicit.

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

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

The description goes beyond the all-false annotations by disclosing that the tool initiates a browser-based sign-in, implying a side-effecting and non-idempotent action. The critical behavioral trait "No session token passes through Codex chat" is a valuable privacy disclosure not captured in the annotations. It does not fully explain session lifecycle or whether user interaction is required, but the core behavior is clearly communicated.

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 with no filler. The primary action is front-loaded, and the second sentence adds a critical security justification without redundancy. Every word contributes to the agent's understanding.

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 tool, the description covers the essential behavior and the important privacy guarantee. The main gaps are the lack of any mention that login is a prerequisite for authenticated sibling operations and no indication of what response or confirmation the agent should expect, especially since there is no output schema. These are minor omissions for such a simple action.

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

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

The tool has zero parameters and the schema description coverage is 100%, so there is nothing for the description to add about parameters. The baseline of 4 applies because no parameter documentation is needed. The description's reference to "private browser sign-in" provides action-level context rather than parameter semantics.

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

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

The description clearly states a specific verb and resource: "Start a private browser sign-in for this local MCP." It also adds a distinguishing security detail — "No session token passes through Codex chat" — which sets this tool apart from the data-oriented sibling tools. Even without the tool name, an agent would understand exactly what action this performs.

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 should be used when authentication for the local MCP is needed, and the tool name reinforces that. However, it does not explicitly state when to use it, when not to use it, or how it relates to the sibling disconnect tool. The "for this local MCP" phrasing provides context, but no explicit exclusions or alternatives are given.

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

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

The annotations already declare destructiveHint=true, and the description reinforces this with 'Replace.' It adds useful context by specifying that only generated prep notes and verified attendee briefings are replaced, implying user-created content is not affected. No contradiction with annotations.

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

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

The description is two sentences, front-loads the core action, and adds a precise usage condition. Every sentence earns its place with no 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 destructive tool with clear annotations and a self-explanatory schema, the description is mostly complete: it states what is replaced and when to call it. The main gap is the lack of parameter-level guidance, though the schema covers structural details.

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 unclear parameters, but it does not explicitly explain meeting_id, result, or people. It only refers to 'prep notes' and 'attendee briefings' in domain terms, leaving the agent to infer how these map to the structured parameters.

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

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

The description clearly identifies the action ('replace'), the object ('generated prep notes and verified attendee briefings'), and the scope ('for a user-accessible meeting'). This differentiates it from sibling tools like insert_prep_notes_for_meeting or add_meeting_prep_note, which add rather than replace.

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 an explicit trigger condition: 'Call only when the user explicitly asks the agent to generate or replace meeting prep.' This is strong when-to-use guidance, though it does not name alternatives or explicitly say when not to use it beyond the stated condition.

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

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

Annotations indicate this is a mutating, non-idempotent operation, so the description does not need to restate that. However, it adds little about real-world effects: whether it creates a calendar event, sends invitations, starts the bot, or otherwise affects external systems. The 'signed-in user's' scoping is helpful, but the behavioral surface remains largely undisclosed.

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

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

Two concise sentences with no filler. The action comes first, and the critical usage precondition is second. 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?

With five optional parameters, no output schema, no parameter-level documentation, and an operation that mutates state, the description is not sufficient for an agent to confidently construct a correct call. It lacks details on which parameters are needed for which providers, how join_at and duration_minutes must be supplied, and what a successful result looks like.

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

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

Schema description coverage is 0%, so the description must compensate for the five undocumented parameters. It only hints at two of them ('link or provider' maps to meeting_url and provider), leaving title, join_at, and duration_minutes unexplained. There is no guidance on formats, defaults, or how the parameters relate to scheduling behavior.

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

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

The description names a specific verb and resource: 'Schedule the signed-in user's Zero meeting bot for a link or provider.' This clearly identifies the action and target, and the 'for a link or provider' clause hints at the meeting URL/provider parameters. It does not explicitly contrast with sibling tools, but no sibling directly overlaps with scheduling this bot.

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 precondition: 'Call only after the user explicitly asks to schedule the bot.' This tells the agent when the tool is appropriate. It does not name alternative tools or say when not to use it, but the explicit trigger condition is strong enough guidance for this context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond those annotations: results preserve the order of the input queries. It does not disclose return shape or match behavior, but the annotation coverage lowers the burden.

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

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

Two short sentences with no redundancy. The first sentence front-loads the primary purpose and scope; the second adds a valuable ordering guarantee. Every word earns its place.

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

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

For a simple read-only search tool with strong annotations, the description covers the essential details: scope, accepted query values, max input count, and result ordering. It omits output shape and pagination behavior, but the absence of an output schema makes that a modest gap rather than a critical one.

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 main 'queries' parameter by explaining that entries are names or email addresses and limited to 10. However, it does not explain 'page' or 'limit' semantics beyond what the schema already shows with defaults and bounds.

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 ('Search'), a precise resource ('the signed-in user's Zero contacts'), and the exact query format (up to 10 names or email addresses). It clearly distinguishes this from sibling tools like search_zero or add_contact by scoping to contacts and limiting input.

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

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

The description implies when to use the tool: whenever an agent needs to look up a signed-in user's contacts by names or emails. However, it does not explicitly mention alternatives or state when not to use it, such as when a broader Zero search or a different resource type is needed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral trait—it searches only titles and summaries and does not retrieve full transcript bodies—but it says nothing about result shape, ordering, pagination, or matching semantics. This is comparable to metadata-scoped read tools that add modest context beyond annotations.

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

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

A single, front-loaded sentence with zero filler. It communicates the core action, the resource scope, and an important behavioral constraint efficiently.

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

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

For a simple two-parameter search tool, the description covers the essential scope of the query but omits return-value expectations and search behavior details like substring/fuzzy matching or ordering. With no output schema present, the description could do more to tell the agent what it will receive.

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 for parameter meaning. It usefully explains that q applies to transcript titles and summaries, not full bodies. However, it says nothing about limit, result counts, or how the query string is matched, leaving part of the parameter surface undocumented.

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

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

The description states a specific verb and resource: 'Search transcript titles and summaries.' It also distinguishes from get_transcript and list_transcripts by noting it does so 'without loading full transcript bodies.' However, it does not explicitly differentiate from the sibling search_zero, leaving some ambiguity about when to pick one search tool over the other.

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

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

The phrase 'without loading full transcript bodies' implies this is the lightweight metadata search option rather than a full-content search, giving some contextual guidance. But it names no alternatives, gives no when-to-use versus search_zero or get_transcript guidance, and offers no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying the data domains searched and the 'stored'/'signed-in user' scoping, but it does not disclose return shape, result grouping, or how the multi-source results are presented.

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 tight sentence with a front-loaded verb and a compact enumeration of searchable content. Every word contributes to defining the tool's scope, with no filler or redundant restatement of the tool name.

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

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

Given the annotations cover safety and idempotency, the remaining gaps are when to choose this over the overlapping search_transcripts sibling and what the returned results actually look like. With no output schema and multiple searchable data types, the description is adequate for basic invocation but not fully complete for confident tool selection.

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

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

Schema description coverage is 50%; after and before are documented in the schema, but q and limit_per_source are not described there. The description clarifies that q searches across the enumerated Zero sources, adding some meaning for q, but it does not explain time-boundary semantics or per-source limiting behavior, so it only partially compensates for the coverage gap.

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

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

The description starts with a specific verb ('Search') and names a concrete resource scope: the signed-in user's stored Zero content across meetings, tasks, transcript speaker blocks, contacts, prep notes, and morning briefs. This makes the tool's broad search purpose clear, but it does not explicitly differentiate itself from the sibling 'search_transcripts' tool, which overlaps on transcript content.

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

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

The phrase 'the signed-in user's stored Zero...' implies this is for user-scoped cross-source search rather than general or list-based retrieval. However, there is no explicit guidance about when to prefer this over search_transcripts, list_meetings, list_tasks, or other sibling tools, leaving the selection mostly to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=true), and the description adds some context: only user-accessible tasks are targetable and only editable fields change. Yet it does not disclose important update semantics — whether omitted fields are preserved or reset, whether due_date can be cleared with null, or what happens on an invalid or inaccessible task_id. No contradiction with annotations, but behavior is only thinly described.

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

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

Two short sentences, both earning their place: the first delivers verb, resource, and scope; the second adds the user-consent precondition. The description is front-loaded, contains no filler, and does not restate the tool name or title.

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

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

For a destructive mutation tool with six parameters, zero schema descriptions, and no output schema, the description is too thin. It leaves failure behavior (missing or inaccessible task), partial-update semantics, and the meaning of optional/nullable fields unaddressed. An agent would need external knowledge or guesswork to invoke it fully correctly.

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

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

Schema description coverage is 0% for all six parameters, so the description carries the full burden of explaining parameter meaning — but it names none of them, referring only generically to 'editable fields.' The role of task_id as the sole required locator, the status enum, the priority const values, and the nullable due_date semantics must all be inferred from the raw JSON schema. This does not compensate for the coverage gap.

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

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

The description names a specific verb and resource ('Update editable fields on a user-accessible Zero task') and scopes the operation precisely: only existing user-accessible tasks, only their editable fields. This distinguishes it from sibling tools like create_task, get_task, and list_tasks without needing to open the schema. No tautology or ambiguity.

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 second sentence provides a clear when-to-call rule: 'Call only after the user explicitly requests the change,' which guards against autonomous agent-initiated mutations. However, it does not state when not to use the tool, what prerequisites must hold (beyond user-accessibility), or name alternatives. The when is explicit, but exclusions and alternatives are absent.

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