Server Quality Checklist

Tool Scores

• timetree_list_memosC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden. It only indicates the operation is a read, which is minimally reassuring, but it does not disclose pagination behavior, filtering semantics, calendar requirements, or return format.

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

  Conciseness3/5

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

  The description is a single clean sentence with no filler, but it is under-specified rather than appropriately sized. It is concise in form yet omits useful context an agent would need.

  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 3-parameter list operation with no annotations and no output schema, the description is incomplete. It provides only the basic purpose and lacks guidance on parameters, behavior, or distinguishing features such as 'category-2' memos.

  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%, so the description needs to compensate by explaining limit, calendar_id, and updated_after. It does not mention any parameter, leaving all semantic burden on the schema.

  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 action ('Read') and resource ('TimeTree memos from a calendar'), and is distinguishable from sibling create/update/delete memo tools. However, 'category-2' is unexplained and the description does not differentiate memos from events or calendars in the sibling list.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus timetree_list_events or other list-style tools. It implies 'use this for memos,' but provides no exclusions, prerequisites, or alternative tool mentions.

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

• timetree_update_eventC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. 'Requires confirm=true' is some useful safety signaling, but the description does not state side effects, authorization needs, partial-update behavior, error outcomes, or what happens when confirm is not passed. For a real write operation, this is a thin behavioral contract.

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

  Conciseness4/5

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

  The description is brief and front-loaded: it states the action first and the key gate 'Requires confirm=true' second. It contains no filler or redundant sentences. However, it is concise to the point of being thin for such a complex tool, so it loses a point.

  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?

  Given the tool's 20 parameters, 3 required parameters, no output schema, and no annotations, this description is not nearly complete enough. It provides no explanation of the three required identifiers, no expected return behavior, no permission or failure context, and no practical guidance. The single confirm requirement is helpful, but far from sufficient.

  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?

  With 20 parameters and only 5% schema description coverage, the description needed to compensate by explaining or grouping fields, but it does not. 'Selected fields' vaguely implies partial updates, and confirm=true is restated, yet calendar_id, event_uuid, and the many optional fields remain effectively unexplained.

  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 identifies the operation and target: 'Update selected fields of a TimeTree event.' This is specific enough to distinguish from create/delete operations at a glance. It does not explicitly contrast with sibling tools, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  No guidance is given on when this tool should be used instead of create_event, delete_event, or update_calendar_labels. There is no mention that the event must already exist, nor any scenario that should route an agent toward this tool. The only usage hint is confirm=true, which is a requirement, not an alternative-selection guide.

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

• timetree_update_event_commentC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It merely repeats the action ('Update') and the confirm=true constraint already documented in the schema, without stating that the previous comment content is overwritten, whether login authorization is needed, or any side effects or return behavior.

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

  Conciseness4/5

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

  The description is very short and the main action is front-loaded. The second sentence, however, largely repeats a specific constraint from the schema; it could instead provide parameter context while staying concise.

  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 five-parameter mutation with no annotations and no output schema, the description is insufficientn tells the agent the purpose but not how to populate the identifiers, what content represents, whether the update is a full replacement, or what a successful invocation returns.

  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 low (20%), and the description does not compensate. It does not explain the roles of calendar_id, event_uuid, comment_id, or content, or how they combine into the updated comment.

  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?

  States a clear verb and resource: 'Update a TimeTree event comment.' The 'TimeTree event comment' scope distinguishes this from event-level operations and from add/list/delete comment siblings.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance about when to use this versus add_event_comment or delete_event_comment. The verb 'Update' implies an existing comment, but the description does not clearly describe this. The only behavioral guidance is the confirm requirement already present in the schema.

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

