Deferno MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Several tools have overlapping purposes, such as 'add_to_plan' vs 'add_to_items_plan' and 'get_calendar_events' vs 'get_items_calendar'. While descriptions clarify differences, the large number of tools increases selection difficulty.
Naming Consistency3/5
Naming is mostly verb_noun snake_case, but there are inconsistencies like 'mark_habit_occurrence' vs 'set_chore_occurrence_status', and 'remove_from_items_plan' vs 'remove_from_plan'. Some patterns are not uniformly applied.
Tool Count2/5
With 81 tools, the server is over-scoped for typical MCP usage. Many specialized operations (e.g., separate occurrence tools for each item type) could be consolidated into fewer, more general tools.
Completeness4/5
The tool set covers CRUD for tasks, chores, habits, events, daily plans, attachments, comments, and settings. A notable gap is that search only covers tasks, not other item types, but overall coverage is robust.
Average 4/5 across 81 of 81 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description must disclose behavioral traits. It only states the action without mentioning effects like duplicate handling, return values, or potential side effects. The existence of an output schema is not mentioned.
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 concise sentence, but it omits essential details. While brevity is valued, the lack of parameter or usage information makes it borderline under-specified for an agent to use correctly.
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 has 2 parameters, an output schema, and no annotations, the description is incomplete. It fails to explain return values (despite an output schema existing) or provide any context for safe and effective use.
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 information about the two parameters: 'task_id' (required) and 'date' (optional). It does not explain what 'task_id' refers to or how 'date' should be formatted, leaving the agent uninformed.
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 ('Add') and the target ('an item to the daily plan'). It is specific enough to convey the core purpose, but it does not differentiate from the sibling tool 'add_to_plan', which may have overlapping functionality.
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 provided on when to use this tool versus alternatives like 'add_to_plan' or 'remove_from_items_plan'. There is no mention of prerequisites, constraints, or contexts where the tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as what happens if the item is not in the plan, whether it is destructive, or any side effects.
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 sentence, which is concise, but it sacrifices essential information that would make it useful.
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 that the tool has an output schema and two parameters, the description is too sparse. It does not address return values, edge cases, or relationships to other tools.
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 explain the meaning of 'task_id' or 'date'. An agent cannot infer how to correctly set these parameters.
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 uses a verb ('Remove') and resource ('an item from the daily plan'), making the core action clear. However, it does not differentiate from sibling 'remove_from_plan', which may cause 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?
No guidance on when to use this tool versus alternatives like 'remove_from_plan' or when not to use it. Lacks prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full burden. It mentions a write operation ('Save') but lacks detail on side effects, authentication needs, or whether duplicates are handled. This is insufficient for safe agent invocation.
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 with two sentences, no wasted words. However, it could have included more detail without becoming verbose. Still, it is appropriately sized for a simple tool.
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 has 2 required params with no descriptions, no annotations, and relies on an output schema (not shown), the description is incomplete. It lacks constraints, error handling, and behavior specifics that an agent needs for correct invocation.
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 coverage is 0% (no param descriptions). The description adds meaning only to 'query_string' by referencing search_items, while 'name' is completely unexplained. For two required params, this is inadequate.
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 'Save a search,' which is a specific verb+resource indicating creation of a saved search. It differentiates from sibling tools like list/delete/update by the action verb, though it doesn't explicitly contrast them.
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 only guidance is that query_string uses the same syntax as search_items, which is a reference but not a clear when-to-use or when-not-to-use statement. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It discloses that complete_by is the start time and end_time must be at or after, but it does not describe return value, side effects, permission requirements, or other behavioral traits. The mention of 'subtask_template' not in the schema may mislead.
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 relatively short and front-loaded with the main purpose. However, it includes version history ('v0.2 optional fields') and a reference to a field not in the schema, which adds unnecessary noise. It could be more succinct.
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 has 7 parameters, no annotations, and an output schema (unseen), the description is incomplete. It does not explain what the event creation entails, what the return value is, or how events differ from tasks. Key context like prerequisites or typical usage scenarios is missing.
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 explains semantics for 'complete_by' and 'end_time' but provides no information for other five parameters (title, description, labels, parent_id, recurrence). Additionally, it mentions a 'subtask_template' field that does not appear in the schema, which could cause confusion.
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 tool creates a time-bound event, using a specific verb and resource. It clarifies that 'complete_by' is the start time. However, it does not explicitly differentiate from sibling tools like create_task or create_habit, though the term 'event' provides some distinction.
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 provides a validation rule (end_time must be after complete_by) and mentions version-specific optional fields, but it does not give explicit guidance on when to use this tool over alternatives. The context of creating an event vs. a task or habit is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it replaces order, but does not disclose destructive behavior, required permissions, or side effects. Missing key behavioral context.
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?
Single sentence with no wasted words, but structure is minimal and could benefit from parameter clarifications or usage hints.
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?
Despite output schema existing, the description does not explain return values or the requirement that task_ids must include all items. Incomplete for a mutation tool with siblings.
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 does not explain the meaning or constraints of 'task_ids' or 'date'. No additional 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 uses a specific verb ('Replace') and resource ('daily plan ordering') and differentiates from siblings like reorder_plan and reorder_pinned_tasks.
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 on when to use this tool versus alternatives like reorder_plan, add_to_items_plan, or remove_from_items_plan. No when-not or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'replace' implying destructive behavior, but does not disclose side effects, safety, idempotency, or return value. Minimal behavioral info.
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 concise, with two sentences and a bullet-like line for parameters. No wasted words, and key information is front-loaded. Appropriate for a simple operation.
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 is a mutation (replaces ordering), the description lacks behavioral details like return value, side effects, or required permissions. With an output schema present, the description could be more complete by explaining what the response contains.
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 description adds meaning beyond the schema by specifying 'task_ids' is a 'full ordered list of task UUIDs' and 'date' defaults to today. However, schema coverage is 0%, and the description could provide more detail on parameter constraints or format.
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 tool replaces the daily plan ordering with a given task ID list. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like reorder_items_plan.
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 provides no guidance on when to use this tool vs alternatives (e.g., reorder_items_plan, reorder_pinned_tasks) or any prerequisites. It only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the important behavior of event_id resolution (accepts various reference forms, resolves to UUID). However, with no annotations, other behaviors (e.g., what happens if no comment exists, idempotency, permissions) are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose and providing key parameter detail without fluff.
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?
An output schema exists, which may cover return values, but the description omits details on parameter behaviors, effect of optional fields, and any prerequisites. Given the tool's complexity (4 params, no annotations), the description is moderately incomplete.
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?
Only the event_id parameter is explained in detail. The other three parameters (date, body, is_private) are not described beyond their schema types, and schema description coverage is 0%. The description does not compensate for the lack of schema documentation.
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 'Edit the latest comment on an event occurrence (date)', specifying the verb and resource. However, it does not explicitly distinguish this tool from siblings like 'post_event_occurrence_comment' or 'update_comment'.
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 provided on when to use this tool versus alternatives such as 'post_event_occurrence_comment' or 'delete_event_occurrence_comment'. The description lacks any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description does not disclose any behavioral traits beyond the implied action of deletion, such as irreversibility or side effects.
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 a single sentence that is front-loaded and concise, but it omits important details that would make it more effective.
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 delete tool with an output schema, the description is adequate but lacks behavioral context (e.g., irreversibility) that helps the agent understand the full impact.
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 tool description does not add any meaning to the 'saved_search_id' parameter beyond its name.
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 (delete) and the resource (saved search), distinguishing it from sibling tools like 'list_saved_searches' and 'update_saved_search'.
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 provides no guidance on when to use this tool versus alternatives, such as prerequisites or conditions for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains ID resolution but fails to specify the effect of 'clear' (e.g., unmark vs delete), side effects, or safety (destructive?). Leaves ambiguity about the tool's actual operation.
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 concise sentences: first clearly states action and date format, second details ID flexibility. No fluff, front-loaded, every word earns its place.
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?
While output schema exists (unmentioned), the description misses what the tool returns and any side effects. For a simple mutation tool, the behavioral gap (effect of clear) reduces completeness.
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 coverage is 0%, but the description richly explains 'habit_id' acceptance of multiple reference forms and resolution process, and gives date format. This adds significant value beyond 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 clearly states the verb 'Clear' and the resource 'habit occurrence' with a specific date format. However, it does not differentiate from sibling tools like 'mark_habit_occurrence' or 'reschedule_habit_occurrence', missing explicit scope boundaries.
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 on when to use this tool vs alternatives. Context like prerequisites (occurrence must be marked) or when-not-to-use is absent, leaving the agent to infer from tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must compensate. It mentions that task_id accepts multiple reference forms and that the return includes the updated parent and both new children. However, it does not specify whether the operation is destructive, what permissions are needed, or any side effects beyond preserving the parent.
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 concise with two paragraphs. The first paragraph states the core functionality, and the second adds useful parameter details. No extraneous information is present, though structure could be improved with bullet points.
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 has 5 required parameters, no parameter descriptions, and no annotations, the description is incomplete. While the existence of an output schema is noted, the description fails to provide sufficient guidance for correct invocation, especially regarding the content of the two child tasks.
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 0% schema description coverage, the description should explain parameters, but it only addresses task_id (reference forms). The other four required parameters (first_title, first_description, second_title, second_description) are not described, leaving the agent without guidance on their format or purpose.
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: 'Decompose a task into two child tasks while preserving the parent.' This provides a specific verb and resource, and the outcome is well-defined, distinguishing it from siblings like merge_task or delete_task.
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 offers no guidance on when to use split_task versus alternatives such as fold_task, merge_task, or other task manipulation tools. No context is provided about prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'update' without disclosing side effects, idempotency, permission details beyond 'admin only', or return behavior. This is minimal for a mutation tool.
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 a single sentence that concisely conveys the core purpose. It is not overly brief but efficiently communicates the key information.
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 has three parameters and an output schema, the description omits details on return behavior, error conditions, and parameter constraints. Without annotations, more context is needed for adequate completeness.
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 mentions 'status' and 'admin notes', aligning with two parameters, but does not explain 'feedback_id' or provide constraints (e.g., valid status values). The added meaning is partial and insufficient.
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 verb 'Update', the resource 'feedback item', and the specific fields that can be updated ('status / admin notes'). It also notes admin-only access, distinguishing it from sibling tools like 'list_feedback' and 'feedback_stats'.
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 indicates admin-only usage, providing basic context. However, it does not specify when to use this tool versus alternatives (e.g., other update tools for different entities) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ownership constraint, which is important behavioral info beyond the verb 'delete'. With no annotations, this partially fulfills transparency, but lacks details like irreversibility or permissions.
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?
Efficient one-sentence description with clear main point, though could include a bit more context without harming conciseness.
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?
Covers action and key condition, but lacks details on error scenarios, prerequisites (e.g., comment must exist), or what happens after deletion, especially given the existence of an output schema.
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?
The description adds no meaning to the single parameter 'comment_id' beyond its name. With 0% schema coverage, it should describe how to obtain or format the ID.
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?
Clearly states the action (delete) and resource (comment) with a specific condition (owned by caller), distinguishing it from sibling tools like delete_event_occurrence_comment.
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?
Provides a usage condition (owned by caller) but no explicit guidance on when to use vs alternatives like delete_event_occurrence_comment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the polymorphic return type and parameter defaults, but does not disclose any side effects, read/write nature, rate limits, or pagination behavior. The behavioral disclosure is incomplete.
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 sentences front-load the purpose and then provide key details on return type and parameters. Every sentence is informative and there is no waste.
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 tool returns a daily plan across multiple item kinds with an output schema, the description covers the return structure (discriminator), parameter defaults, and timezone format. Minor gaps exist (e.g., no mention of ordering or plan scope), but it is largely 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 input schema has 0% description coverage, but the description compensates by explaining that 'date' defaults to today and 'tz' is an optional IANA timezone. This adds essential meaning beyond the bare 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?
Description clearly states it retrieves a daily plan covering Tasks, Habits, Chores, Events, and mentions the polymorphic array with kind discriminator. However, it does not explicitly differentiate from the sibling tool 'get_daily_plan', which may have overlapping functionality.
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 on when to use this tool versus alternatives like 'get_daily_plan', 'get_item', or 'search_items'. The description implies usage for daily planning but does not provide explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It implies mutation (patch) and notes one error case, but omits details on idempotency, permissions, return value, or error handling for missing comment_id.
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 long, puts the purpose first, and includes a critical constraint without unnecessary words. Extremely concise and front-loaded.
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 core action and a key error condition. However, it does not address preconditions (comment must exist), postconditions (return value when output schema exists), or permissions. Adequate but with clear gaps.
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?
With 0% schema coverage, the description explains two optional parameters (body, is_private) corresponding to "body or visibility". The required comment_id is implied but not explained. The empty payload warning adds context about parameter combinations.
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 verb "Patch" and the resource "comment", and specifies which aspects can be modified (body or visibility). It distinguishes from siblings like delete_comment. However, it could be more explicit about it being for existing comments.
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 provides context that the tool is for patching body or visibility, and warns against sending an empty payload (422 error). This gives some usage guidance but lacks explicit alternatives or when-not-to-use hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that omitted fields stay unchanged (partial update), but it does not mention authentication requirements, rate limits, whether the operation is destructive, or any side effects. The output schema exists but is not described here.
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 long with no unnecessary words. It is front-loaded with the main purpose and adds one vital behavioral detail. Every sentence earns its place.
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 simplicity (two optional parameters) and existence of an output schema, the description covers the core function and partial update behavior. However, it lacks any mention of authentication, side effects, or when to use it vs siblings, leaving some gaps for an agent.
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%, and the description does not elaborate on the parameters. It only states that omitted fields stay unchanged, which informs the agent about partial update semantics but does not explain the purpose or allowed values of 'done_visibility' and 'theme'. The agent must infer from parameter names.
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 tool patches user settings, with a specific verb 'patch' and resource 'user settings'. The name 'update_settings' directly corresponds, and it is distinct from siblings like 'get_settings' and other update tools for specific entities.
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 versus alternatives. However, it implies that this tool is for updating user-level settings, while siblings like update_chore are for specific items. No direct comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the action without disclosing side effects, permissions, or reversibility. For a mutation tool, this is insufficient.
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 concise sentences with front-loaded purpose. Every word adds value.
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?
Adequate for a simple removal tool, but lacks details on error handling or effect on plan ordering. Output schema exists, so return value explanation is not needed.
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?
Despite 0% schema description coverage, the description explains that task_id is a UUID and date defaults to today, adding meaning beyond the raw 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 states the action ('Remove') and the resource ('a task from the daily plan'), which distinguishes it from sibling tools like 'remove_from_items_plan'.
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 on when to use this tool versus alternatives (e.g., remove_from_items_plan). No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It explains habit_id resolution and that omitted fields are untouched, but does not mention error handling, permission requirements, or whether fields are truly mutable. The mention of v0.2 optional fields adds some context but leaves other behavioral aspects unclear.
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 with no extraneous text. The first sentence communicates the purpose, followed by focused details on habit_id and optional fields. Every line adds value, and the structure is front-loaded and 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?
Given 6 parameters, no annotations, and an output schema not shown, the description is incomplete. It omits explanations for key mutable fields like recurrence, labels, and null behavior. The mention of v0.2 fields not in schema creates confusion. Overall, it fails to fully equip an agent for correct invocation.
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 coverage is 0%, so the description must add meaning. It thoroughly details habit_id formats and two extra fields (deadline_time_of_day, subtask_template) not in schema, but the 5 other schema parameters (title, description, etc.) receive no description. This partial coverage leaves most parameters semantically opaque.
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 tool patches mutable fields on a habit, with the first sentence specifying the operation and resource. It distinguishes from siblings like create_habit and delete_habit by explicitly focusing on updating existing habits, leaving no 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 implies use for partial updates via 'Omitted fields stay untouched' but provides no explicit when-to-use or when-not-to-use guidance relative to alternatives like update_habit vs mark_habit_occurrence. Context of sibling tools suggests this is for field updates, but the description lacks direct contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that task_id accepts multiple reference formats, preserves existing chain, and returns both tasks. But it lacks details on permissions, error handling, or side effects, which is a gap.
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 relatively concise with four short sentences, front-loading the purpose. The explanation of task_id formats is useful but could be condensed without losing 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?
Given 7 parameters and no schema descriptions, the description is incomplete. It fails to document most parameters, lacks error conditions, and only briefly mentions return value. The presence of an output schema partially compensates for return format, but parameter documentation remains insufficient.
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 description must explain parameters. It only details task_id's reference formats, ignoring the other 6 parameters (title, description, labels, etc.), which are left without meaning beyond their names.
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 tool inserts a new task after a given task_id, using specific verbs and resource. It distinguishes from siblings like create_task (standalone creation) and move_task (reordering by explaining it inserts a next-step task).
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 implies usage for inserting a task after another in a sequence, and mentions it preserves downstream chain, which differentiates it from other tools. However, it does not explicitly state when not to use or name alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions that habit_id is resolved to UUID and date defaults to today, but does not reveal idempotency, error handling, or whether it overwrites existing occurrences. Key behavioral traits are missing.
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 concise, with a clear purpose in the first sentence and parameter details in a structured second paragraph. No superfluous text, though could be slightly more compact without losing meaning.
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 habit_id and date well, but lacks information on error conditions, idempotency, or the relationship to clear_habit_occurrence. With an output schema present, return values are not required, but overall context for a complete agent decision is moderately 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 description adds significant meaning beyond the schema for habit_id (accepts various reference forms and resolves to UUID) and date (YYYY-MM-DD format, defaults to today). However, the 'done' parameter (boolean) is not explained, leaving a gap despite low schema coverage (0%).
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 'Mark a habit occurrence as done or not-done,' specifying the verb (mark), resource (habit occurrence), and the binary outcome. Among sibling tools like clear_habit_occurrence and reschedule_habit_occurrence, this tool is unambiguously distinct.
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 usage for marking a habit occurrence, but does not explicitly state when to use this tool versus alternatives like clear_habit_occurrence or other habit-related tools. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The term 'Patch' suggests a non-destructive partial update, but the description does not disclose idempotency, what happens to unspecified fields, or whether the tool returns the updated object. It adds some value by naming the updatable fields but lacks deeper behavioral context.
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 of eight words, highly concise, and front-loaded with the verb 'Patch'. Every word is purposeful and earns its place.
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?
With 3 parameters, no annotations, and an output schema, the description is too minimal. It does not clarify that 'saved_search_id' is required, what happens if neither optional field is provided, or what the response contains (even though an output schema exists). For a mutation tool, more context is needed for completeness.
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 must compensate. It lists the two mutable parameters ('name' and 'query string'), adding meaning beyond the schema property names. However, it does not explain the 'saved_search_id' parameter or the format of 'query_string', leaving gaps. The description provides moderate added value.
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 ('Patch') and resource ('saved search') and identifies the exact fields that can be updated ('name or query string'). This clearly distinguishes it from sibling tools like create_saved_search, delete_saved_search, list_saved_searches, and reorder_saved_searches.
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 usage via the action 'Patch a saved search's name or query string' but provides no explicit guidance on when to use this tool versus alternatives (e.g., creating a new saved search) or conditions like required existence of the search. The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'soft-delete', indicating non-destructive behavior, and explains the flexible input format for event_id. However, it does not disclose what happens if no comment exists, error handling, or permission requirements. With no annotations, more detail would be helpful.
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 long, front-loading the core action and then adding detail on event_id. No extraneous information; every sentence contributes value.
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 two required parameters and an output schema, the description covers the basic action and event_id flexibility but omits the return value, missing parameter format for date, and edge cases. It is adequate but not comprehensive.
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 0%, so the description must compensate. It thoroughly explains event_id (accepts various reference forms and resolves to UUID), but only vaguely mentions date as part of the occurrence. The date parameter lacks format or constraints, leaving it partially ambiguous.
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: 'Soft-delete the latest comment on an event occurrence (date).' It specifies the verb (soft-delete), resource (latest comment on an event occurrence), and context (occurrence date), distinguishing it from siblings like delete_comment (general) and delete_event_occurrence (deletes occurrence itself).
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 usage for deleting the latest comment on an event occurrence, but does not explicitly compare to alternatives like patch_event_occurrence_comment or delete_comment. No 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an administrative access requirement, which is a behavioral trait. However, it does not explicitly state whether the operation is read-only or if it has any side effects. With no annotations provided, the description carries the full burden, and it only partially fulfills it.
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, clear sentence with no wasted words. It efficiently conveys the tool's purpose and access restriction.
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 tool has no parameters and an output schema (which describes return values), the description is fairly complete. However, it could elaborate on what 'aggregate feedback statistics' entails, but that is partially covered by the output schema.
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?
There are no parameters in the input schema, so the description does not need to add parameter semantics. According to the rubric, 0 parameters warrant a baseline of 4, which is appropriate here.
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 tool returns aggregate feedback statistics, with an access restriction (admin only). It distinguishes from sibling tools like list_feedback by implying it provides summary data rather than individual items. However, it could be more specific about what statistics are included.
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 mentions 'admin only', which implies usage context, but it does not explicitly state when to use this tool versus alternatives like list_feedback. No exclusion criteria or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the burden. It discloses that the backend returns 501 for habits (legacy storage) and that the tool is exposed for forward compatibility. However, it does not describe side effects (e.g., what happens if the target date already has an occurrence) or error states beyond the note.
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 concise with three clear sentences. The version note is relevant but adds a slight overhead. Information about resolution and date format is front-loaded after the main purpose.
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 3 required parameters, 0% schema coverage, and no annotations, the description covers the essential parameter formats and a critical behavioral caveat (501 error). An output schema exists but is not utilized; the description does not need to explain return values. It is complete enough for an agent to use correctly despite the limitation.
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?
With 0% schema coverage, the description adds valuable meaning: it explains that habit_id accepts multiple reference forms (UUID, sequence shorthand, canonical ref, app URL) and is resolved to UUID. It explicitly states that date and new_date are YYYY-MM-DD occurrence dates, not item references.
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 verb ('Move'), the resource ('a single habit occurrence'), and the constraint ('without touching the cadence'). It distinguishes from sibling tools like reschedule_chore_occurrence and reschedule_event_occurrence by specifying 'habit'.
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 explicit guidance on when to use this tool versus alternatives is provided. The description mentions a backend limitation (501 error for habits) but does not explain when rescheduling a habit is appropriate or when other actions (e.g., updating the habit) might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions adding a task but does not disclose any side effects, required permissions, or constraints (e.g., can the same task be added multiple times to the same day?). This is insufficient for full transparency.
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 extremely concise with two sentences, front-loaded with the primary action. No wasted words.
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 tool has an output schema (not shown), so return value details are not required. The description adequately covers the main behavior and parameter semantics. Minor gaps: no mention of whether the plan must exist or if the task can be added without a plan.
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 0% description coverage, so the description adds crucial meaning: it clarifies that task_id is a UUID of an existing task and that date defaults to today. This goes beyond the raw 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 states the action ('Add a task') and the target resource ('the daily plan'). It differentiates from siblings like 'add_to_items_plan' by specifying 'daily plan' and from 'remove_from_plan' by being an add 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 explains parameter semantics (task_id is UUID, date defaults to today) but does not provide explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives like 'add_to_items_plan' or 'batch_tasks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains acceptance of various reference forms and UUID resolution, but does not mention pagination, rate limits, error handling, or whether history is full or limited. No annotations to supplement.
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 sentences, front-loaded with purpose, no fluff. Parameter details are efficiently integrated.
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?
Output schema exists, so return format is covered. However, missing usage guidance and behavioral traits like scope of history limit completeness. Adequate but not thorough.
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?
Schema has 0% description coverage, but description provides rich details on accepted formats (UUID, sequence shorthand, canonical ref, app URL), adding significant meaning 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?
Description clearly states verb 'Return' and resource 'change-history list for any item kind', and distinguishes from siblings like 'get_item' by specifying history vs current state.
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 explicit guidance on when to use this tool vs alternatives like 'get_item' or 'search_items'. Sibling tools are listed but no comparison or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains date format and timezone, but does not mention that this is a read-only operation, nor any potential limits, pagination, or ordering. For a tool with no annotations, more detail is needed.
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 first sentence states the purpose, followed by two lines detailing parameter formats. Every sentence adds value with no repetition or filler.
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 tool's simplicity (3 params, output schema present) and the context of many siblings, the description covers the key aspects: purpose, parameter formats, and timezone handling. The presence of an output schema reduces the need to describe return values, making this fairly complete for an agent to use correctly.
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?
With 0% schema description coverage, the description effectively adds meaning: it specifies that 'start' and 'end' are 'YYYY-MM-DD' with 'end' exclusive, and 'tz' is an 'optional IANA timezone'. This clarifies usage beyond the raw schema types, though it could further explain defaults or behavior when tz is omitted.
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 it provides a 'Calendar view across all item kinds (Task, Habit, Chore, Event)'. This identifies the specific verb ('view') and resource ('all item kinds'), and distinguishes it from sibling tools like 'get_tasks_calendar' or 'get_calendar_events' that likely focus on subsets.
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 usage for a combined calendar view, but does not explicitly state when to prefer this over siblings like 'get_tasks_calendar' or 'get_calendar_events'. No exclusions or alternatives are mentioned, leaving the agent to infer based on tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden for behavioral disclosure. It only states the basic function (returning settings blob) without mentioning that it is read-only, requires authentication, or has no side 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, clear sentence that efficiently communicates the tool's purpose with relevant examples. No unnecessary words.
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 tool has no parameters and an output schema exists, the description is largely sufficient. It could optionally hint at the output structure, but the examples provide enough context.
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 schema coverage is 100%. The description adds value by giving examples of settings fields, which goes beyond the empty schema. Baseline for zero parameters is 4.
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 tool returns the user's settings blob and lists example fields (theme, done-visibility). This distinguishes it from siblings like update_settings, which is a write 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?
No explicit when-to-use or when-not-to-use guidance is provided. The context implies it is for reading settings, but alternatives like how to modify settings (update_settings) or get other data are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 correctly discloses input reference resolution, status values, and date format/inclusiveness. However, it omits details like whether the operation is read-only, pagination behavior, ordering, or error handling, leaving gaps in transparency.
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?
Three short paragraphs, each adding value: purpose first, then chore_id details, then status and date info. Front-loaded and efficient with no redundant sentences.
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 existence of an output schema, the description covers essential input parameters and output statuses. It lacks mention of ordering or pagination, which are common for list endpoints, but overall it provides enough context for the tool's primary function.
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 effectively explains chore_id reference forms and resolution, date format (YYYY-MM-DD), and inclusive range. This adds significant meaning beyond the bare schema, though it could be more explicit about default values (null means no bound).
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 tool lists derived occurrences for a chore within a date window. The verb 'list' and resource 'chore occurrences' are specific, and the tool is easily distinguishable from sibling list tools like list_habit_occurrences and list_event_occurrences.
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 explicit guidance is provided on when to use this tool versus alternatives. While the purpose is clear, the description does not mention scenarios where other tools (e.g., get_calendar_events) might be more appropriate or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It reveals that event_id is resolved to UUID and that url is a freshly signed GET for s3-backed entries. This gives good insight into input handling and output behavior. Could mention potential expiration of the URL or pagination.
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 (4 sentences) and well-structured: purpose first, then event_id flexibility, then output shape. No redundant 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?
Given the output schema exists and the description covers the response shape, this is fairly complete. It lacks mention of error handling or pagination, but for a simple list tool it is sufficient. Sibling tools are listed but not referenced.
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 0%, but the description adds significant value for event_id by listing accepted reference forms. However, the date parameter is not explained (e.g., format). With only two parameters, this partial coverage justifies a 3.
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 ("List attachments") and the resource ("on a specific event occurrence (date)"). It distinguishes from sibling tools like delete_event_occurrence_attachment and presign_event_occurrence_attachments by specifying the list operation.
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 explains how to provide event_id in various formats but does not specify when to use this tool versus alternatives such as list_task_attachments or presign_event_occurrence_attachments. No context about prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only adds 'admin only' as a behavioral constraint. Does not disclose whether the operation is read-only or any other side 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?
Single sentence with no wasted words, conveying all essential information upfront.
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?
Sufficient for a simple list operation with no parameters and an output schema, though lacks mention of pagination or sorting which could be relevant.
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?
No parameters in schema, so description cannot add value beyond the schema. Baseline 3 applies as schema coverage is 100%.
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?
Clearly states verb 'list', resource 'feedback', and context 'submitted' with access restriction 'admin only'. Distinguishes from sibling 'feedback_stats' which implies statistical aggregation.
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?
Defines a clear prerequisite (admin only) but does not explicitly address when to use this tool versus alternatives like 'feedback_stats'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the delete is a soft-delete (archive) and explains input resolution behavior. With no annotations, this provides useful behavioral context. However, it does not mention any side effects or limitations.
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 sentences, no extraneous words. The first sentence states the purpose, the second details the parameter. Perfectly sized and front-loaded.
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 simple one-parameter tool and presence of an output schema, the description covers the essential aspects. It could mention the return type or success confirmation, but is largely sufficient.
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 single parameter chore_id has no schema description, but the description thoroughly explains the accepted reference forms and resolution process, adding significant meaning beyond the raw string type.
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 tool archives (soft-deletes) a chore, using a specific verb and resource. It distinguishes itself from sibling tools like create_chore and update_chore by explicitly indicating deletion.
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 explicit guidance on when to use this tool versus alternatives. It provides no context on when a soft-delete is appropriate or when other deletion-related tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It explains that the tool returns a calendar view with recurring expansions and due dates, and clarifies parameter date formats and timezone handling. However, it does not explicitly state whether the operation is read-only or if any side effects occur, and lacks details on authentication 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 extremely concise, with a front-loaded first sentence defining the tool's purpose, followed by a single sentence explaining parameter formats. Every piece of information is relevant and there is no verbosity.
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 tool's modest complexity (3 parameters, output schema present), the description covers the key input details and purpose. It does not describe the output schema structure, but per rules that is not required since an output schema exists. The description is sufficient for an agent to understand input requirements and overall behavior.
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 0% description coverage, so the description adds essential meaning: specifying that 'start' and 'end' are YYYY-MM-DD strings with 'end' exclusive, and that 'tz' is an optional IANA timezone for local-midnight alignment. This significantly aids correct parameter usage.
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 that the tool provides a 'Calendar view of tasks (recurring expansions + due dates)', which specifies the verb (view), resource (tasks), and scope (calendar). It effectively distinguishes this tool from siblings like get_calendar_events (for events) and get_items_calendar (for all items).
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 offers no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when to avoid it, or which sibling tools might be more appropriate for specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses removal of saved credentials, but lacks details on token invalidation, side effects, or return value. With no annotations, more detail is needed.
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?
Extremely concise, single sentence, front-loaded with key action and resource.
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?
While concise, the description omits what happens after logout (e.g., return value, whether session ends globally). Output schema exists but isn't leveraged.
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?
No parameters exist, so no additional meaning needed. Baseline of 4 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 clearly states the action ('Log out') and the resource ('saved credentials'), distinguishing it from auth-related siblings like start_auth and complete_auth.
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?
Implied usage (end session) but no explicit guidance on when to use or not use, nor mention of prerequisites like being authenticated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that event_id references are resolved to UUID, multiple comments per occurrence are supported, and returns the persisted Comment with id and created_at. However, it does not mention authentication requirements or potential side 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 concise and front-loaded: the first sentence states the purpose, followed by relevant details about parameter flexibility, multiple comments, and return value. No redundant information.
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 complexity (4 parameters, output schema exists), the description explains event_id well and mentions return value. However, it fails to describe the expected format or constraints for required parameters date and body, and the optional is_private flag, leaving gaps for an AI agent.
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?
Input schema has 0% description coverage, so description must compensate. Only event_id is explained in detail (accepts multiple reference forms and resolved to UUID). The parameters date, body, and is_private lack any semantic explanation in the description, leaving them unclear.
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 'Append a new comment to an event occurrence (date),' specifying the verb (append) and resource (comment to event occurrence). It distinguishes from sibling tools like delete_event_occurrence_comment and patch_event_occurrence_comment.
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?
While the purpose implies when to use the tool (to add a new comment), it does not explicitly differentiate from alternatives like patch_event_occurrence_comment for editing or delete_event_occurrence_comment for removal. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It reveals backend validation for time fields and ID resolution. However, it does not disclose permissions, partial update behavior, or response format (though output schema exists). The information is useful but not comprehensive.
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 with two paragraphs: first sentence states purpose, then adds constraints and parameter details. No superfluous text; every sentence adds value. Front-loaded with purpose.
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?
With 7 parameters and no annotations, the description covers only event_id and a validation rule. It lacks details for most parameters (e.g., recurrence, labels). Output schema exists, so return values are not needed, but the description does not fully equip an agent to handle all mutable fields.
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 must compensate. It adds meaning for event_id (reference forms) and mentions a validation constraint for end_time/complete_by. It also notes a v0.2 optional field subtask_template not present in the schema. Other parameters (title, labels, recurrence) are not explained. Partial compensation.
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 'Patch mutable fields on an event,' clearly specifying the verb (patch) and resource (event). This distinguishes it from sibling tools like create_event (creation) and delete_event (deletion).
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 provides explicit usage constraints: backend rejects end_time < complete_by, and event_id accepts multiple reference forms (UUID, shorthand, canonical, URL). It lacks explicit when-to-use vs. alternatives, but the clear purpose and constraints give adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It explains reference resolution for item_id, backend wire field name for 'to', conditional requirements for complete_by, recurrence, and end_time, and idempotent behavior (200 vs 201). It does not cover permissions or error cases but provides substantial behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, front-loading the main purpose. However, it could be more structured (e.g., bullet points) for easier parsing. It is efficient but slightly dense.
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 complexity (5 parameters, mutation, no annotations, output schema exists), the description covers parameter requirements, transformation behavior, and idempotent return codes. It does not address error scenarios or invalid conversions but is fairly complete for an AI agent.
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?
Schema coverage is 0%, so the description must compensate. It thoroughly explains each parameter: item_id accepts multiple reference forms; to is the backend field name; complete_by required for Event/Chore/Habit; recurrence required for Habit/Chore; end_time Event-only. This adds crucial meaning beyond the bare schema types.
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 tool's purpose: 'Convert an item to a different kind (Task / Chore / Habit / Event).' This is a specific verb+resource combination, and the conversion aspect distinguishes it from sibling create/update/delete tools.
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 does not provide guidance on when to use this tool versus alternatives like creating a new item or updating item attributes. It lacks explicit context for appropriate usage and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses that habits reset each period and unfinished occurrences do not carry forward, which is a key behavioral trait. It also provides examples for the recurrence field structure. It does not cover auth needs or potential side effects.
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 concise, using a brief summary and bullet points for optional fields. It front-loads the key difference from chores. The structure is clean, though the mention of v0.2 optional fields could be streamlined.
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 complexity of the tool (6 parameters, output schema present), the description lacks completeness. Only the recurrence parameter is explained in detail. The extra fields mentioned without schema presence and lack of explanation for other parameters leave gaps.
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 must add meaning. It provides examples and shapes for the recurrence parameter but does little for other parameters like title, description, complete_by, parent_id, labels. Additionally, it mentions optional fields (deadline_time_of_day, subtask_template) that are not in the input schema, which could confuse.
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 'Create a recurring habit that resets each period', providing a specific verb and resource. It distinguishes habits from chores by explaining that unfinished occurrences do not carry forward, which sets it apart from sibling tool create_chore.
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 explains when to use habits instead of chores by contrasting the reset behavior. However, it does not explicitly state 'use this when you want to create a habit' or provide exclusions for other siblings like create_task or create_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It explains recurrence behavior and optional occurrence_id but does not mention auth requirements, side effects, or error conditions.
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?
Description is well-structured, front-loaded with purpose, then parameter details. Slightly verbose but justified given 10 parameters.
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?
Covers all parameters with meaningful detail. Has output schema (context hint). Lacks error handling or prerequisite info but is comprehensive for a creation tool.
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?
Schema has 0% description coverage; description adds meanings for all parameters, including formats and examples for recurrence, complete_by, productive, desire, and recurring_type.
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 'Create a new task' and explains parameter purposes, distinguishing it from sibling tools like create_chore, create_event, create_habit.
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?
Does not explicitly state when to use create_task vs siblings. It implies context for occurrence_id but lacks when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns only historical data for finished tasks, which is a key behavioral trait. Since no annotations are provided, the description carries the full burden; it also implies a read-only operation without side 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 extremely concise at a single sentence, front-loading the key information without any unnecessary words.
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 zero parameters and the presence of an output schema, the description adequately covers the purpose and scope. It could mention ordering or limits, but the output schema likely handles return structure.
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?
No parameters exist, so the description has no need to add parameter information. The baseline for zero parameters is 4, and the description does not detract from that.
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 tool returns the user's historical mood-per-task log for finished tasks, specifying the verb 'return', the resource 'mood-per-task log', and the scope 'finished tasks', which distinguishes it from sibling tools like get_item_history.
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 guidelines are provided about when to use this tool vs alternatives. The description implies it is for finished tasks, but does not explicitly state that it is not for ongoing tasks or provide alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some transparency by noting habit_id resolution and date inclusivity. However, it omits other behavioral traits such as authorization requirements, pagination, or idempotency, leaving gaps that an agent needs to infer.
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, front-loading the purpose in the first sentence. It uses clear formatting for parameter details and avoids unnecessary words. Every sentence adds 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?
With an output schema present, the description does not need to explain return values. It thoroughly covers parameter behavior and usage. Minor gaps exist (e.g., default date range behavior), but overall it is complete enough for a tool with this complexity.
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 coverage is 0%, but the description adds significant semantic value: it explains that habit_id accepts various reference forms (UUID, sequence shorthand, canonical ref, URL) and that dates must be YYYY-MM-DD with inclusive range. This goes well beyond the schema's basic type information.
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 'List occurrences for a habit in a date window,' specifying the verb, resource, and scope. It also clarifies that habit_id accepts multiple reference forms, making the tool distinct from siblings like list_chore_occurrences or list_event_occurrences.
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 explains how habit_id and dates should be provided, but it does not explicitly guide when to use this tool versus alternatives. Given the sibling tools, the resource differentiation is implicit, but explicit usage guidelines would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses ordering behavior but omits potential details like pagination, limits, or authentication requirements. This is acceptable for a straightforward list but lacks thoroughness.
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, no fluff. Front-loaded with the verb and resource. Every word serves a purpose.
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 tool's simplicity, the description is fairly complete. It explains the action and ordering. An output schema exists for return values. Could mention if it returns all items or paginated, but not a major gap.
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?
There are no parameters, so the schema is empty. Schema description coverage is 100% trivially. The description adds nothing about parameters, but that's fine since none exist. Baseline 4 for 0-param 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 states the verb 'List' and resource 'saved searches', and adds the key detail 'in their explicit order', which distinguishes it from a generic list. The tool name itself is descriptive, and the description reinforces its specific purpose.
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?
No explicit guidelines on when to use this tool versus alternatives like 'search_items' or 'reorder_saved_searches'. For a simple 0-parameter list, some guidance is not critical, but it would strengthen clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a destructive write operation by using 'Replace', but lacks details on authentication, error handling, or side effects. Basic disclosure is present but limited.
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, front-loaded with the action, no wasted words. Efficiently communicates the core functionality.
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 an output schema exists (not needing return description), the tool is simple with one parameter. The description covers the essential semantics (full list, replace order). However, it could be slightly more explicit about the ordering being based on array index.
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 compensates by adding that the IDs must be the 'full list' to define the new ordering. This provides meaning beyond the bare schema type of array of strings.
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 verb 'Replace', the resource 'saved-search ordering', and specifies the manner 'with the given full list of IDs'. It distinguishes from siblings like update_saved_search or list_saved_searches by focusing on ordering.
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 usage by stating what the tool does, but it does not explicitly provide when to use it versus alternatives like other reorder tools or update_saved_search. No when-not-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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains that 'event_id' accepts multiple reference forms and is resolved to UUID, that 'att_id' is an attachment ID passed through unresolved, and states the return value {'ok': true}. This gives a clear understanding of the tool's 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 well-structured with a clear purpose statement first, followed by parameter details. It is efficient but could be slightly more concise by combining the two parameter paragraphs into one. Overall, it earns its sentences.
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 tool has three required parameters, no annotations, and no output schema provided (though description states return value). The description covers purpose, parameter handling, and return value, but the missing explanation for the 'date' parameter reduces completeness.
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 0% description coverage, so the description must compensate. It explains 'event_id' reference resolution and 'att_id' semantics, but fails to describe the 'date' parameter, leaving a gap for one of three required 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 description clearly states 'Delete a single attachment from an event occurrence.' It specifies the verb 'delete', the resource 'attachment', and the context 'event occurrence', which distinguishes it from sibling tools like 'delete_event_occurrence_comment' or 'delete_task_attachment'.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide context about choosing between similar delete tools for different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Discloses it's a hard-delete and the returned task_id, but lacks details on side effects, authorization, or error conditions.
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 paragraphs, front-loaded with purpose, followed by parameter details. Every sentence adds 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?
Covers input and output adequately. Output schema exists, reducing need for return value explanation. However, could mention error conditions or prerequisites.
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?
Adds significant meaning beyond schema (0% coverage) by detailing that task_id accepts UUID, sequence shorthand, canonical ref, or app URL, and explains the returned value.
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?
Clearly states it 'hard-deletes a task by id', with a specific verb and resource. Differentiates from sibling delete tools for other entities and delete_task_attachment.
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?
Implied usage (when you need to delete a task), but no explicit guidance on when to use vs alternatives, prerequisites, or consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses how the plan auto-seeds from recurring tasks, carries forward incomplete items, and includes due items. It also explains timezone handling and parameter defaults. No side effects or destructive actions are indicated, which is appropriate for a read-only tool.
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 well-structured with a clear intro followed by parameter details. It is concise without unnecessary text, though the parameter documentation could be slightly more compact. Every sentence contributes to understanding.
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?
Given the tool has only 2 optional parameters, no required fields, and an output schema (not shown), the description covers all essential aspects: behavior, parameter semantics, and timezone handling. It is complete and leaves no critical gaps.
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?
Schema coverage is 0%, so the description must compensate. It explains both parameters in detail: date format (YYYY-MM-DD), default behavior (today in user's timezone), and timezone (IANA format, persistence after first use). This adds significant value beyond the raw 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 clearly states 'Return today's curated daily plan' and explains its contents (recurring tasks, incomplete items, due items). It is specific about the verb and resource, but does not explicitly differentiate it from sibling tools like get_items_plan or get_calendar_events.
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 provides guidance on when to supply the timezone parameter and mentions that the date defaults to today in user's timezone. However, it does not discuss when to use this tool versus alternatives or note any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions event_id resolution and the 400 error condition, but lacks details on side effects (e.g., append vs. replace), permissions, or error handling beyond the 400 case. Additional behavioral context would be beneficial.
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 well-structured: a one-sentence purpose, a paragraph on event_id resolution, and a paragraph on intents/urls with error condition. Every sentence adds value, and critical information is front-loaded.
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 presence of an output schema, the description does not need to detail return values. It covers most parameters and essential behavioral notes, but the lack of explanation for the 'date' parameter and potential overwrite behavior leaves minor gaps. Overall, fairly complete for a 4-parameter 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 input schema has 0% description coverage, so the description must compensate. It explains the flexible forms of event_id, that intents come from a prior presign, and the structure of urls. However, the 'date' parameter is not explained, leaving a gap for a required field.
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 it commits intents and/or URL-provider entries to an event occurrence, with a specific verb and resource. It distinguishes from sibling tools like commit_task_attachments by focusing on event occurrences and referencing a prior presign call.
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 implies when to use the tool (after a presign call) and provides a condition to avoid (400 if both lists empty). However, it does not explicitly mention alternatives or when not to use it, but the workflow context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It discloses the expected structure and dry-run behavior but does not detail side effects, permissions, or conflict handling. Adequate but not exhaustive.
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 very concise—two sentences that state the purpose and explain the parameter. No wasted words; the key information is front-loaded.
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 one parameter, no required fields, and an output schema, the description is mostly complete. It covers input structure and dry-run capability, though it could mention whether existing data is overwritten or appended.
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?
With 0% schema coverage, the description adds critical meaning: 'data' must be the full ExportData object with specific keys, and an empty dict triggers a dry-run. This goes beyond the schema's minimal definition of an optional object.
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 tool imports an ExportData blob produced by export_data. It specifies the verb ('import') and resource ('ExportData blob'), and distinguishes itself from the sibling export_data 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 description implies when to use: after exporting data with export_data. It mentions a dry-run option (pass empty dict), but does not explicitly exclude other scenarios. No alternative import tools exist among siblings, so guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It explains return value and event_id resolution, but does not explicitly state that the deletion is permanent or destructive, nor mention any side effects or authorization needs.
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 extremely concise: two sentences plus brief parameter clarifications, front-loaded with the main purpose, and every word adds value. No unnecessary text.
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 tool's simplicity and presence of output schema (implied), the description covers parameters and return value well. It lacks mention of error conditions or side effects, but is otherwise adequate for a straightforward delete operation.
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?
Although schema description coverage is 0%, the description adds substantial meaning: it explains accepted reference forms for event_id and date format, which the schema lacks. This compensates fully for the schema's omissions.
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 tool clears an event occurrence row, using specific verbs like 'clear' and 'undo a prior mark', which distinguishes it from sibling tools like 'delete_event' and 'set_event_occurrence'.
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 implies usage for undoing a prior mark, but does not explicitly list when to use versus alternatives or when not to use, though context from sibling names provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It discloses that the operation is a soft-delete ('Archive') and explains the ID resolution behavior, providing useful behavioral context.
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?
Three sentences with no fluff: first sentence states purpose, second explains parameter. Every sentence earns its place.
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 output schema existence, return values need not be explained. The description covers purpose and parameter semantics fully, but lacks any mention of conditions or outcomes beyond soft-delete.
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?
Schema coverage is 0%, so the description must compensate. It does so excellently by explaining that habit_id accepts UUID, sequence shorthand, canonical ref, or app URL and is resolved to UUID, adding significant meaning beyond the schema's generic string type.
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 'Archive (soft-delete) a habit', specifying the action (soft-delete) and the resource (habit), distinguishing it from sibling tools like delete_task or delete_chore.
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 explains ID resolution but lacks explicit guidance on when to use this tool versus alternatives like update_habit or other delete tools. No conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly explains the default compact projection, the rejection of unfilterable fields with a 400 error, the limit cap behavior (backend rejects >500), and the automatic injection of fields like ref, org_slug, type, and sequence. It also clarifies the effect of the 'full' and 'window' parameters. This level of detail is exemplary.
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 well-structured with a clear opening sentence and bullet points for filters. It is somewhat lengthy but each sentence adds value. It could be slightly more concise, but the organization compensates.
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?
Given the complexity (7 parameters, no annotations, no param descriptions in schema), the description covers all necessary aspects: projection details, filter syntax, limit behavior, and error handling. The existence of an output schema (not shown) means return values need not be explained, and the description still mentions the compact vs full rows. It is complete enough for an agent to use 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 0% description coverage, so the description must compensate. It does so by explaining each parameter: kind (listing possible values), status, from_date/to_date (format and behavior), limit (maps to $top and cap), full (boolean to drop projection), and window (opt-out default). This adds significant meaning beyond the bare 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 clearly states it lists items of various kinds (Task/Habit/Chore/Event) with windowing, calling itself the 'canonical, bounded list view'. It specifies the verb 'list' and the resource 'items', but does not explicitly differentiate from sibling tools like search_items or get_items_calendar, leaving some ambiguity about when to choose this tool over alternatives.
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 provides context such as the default projection and mentions when to use window='all' for full history. However, it does not explicitly state when to use this tool versus search_items or other listing tools, nor does it provide exclusions or conditions for not using it. Usage guidelines are implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains ID resolution, status values including alias, and the behavior of 'Done' resolving to DoneOnTime/DoneLate. It also mentions the 404 error case. Some side effects (e.g., updating any other data) are not mentioned but likely minimal.
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 concise with several sentences, each adding value. It is front-loaded with the core action. No wasted words.
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 tool's complexity (2 parameters, one required, output schema exists), the description covers behavior, parameter details, and an error case. It does not describe the output format, but the presence of an output schema lessens that need.
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 has 0% coverage, so description compensates fully. It explains chore_id accepts multiple reference forms and resolves to UUID, and enumerates valid status values including aliases. This adds meaning beyond the raw schema types.
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 it applies a status to the earliest unresolved occurrence of a chore, using specific verbs and distinguishing from siblings like set_chore_occurrence_status that require a specific occurrence.
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?
Explicitly mentions it's useful for the common case of not wanting to look up which date is overdue, and notes a 404 if no unresolved occurrence exists. However, it does not explicitly mention when not to use or directly name alternative tools like set_chore_occurrence_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains parameter resolving behavior, detachment with None, and position indexing, providing good behavioral detail. However, it omits potential pitfalls like moving to descendants.
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, front-loaded with purpose, and each sentence adds value. No redundant or extraneous 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?
With an output schema present, return values need not be described. The description covers key behaviors and parameter usage. Minor lack of constraints (e.g., 'cannot move to a descendant') but overall adequate for a move/reorder operation.
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?
Despite 0% schema description coverage, the tool's description thoroughly explains each parameter: task_id and new_parent_id accept multiple reference forms, new_parent_id=None detaches, position is insertion index with omission to append. This fully compensates for the schema's lack of descriptions.
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 tool moves a task to a different parent or reorders within the same parent, using specific verbs and resource. This distinguishes it from sibling tools like create_task, delete_task, update_task, etc.
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 over alternatives like update_task or promote_task. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: the chore_id resolution (UUID, sequence shorthand, canonical ref, URL), status aliases, and the server-side resolution of 'Done' to DoneOnTime or DoneLate. It does not mention authorization requirements or side effects like notifications, but it covers the core mutation behavior adequately.
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 front-loaded with the main purpose, followed by structured details for each parameter. While slightly verbose with the note and formatting, every sentence provides necessary information without waste.
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 no annotations and an existing output schema (not shown), the description does not explain return values or potential errors. It also omits preconditions like requiring an existing chore occurrence. For a mutation tool, additional context on side effects or idempotency would improve completeness, but the core behavior is clear enough.
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 0% description coverage, so the description must compensate. It does so thoroughly: explains chore_id accepts multiple reference forms, status is one of three values with legacy alias, and date is YYYY-MM-DD format. Every parameter is fully documented.
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 clear verb+resource: 'Set the status of a single chore occurrence.' It distinguishes from sibling tools like 'mark_next_chore_done' (which marks the next due occurrence) and 'reschedule_chore_occurrence' (which changes the date).
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 lists valid status values and notes the alias for 'dropped', guiding correct usage. It explains that 'Done' resolves server-side based on 'complete_by'. It does not explicitly say when not to use this tool vs alternatives, but the context from sibling tools provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must compensate. It discloses that task_id accepts multiple reference formats and lists valid statuses. However, it does not describe side effects, error handling, or whether the tool is idempotent.
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 sentences and a bullet list are extremely concise. The purpose is stated first, followed by parameter details in a logical order. Every sentence adds value without redundancy.
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 tool has only two parameters and an output schema. The description covers input semantics and valid statuses. It doesn't explain output, but the output schema covers that. A minor gap is not mentioning that it is an alternative to update_task for status changes, but the wrapper concept implies it.
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?
Schema coverage is 0%, so description adds substantial value. For task_id, it explains multiple reference forms beyond schema's string type. For status, it lists all allowed values, which the schema does not as an enum. This fully compensates for the lack of schema descriptions.
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 it is a convenience wrapper around update_task for status changes, specifying the verb 'set status' and the resource 'task'. It differentiates from sibling update_task by focusing on status-only updates.
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 implicitly guides usage for status changes only, listing accepted statuses. It doesn't explicitly exclude other updates, but the context of being a wrapper conveys when to use this tool versus update_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers multiple behavioral traits: chore_id accepts multiple reference forms, complete_by cannot be cleared, recurrence update rotates series ID, and v0.2 field behaviors. It lacks details on auth or rate limits but provides substantial transparency.
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 well-structured with paragraphs and bullet points, front-loading the main purpose. It is not overly verbose, though some sections could be slightly more concise. Every sentence adds 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?
Given an output schema exists (not shown), the description covers parameter details and constraints well. It lacks mention of error handling or defaults but is quite complete for a patch tool with 6 parameters.
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 coverage is 0%, so the description carries full burden. It explains chore_id formats, constraints on complete_by and recurrence, and v0.2 optional fields (cadence_mode, deadline_time_of_day, subtask_template). It does not detail title, description, or labels, but these are intuitive.
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 'Patch mutable fields on a chore,' clearly stating the verb (patch) and resource (chore). It distinguishes from sibling tools like create_chore and delete_chore, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that omitted fields stay untouched and provides specific field behaviors (e.g., complete_by cannot be cleared). It implies usage for updating chores, but does not explicitly state when not to use it or list alternatives. Still clear enough for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns 'the full attachments Vec post-commit' and explains parameter constraints. However, it does not mention if the operation is idempotent, what side effects occur (e.g., deletion of intents), or required permissions. Some behavioral aspects are implicit (mutation), but not fully transparent.
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 (5-6 lines) and well-structured. It starts with a one-line summary, then uses clear bullet-style explanations for each parameter and constraint. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not shown), the description appropriately doesn't detail return fields but states 'Returns the full attachments Vec post-commit.' It covers purpose, parameter meanings, constraints, and usage context. For a commit action, this is complete.
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?
Schema coverage is 0%, so description must compensate. It explains that 'intents' is a list of attachment_ids from a prior presign call, 'urls' is a list of {url, filename?} records, and 'task_id' accepts various forms (UUID, sequence shorthand, canonical ref, app URL) and is resolved to UUID. This adds significant meaning beyond the bare 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 states the tool's purpose: 'Commit presigned intents and/or url-provider entries to a task.' It distinguishes from siblings like presign_task_attachments (creating intents) and list_task_attachments (listing attachments). The verb 'commit' is specific and the resource 'task attachments' is 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 provides usage context: it mentions 'presign call' as a prerequisite and states that at least one of 'intents' or 'urls' must be non-empty. However, it does not explicitly list alternatives or state when not to use this tool. It implies the workflow but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that the operation is a soft-delete (archive), not a hard delete, and explains how event_id is resolved. This adds useful behavioral context beyond a simple 'delete'.
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 sentences: first states purpose, second details parameter flexibility. No redundancy, front-loaded, and every sentence 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?
Given only one parameter and no annotations, the description covers purpose and parameter semantics adequately. An output schema exists, so return values need not be explained. The description is complete for this straightforward tool.
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?
Schema coverage is 0% (no parameter description), but the description compensates thoroughly by explaining that event_id accepts multiple reference forms (UUID, sequence shorthand, canonical ref, app URL) and is resolved to UUID. This adds significant meaning beyond the generic 'string' type.
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 verb ('Archive (soft-delete)') and resource ('an event'), distinguishing it from sibling tools like delete_event_occurrence. The purpose is specific and 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 implies usage through its purpose but lacks explicit guidance on when to use this tool vs alternatives (e.g., delete_event_occurrence, update_event). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses key behaviors: task re-encryption under the target org's key, ownership and membership requirements, and null return on success. It does not mention potential side effects like deletion from the personal org, but the core behavioral traits are well-covered.
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: three sentences covering purpose, mechanism, constraints, and return. No redundant phrases. Information is front-loaded with the core action, making it easy for an agent to quickly understand.
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 2 parameters and a null output, the description covers the main points: purpose, cryptographic operation, ownership prerequisites, and return. It does not specify whether the original task is deleted or error conditions, but overall it is sufficiently complete given the tool's simplicity.
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?
With 0% schema description coverage, the description adds essential meaning: it clarifies that task_id is the task to promote and target_org_id is the destination org. The description explains 'Moves the task into target_org_id,' giving context beyond the bare schema. However, it does not specify format or constraints like UUIDs.
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 tool's purpose: 'Promote a personal-org task into a target org.' It specifies the action (promote), resource (task), and context (personal to target org). This distinguishes it from sibling tools like move_task or merge_task, which have different semantics.
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 explicitly states prerequisites: 'The caller must own the task in their personal org AND be a member of target_org_id.' It also notes the return value. However, it does not provide explicit guidance on when not to use this tool or mention alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses behavioral traits: event_id resolution, action values and alias, date format, and the cascade_subtasks behavior including 409 error. It is transparent about mutation and error conditions, though idempotency is not mentioned.
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 (7 sentences), well-structured with a clear purpose sentence followed by parameter details in code format. No extraneous information; every sentence 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?
Given four parameters, no annotations, and an output schema, the description covers all necessary details: parameter behavior, valid values, error handling, and resolution. It is complete for an agent to select and invoke 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?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: event_id accepts multiple forms, action enumerates values and alias, date format, and cascade_subtasks default and error behavior. This provides critical meaning beyond schema types.
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 tool marks a single event occurrence with an action, specifying verb, resource, and scope. It distinguishes from sibling tools like delete_event_occurrence or reschedule_event_occurrence by focusing on status marking.
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 usage for changing occurrence status but does not explicitly state when to use vs alternatives or provide exclusion criteria. The context of sibling tools offers differentiation, but the description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses the backend body ({pinned: bool}), the return format ({"ok": true}), and explains the resolution of item_id from various reference forms. It could mention potential errors or side effects, but for a simple toggle operation, the information is adequate.
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 (roughly 80 words) and well-structured. It starts with the core purpose, then details parameter semantics, and ends with backend behavior and return value. Every sentence serves a purpose without redundancy.
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 simplicity of the tool (2 parameters, no annotations) and the presence of an output schema (though not shown), the description covers the essential aspects: action, parameter details, backend logic, and return. It could mention error scenarios or permissions, but for a pin toggle, it is largely 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 input schema has 0% description coverage, so the description must compensate. It thoroughly explains the 'item_id' parameter, including accepted reference forms (UUID, sequence shorthand, canonical ref, app URL). The 'pinned' parameter is only described as 'bool' but its purpose is obvious from the tool name. Overall, it adds significant 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 explicitly states the action ('Pin or unpin a sidebar item') and specifies the item types (Task/Habit/Chore/Event). It clearly distinguishes itself from the sibling tool 'update_pinned_label' by noting that custom pin labels are handled elsewhere.
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 provides clear usage context: it explains that the endpoint toggles pin status and that the label argument is not part of this endpoint, directing to the custom label endpoint. However, it does not explicitly state when to use this tool over other related tools like 'batch_tasks' or 'update_task', though the specific action makes the usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses atomicity (all-or-nothing) and the return format. It details operation structure for both update and move. However, it does not cover error handling, permission checks, or edge cases.
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 well-structured, with a concise opening sentence summarizing the purpose, followed by bullet-like explanations. Every sentence adds value without redundancy.
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 description covers the main aspects: operation types, atomicity, return format. However, it lacks details on validation, error responses, batch size limits, and whether operations can be mixed. Given the complexity and presence of an output schema, it is fairly complete but could be more thorough.
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?
With 0% schema description coverage, the description fully compensates. It explains the operations array structure, required op and task_id, and the different fields for update vs move. It also references update_task for allowed fields. This adds significant meaning beyond the bare 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 states the tool's purpose: executing multiple task operations atomically. It specifies the verb 'execute multiple task operations' and the resource 'tasks'. It distinguishes from sibling tools like update_task and move_task by batching operations.
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 explains when to use the tool: for multiple atomic operations. It references individual tools (update_task) for operation fields. It does not explicitly state when not to use it, but the context of batch vs individual is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains core behavior (lingering, recurrence types, cadence_mode, deadline_time_of_day, subtask_template). Lacks details on error handling or failure modes.
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?
Well-structured: opening sentence, distinction from habits, recurrence format, then optional fields. Each sentence adds value, no fluff.
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 tool with 6 parameters and recurrence complexity, the description covers core concept, usage context, parameter formats, and optional features. No annotations or output schema needed. Complete for an AI 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%. Description explains 'complete_by' format (ISO-8601), 'recurrence' shape, and optional fields (cadence_mode, deadline_time_of_day, subtask_template). Does not cover all parameters (e.g., parent_id, labels), but adds significant value.
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 it creates a recurring chore that 'lingers until done,' distinguishing it from habits. It specifies the verb 'Create' and resource 'chore' with explicit behavioral difference.
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 contrasts chores with habits, giving clear context for when to use this tool. However, it does not explicitly state when not to use or name alternative tools beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes ID resolution behavior (task_id resolved to UUID) and that att_id is passed through. No annotations, so description carries burden. Could mention irreversibility, but sufficient for understanding.
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 front-loaded sentences with no waste. Every sentence adds distinct value: purpose and ID resolution 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?
Covers input parameters well. No output schema shown but presumably available; description doesn't need to explain return values. Missing potential error conditions, but acceptable for a simple delete operation.
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?
With 0% schema coverage, description adds critical meaning: explains accepted reference forms for task_id and clarifies that att_id is an attachment id (not item ref). Significantly beyond type info.
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?
Clearly states it deletes a single attachment from a task. Differentiates from siblings that delete other entities like tasks or comments.
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?
Specifies the action and the context (delete attachment from task). Provides guidance on ID formats for task_id. No explicit when-not-to-use but clear from name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it returns a complete backup of specified data. Implicitly non-destructive (read operation), though no explicit safety guarantee. Good context despite lack of 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?
Three sentences with no wasted words. First sentence states purpose, second details contents, third mentions reimport. Information is front-loaded.
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?
Given no parameters and presence of output schema, description covers all essential behavioral aspects (what is exported, import capability). Complete for this tool's complexity.
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?
No parameters, so schema coverage is 100%. Description adds value by clarifying it exports 'all' user data with no filtering, which is meaningful beyond 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?
Description explicitly states it exports all user data as JSON, a complete backup. Lists specific data types (tasks with full history, mood vectors, recurrence rules, root ordering, daily plans). Distinguishes from sibling import_data.
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?
Clearly indicates usage for backup purposes and mentions reimport via web UI. No direct when-not or alternatives, but context suggests export is for backup, import for restore.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains expansion of RRULE and timezone handling. Lacks mention of read-only nature but is implied by 'query'.
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?
Well-structured with concise intro and clear parameter explanations. No redundant sentences.
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?
Complete for a simple query tool. Output schema exists, so return format is covered. Could mention pagination or limits but not necessary.
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?
Schema coverage is 0%, so description provides all semantics: start/end are YYYY-MM-DD with inclusive/exclusive; tz is IANA timezone for local midnight alignment.
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 explicitly states it queries calendar events for a date range, including recurring tasks from RRULE. This distinguishes it from sibling tools like get_daily_plan or get_tasks_calendar.
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?
Clear context for use: date range queries. It does not explicitly say when not to use or mention alternatives, but the behavior for recurring events is well explained, implying differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the return shape and notes that Events never produce 'DoneLate', adding behavioral context beyond basic functionality.
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, front-loads the purpose, then systematically covers parameters, return shape, and a behavioral note. No redundant sentences.
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 tool's simplicity and the presence of an output schema, the description covers the key aspects: purpose, parameter formatting, return shape, and a behavioral constraint. Missing pagination details but adequate.
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?
Schema coverage is 0%, so the description must compensate. It fully explains event_id's accepted formats and resolution process, and clarifies from_date/to_date format and optionality, adding significant value.
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 tool lists occurrences for an Event in a date range, with a specific verb and resource. It distinguishes from siblings like list_chore_occurrences and list_habit_occurrences by focusing on events.
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 explains how to specify the event_id (multiple reference forms) and that from_date/to_date are optional. It provides clear usage context but does not explicitly mention when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries the burden. It discloses that chore_id is resolved to UUID, date formats are YYYY-MM-DD, and that the backend currently returns 501 for chores (forward compatibility). This is transparent about current behavior and limitations.
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 concise sentences plus a brief note. Front-loaded with main purpose, no redundant words, efficient for an AI agent to parse.
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?
Has output schema (not shown), so return value explanation is not needed. The description covers purpose, parameter semantics, and current limitation. Could mention success/error cases beyond 501, but overall sufficient given output schema and tool complexity.
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?
Schema coverage is 0%, so description compensates fully. It explains chore_id accepts multiple reference forms (UUID, sequence shorthand, canonical ref, app URL) and is resolved to UUID. It clarifies that date and new_date are YYYY-MM-DD occurrence dates, adding essential meaning not 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 clearly states 'Move a single chore occurrence to new_date without touching the cadence', specifying the action, resource, and key differentiator. It distinguishes from siblings like set_chore_occurrence_status and mark_next_chore_done, and from other reschedule tools for events and habits.
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 explains what the tool does and its scope (single occurrence, no cadence change), and notes that chore_id accepts multiple reference forms. It also provides a forward compatibility note, but lacks explicit when-not or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses mutation (setting/clearing), the only way to clear (null), and the 404 error condition. It could mention authorization or side effects, but the disclosed information is sufficient for safe usage.
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?
Five sentences, front-loaded with the main action, concise and no fluff. Every sentence adds necessary detail (parameter clarification, clearing method, error condition).
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?
Completeness for a simple update tool: explains operation, parameters, behavior for clearing, error condition. Output schema exists, so return value detail is not needed. No gaps identified.
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 coverage is 0%, but description adds meaning to both parameters: pinned_id is 'the underlying task UUID', label can be null to clear, and body is always sent as JSON with null. This compensates for lack of schema descriptions.
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 verb 'Set or clear' and the resource 'custom sidebar label for a pinned task', making the purpose explicit. It distinguishes from sibling tools like set_item_pinned or reorder_pinned_tasks by focusing on label manipulation.
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?
Provides clear instructions on how to use: pass label=None to clear, and notes the body format. Mentions that 404 indicates task not pinned. However, it does not explicitly contrast with sibling tools or give when-to-use/not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool 'returns' user info, implying a read-only operation, but does not disclose any other behavioral traits like response structure or potential errors. The output schema exists but description adds no context beyond the action.
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 sentences, front-loaded with purpose, no wasted words. Each sentence 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 auth-check tool with no parameters and an existing output schema, the description is complete. It tells the agent exactly what it does and when to call it.
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 0 parameters and schema coverage is 100%. No parameter explanation needed; baseline for 0 params is 4.
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 'Return' and resource 'currently authenticated Deferno user', making the tool's function unambiguous. It clearly distinguishes from siblings, which are all about managing tasks, events, habits, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first to confirm that the Authorization header is valid before issuing task operations', providing clear when-to-use and implied when-not-to-use guidance. No alternatives needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains resolution behavior, default vs full response, and ambiguity handling. It does not explicitly state read-only or idempotency, but the 'get' verb and context imply it. Overall, it adds significant behavioral context.
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?
Description is well-structured: starts with a clear one-liner, then organized bullet points for input forms, and detailed explanation of ambiguity. Every sentence adds value. No wasted words.
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?
Given the complexity of input forms and ambiguity, the description is comprehensive. It covers all parameters, default behavior, and when to use flags. Output schema exists, so return values are not needed. Complete for the tool's purpose.
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?
Schema description coverage is 0%, so the description fully compensates. It explains all three parameters in detail: item (multiple forms, resolution, ambiguity), full (comparison to default), and as_alias (escape hatch). Adds rich semantics 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 clearly states it fetches a single item (Task/Habit/Chore/Event) by any reference. It distinguishes itself from sibling tools like search_items by focusing on single-item retrieval via various reference forms.
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 implies when to use this tool (fetch a single item by reference) but does not explicitly contrast it with sibling tools like search_items or get_item_history. However, it provides detailed usage guidance for parameters, including when to use as_alias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains URL signing for S3 and task_id resolution, offering good transparency beyond the basic operation.
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?
Three efficient sentences covering purpose, output, and parameter behavior without waste.
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?
Despite output schema existing, the description provides the wire shape, and all relevant behaviors are covered for a simple list tool.
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?
Schema coverage is 0%, but the description fully explains that task_id accepts UUID, shorthand, canonical ref, or app URL, adding critical meaning.
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 'List a task's attachments' and provides the output wire shape, distinguishing it from siblings that create, delete, or presign attachments.
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 implies usage for retrieving attachments without explicit when-not or alternatives, but the context of sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it explains that child content is appended to the parent description and children are marked as 'pruned' but recoverable. This provides sufficient transparency for a safe operation.
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, with the main action in the first sentence and supporting details in short, well-structured sentences. No redundant information.
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?
Given the tool's simplicity (one parameter, output schema exists), the description provides all necessary context: parameter flexibility, behavioral effect, and the role of the input. It is fully complete for an agent to use 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 single parameter task_id is thoroughly explained: it accepts multiple reference forms (UUID, sequence shorthand, canonical ref, app URL) and clarifies that it expects a child's ID, adding meaning beyond the input schema's type definition.
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 tool's purpose: 'Roll the active children of a task back into the parent.' It uses specific verbs and resources, and distinguishes from siblings like fold_task and split_task through its unique 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 gives clear context on how to use the tool ('Pass the id of any child whose parent should receive the merge'), but does not explicitly state when not to use it or compare to alternative siblings, leaving some guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: event_id accepts multiple reference forms and is resolved to UUID, files expect a specific structure, server enforces caps, and returns presigned PUT URLs with intent IDs. It lacks details on authentication or error handling, but covers the core workflow well.
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 with two clear paragraphs. The first sentence states the purpose, and the rest provides necessary details without redundancy. Every sentence adds value, making it easy to parse quickly.
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?
Given the presence of an output schema (not shown), the description appropriately explains the return type ('presigned PUT URLs with intent ids') and the two-step flow with 'commit_event_occurrence_attachments'. It covers all parameters and constraints, making the tool's behavior fully understandable for selection and invocation.
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 schema has 0% description coverage, but the description adds significant meaning: it explains event_id's flexible input formats, specifies the exact structure for each file entry ('filename, content_type, size_bytes'), and clarifies that date is for the specific occurrence. This compensates fully for the schema gaps.
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 tool's purpose with a specific verb ('batch-presign') and resource ('attachments for a specific event occurrence (date)'). It distinguishes itself from sibling tools like 'commit_event_occurrence_attachments' (which consumes the presigned URLs) and 'presign_task_attachments' (for tasks), leaving no ambiguity about its function.
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 provides implicit usage guidelines by mentioning the server-enforced caps (25 MB per-file, blocked-MIME list, max-attachments) and linking to 'commit_event_occurrence_attachments', indicating a two-step process. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, which keeps it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses batch operation, per-file size limit, blocked MIME types, return format (attachment_id, put_url, expires_at), and error response (400). No annotations exist, so description carries full burden; it provides substantial behavioral context.
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?
Three sentences, purpose is front-loaded. Each sentence adds unique value: purpose, parameter details, constraints, and follow-up action. No redundancy or unnecessary words.
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?
Covers the full workflow: presign URLs, caller PUTs, then commit. Includes constraints, return fields, and error handling. With an output schema present, no further details needed. Complete for a 2-parameter tool.
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?
Schema has 0% description coverage but description explains task_id accepts multiple reference forms (UUID, shorthand, etc.) and resolves to UUID. For files, specifies it's a list of {filename, content_type, size_bytes} and notes wire key alignment. Adds critical meaning 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?
Description clearly states 'Batch-presign S3 PUT URLs for files to attach to a task.' It specifies the action (presign) and resource (files for tasks), distinguishing it from siblings like commit_task_attachments.
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?
Instructs that after presigning, the caller must PUT blobs before invoking commit_task_attachments. Mentions alternative reference forms for task_id and constraints (25 MB cap, blocked MIME). Does not explicitly state when not to use, but the sequential usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses key behaviors: multiple ID formats (UUID, shorthand, canonical ref, URL), status constraints (cannot complete with active children), field clearing via None, recurring scope requirement and error message, and optional occurrence_id field. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and clear sections; every sentence adds value. Slightly long but justified by complexity of recurring tasks and multiple ID formats. Could be more concise, but overall effective.
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?
Given 13 parameters, 0% schema coverage, and presence of output schema, the description comprehensively covers ID resolution, status constraints, recurring scope rules, and clearing mechanism. References external docs for recurrence details. Sufficient for agent to use correctly.
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?
Despite 0% schema coverage, description adds significant semantic value: explains task_id formats, status enum values, clearing behavior for all parameters, recurring scope/ID dependencies, and references create_task for recurrence details. However, not every parameter (e.g., assignee, labels, productive) gets individual explanation, relying on general rules.
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?
Clearly states 'Patch mutable fields on a task.' The verb 'patch' and resource 'task' are specific, and the description distinguishes the tool from siblings like create_task, delete_task, set_task_status by focusing on partial updates to existing tasks.
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?
Provides clear guidance on when to use: updating task fields, with explicit instructions for clearing fields (None), handling recurring tasks (scope/ID dependencies), and error handling. Lacks an explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavior: it returns a JSON array with specific structure, reconciles inconsistencies by dropping unpinned/deleted entries, and guarantees self-consistent output safe for rendering. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (about 60 words) and front-loaded. The first sentence states the core purpose, the second adds output details and behavioral guarantees. Every sentence earns its place with no wasted words.
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?
Given zero parameters and an output schema (inferred), the description fully covers the tool's behavior including reconciliation logic and output format. No gaps remain for an agent to understand invocation or results.
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 parameters, so the description does not need to add parameter details. Baseline 4 is appropriate as the schema coverage is 100% and no parameters exist to clarify.
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 clearly identifies the resource as 'sidebar-pinned items in display order'. It distinguishes this tool from siblings like 'set_item_pinned' and 'reorder_pinned_tasks' by focusing on listing, not pinning or reordering.
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 states the tool's purpose (listing pinned items in order) and implies usage in sidebar rendering context. However, it does not explicitly state when not to use this tool or provide alternatives for other listing needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the internal behavior: marking origin as 'Dropped' with rescheduled_to, creating new 'Scheduled' row with rescheduled_from, and returning 400 if new_date equals origin date. It also explains the flexible event_id format.
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 (4-5 sentences) and well-structured: first sentence states purpose, then explains event_id, then the effect on data, and an error condition. No unnecessary words.
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?
Despite no annotations, the description covers purpose, parameter details, internal behavior, and an error condition. Combined with the presence of an output schema (to describe return values), this is complete for a mutation 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?
Schema coverage is 0%, so the description compensates by explaining event_id in detail (accepts various reference forms and resolves to UUID). However, it does not explicitly describe the 'date' parameter (the origin date) beyond mentioning 'origin_date', and 'new_date' is trivial. Overall adds significant value for one parameter.
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 tool's purpose: 'Move a single event occurrence to new_date without touching the RRULE.' This is specific, uses a verb and resource, and distinguishes it from sibling tools like reschedule_chore_occurrence and reschedule_habit_occurrence which target different item types.
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 implies the tool is for event occurrences and mentions it doesn't affect the RRULE, but does not explicitly state when to use it versus alternatives like set_event_occurrence. It provides context for use but lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the flow: returns URL, user opens browser, authenticates via OIDC, and sees a short code to paste. No annotations, so description covers behavior well, though could mention idempotency or state reset. No contradiction with annotations (none).
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?
Concise two-paragraph description with clear structure. Every sentence adds value: purpose, return value, flow steps, and transport note.
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?
Fully adequate for a zero-parameter authentication initiation tool. With no parameters and an output schema (presumably containing the URL), the description covers everything needed.
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?
No parameters; baseline 4 applies as description does not need to add meaning beyond the empty schema. Adequately explains the tool's function.
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 it 'Begin the Deferno authentication flow' and returns a URL, clearly identifying it as the first step in authentication. Distinguishes from sibling tools like complete_auth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes that in HTTP transport with OAuth, authentication is handled automatically, and this tool is only needed for stdio/CLI transport. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the exchange operation and transport-specific applicability. It implies mutation (token creation) but could mention idempotency or failure behavior. Still, it adds value beyond missing 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?
Three sentences, front-loaded with purpose, then parameter details, then transport note. Every sentence earns its place; no waste.
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 auth completion tool, the description covers all essentials: parameters, usage context, and transport differentiation. Output schema exists, so return values need not be described. Sibling start_auth is referenced.
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?
Schema has 0% description coverage, but description fully explains each parameter: session_id from start_auth response, code from user's browser. This adds critical meaning that the schema lacks.
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?
Description clearly states the tool finishes authentication by exchanging a browser code for a token. It identifies the specific verb and resource, and distinguishes from sibling tools like start_auth by noting the HTTP transport case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: only for stdio/CLI, not HTTP transport with OAuth. It also explains where session_id and code come from, giving clear context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully explains the tool's behavior: the input must be an exact permutation of the current pinned set, errors on invalid input, and returns a specific JSON object on success.
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?
Three sentences, front-loaded with purpose, constraints, and example output. Every sentence adds value without redundancy.
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 single-parameter tool with an output schema, the description covers the core function, input constraints, error behavior, and return format. No gaps remain for an agent to make an informed call.
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?
With 0% schema description coverage, the description compensates by explaining that task_ids must be an exact permutation and cannot have extra, missing, or duplicate IDs, adding significant meaning beyond the bare array definition.
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 ('Replace') and resource ('pinned-list ordering'), clearly distinguishing it from siblings like set_item_pinned (which adds/removes) and list_pinned_tasks (which lists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use this tool: 'To add or remove an item, use set_item_pinned first, then reorder.' It also explains error conditions (400 for invalid permutations), providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description fully discloses behavior: returns compact projection by default, option for full rows, scope limited to Tasks, and backend limitation. No hidden surprises.
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?
Well-structured with a summary, projection detail, scope note, and arg list. Could be slightly more concise, but every sentence adds value; front-loaded with the most important info.
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?
Given the presence of an output schema, the description adequately explains the return values (compact projection fields) and covers scope, limitations, and parameter semantics. No gaps for a search tool.
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?
Despite 0% schema coverage, the description provides a clear, concise explanation for each of the 7 parameters (query, status, label, from_date, to_date, parent_id, full), adding meaning 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?
Clearly states the tool does full-text search over items returning a Compact projection. It distinguishes from sibling list_items by noting the compact field set and scope limitation to Tasks only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (full-text search) and when not (non-Task kinds, recommending list_items). Also notes the backend limitation, providing clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![defernowork-mcp MCP server](https://glama.ai/mcp/servers/Circuit-Stitch/defernowork-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Circuit-Stitch/defernowork-mcp)

Score Badge

Copy to your README.md:

[![defernowork-mcp MCP server](https://glama.ai/mcp/servers/Circuit-Stitch/defernowork-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Circuit-Stitch/defernowork-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Circuit-Stitch/defernowork-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server