Server Quality Checklist

Tool Scores

• update_taskB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating, non-idempotent operation, and the description aligns with that. It adds context that only user-accessible tasks can be updated and only editable fields should be changed. It does not detail side effects, validation behavior, or response characteristics, but the annotations cover the basic safety posture adequately.

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

  Conciseness5/5

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

  The description is only two sentences and every part is useful. The main action is stated first, and the crucial user-consent condition is appended without redundancy.

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

  Completeness2/5

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

  For a mutation tool with six parameters and no output schema, the description is too thin. It tells the agent when to call it but not what fields can be updated, how to clear optional values, what the result will be, or any constraints on the update. The schema supplies some structure, but the description leaves important operational context missing.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description adds no parameter-level meaning. It does not explain task_id, title, status, due_date, priority, or description semantics beyond what the raw schema names and types convey. Since coverage is low, the description should compensate but does not.

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

  Purpose4/5

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

  The description clearly states the action ('Update editable fields on a user-accessible Zero task') and identifies the resource as an existing task. It does not explicitly distinguish this from sibling tools like create_task or get_task, but the verb and target make the core purpose clear.

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

  Usage Guidelines4/5

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

  The description gives explicit guidance: call only after the user explicitly requests the change. This prevents proactive or unsolicited updates. It does not mention alternatives or situations where another tool should be used instead, but it provides a clear and relevant usage condition.

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

• get_transcriptA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters2/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• search_transcriptsA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• search_zeroA
  3.5/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• add_meeting_prep_noteA
  3.8/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness3/5

  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.

  Parameters2/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• list_tasksA
  3.8/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose4/5

  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.

  Usage Guidelines3/5

  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.

• create_taskA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate a non-read-only, non-idempotent mutation; the description adds that the operation persists a task for the signed-in user and frames it as saving. No hidden behavior or contradiction is present.

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

  Conciseness5/5

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

  Two compact sentences, with the action and scope first and the essential call trigger second. There is no filler or repetition of schema details.

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

  Completeness4/5

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

  The schema provides types, constraints, enums, defaults, and required fields, so the parameter list is structurally usable. The description supplies the key missing context: whose task is created and when the tool may be called. It falls short of 5 because it does not mention using update_task for existing tasks or what a successful save returns.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description mentions none of the five parameters or their roles. The agent is left to infer semantics from bare property names like title, description, status, due_date, and priority, with no explanation of required inputs or the priority default.

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

  Purpose5/5

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

  The description uses the specific verb 'Create' with the resource 'Zero task' and scopes it to the signed-in user, making it clearly distinct from sibling update_task. It states exactly what the tool does without merely restating the name.

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

  Usage Guidelines4/5

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

  The instruction 'Call only after the user explicitly asks to save the task' gives a concrete, enforceable trigger and prevents proactive creation. It does not explicitly name the alternative for editing existing tasks, so it is not a full routing guide.

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

• get_taskA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• list_transcriptsA
  4/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• list_meetingsA
  4.2/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• loginA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• get_meeting_prepA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• disconnectA
  4.5/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations by clarifying that it only removes the local MCP session and does not revoke or sign out other ZeroHrs sessions. This helps an agent understand the limited scope of the action, complementing the idempotentHint and destructiveHint annotations.

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

  Conciseness5/5

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

  The description is two concise sentences with no wasted words. The primary action is front-loaded and the clarifying exclusion is delivered efficiently.

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

  Completeness5/5

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

  For a zero-parameter, simple action tool, the description is fully complete: it states what the tool does, its scope, and its limitations. No output schema exists, but a return value explanation is not essential for a disconnect action.

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

  Parameters4/5

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

  The tool has zero parameters and the schema has 100% coverage, so the baseline of 4 applies. The description correctly does not attempt to document parameters that do not exist.

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

  Purpose5/5

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

  The description uses a specific verb ('Remove') and a precise resource ('the session saved by this local MCP'), immediately clarifying the tool's action. It also distinguishes the tool from other ZeroHrs session management by stating it does not affect other sessions.

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

  Usage Guidelines4/5

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

  The description clearly communicates what the tool does and explicitly states what it does not do, providing good context for when to use it. However, it does not name alternative tools like 'login' or explicitly state when not to use it, leaving some inference to the agent.

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