• timetree_add_event_commentB
  3/5.0
  Behavior2/5

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

  With no annotations, the description must carry behavioral disclosure. It discloses that this is a real write by requiring confirm=true, which matches the schema const. However, it does not mention whether comments are visible to all calendar members, whether deletion by comment authors is supported, or what happens when the write succeeds or fails.

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

  Conciseness4/5

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

  One short sentence that front-loads the action and then stresses the confirm requirement. Efficient and easy to parse, though it could have included a tiny bit of parameter context without becoming bloated.

  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 5-parameter write action, the definition is nearly complete enough to invoke the tool, but an agent might not know how to obtain a valid event_uuid or calendar_id, or what silent affects. The absence of an output schema means the description should hint at return values, but does not. Still, the essential safety-critical confirm parameter is explicit.

  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 20%, so the description must compensate for the mostly undocumented parameters. It names the action but does not explain the roles of content (does it support HTML?), event_uuid, calendar_id, or silent. The confirm parameter is described in the schema, so the description adds no extra meaning there.

  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 clear verb and resource: 'Add a comment to a TimeTree event.' This distinguishes it from the event-level create tool and the list/update/delete comment siblings, though it doesn't name those siblings explicitly.

  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 it (when a comment should be added to an event) and emphasizes the confirm=true authorization gate. However, it does not explain how this differs from creating a memo, when to set silent, or what prerequisites (e.g., must already have the event_uuid from a list_events call) are needed.

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

• timetree_delete_event_commentB
  3.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It does state that this is a destructive delete and requires confirm=true, which is useful safety context. It stops short of explaining side effects, permission needs, or irreversibility beyond the confirmation requirement.

  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 short sentences with no filler. The operation is stated first, and the critical confirmation requirement is presented prominently.

  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 straightforward delete operation, the description is near-adequate. The required identifiers are discoverable from the schema property names, and confirm's role is clear. It would be more complete if it noted how to obtain the event_uuid and comment_id via sibling tools, but that is not essential for basic usage.

  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 needed to compensate for calendar_id, event_uuid, and comment_id. It does not explain any of those identifiers. The confirm parameter is repeated in the schema already with the const:true, so the description adds no parameter semantics.

  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 resource ('a TimeTree event comment') and the action ('Delete'), so the agent knows what operation this tool performs. It does not explicitly differentiate from sibling tools like timetree_delete_event or timetree_update_event_comment, but the resource is specific enough to avoid obvious confusion.

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

  Usage Guidelines2/5

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

  The description gives no guidance about when this tool should be used versus alternatives, and it does not mention exclusions or preconditions. The only usage hint is 'Requires confirm=true,' which is more of a safety requirement than a usage rule.

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

• timetree_start_monitorB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of explaining behavioral side effects. It mentions 'background polling' and notification delivery, but does not disclose that this is a persistent, stateful operation, how to stop it, whether multiple monitors can overlap, or what cleanup is required. For a side-effect-producing tool, this is a significant gap.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no filler. Every word contributes to the core purpose and notification behavior, and it is easy to scan.

  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 stateful background-monitoring tool with zero annotation coverage and no output schema, the description is too sparse. It omits critical operational ctx such as the required lifecycle (stopping the monitor), login prerequisites, and parameter semantics, making it incomplete for reliable invocation.

  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 fails to mention either parameter. calendar_id and interval_seconds are not explained at all, so an agent cannot understand how to choose or interpret them. The description adds no value beyond the raw input schema, which itself provides no semantic explanation.

  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 the action ('Start') and the resource/scope ('background polling for calendar changes'), making its purpose immediately understandable. It also distinguishes itself from sibling tools like timetree_stop_monitor and timetree_monitor_status by focusing on the start action.

  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 clear context: use this tool to begin polling for calendar changes and receive them as MCP notifications. However, it does not explicitly state when not to use it, what prerequisites exist (e.g., being logged in), or how it relates to timetree_stop_monitor/timetree_monitor_status, leaving usage guidance mostly implied.

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

• timetree_create_eventB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description must carry the safety/behavioral burden. It does disclose that this writes to the real calendar and that confirm=true is mandatory, which is meaningful transparency about a mutating side effect. It does not, however, explain likely failures, returned data, or other behavioral consequences beyond the write itself.

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

  Conciseness4/5

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

  The description is short, front-loaded with the action, and every sentence earns its place; there is no filler. It is efficient for a summary, though it relies on the schema for parameter details.

  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 write tool with 19 parameters, no annotations, and no output schema, this description is too thin to be fully contextually complete. It gives the essential safety guard but does not explain how to use it alongside the calendar/memo/event tools or what the agent should expect after a successful call.

  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?

  There are 19 parameters with only 5% schema-description coverage, so the description needed to compensate. It only mentions confirm=true, which is essentially already declared by the schema’s const and confirm description, and it adds no guidance about calendar_id, title, start_at, end_at, timezone, recurrence, or the other fields.

  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 opening sentence 'Create a TimeTree event' names a specific verb and resource, and it is clearly distinct from the memo/update/delete siblings. The added 'writes to the real calendar' reinforces that this is the real mutation, not a preview or read-only operation.

  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 is the tool to use when actually creating and committing a TimeTree event, and it gives an important prerequisite: confirm=true. However, it does not explicitly mention alternatives such as timetree_update_event for existing events or timetree_list_events for reading, so the routing guidance is only implicit.

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

• timetree_get_calendar_virtual_membersB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly says 'Read', which indicates a non-mutating operation, and mentions the optional deactivated member inclusion, but it does not disclose the return format, authentication requirements, error cases, or any other behavioral characteristics that would help an agent predict the tool's effects.

  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, front-loaded sentence with no filler. It efficiently captures the core action, the object, and the key parameter behavior 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 simple read operation with two parameters, this is a minimal but adequate definition: an agent can infer the primary action and the optional flag. However, there is no output schema and no mention of what the tool returns, and with sparse annotations the description could be strengthened by stating the expected result or clarifying the difference from the non-virtual members tool.

  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 compensate. It does clarify semantically that 'include_deactivated' relates to optionally including deactivated members, but it does not explain the calendar_id parameter's meaning or format beyond the phrase 'a TimeTree calendar'. Given two parameters at zero schema coverage, this leaves one param entirely implicit.

  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 ('Read') and resource ('virtual members of a TimeTree calendar'), and the qualifier 'virtual' distinguishes this from sibling tool timetree_get_calendar_members. It also mentions the optional deactivated filter, making the tool's scope unmistakable.

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

  Usage Guidelines2/5

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

  While the description conveys what the tool does, it provides no explicit guidance about when to use this tool versus alternatives such as timetree_get_calendar_members or the broader calendar tools. The only implicit usage signal is the phrase 'Read,' but there is no stated condition or exclusion for when this tool should be selected.

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

• timetree_update_memoB
  3.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description alone must disclose behavioral traits. It does disclose an important safety gate: the update requires confirm=true before proceeding. However, it stops there and does not describe permissions, side effects, failure modes, or how the confirmation actually protects the user.

  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 sentence with no filler. It front-loads the operation and promptly cites the critical confirmation requirement. This is appropriately concise for what little it sets out to say.

  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 tool with 10 parameters, no annotations, no output schema, and only 10% schema-described params, the description is insufficient. An agent is left to infer the purpose of most parameters, how calendar_id and memo_uuid relate to the memo, and what the effect of an update without proper confirmation or with optional fields is.

  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 10%, yet the description adds no meaning for the remaining parameters. 'Update a TimeTree memo' vaguely relates to the fields, but calendar_id, memo_uuid, label_id, checklist, and other important inputs remain unexplained. The only parameter touched on, confirm, is already documented in 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 and resource: 'Update a TimeTree memo.' It clearly identifies the target operation and differentiates the tool from sibling tools like timetree_create_memo, timetree_list_memos, and timetree_delete_memo. The one-line scope is immediately actionable.

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

  Usage Guidelines2/5

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

  There is no guidance on when to prefer this tool over alternatives, no mention of prerequisites, and no exclusionary conditions. The only additional note, 'Requires confirm=true,' concerns confirmation behavior rather than usage context.

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

• timetree_get_calendar_labelsB
  3.4/5.0
  Behavior3/5

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

  There are no annotations, so the description itself is the only signal about behavior. 'Read' makes it clear the operation is non-mutating, but the description does not cover other behavioral aspects such as auth requirements, expected response shape, failure behavior, or rate limits.

  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, short sentence that is front-loaded and easy to parse. There is no wasted wording, and the core operation and resource are stated immediately.

  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?

  This is a simple tool with one required parameter and no output schema, so the description is minimally sufficient for an agent to understand the intended operation. However, it lacks guidance about when to use it, what the result will look like, and any caveats, leaving the context only partially 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?

  The input schema has 0% description coverage, and the description does not mention calendar_id, its formats, or how to obtain it. The single parameter's role is inferable from the phrase 'a TimeTree calendar,' but the description adds little beyond what the schema already provides.

  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 'Read' and a precise resource 'all labels for a TimeTree calendar.' This clearly identifies the operation and distinguishes it from sibling tools like timetree_update_calendar_labels or timetree_list_calendars.

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

  Usage Guidelines2/5

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

  The description states what the tool does but does not explain when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The reading intent is implied by 'Read,' but there is no explicit usage guidance for an agent deciding between this and related label/calendar tools.

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

• timetree_create_memoA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the important confirmation gate and clearly implies a write operation, but it does not comment on side effects, permissions, reversibility, or what the response might be. Some useful guardrail context is provided, but substantial behavioral detail remains uncovered.

  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 concise and front-loaded: the action first, the confirming guardrail immediately after. There is no waste or redundant detail.

  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?

  A 10-parameter write operation with no annotations and no output schema is under-equipped with a two-sentence description. The description does not clarify how to obtain calendar_id, how the checklist items are structured, or what the result will be, leaving too much unspecified.

  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 10%, so the description must compensate but only mentions 'confirm'. Other parameters like calendar_id, label_id, checklist, and virtual_user_attendees are neither explained in the description nor described in the schema beyond names and basic types. This leaves the agent to infer semantics for most of the 10 parameters.

  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 specific verb ('Create') and the resource ('a TimeTree memo'), clearly identifying the operation. This distinguishes it from sibling tools like timetree_update_memo, timetree_delete_memo, and timetree_create_event without ambiguity.

  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 makes the core use case clear—creating a memo—and adds a mandatory prerequisite ('Requires confirm=true'). However, it does not contrast with alternatives or mention when to use list_memos/update_memo instead, leaving the comparative guidance implied.

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

• timetree_list_eventsA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description itself states the important read-only trait and the overlapping-date-range behavior. It does not disclose return shape, pagination, or any other operational details, but for a read-only list tool the disclosed traits cover the main behavioral risk.

  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 brief sentences deliver the essential action, scope, and read-only trait with no filler. The core information is front-loaded.

  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?

  Given the five parameters, low schema coverage, and no output schema, the description is too sparse. It does not clarify what calendar_id does, how query filters work, what the response contains, or what happens when no parameters are supplied—information an agent would need to invoke this tool correctly.

  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 40%, and the description adds no parameter-specific meaning. Only start_date and end_date are described in the schema; query, limit, and calendar_id are left undocumented in both schema and description, so the description 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.

  Purpose5/5

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

  The description clearly states the action ('Read'), the resource ('TimeTree events'), and the core scope ('overlapping a date range'). It also says 'This tool is read-only', which separates it from event mutation tools like create/update/delete.

  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 the tool should be used when events need to be read within a date range, and 'read-only' hints it is not for writes. However, it gives no explicit guidance on when to choose this tool over other read-oriented siblings like list_event_comments or list_memos.

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

• timetree_monitor_statusA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. The word 'Read' indicates a non-mutating operation, which is useful, but the description does not disclose details like whether the monitor must already be running, whether it can affect state, or how errors 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, front-loaded sentence that states the action and the key information returned. Every word earns its place, with 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 zero-parameter read-only status tool without an output schema, the description adequately conveys what the tool does and what kind of information it returns. It could mention prerequisites or relationship to monitor start/stop tools, but the tool is simple enough that the current description is nearly complete.

  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 confirms all properties are empty, so no parameter documentation is needed. The description adds no parameter detail, but none is required.

  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 clear action and target: 'Read background monitor state' and specifies the fields included ('last error/change information'). It is distinct enough from siblings like start/stop monitor and timetree_status, though it does not explicitly call out those differences.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives like timetree_status, timetree_start_monitor, or timetree_stop_monitor. The description implies a read-only check but does not state conditions, preconditions, or explicit exclusions.

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

• timetree_list_event_commentsA
  3.7/5.0
  Behavior3/5

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

  There are no annotations, so the description must carry the behavioral burden. 'Read' implicitly indicates no side effects, which is useful. However, it does not disclose what is returned, whether all comments are listed, ordering, pagination, or authentication requirements, leaving some behavioral opacity.

  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, focused sentence with no filler. The purpose is front-loaded and every word contributes meaning.

  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 two-parameter, unannotated tool with no output schema, this description is minimal but not fully sufficient. It leaves calendar_id's purpose unexplained and provides no context about the response shape or any operational requirements. An agent could guess the call shape from the schema, but the description adds little beyond the tool name.

  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 should compensate by explaining the parameters. It only alludes to an event, which maps to event_uuid, but gives no semantic explanation of calendar_id or the relationship between the two required fields. This is a meaningful gap.

  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 ('Read') and identifies a clear resource ('comments attached to a TimeTree event'). It immediately differentiates this from sibling mutations like timetree_add_event_comment and from other resources such as events or memos.

  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: use this tool when you want to read comments on a specific TimeTree event. It does not explicitly state exclusions or call out alternatives, but the read vs. add/update/delete split across sibling tools makes the intended usage reasonably obvious.

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

• timetree_delete_eventA
  3.8/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the behavioral disclosure burden. It explicitly warns that the operation cannot be undone and requires confirm=true, which is essential for a destructive write operation and goes beyond the schema's parameter-level requirements.

  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 short, direct sentences with no filler. It front-loads the core action and then adds the two critical warnings: irreversibility and confirmation.

  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?

  The description covers the main destructive behavior and confirm flag, but without annotations or an output schema it leaves some ambiguity about the expected response and what happens if the event or calendar is invalid. Still, the core invocation surface is reasonably understandable.

  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 33%, and the description does not compensate for the underdocumented event_uuid and calendar_id parameters. It only restates the confirm requirement already present in the schema, so it adds no real guidance for constructing the other parameters.

  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 the specific action ('Delete') and the resource ('TimeTree event'), making it immediately distinguishable from related tools like timetree_update_event or timetree_delete_memo. It is not tautological and names exactly what the tool does.

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

  Usage Guidelines3/5

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

  The description makes clear this is the deletion path and explicitly calls out the confirm=true prerequisite. However, it does not state when to prefer this over alternatives or mention any conditions that would make deletion inappropriate.

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

• timetree_stop_monitorA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It does state the core side effect: it stops the background monitor. However, it does not explain idempotency, behavior when no monitor is running, whether state is preserved, or any login prerequisites.

  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, direct, active sentence with no filler. Every word contributes meaning, and the core action is placed at the beginning.

  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 operation, the description is nearly sufficient: it states exactly what will happen. It could be slightly more complete by mentioning that it refers to a monitor started by `timetree_start_monitor` or how to confirm the monitor exists, but the overall operational context is clear.

  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, so the schema already fully describes the inputs. With no parameters, there is nothing more the description needs to add, and this meets the baseline for a parameterless tool.

  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 an explicit verb-resource pair: 'Stop' + 'background TimeTree change monitor'. It clearly differentiates this from sibling tools like `timetree_start_monitor` and `timetree_monitor_status` by naming the exact action and what is being acted on.

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

  Usage Guidelines2/5

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

  No guidance is given about when this tool should be used, such as after `timetree_start_monitor` or only while a monitor is active. The correct usage is implied by the tool name and sibling context, but the description itself does not state it.

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

• timetree_get_calendar_membersA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full behavioral burden. It clearly indicates a read operation and discloses the deactivated-member filtering option, which is useful. However, it does not mention auth requirements, default exclusion behavior, or response contents, leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is a single, concise sentence that front-loads the key action and resource, then adds the optional behavior. No wasted words or redundant details.

  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 tool with 2 parameters, no annotations, and no output schema, the description gives minimal but sufficient context for the primary action. It lacks details about required authentication, what fields each member includes (e.g., name, email, role), and error behavior, but the core call is understandable. It is adequate but not complete for a production agent.

  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 0%, so the description must compensate. It adds meaning for include_deactivated ('optionally including deactivated members') and implies the core resource for calendar_id, but it does not explain the calendar_id format (string vs integer). It still adds meaningful semantic value 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 states a specific verb ('Read'), a clear resource ('active members of a TimeTree calendar'), and a distinguishing optional behavior ('including deactivated members'). It clearly separates this tool from siblings like timetree_get_calendar_virtual_members and timetree_list_calendars.

  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 (reading calendar members) but does not explicitly contrast it with alternatives such as timetree_get_calendar_virtual_members or provide exclusions. The optional 'including deactivated members' hints at a usage toggle, but no explicit when-to-use guidance is given.

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

• timetree_statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden. 'Read' indicates a non-destructive, non-mutating operation, and 'direct HTTPS' suggests a network call to TimeTree. It does not disclose potential failure modes, rate limits, or whether any implicit state is changed, but for a zero-parameter status check this is acceptable.

  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 worded sentence with no filler, no redundancy, and no irrelevant details. The subject and qualifier are front-loaded, making the entire purpose clear at a glance.

  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?

  The tool is simple and has no inputs, but there is no output schema and no mention of what the returned status looks like (e.g., boolean, string, or object). An agent can decide to call it, but may need to inspect the actual result to determine its exact meaning.

  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 accepts no parameters, so parameter documentation is moot. The description correctly avoids claims about inputs and the schema confirms no parameters exist. This is a strong baseline for zero-parameter tools.

  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 names a specific verb ('Read') and resource ('current direct HTTPS TimeTree authentication status'). The qualifier 'direct HTTPS' helps distinguish this from closely named status tools like timetree_keychain_status, since it focuses on the live HTTPS connection rather than stored credentials.

  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 'current direct HTTPS' implies this is a live network connectivity/authentication check, which makes intended usage inferable. However, it provides no explicit guidance about when to choose this over timetree_keychain_status or timetree_login, and no exclusionary conditions.

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

• timetree_list_calendarsA
  4/5.0
  Behavior3/5

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

  The description uses 'Read', which clearly signals a non-mutating operation, and 'authenticated' indicates that a valid session is required. It does not explicitly state effects like needing an existing login, whether a failed authentication returns an error, or that no data will be changed, so the behavioral disclosure is adequate but minimal.

  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 sentence that clearly states the action, scope, and resource with no wasted words. It is front-loaded and immediately parseable by an agent.

  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?

  This is a simple zero-parameter, no-output-schema tool, so a much longer description is not necessary. The text sufficiently conveys read-only access to the authenticated account's calendars, though it does not specify the exact shape of returned calendar objects. For the tool's low complexity, this is adequate.

  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 input schema has zero properties and schema description coverage is 100%, so there are no parameters needing documentation. The description adds no parameter details, but none are needed; the baseline for zero parameters is appropriately high.

  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 'Read the calendars available in the authenticated TimeTree account' clearly identifies a specific verb (Read), resource (calendars), and context (authenticated TimeTree account). It is unambiguous and easily distinguished from sibling tools like timetree_list_events and timetree_create_event.

  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 'available in the authenticated TimeTree account' implies this is the read-only enumeration tool for the current account, but the description does not explicitly state when to prefer this tool over alternatives or when not to use it. Usage guidance is present only by implication.

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

• timetree_delete_memoA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden, and it handles the key risk well by stating the action cannot be undone and requires an explicit confirmation flag. It does not deep-dive into permissions or downstream effects, but for a memo delete it covers the most important destructive characteristics accurately.

  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 short, purposeful sentences: the first states the action, the second delivers the critical safety warning. Every word earns its place; there is no filler or redundant elaboration.

  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 tool with three flat required parameters, no nested objects, and no output schema, the description plus schema provide a workable call contract. It does not explain how to source memo_uuid or calendar_id, but sibling tools and the schema cover the remaining context reasonably well.

  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 33%, covering only the confirm parameter. The description adds no meaningful context about memo_uuid or calendar_id, and merely repeats the confirm=true requirement already present in the schema. Since the description must compensate for the low coverage but does not, this is inadequate.

  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 specific verb ('Delete') and resource ('TimeTree memo'), making the tool's purpose immediately clear. It is easily distinguished from sibling tools like timetree_update_memo and timetree_delete_event without needing to inspect schemas.

  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 usage context and a hard precondition: deletion is irreversible and requires confirm=true. It does not explicitly discuss alternatives or when not to use it, but the tool name and purpose are unambiguous enough that this is a strong guidance gap rather than a critical omission.

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

• timetree_update_calendar_labelsA
  4.2/5.0
  Behavior4/5

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

  With annotations present, the description would need to carry full behavioral burden; it does so in a useful way by disclosing a required confirmation guard and the non-destructive partial behavior for labels not included. It does not detail error responses or reversibility, but it goes beyond tautological 'update' phrasing and prevents an agent from assuming a full overwrite.

  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 concise sentence with the main verb first, the confirmation requirement second, and the key preservation behavior last. Every clause adds decision-relevant information and there is 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?

  Given the small three-parameter surface, the description plus input schema covers calendar identification, the labels payload, and the mandatory confirm flag. The lack of an output schema or return-value explanation is notable, but for a guarded write tool the agent likely needs the key, unless the calibration is calibrated by whether it can invoke correctly and understand side effects; it can.

  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 only 33%, but the description adds meaning to the labels parameter by clarifying that name/color and omitted labels are preserved. However, calendar_id is left entirely to the schema’s simple name/type representation, and the confirm parameter is largely defined by the schema's const and description rather than enriched in the tool description.

  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 opens with a specific verb-resource pair, 'Merge-update TimeTree label names/colors', which identifies exactly what the tool does and narrows the scope to label names and colors. This also separates it from read-oriented siblings like timetree_get_calendar_labels without needing to inspect schemas.

  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 usage context by explaining that confirm=true is required and that omitted labels are preserved, which tells the agent this is a partial merge update rather than a full replacement. It does not explicitly list sibling alternatives or exclusions, but the usage pattern is concrete enough for a long-tail update tool.

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

• timetree_logoutA
  4.3/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the full transparency burden. It discloses a meaningful side effect: clearing the session cookie and CSRF token. The 'in-memory' qualifier also usefully scopes the effect to client-side runtime state, which goes beyond what the schema conveys.

  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 front-loaded sentence with no filler. Every part of it contributes meaning: what is cleared, the scope ('in-memory'), and the exact artifacts affected.

  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 no-input, no-output-schema destructive action, the description is complete enough for invocation. It identifies the target state change and the scope, and nothing meaningful is missing for an agent deciding whether to call this tool.

  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 is an empty object with 100% coverage, so the baseline for parameter semantics is 4. The description does not need to add parameter-level meaning because there are no parameters to document.

  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 ('Clear') and a precise resource ('in-memory TimeTree session cookie and CSRF token'), so it is not a tautology of the tool name. It is easy to distinguish from related auth tools like timetree_login and timetree_status.

  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 does not explicitly state when to use this tool instead of alternatives, nor does it mention conditions or exclusions. However, the logout semantics are implied by the tool name and by the existence of timetree_login, so the use case is inferable rather than fully absent.

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

• timetree_keychain_statusA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of behavioral disclosure. It clearly discloses a key behavioral trait: it reports presence/absence only and never returns stored values. This is meaningful transparency, though it does not mention other behaviors such as error cases or whether Keychain access may trigger prompts.

  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 sentence with no filler. It front-loads the primary behavior and adds a critical security-relevant note compactly after a semicolon. Every word contributes value.

  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, read-only status tool, this description is adequately complete. It explains what the tool reports and what it never returns, which covers the main operational need. It does not specify the exact return shape, but the return semantics are reasonably inferable and tool complexity is very low.

  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, so parameter semantics are essentially moot. The description correctly focuses on output behavior rather than input, which fully satisfies the context despite the unusually sparse 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 clearly identifies the exact action: report whether the macOS Keychain contains TimeTree email/password items. It also disambiguates the operation by explicitly stating that credential values are never returned, which distinguishes this from any credential-fetching or login tool.

  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 purpose implies a clear use case: check whether stored TimeTree credentials exist without exposing them. It does not explicitly mention alternatives or exclusions, but the condition is self-contained and unambiguous enough for an agent to know when to call it.

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

• timetree_loginA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden, and it adds useful behavioral detail beyond the name: it authenticates over direct HTTPS, consumes environment variables, and avoids browser-based flows. It does not mention side effects like session persistence or idempotency, but the core login behavior is clearly disclosed.

  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 22-word sentence with no waste. It front-loads the action and target, then states mechanism and credential source. Every part of the sentence contributes useful information.

  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 with no output schema, the description is reasonably complete: it names the resource, the action, the transport, and the credential source. It intentionally does not mention return values or session side effects, which are not strictly necessary for invoking this simple login tool correctly.

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

  Parameters5/5

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

  The input schema has zero parameters, which usually means the baseline is 4, but the description adds further value by naming the exact environment variables used, TIMETREE_EMAIL and TIMETREE_PASSWORD. This tells an agent exactly where credentials are sourced even though no schema parameters 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 clearly names the action ('Login'), the resource ('TimeTree'), and the mechanism ('direct HTTPS' with environment credentials). It also differentiates itself from sibling tools like timetree_status, timetree_keychain_status, and timetree_logout by describing an actual authentication action.

  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 states clear context: login is done without a browser using TIMETREE_EMAIL and TIMETREE_PASSWORD from the MCP environment. It does note a key implementation detail, but does not explicitly say when to check status or when to avoid calling this tool, such as 'use only if not already logged in.'

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