Personal OS MCP

by likalg

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a specific resource and action (e.g., list_tasks vs. list_notes; archive_project vs. archive_container). Subtle distinctions like restore_task (Trash recovery) vs. unarchive_task (archive restoration) are clearly documented, reducing ambiguity despite the large surface.
Naming Consistency5/5
All tools follow a strict `personal_os_<verb>_<noun>` pattern in snake_case. Verbs are consistent across resources (list, get, create, update, archive, restore, delete), and special operations like `move_task_to_trash` and `update_task_planning` retain the same predictable style.
Tool Count1/5
With 66 tools, the server is extremely heavy. The scope is broad (tasks, notes, tags, containers, projects, collections, reviews, planning), but much duplication exists—projects and collections are typed container projections with full CRUD duplication. This is a severe count that will overwhelm agents and increase misuse risk.
Completeness4/5
The lifecycle coverage for tasks, notes, tags, containers, projects, collections, and reviews is comprehensive—including create/read/update/archive/restore/delete or trash. Minor gaps exist, such as no dedicated checklist management tools (checklists are referenced in mixed feeds) and no permanent task deletion, but the core domain is well covered.
Average 3.8/5 across 66 of 66 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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 passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
The description adds minimal behavioral context beyond the annotations. It states the state change ('complete') but does not disclose what happens to the note, whether it is reversible, or any side effects. Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not elaborate on the write behavior or lifecycle implications.
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 very short and front-loaded, which is good for conciseness. However, it omits useful details and uses filler ('using the existing API lifecycle') that adds little value. It is not as damaging as verbose descriptions, but it is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-change tool with no output schema and minimal annotations, the description is incomplete. It does not clarify what 'complete' means, whether it can be undone, or what the response looks like. The sibling uncomplete_note exists, but the description does not position this tool within the note lifecycle.
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 carries the burden. It does not mention the note_id parameter at all, leaving the agent to rely solely on the schema. Although the parameter name is self-explanatory, the lack of any parameter context in the description is a gap for a 1-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Mark a Note complete'. This clearly identifies the tool's purpose and distinguishes it from siblings like uncomplete_note or complete_task. The verb 'complete' and resource 'Note' are unambiguous.
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 about when to use this tool versus alternatives. It does not mention related tools like uncomplete_note, nor does it explain prerequisites or context. The phrase 'using the existing API lifecycle' is vague and adds no actionable direction.
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?
Annotations already convey that this is a non-read-only, non-destructive, non-idempotent operation. The description adds the semantic caveat 'it is not a Checklist' and clarifies the root-level nature, which provides useful behavioral context beyond annotations, though it does not disclose details like duplicate name handling or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, and every word adds value. It avoids redundancy and clearly states the key caveat in a compact form.
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?
The tool has 3 parameters with 0% schema description coverage and no output schema, so the description must carry significant weight. It establishes the basic purpose but omits usage distinctions among sibling create tools and parameter semantics, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'name', 'sort_order', or 'description' parameters. The input schema only defines basic types and constraints, so the agent receives no semantic meaning about how these fields affect the created collection.
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 specific verb ('Create') and identifies the resource as a root-level Collection Container, making the core purpose clear. It adds a useful distinction from a Checklist, but does not explicitly differentiate from sibling create tools like create_container or create_project, which leaves some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as create_container or create_project. The phrase 'it is not a Checklist' provides an exclusion, but no checklist sibling exists, so it does not materially help with selection among the available create tools.
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?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive nature. The description adds a useful hierarchy rule ('Area organizes Projects') and allowed task containers, which goes beyond annotations. However, it does not disclose potential side effects, relationship to other entities, or naming/uniqueness constraints.
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?
Two concise sentences with no filler. The purpose is front-loaded, and the additional context is brief. Minor deduction for not explicitly naming parameters, but structure is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, no output schema, and overlapping sibling tools, the description is incomplete. It lacks details on return values, required parent relationships, and how to differentiate from create_project/create_collection. The agent would need to guess at key semantics.
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 some enum values ('Inbox, Project, Collection, Reach Out, or Someday') and implies parent-child relationships, but it does not explain the `name`, `sort_order`, `description`, or `parent_container_id` parameters. This is insufficient for 5 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 clearly states the action ('Create a Container/List') and provides useful context about container types. However, it does not explicitly distinguish this generic tool from sibling tools like create_project or create_collection, which might cause confusion about which tool to use.
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 when-to-use vs. alternatives is provided. The second sentence explains type semantics but does not guide the agent on choosing this tool over the more specific create_project/create_collection tools. Missing exclusions or alternative references.
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?
Annotations already declare the operation as read-only, idempotent, and non-destructive, so the bar is lower. The description adds the context of 'existing unified planning view,' which is a minor behavioral detail, but it does not mention pagination, sorting, or what happens if the view is empty or invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb 'List' and contains no filler words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with 2 parameters and no output schema. It does not clarify what 'mixed items' means, what the return structure looks like, or how the search parameter works. Given the existence of sibling tools like list_planning_tasks, the ambiguity could lead to incorrect tool selection.
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 compensate by explaining parameters. It indirectly references the 'view' parameter through 'planning view,' but completely ignores the 'search' parameter and its behavior. The schema enums are self-explanatory, but the description adds minimal value beyond it.
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 lists items ('List mixed items') for a planning view, using a specific verb and resource. It distinguishes from sibling tools via the word 'mixed' (implying multiple item types) versus list_planning_tasks, but could be more explicit about what item types 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like personal_os_list_planning_tasks or personal_os_list_inbox_items. The description lacks exclusions, prerequisites, or explicit alternative references, leaving the choice to the agent's inference.
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?
Annotations already indicate a non-read-only, non-idempotent operation, and the description adds context like 'pending item' and 'owned review session'. However, it does not disclose what 'skip' means in terms of state changes (e.g., whether the item remains pending, moves to a later position, or can be undone).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the verb and object, making it easy to parse.
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?
The description is too minimal for a tool with two required parameters, no output schema, and a complex domain (review sessions). It omits crucial context about the effect of skipping, preconditions (e.g., session ownership and state), and how it differs from apply_review_action, making it risky for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for parameter meaning. It does so only implicitly: 'review session' suggests session_id and 'pending item' suggests item_id, but it does not explicitly map or explain the parameters, nor does it clarify unusual schema definitions (e.g., item_id referencing session_id in 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 action ('skip') and the resource ('one pending item in an owned review session'). It is specific and unambiguous, but it does not explicitly differentiate from sibling tools like personal_os_apply_review_action, which might handle similar operations.
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. It does not mention prerequisites (e.g., session must be active) or contrast with related review actions such as apply_review_action or complete_review.
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?
Annotations already indicate a mutating, non-destructive operation. The description adds the specific behavior of archiving, but does not disclose any prerequisites, side effects, or reversibility aspects beyond 'existing lifecycle'. This adds some context but is still thin on behavioral details.
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 with no redundant words, making it concise and front-loaded. However, 'using the existing lifecycle' is somewhat abstract and may not earn its place without further explanation, slightly reducing effectiveness.
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 simple tool signature (one parameter, no output schema), the description adequately conveys the core action. Yet it lacks details on return values, required task state, and potential side effects on related items, leaving some gaps for an agent to make fully informed invocation decisions.
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 only parameter, task_id, is self-explanatory as a UUID identifier, but schema description coverage is 0% and the description does not add any meaning about the parameter, such as how to obtain it, whether it must be an active task, or any format constraints 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 action ('Complete and archive this Task') and identifies the resource ('Task'), distinguishing it from sibling tools like 'complete_note' and 'archive_task'. However, the phrase 'using the existing lifecycle' is somewhat vague and doesn't fully explain what 'complete' entails in this system.
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 completing and archiving a task, but provides no explicit when-to-use or when-not-to-use guidance. It doesn't mention alternatives such as 'reopen_task' or 'archive_task' for other lifecycle transitions, so the agent is left to infer context from the name and resource type.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, establishing that this is a non-destructive mutation. The description adds the context that the tag is 'archived,' implying a state change from archived to active, but does not disclose edge cases (e.g., behavior if already unarchived) or any side effects. This is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the core action and resource. There is no unnecessary verbosity or filler, making it optimally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is adequate but incomplete. It lacks information on return values, potential errors (e.g., tag not found or not archived), and confirmation behavior. This is a minimum viable description for a simple operation but does not reach the level of effectively complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the tag_id parameter. It does not. The description only mentions 'an archived Tag' without indicating how to specify which tag, leaving the sole parameter's meaning entirely to the schema's 'tag_id' field. This is insufficient for low-coverage situations.
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 'Restore an archived Tag' uses a specific verb ('restore') and explicitly names the resource ('Tag'), clearly distinguishing this tool from sibling restore operations for other entity types. It conveys exactly what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 restore_note or restore_container. It does not mention any prerequisites (e.g., the tag must be archived first) or exclusions, leaving the agent without contextual selection support.
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?
Annotations already signal destructive potential and non-read-only behavior. The description adds one extra note ('Source lifecycle and ownership remain API-controlled') which offers a small behavioral hint about ownership, but it is vague and does not clarify side effects like deletion or archiving. Given the annotation coverage, this is slightly above baseline but still 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?
The description is exceptionally short (two sentences) with no filler. The core action is front-loaded, and the second sentence, while cryptic, adds a governance caveat without bloating the text. It is highly concise and well-structured.
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?
The tool is complex (7 parameters, no output schema, domain-specific review actions), but the description offers minimal context. It fails to explain what a 'ReviewAction' entails, what the function returns, or how it fits into the review workflow. Given the complexity, the description is incomplete and leaves critical information to inference.
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 provides no explanation of any parameter. Terms like 'snapshot item' hint at 'item_id', but the description does not elaborate on date, time, container_id, tag_ids, or session_id. The agent must rely on the schema's minimal field names and enums, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Apply') and resource ('one existing ReviewAction to one snapshot item'), which precisely identifies the tool's function. It also distinguishes itself from sibling review tools like 'skip_review_item' or 'complete_review' by focusing on applying a single predefined action.
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 about when to use this tool versus alternatives. The description does not mention review contexts, prerequisites (e.g., starting a review), or contrast with helpful siblings like 'personal_os_skip_review_item' or 'personal_os_complete_review'. The agent must infer usage from the 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that the container 'can be restored' and that archiving happens 'under existing propagation and Inbox rules', which provides some behavioral context beyond the annotations. However, the concept of propagation is vague and not elaborated, so it offers limited 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 two short sentences, front-loaded with the action. Each sentence provides essential information: what the tool does and that it is reversible. There is no fluff or repetition, making it appropriately concise.
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 one-parameter tool with annotations, the description covers the core action and reversibility but omits details about what 'archive' means for the container's contents, how propagation affects related items, and the effect on Inbox. It is adequate but leaves room for ambiguity, especially given the lack of output schema.
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 schema has one parameter, container_id, with 0% description coverage. The tool description does not mention this parameter or explain how to obtain it. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema documentation, leaving the agent without guidance on the required input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Archive a Container') and resource, which is specific that it applies to containers. It does not explicitly contrast with other archive operations (e.g., archive_task, archive_project), but the resource is unambiguous enough to distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (archiving a container) and notes that it is reversible, hinting it is not a permanent deletion. However, it does not explicitly mention alternatives like delete_container or restore_container, nor does it explain the 'propagation and Inbox rules' that govern the operation.
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?
Annotations already indicate readOnlyHint=false, and the description adds the prerequisite of no pending items. However, it doesn't disclose what happens if called with pending items, whether the action is reversible, or the disposition of the completed review. Some context is added, but behavioral detail remains thin.
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, direct, and free of unnecessary words. It communicates the core purpose and condition efficiently.
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 one required parameter, no output schema, and a state-changing operation, the description is too terse. It fails to clarify what 'complete' means in terms of side effects, the role of session_id, or failure behavior, leaving significant gaps for an agent to fill.
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 coverage is 0% and the description never mentions session_id. The parameter name suggests it identifies a review session, but the description provides no explanation of how it is used or what value to supply, leaving the agent to guess.
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 specific verb ('Complete') with a specific resource ('review') and adds a condition ('only when no pending items remain'), distinguishing it from sibling review tools like start_review or abandon_review. It clearly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: 'only when no pending items remain.' This gives a clear precondition, though it doesn't explicitly name alternatives or describe when not to use it beyond the condition.
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 adds context beyond annotations: 'owned Container' implies an ownership prerequisite, and 'under existing hierarchy and Inbox restrictions' hints at validation constraints not captured by annotations. It also discloses partial-update semantics (only provided fields changed). Annotations already indicate non-read-only, non-idempotent, non-destructive behavior, so the description complements them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and key constraints. No extraneous words.
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?
The tool has 6 parameters and no output schema, and the description omits essential context for safe invocation: it does not explain what 'Inbox restrictions' entail, which fields are updatable via partial semantics, or how this relates to sibling update tools for projects/collections. While the schema lists names and types, the description fails to provide behavioral context needed for correct 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 mentions no parameters. The six parameters, including the required container_id and the enum type, are documented only by their schema names and types, with no added meaning from the description. This leaves the agent without semantic guidance for parameters beyond 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 a partial update action on an owned Container, with explicit mention of hierarchy and Inbox restrictions. This distinguishes it from create/archive/delete container and from update tools for other resources, though it could explicitly reference 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 implies usage when updating an existing container, but it does not explicitly state when to use this over update_project/update_collection or list before updating. It provides context about ownership and restrictions but no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description directly contradicts the annotations: it states 'It can be unarchived' (implying reversibility) while annotations mark destructiveHint=true. This is a clear contradiction, and the description fails to disclose any other behavioral traits beyond the schema, making transparency poor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences with no extraneous information. It is front-loaded with the core action and immediately adds a clarification, earning a perfect score for conciseness and structure.
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 single-parameter tool, the description covers the main action and reversibility, but this is undermined by the annotation contradiction. It does not explain what archival means in the system, nor what the outcome will be (e.g., whether the task disappears from lists). Given no output schema, some additional context would improve 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, but it never mentions the only parameter, task_id. The parameter name is self-explanatory, but the description adds no additional meaning or context about how to supply it or what values are valid, failing low-coverage requirements.
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 (archive) and the object (this Task), explicitly differentiating it from completing the task. The phrase 'without completing it' directly contrasts with the sibling tool complete_task, and 'It can be unarchived' distinguishes it from destructive actions like trash or delete.
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: use this when you want to archive (not complete) a task, and it tells the agent the action is reversible. While it does not explicitly name alternatives like unarchive_task or complete_task, the 'without completing it' exclusion and reversibility note give practical 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?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which aligns with a create operation. The description adds minor context ('plain-text', 'eligible Container') but doesn't disclose side effects, permissions, or other behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. However, terms like 'eligible' and 'complete' are vague and slightly undermine clarity, though overall it's well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is too sparse. It doesn't explain required fields, return values, or how the optional fields interact. The description alone would leave an agent under-informed about how to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate for the 9 parameters. It provides high-level groupings (Container, planning, appearance, Tag set) but omits specific parameters like in_inbox, sort_order, and planned_for_date, and doesn't clarify that body is required. This is insufficient for guiding 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 the tool creates a plain-text Note, with optional attributes like Container, planning, appearance, and Tag set. This distinguishes it from sibling tools like personal_os_create_task or personal_os_create_tag.
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 noting optional fields, but it doesn't explicitly state when to use this tool over alternatives or any exclusions. Since the tool name and description clearly indicate note creation, usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds minimal context by specifying that the response includes snapshot items, but it does not disclose error behavior, ownership requirements, or result format beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers the basic operation but lacks context on what 'snapshot items' are and how this relates to the broader review lifecycle. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter (session_id) with 0% schema description coverage. The description does not elaborate on the parameter, relying on the parameter name. It fails to compensate for the missing schema documentation.
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 (get), the resource (owned review session), and the included data (snapshot items). It distinguishes from sibling tools like list_reviews (which lists all) and get_review_summary (which returns only a summary).
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 explicit guidance on when to use this tool versus alternatives like list_reviews or get_review_summary. There is no mention of conditions, exclusions, or alternative tool preferences.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the scoping constraint 'owned,' which may imply permission boundaries, similar to adding a constraint in a getter tool. It does not add further behavioral details like return format or error handling, but annotations already cover the key safety aspects.
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 five-word sentence that communicates the essential information without any fluff. It is front-loaded with the action and resource, and every word contributes meaning, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple get-by-ID tool with one parameter, rich annotations, and no output schema. The description is adequate for basic use, but it could be more complete by explicitly stating the return value (e.g., 'Returns the Tag object for the given tag_id') and noting that the tag must be owned. Given the simplicity, it does not need much more, but there is slight room for improvement.
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 schema description coverage is 0%, so the description should compensate by explaining the parameter's meaning. It does not explicitly mention 'tag_id' or how to provide the tag identifier. While the single parameter is self-explanatory from its name and uuid format, the description adds no value beyond the schema, leaving a gap for a tool with zero schema coverage.
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 'Get one owned Tag.' clearly identifies the action (get) and resource (Tag), and the qualifier 'owned' distinguishes it from other tag operations like list_tags or create_tag. However, it is very terse and does not explicitly state that retrieval is by ID, though the schema implies it.
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 verb 'Get' and the resource 'Tag' imply a single-tag retrieval, and the sibling tools list_tags (for listing all) and create/update/delete provide contrast. However, the description offers no explicit guidance about when to use this tool versus alternatives, such as 'use this to fetch a single tag by ID; use list_tags to see all tags.'
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?
Annotations already declare the operation as read-only, open-world, idempotent, and non-destructive, so the safety profile is covered. The description adds that the feed is 'bounded' and 'mixed', providing slight behavioral context, but does not specify the bound or return format. It adds value without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose. It contains no filler, and every word serves to specify the resource and scope.
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 clearly identifies what the tool lists, but it omits any explanation of the 'search' parameter and does not describe the response shape or pagination. Given the presence of sibling list tools and the lack of an output schema, more detail would help, but the core purpose is sufficiently clear for a basic list operation.
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 input schema has one optional 'search' parameter with zero description coverage. The tool description does not mention search at all, leaving its purpose and behavior completely unspecified. The parameter's name hints at filtering, but the description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the exact resource: the bounded mixed Inbox feed containing Tasks, Notes, and Checklists. This clearly differentiates it from sibling list tools like list_tasks and list_notes by emphasizing the mixed Inbox scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for the Inbox feed and the word 'mixed' signals it returns multiple item types. However, it does not explicitly state when to use this over list_tasks or list_notes, nor does it provide exclusions or alternative tool references. The usage context is inferred from the name and resource description.
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 states the core behavior—reopening and restoring previous status—which adds context beyond the annotations that it is non-read-only, non-destructive, and non-idempotent. However, it leaves unspecified what 'previous status' resolves to, whether it validates that the task is completed, or how it handles already-open tasks. Given the annotations cover the safety profile, this is adequate but not rich.
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, focused sentence that conveys the action and result without unnecessary words. It is concise and front-loaded, exemplifying efficient structure.
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 only one parameter, no output schema, and minimal complexity, the description covers the essential behavior. It could be improved by clarifying the meaning of 'previous status' and referencing sibling restore_task, but for a simple action tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes only task_id with type and format, and the description mentions 'Task' but not the parameter explicitly. With 0% schema description coverage, the description should compensate, but the single parameter is self-evident and largely explained by the tool's name and description. No additional meaning is added, yet none is critically needed.
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: reopen a completed Task and restore its previous status. It uses a specific verb and resource, making the purpose obvious. It doesn't explicitly distinguish from sibling tools like restore_task, but the phrase 'completed Task' narrows the scope sufficiently.
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 restore_task or unarchive_task. The description implies usage for completing tasks but does not state exclusions or preferences, leaving the agent without clear decision criteria.
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?
Annotations already convey readOnly=false and idempotent=false, so the description doesn't need to state that it mutates. The added constraint 'under an owned active Area' provides useful context beyond annotations, but the description doesn't disclose what happens if the Area is not owned/active, the return value, or other behavioral traits. It adds a little value but remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence of 9 words. Every word contributes meaning, and there is no redundant or filler content. It is appropriately sized for a tool whose purpose is clear from the name.
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 4 parameters, no output schema, and no parameter descriptions, the description should provide more context (e.g., what the tool returns, error conditions, parameter roles). It only covers the core action and a prerequisite, but leaves the agent without enough information to confidently invoke the tool in varied scenarios.
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 schema has 0% description coverage, so the tool description bears full responsibility for explaining parameters. The description only references 'Area' (corresponding to area_id) but offers no explanation of 'name', 'description', or 'sort_order'. It adds some semantic context for one parameter but fails to clarify the others.
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 ('Create') and resource ('Project'), and adds a scope ('under an owned active Area'). This clearly distinguishes it from sibling tools like create_task or create_container. The capitalization of 'Project' and 'Area' reinforces the domain-specific resource types.
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 a precondition: the parent Area must be owned and active. This gives some usage context, but it doesn't explicitly state when to use this tool versus alternatives (e.g., create_container, create_collection) or mention any exclusion cases. Usage is implied rather than clearly 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?
Annotations already indicate a write operation (readOnlyHint=false), and the description adds a critical behavioral detail: providing tag_ids replaces the entire tag set rather than merging. It also specifies container ownership and activity requirements, which are not captured by annotations. This is consistent with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It states the verb and resource immediately and adds the most important constraint, making it highly efficient.
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 having 12 parameters and no output schema, the description is minimal. It omits default behaviors for status, effort, priority, and the return value. The tag replacement hint is useful, but overall the tool would benefit from significantly more context to guide 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 descriptions cover only 25% of parameters (due_at, container_id, estimated_minutes). The description adds meaning for tag_ids (replacement behavior), but does not clarify the many other optional fields like status, effort, priority, or planned_for_date. Given low schema coverage, the description fails to compensate adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and the resource ('Task'), and specifies a unique constraint about the container type ('owned active non-Area'). This distinguishes it from sibling tools like update_task or list_tasks, so the purpose is unambiguous.
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 explicit guidance on when to choose this tool over alternatives. It implies task creation but does not mention related tools for other operations or any exclusions, leaving the agent to infer usage purely from the name.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'owned' and 'plain-text' which are properties of the target note, not behavioral traits. It does not disclose return format, error behavior, or ownership verification, but the annotations mitigate the need for such detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loaded with the core action and resource. There is no redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the annotations are robust. The description is minimal but adequate for an agent to understand the basic function. However, it does not explain the return value or any prerequisites (e.g., the note must exist), leaving minor gaps. For a getter with strong annotations, a score of 3 is appropriate.
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 input schema documents one parameter, note_id, as a UUID string. The description does not mention this parameter, and schema coverage is 0%, so the description does not compensate. However, the parameter name and format are self-explanatory, and the description's 'Get one' implies selecting a specific note by ID. The schema carries the semantic burden adequately for this simple case.
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 'Get one owned plain-text Note' uses a specific verb ('Get') and resource ('Note'), and further specifies 'owned' and 'plain-text' to clarify the scope. It clearly distinguishes this from sibling tools like list_notes, create_note, and delete_note by indicating a single-note fetch 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 provides no guidance on when to use this tool versus alternatives. It does not mention that it fetches a single note by ID, nor does it direct users to list_notes for browsing. The lack of usage context makes it harder for an agent to decide between this and similar note-related tools.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds a useful constraint ('scheduled requires a date') but leaves 'authoritative planning view' undefined and says nothing about filtering, ordering, or response structure, which is beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first sentence states the core purpose, and the second adds a necessary caveat about the 'scheduled' view. Every word 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?
For a tool with an 8-value enum and no output schema, the description is too sparse. It does not explain what distinguishes this 'planning view' from the regular task list, nor does it clarify semantics of views like 'overdue' or 'unplanned'. Annotations cover safety but not domain meaning, leaving a significant gap.
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 only hints that 'scheduled requires a date', leaving the other seven enum values (today, tomorrow, someday, future, overdue, unplanned, no_due_date) unexplained and the date format/behavior unspecified. This is minimal compensation for a parameter-heavy tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Tasks') with a qualifier ('in an authoritative planning view'), which clearly distinguishes it from sibling tools like personal_os_list_tasks. It also specifies 'active Tasks', narrowing the scope further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the planning-specific list tool via 'authoritative planning view', but does not explicitly state when to use it over personal_os_list_tasks or personal_os_list_planning_items. It provides a conditional usage rule ('scheduled requires a date'), which is useful but not a full usage guide.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side-effect expectations. The description adds 'current availability' as extra context, but no deeper behavioral details. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb and resource, no wasted words. Every part contributes meaning, making it an appropriately concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and rich annotations, the description sufficiently conveys what is listed (review types) and adds nuance (current availability). No output schema exists, but return expectations are implied.
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 effectively 100%. With 0 params, the baseline for this dimension is 4; the description doesn't need to compensate for any undocumented inputs.
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 ('List') and resource ('review types'), adding 'current availability' as useful context. It doesn't explicitly distinguish from sibling list tools, but the resource name is unique enough to avoid 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, no prerequisites, and no mention of exclusion contexts. The description merely states the function, leaving usage entirely implicit.
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?
Annotations already disclose that the operation is mutating, non-idempotent, and non-destructive. The description adds the archive-vs-trash distinction, which is helpful context, but does not mention side effects, prerequisites, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences: 'Restore an archived Note. This is not Trash recovery.' Every word earns its place, and the key information is 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?
For a simple one-parameter tool, the description covers the core purpose and distinguishes from trash recovery. However, it does not clarify preconditions (e.g., the note must be archived) or behavior if the note is already active, leaving some gaps.
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%, and the description does not mention the note_id parameter at all. The parameter name is self-explanatory, but the description fails to add meaning such as 'the ID of the archived note to restore.'
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 (restore), the resource (an archived Note), and explicitly differentiates from trash recovery. This distinguishes it from related operations like restore_task or delete_note, though it doesn't name the specific alternative 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 use when you want to unarchive a note, and explicitly excludes trash recovery, providing clear context. It lacks a more comprehensive 'when-not-to-use' beyond trash, but the given guidance is sufficient for a simple tool.
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?
Annotations already indicate a non-readonly, non-idempotent mutation. The description adds context about the resource being a 'section marker' in an 'in-progress owned review session,' which is helpful. However, it does not disclose behavioral details such as whether current_section can be null, what constraints exist on section values, or side effects. The description is not contradicting annotations, but it adds limited extra 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 a single concise sentence (13 words) that is front-loaded with the action and resource. Every word contributes to the meaning without redundancy or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with two required parameters, no output schema, and no parameter descriptions, the description leaves important gaps. It does not explain what valid section values are, the effect of setting current_section to null, or what the return value might be. While the tool is simple, the description alone is insufficient for an agent to use it correctly without additional implicit knowledge.
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 'current section marker' which roughly maps to the current_section parameter, but does not explain session_id or clarify the meaning of current_section values, including the nullable option. The description provides minimal added meaning beyond the schema field 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 uses the specific verb 'Update' with a clear resource: 'the current section marker of an in-progress owned review session.' This precisely distinguishes it from sibling tools like complete_review, abandon_review, or start_review. The addition of 'in-progress owned' adds useful scope.
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 in-progress owned review sessions but does not explicitly state when to use this tool versus alternatives or mention any exclusions. It provides context ('in-progress owned') but no direct comparison with sibling tools, so while usage is implied, guidance is not explicit.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds 'permanently and irreversibly' (reinforcing destructive) and 'subject to existing Container guards' (new context). However, it does not disclose whether deletion cascades to associated tasks/notes or what happens if guards block deletion, leaving key behavioral details vague.
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 one tightly-worded sentence that includes a warning and key constraints. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) but destructive and irreversible. The description covers permanent deletion, confirmation requirement, and container guards, but does not clarify what 'Container guards' are or explain consequences for dependent data. Given the high-stakes nature, more context would be expected for full 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%, and the description does not mention project_id or add any meaning beyond the parameter name. The single parameter is self-explanatory, but the description fails to compensate for the complete lack of schema-level 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's function: 'Permanently and irreversibly delete this Project' with a specific verb and resource. It differentiates from archive operations by emphasizing irreversibility, and is distinct from delete operations on other 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 gives context on when to use this tool (for permanent deletion) and warns 'CONFIRMATION REQUIRED', but it does not explicitly mention alternatives like archive_project or specify when NOT to use it. The mention of 'existing Container guards' implies conditions but no direct comparison.
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 annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal context by noting the feed is 'bounded' and 'mixed', which hints at pagination and heterogeneous content. However, it does not disclose details about ordering, result limits, or search behavior beyond those terms.
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, focused sentence that front-loads the core action and resource. Every word contributes meaning ('bounded', 'mixed', 'Archive feed'), with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description provides the essential scope (archive, mixed types) but remains incomplete given there is no output schema and the 'search' parameter is unexplained. The presence of good annotations reduces the need for safety disclosures, but return format and filtering behavior are still unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'search' with maxLength 200, but schema description coverage is 0%. The description does not mention the 'search' parameter at all, leaving its purpose (e.g., filtering the archive feed) undocumented. Since there is no other parameter information, the description fails to compensate for the missing 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 'List' and specifies the resource: the 'bounded mixed Archive feed' containing Tasks, Notes, and Checklists. It effectively distinguishes itself from sibling tools like list_tasks and list_notes by emphasizing the archived and mixed nature.
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 retrieving archived items, but it does not explicitly state when to use this tool versus other list tools (e.g., list_inbox_items, list_planning_items). No exclusions or alternatives are mentioned, leaving the guidance to rely on the tool's name and the term 'Archive feed'.
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?
Annotations indicate a mutating operation (readOnlyHint=false) and possible side effects (openWorldHint=true). The description adds the specific state transition (completed to incomplete) but does not disclose edge cases like what happens if the note is already incomplete or if the note does not exist. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (8 words) that states the tool's purpose without any filler or redundancy. It is perfectly sized for this simple operation.
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 operation is simple with one parameter and no output schema. The description tells what it does but omits behavior for edge cases (e.g., already-incomplete note, invalid note_id) and does not mention any side effects despite openWorldHint=true. It is minimally adequate but lacks deeper context.
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% for the single parameter note_id. The description does not explicitly explain that note_id identifies the note to uncomplete, though the parameter name is self-explanatory. The description fails to 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: reverting a completed note to its incomplete state. It uses the specific verb 'Return' and identifies the resource (a completed Note). This distinguishes it from the sibling tool 'complete_note', which does the opposite.
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 context—when you want to revert a note's completion status—but it does not explicitly mention the alternative 'complete_note' or provide exclusion criteria. The context is clear but not formally 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?
Annotations already convey mutating, non-destructive, non-idempotent behavior. The description adds useful context that the operation restores visibility and is limited to manually archived tasks. It does not disclose error conditions (e.g., if the task is not archived) or other side effects, but given the simple scope and annotations, this 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 a single, front-loaded sentence with no filler. It conveys the essential action and scope in seven words, earning maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core functionality well. The main gap is the lack of distinction from the sibling restore_task, but 'manually archived' partially addresses this. Overall, it is sufficiently complete for the tool's complexity.
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 description provides no information about the task_id parameter, and schema coverage is 0% (no property descriptions). Since the schema does not explain the parameter, the description should have compensated but did not. The parameter name is self-explanatory, but the description still leaves the agent without explicit semantic guidance.
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 ('Restore'), resource ('manually archived Task'), and scope ('to active visibility'). It clearly distinguishes from archive_task and, by specifying 'manually archived', hints at a difference from restore_task (which may handle trashed tasks). This is a clear and specific statement of 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?
The phrase 'manually archived' implies this tool is for tasks previously archived via archive_task, providing some context. However, there is no explicit mention of when NOT to use it or which sibling (e.g., restore_task) should be used for other states (like trashed). Guidance is implied rather than stated.
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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds the 'owned' qualifier, which is a meaningful restriction beyond annotations, clarifying that only containers owned by the user are retrievable.
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, 'Get one owned Container/List.', with no redundant words. It communicates the purpose efficiently and is appropriately 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?
For a one-parameter get operation, the description covers the core purpose but is minimal. It does not describe return values, error behavior, or whether archived containers are included, and no output schema exists to fill the gap.
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 description does not mention container_id or explain its semantics. With 0% schema description coverage, the description fails to compensate, leaving the parameter meaning entirely to the parameter name and format uuid.
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 gets a single owned Container/List, using the specific verb 'Get' and identifying the resource. It distinguishes itself from sibling list/create/update/delete container tools by specifying 'one' and the ownership qualifier.
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 retrieving a single container by ID, but it does not explicitly contrast with list_containers or other get_* tools. There is no mention of when not to use it or alternatives, leaving the guidance at an implied level.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal beyond that, mentioning the 'existing Task detail endpoint' as implementation context but no extra behavioral traits like error handling 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the action, target, and scope without redundancy. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with strong annotations and a single parameter, the description adequately conveys what is returned (planning and due fields). It lacks explicit return format or error scenarios, but the 'planning and due fields' phrase covers the essential output, and no output schema exists to shift the burden.
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?
Only one required parameter (task_id) with zero schema description coverage. The description implies task_id identifies the task but does not add meaningful detail beyond the schema's uuid type and the word 'Task' in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Read') and resource ('one Task's current planning and due fields'), distinguishing it from general task retrieval (personal_os_get_task) and planning updates (personal_os_update_task_planning). The scope is 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?
Usage is implied: use this when you need only the planning and due fields of a single task. However, there is no explicit guidance on when not to use it or how it compares to alternatives like personal_os_get_task or personal_os_list_planning_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?
Annotations already declare this as a safe read-only operation. The description adds the 'active owned' scoping and the 'typed Container projection' context, but does not disclose additional behavior such as pagination, ordering, or return shape. With annotations covering safety, the added context is useful 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?
The description is two short sentences with no wasted words. The first sentence states the action, and the second clarifies the domain concept, ensuring every word 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?
For a simple no-param list tool with strong annotations, the description is adequate. It clearly indicates the scope (active, owned) and the type of entity. Missing details about return fields are not required given the tool's simplicity, though a bit more context could push it higher.
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 trivially complete. There are no parameter semantics to add, and the baseline for 0-parameter tools 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 it 'List active owned Projects,' using a specific verb and resource. It also distinguishes from sibling tools like list_containers by noting that a Project is a typed Container projection, making its scope unambiguous.
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 like list_containers or get_project. The purpose implies usage for retrieving active owned projects, but the description does not mention exclusions or alternatives.
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?
Annotations already indicate the operation is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds a key behavioral distinction (archive restoration vs. Trash recovery) but does not elaborate on side effects, reversibility, or state changes beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, focused, and front-loaded with the core action. Every word earns its place and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core operation and distinguishes from trash recovery. However, it does not state what happens if the project is already unarchived or in trash, nor describe the return value, leaving some gaps in operational context.
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 one parameter (project_id) with 0% description coverage, and the description does not mention or explain this parameter. The parameter name and format provide some clarity, but the description fails to compensate for the missing schema documentation, leaving the agent without additional semantic guidance.
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 ('Restore') and the resource ('archived Project'), making it unambiguous what the tool does. It also explicitly distinguishes this from Trash recovery, which adds specificity and aligns with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to restore an archived project, not for trash recovery. It offers an exclusion but does not name alternative sibling tools explicitly, so it falls short of a full 5.
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?
Annotations already indicate a mutating, non-idempotent, open-world action. The description adds the constraint that it starts/resumes one session and requires an existing ReviewType, but does not explain side effects (e.g., whether resuming overwrites prior progress, or what state changes occur). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence. Every word earns its place, with no fluff or repetition.
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 simple single-parameter schema and low complexity, the description is adequate but minimal. It does not mention return values or what a 'session' entails, even though no output schema is present. The sibling tools provide some workflow context, but the description alone leaves gaps for a stateful action.
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 explicitly explain the 'type' parameter, only implying it via 'existing ReviewType'. The enum values help, but the description does not compensate for the missing schema descriptions, leaving the semantics of 'type' mostly inferred.
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 ('Start or resume') with a clear resource ('one review session of an existing ReviewType'). It distinguishes itself from siblings like list_reviews, get_review, complete_review, and abandon_review by focusing on initiating or continuing a session.
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 implies using this tool when you want to begin or re-enter a review session, as opposed to listing/completing reviews. It doesn't name explicit alternatives, but the context is clear and no exclusions are 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?
With annotations (destructiveHint=true, readOnlyHint=false), the description adds valuable behavioral context: the collection 'disappears from active views' yet 'can be restored', explaining the material effect of the destructive action. It does not discuss additional side effects but sufficiently clarifies the core behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and containing no filler. Every word earns its place, making it an ideal length for a simple tool.
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 single-parameter, no-output-schema tool with annotations, the description is quite complete: it states the action, the immediate effect (disappears from active views), and the reversibility (can be restored). It does not address return values, errors, or side effects on related items, but these are not critical for such a simple operation.
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 one required parameter, collection_id, with schema description coverage at 0%. The description does not mention this parameter at all, so it fails to compensate for the lack of schema descriptions. While the parameter name is self-explanatory, the description adds no explicit semantic meaning, leaving a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool archives a Collection, with a specific verb ('Archive') and resource ('Collection'). It also distinguishes itself from deletion by noting 'can be restored', and from the many sibling archive tools by specifying 'this Collection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Archive this Collection') and implies reversibility, but it does not explicitly differentiate from restore/delete alternatives or provide usage context like 'use this to hide from active views instead of permanently deleting'. No explicit when-not guidance is given.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds that the result includes planning and lifecycle fields, giving some context beyond the annotations. However, it does not disclose potential edge cases like not-found errors or ownership restrictions, so it adds moderate value only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the core action and includes relevant qualification ('owned', 'planning and lifecycle fields'), making it efficient and well-structured.
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 is simple (one parameter, no output schema). The description adequately conveys what the tool does and what it returns (planning and lifecycle fields). Given the low complexity and available annotations, the description is nearly complete, though it could have mentioned the output structure or error handling explicitly.
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% (task_id has no property description). The tool description does not explain the parameter either; it only says 'Get one owned Task' without explicitly stating that task_id is the unique identifier. The parameter name is self-explanatory, but the description should have compensated for the missing schema documentation, which it does not.
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 'Get one owned Task, including its current planning and lifecycle fields' clearly identifies the verb (Get), resource (Task), and scope (owned, with planning and lifecycle fields). It distinguishes from list_tasks (which lists all) and get_task_planning (which only gets planning) by specifying what is included.
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: to fetch a single owned task by ID. It provides clear context but does not explicitly mention alternatives or exclusions, such as 'use list_tasks for all tasks'. However, the context is sufficient for an agent to select this tool over list/get siblings.
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?
Annotations already indicate a non-read-only, non-idempotent mutation. The description adds the useful distinction of archive restoration vs. trash recovery, but does not disclose effects like the collection becoming active again or preservation of contents.
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 deliver the essential message with no redundant text. The structure is straightforward 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?
For a simple one-parameter tool with annotations and no output schema, the description covers the core purpose and a key distinction. It could mention post-restore state or error conditions, but the low complexity makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only refers to 'this archived Collection', which weakly implies collection_id as the target, but does not explain how to obtain or use 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?
The description clearly states 'Restore this archived Collection', providing a specific verb and resource. It distinguishes itself from potential confusion by explicitly noting 'This is archive restoration, not Trash recovery.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: for restoring an archived Collection. It also provides an exclusion by stating it is not for Trash recovery, but does not explicitly name an alternative 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?
The description discloses a key behavioral trait beyond annotations: partial update semantics ('Only supplied fields change') and the requirement that the project be owned and active. Annotations already indicate a write operation, but the description adds meaningful context about how the update behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and clearly communicates the core behavior. Every word contributes necessary information, with no redundant phrases.
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 five parameters, zero schema documentation, no output schema, and only brief annotations, the description offers minimal contextual grounding. It does not clarify parameter usage, validation behavior, or potential error conditions, leaving the agent to infer too much 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.
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 compensate by explaining any of the five parameters (name, area_id, project_id, sort_order, description). It only generically says 'Only supplied fields change,' which adds no field-level meaning beyond what the schema property names alone convey.
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 (partially update) and target resource (a Project), and specifies that it applies to owned active Projects. This distinguishes it from sibling update tools for other resources and from project lifecycle tools like archive or delete.
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 implies the appropriate context: use this tool to modify specific fields of a project without affecting others ('Only supplied fields change'). It also sets a precondition ('owned active Project'). However, it does not explicitly name alternative tools or exclusion scenarios, so it falls short of the top 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?
The description adds useful behavioral context beyond the annotations: 'Atomically' indicates atomic update semantics, and 'Today/Tomorrow are resolved by Personal OS in the User timezone' explains how relative dates are handled. This is valuable context not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly crafted sentence that delivers both the primary purpose and a key behavioral nuance without any filler. It is well front-loaded and every word 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 5 parameters, no output schema, and 0% parameter coverage, the description is too sparse to be fully actionable. It covers atomicity and timezone resolution but omits essential details like required vs optional fields, timing constraints, or how 'scheduled' relates to due_date/due_time. The tool is relatively complex, so the description is insufficient for safe invocation without additional inference.
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 only groups parameters as 'timeline and/or due information' but does not explain individual parameters like task_id, scheduled_date, due_date, or due_time, nor their relationships (e.g., when scheduled_date is relevant). The parameter names are somewhat self-explanatory, but the description adds minimal semantic 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's function: 'Atomically update Task timeline and/or due information.' It uses a specific verb ('update') and resource ('Task timeline and/or due information'), distinguishing it from the more generic sibling 'personal_os_update_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 provides clear context for when to use this tool: when updating planning/due fields. It does not explicitly name alternatives like 'personal_os_update_task' or state when not to use it, but the scope is well-defined enough for an agent to infer appropriate usage.
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 already mark destructiveHint=true, but the description adds nuance by explaining the note 'disappears from active views but can be restored,' clarifying that archiving is not permanent destruction. This is useful behavioral context beyond the raw annotations, even if specifics like auth or effects on archives are omitted.
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, front-loaded sentences: 'Archive a Note' states the action directly, and the second explains the consequence. No wasted words, perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool with annotations and no output schema, the description covers the core effect and recoverability. It could explicitly mention restore_note, but 'can be restored' suffices. The description is complete enough for an agent to select and invoke this tool correctly.
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 single parameter note_id is not described, and schema coverage is 0%. However, the parameter name and the description 'Archive a Note' make its purpose self-evident, so the lack of compensation is not critical. The description adds no meaning beyond the schema's type/format, but the obviousness of the parameter warrants a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Archive a Note') and distinguishes itself from deletion by noting the note 'can be restored.' This clearly separates it from delete_note and clarifies its role among sibling note tools.
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 a use case (hiding a note from active views while keeping it recoverable) but does not explicitly contrast it with alternatives like delete_note or complete_note. No explicit 'when to use' or exclusion is provided, leaving the context implied.
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 already flag this as destructive; the description adds that deletion is 'permanently and irreversibly' done and 'subject to existing Container guards', providing valuable context beyond the annotations. It also notes that confirmation is required, which is not in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with 'CONFIRMATION REQUIRED', immediately conveying a critical prerequisite. Every word contributes meaning; there is no redundancy or fluff.
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 one-parameter delete tool with no output schema, the description covers the essential behavioral aspects: permanence, irreversibility, container guards, and confirmation requirement. It doesn't detail side effects on associated data or error handling, but given the tool's simplicity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (collection_id) with no description coverage. The description only refers to 'this Collection' and doesn't explicitly explain that collection_id is the identifier of the collection to delete. However, the schema provides the uuid format, and the parameter is singular and self-evident for a delete operation, so the description adds minimal but acceptable 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 the tool deletes a Collection, using a specific verb and resource. It distinguishes itself from sibling delete tools by explicitly naming the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for deleting collections, but it does not explicitly compare against alternative delete tools or provide when-to-use vs when-not-to-use guidance. It mentions 'CONFIRMATION REQUIRED' and 'Container guards' as prerequisites/constraints, but these are not alternative-selection guidelines.
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 already mark destructiveHint=true, so the destructive nature is known. The description adds valuable context: 'CONFIRMATION REQUIRED' and 'after existing child/content/Inbox guards', which explain operational safeguards beyond the annotation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with every clause adding value. It front-loads the safety warning 'CONFIRMATION REQUIRED' and concisely communicates irreversibility and guards 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?
For a simple delete tool with one parameter and strong annotations, the description is complete. It covers the destructive nature, the need for confirmation, and the existence of guards. It does not elaborate on error cases or return values, but those are not essential given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (container_id) with 0% description coverage, and the description does not explain it. However, the parameter name is self-explanatory and the schema already provides type and format (uuid). The description adds no extra semantic value for this 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: 'permanently and irreversibly delete a Container'. It uses a specific verb ('delete') and resource ('Container'), and distinguishes from related operations like archiving by emphasizing irreversibility and guards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for permanent deletion but does not explicitly compare it to alternatives such as archive_container or restore_container. The 'CONFIRMATION REQUIRED' note signals a prerequisite (user confirmation) but provides no direct when-to-use vs alternatives 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?
Annotations already indicate destructive, non-idempotent behavior. The description adds that deletion is irreversible and that pivot assignments are removed, which are meaningful side effects beyond the annotation hints. It does not contradict the annotations, though it could also mention permission requirements or broader relational impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the confirmation warning front-loaded. Every word contributes value—irreversibility and pivot assignment removal are essential facts. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter deletion tool with rich annotations, the description covers the core behavior and a key side effect. It does not explain what happens to associated tasks/notes beyond pivot assignments or describe a return value, but the absence of an output schema and the straightforward destructive nature reduce the need. The 'CONFIRMATION REQUIRED' phrase is slightly ambiguous but not misleading.
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 only parameter, tag_id, is clearly named and typed as UUID in the schema. The description's 'delete a Tag' implies the tag_id refers to the tag to delete, but it does not explicitly map it or add constraints. Since schema coverage is 0%, the description could have compensated more, but the simple self-explanatory parameter makes this acceptable.
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 ('permanently and irreversibly delete') on the specific resource ('a Tag') and explicitly distinguishes it from reversible archiving by noting irreversibility. The additional detail about pivot assignments being removed further clarifies the scope.
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 word 'permanently' implies this tool is for final deletion, suggesting archive_tag as a reversible alternative, but it does not explicitly name or contrast with sibling tools. No exclusions or prerequisites are mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds the ownership constraint but does not disclose return format or behavior on missing/unauthorized sessions. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no redundant words. It efficiently conveys the tool's 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?
For a simple read-only tool with one parameter and rich annotations, the description adequately covers the core output concept (section and action totals). It lacks details on return structure or edge cases, but this is acceptable given the tool's simplicity and the annotations provided.
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 schema only specifies a required session_id of type UUID, giving no semantic meaning. The description adds that the session must be an 'owned review session,' which provides useful context beyond the raw type. Though it doesn't explicitly name session_id, the reference is clear.
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 specifies the tool's function: retrieving section and action totals for an owned review session. The verb 'Get' and the resource 'section and action totals' are precise, and this distinguishes it from sibling tools like get_review or list_reviews which serve different purposes.
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 when summary totals for a review session are needed, but it does not provide explicit alternatives or when-not conditions. The word 'owned' offers some context on applicable sessions, but there is no comparison with other review-related tools.
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?
Annotations already declare the tool read-only and non-destructive, so the description does not need to repeat that. It adds the behavioral detail that the result set is limited to 'active owned' Collections, which is useful. However, it does not disclose any further behavior such as ordering, pagination, or the meaning of 'active'/'owned', leaving some transparency gaps beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences. The main action is front-loaded, and the second sentence provides a valuable clarifying definition without any 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?
For a simple, zero-parameter, read-only list tool, the description adequately covers the action, filters, and semantic nature. It lacks an explicit return structure, but since there is no output schema and no parameters, the description is sufficiently complete for an agent to select and invoke the tool correctly. A minor gap is not naming a sibling tool or providing integration context, but overall it is well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain any. The terms 'active' and 'owned' are fixed filters rather than parameters, and the empty schema already conveys all parameter information. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List'), a resource ('Collections'), and two scoping filters ('active', 'owned'). It also distinguishes this tool from the related 'list_containers' by clarifying that a Collection is a typed Container projection. This is a clear, differentiated 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?
The description implies the tool is for listing active owned Collections, and the phrase 'typed Container projection' hints at a distinction from raw Containers. However, it does not explicitly say when to use this tool instead of list_containers, list_projects, or other list tools, nor does it mention any exclusions or fallback 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description need not repeat safety. It adds meaningful scoping context ('active', 'owned', 'plain-text') that shapes the return set, which is valuable for an agent selecting or invoking the tool. However, it does not clarify filtering details (e.g., whether 'active' excludes completed or only archived notes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word adds meaning, with no redundant or filler content. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with rich annotations and a clear description, the context provided is largely sufficient. It omits return format details, but the name and description imply a collection of note objects. Minor ambiguity around 'active' and 'owned' could be improved, but overall the tool is straightforward and complete enough for correct selection and invocation.
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 takes zero parameters, so the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description's qualifiers (active, owned, plain-text) effectively serve as implicit input context, clarifying what will be returned without needing schema coverage.
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 'List active owned plain-text Notes' uses a specific verb (list) with a well-defined resource and qualifiers (active, owned, plain-text) that clearly distinguish it from sibling tools like list_tasks or list_archive_items. It precisely conveys what is listed and what subset is included.
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 explicit guidance on when to use this tool versus alternatives such as list_inbox_items, list_archive_items, or list_tasks. It only states the purpose without mentioning alternative tools or exclusions, leaving the agent to infer usage solely from the name and qualifiers.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope context ('owned', 'history') that clarifies the data returned, but it does not go beyond this to disclose additional behavioral details like pagination or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word is meaningful, with no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with no parameters, and annotations are strong. The description sufficiently conveys the tool's purpose and scope. Without an output schema, the agent might be uncertain about the return format, but the description is adequate for 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?
The tool has zero parameters, so the schema is trivially complete. The description adds no parameter-specific semantics because there are none; the baseline for 0 params is 4, which is appropriate due to no additional information being needed.
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 'List owned review session history' clearly states the action (List) and the resource (owned review session history). It distinguishes itself from sibling tools like list_review_types and other list_* tools by specifying 'review session history' rather than generic reviews or other object types.
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 its use case—when the user wants to see their review session history—but it does not explicitly discuss when to use it versus alternatives, nor does it mention related tools like list_review_types or get_review. No exclusions 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnly=false. The description adds valuable context that this is recoverable (soft delete), not final deletion, and requires confirmation. It also specifies only active tasks can be moved, which is a useful behavioral constraint.
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 compact sentence with an upfront confirmation warning. It conveys the key facts without 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?
For a simple single-parameter tool with no output schema, the description covers the core behavior (soft delete to Trash), recoverability, and the active-task constraint. It doesn't mention cascading effects on subtasks, but given the simplicity, this is acceptable. The absence of output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only task_id as a required UUID with no description. The description adds minimal parameter semantics by referring to 'an active Task', implying task_id identifies the task to trash, but does not explicitly document the parameter or any constraints beyond 'active'.
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 an active Task to Trash as a recoverable soft delete, using a specific verb and resource. It distinguishes from archive_task (archive vs trash) and restore_task (inverse), and clarifies it is not final deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for soft-deleting active tasks by moving them to Trash, but it does not explicitly state when to use this over archive_task or other alternatives. It does note it's not final deletion, but doesn't name alternatives or exclusions.
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?
Beyond the annotations (which indicate a write operation), the description adds valuable behavioral context: it is a partial update (PATCH-like) and tag_ids replaces the entire tag set. It also restricts the scope to 'active owned' notes. No contradiction with annotations is present. It does not disclose return values or error handling, but the provided insights exceed baseline expectations.
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, well-structured sentence. It front-loads the primary purpose and then adds a crucial detail about tag_ids behavior. There is no fluff, and every word contributes meaning. This is an example of concise, high-density documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters) and lack of output schema, the description provides a reasonable baseline: it clarifies the partial update nature and tag set replacement. However, it omits information about return values and does not elaborate on the semantics of several parameters (e.g., in_inbox, sort_order). It is adequate but leaves room for improvement in fully informing the 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%, so the description must compensate for explaining parameters. It clarifies the semantics of tag_ids (replaces the complete set) and the general 'partial update' behavior for all fields. However, most of the 10 parameters (e.g., in_inbox, sort_order, container_id) are not explained at all, leaving significant ambiguity. The description adds value only for tag_ids, which is insufficient given the low schema coverage.
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: partially update an active owned Note. It uses a specific verb ('update') and resource ('Note'), and distinguishes from sibling tools by specifying 'active owned' and the partial update semantics. This is a precise, differentiated purpose.
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 is for partially updating notes, not for creating or deleting. It also highlights a key behavior ('tag_ids replaces the complete Tag set') which is an important guideline for using the tool correctly. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true, but the description adds crucial nuance: partial update semantics ('Only supplied fields change') and the special behavior of tag_ids ('replaces the complete Tag set'). This goes beyond the structured annotation data and discloses non-obvious mutation behavior, though it does not cover potential edge cases like what happens when status is set to completed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, immediately front-loading the core purpose and then adding a key behavioral detail. Every word earns its place, with no fluff or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters, no output schema, and a complex domain (tasks, containers, planning), the description is adequate but not complete. It explains the core update semantics and tag handling, but leaves questions about field interactions (e.g., clearing fields with null, moving tasks via container_id, and lifecycle changes from status transitions). This is a minimum viable description for an API of this complexity.
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 schema description coverage at only 23% and 13 parameters, the description carries a heavy burden to explain parameter behaviors. It only clarifies tag_ids replacement, leaving ambiguous distinctions like due_at vs. due_date vs. planned_for_date, and the exact semantics of fields like sort_order or container_id. The description does not sufficiently compensate for the low schema coverage, so a 2 is warranted.
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: 'Partially update one owned active Task.' It uses a specific verb ('update') and resource ('Task'), and distinguishes itself from siblings by emphasizing 'one' (vs. bulk) and 'owned active' (vs. archived or unowned). The additional note about tag_ids replacing the complete set further clarifies the exact behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: for updating a single owned active Task, and that only supplied fields change (partial update). It implicitly distinguishes from bulk_update_tasks by 'one' and from update_task_planning by focusing on general task fields. However, it does not explicitly mention when NOT to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds non-obvious behaviors not covered by annotations: the default limit of 100 and maximum of 200, and the fact that duration filters are in total minutes with exact/range matching. These are valuable behavioral details that help the agent predict results.
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 three sentences, front-loaded with the core purpose. The second sentence gives limit behavior, and the third provides detailed filter semantics with examples. No extraneous content; 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 11 parameters and no output schema, the description leaves gaps: it does not clarify whether filters combine with AND, what 'search' targets, or the distinction between state and status. It covers the most complex aspect (duration filters) but does not fully round out the tool's behavior, making it moderately complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 27% (3 of 11 parameters have descriptions), so the description must compensate. It does explain the three duration-related parameters with concrete examples, and the default limit is not in the schema. However, other parameters like state vs status, search scope, and planned_for_date are not elaborated, so the compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List owned Tasks using only supported filters,' clearly specifying the verb (List), resource (owned Tasks), and scope (supported filters). It distinguishes the tool from siblings like personal_os_get_task (single task retrieval) and tools for other resource types. The mention of ownership adds precision beyond the title.
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 context on when to use this tool: to list owned tasks with a defined set of filters. It also gives operational details like default/max limits and duration filter semantics. However, it does not explicitly name alternative tools (e.g., get_task for a single task) or state when NOT to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds valuable behavioral details: 'history is retained' clarifies that the action is not fully destructive, and 'CONFIRMATION REQUIRED' warns of an extra step. These are useful context the annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the confirmation warning. Every word serves a purpose: 'Abandon' states the action, 'in-progress review session' specifies the target, and 'history is retained' clarifies the side effect. No filler or 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 is simple (one parameter, no output schema), and the description covers the essential purpose and behavioral traits. It could mention the outcome state (e.g., whether the session is marked abandoned) or error conditions, but given the low complexity and the presence of sibling tools for related actions, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate for the parameter. The phrase 'review session' implies that session_id refers to the review session being abandoned, but it does not explicitly state that session_id is the identifier to use. Given the parameter name and format, the meaning is mostly inferable, but the description adds only marginal semantic 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 'Abandon' with a clear resource 'an in-progress review session', and explicitly distinguishes the action from completing or deleting by adding 'history is retained.' This makes the tool's purpose unmistakable, especially alongside sibling tools like complete_review and start_review.
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 context: it is for abandoning an in-progress review session, implying it should be used when you want to stop without completing. The 'history is retained' note adds important usage context. However, it does not explicitly mention alternatives like complete_review or state 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?
Annotations already flag this as destructive (destructiveHint=true), and the description adds valuable context that the action is not permanent ('can be restored') and hides the project from active views. This goes beyond the annotations by clarifying the reversible nature of the operation, without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately state the action and its consequence. Every word adds value with no redundancy or filler, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and annotations covering safety, the description fully explains the operation and its effect. It conveys both the immediate action and the reversibility, making it complete for the tool's complexity.
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 description does not mention the project_id parameter at all, and the schema description coverage is 0%. While the parameter name is self-explanatory, the description fails to explain how to identify the project or that a valid ID must be passed, providing no added 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?
The description uses the specific verb 'Archive' with the resource 'Project', clearly stating the action and its effect: 'It disappears from active views but can be restored.' This distinguishes it from sibling tools like delete_project (permanent) and archive_task (different resource).
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 context for when to use this tool: to hide a project from active views while retaining the ability to restore it. It does not explicitly exclude alternatives or name them, but the 'can be restored' phrase differentiates from deletion, giving a clear implication of use cases.
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?
The description discloses critical behavioral traits beyond annotations: atomicity with full rollback on any failure, and a mandatory confirmation requirement. These add significant context not available from the destructiveHint/readOnlyHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that front-load the confirmation requirement and then state the atomic behavior. Every word earns its place, with no filler.
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 most important safety and atomicity aspects but omits what happens on success (e.g., return value) and does not mention the variety of fields that can be updated. The rich schema partially compensates, but the tool's complexity warrants a bit more guidance.
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 schema has only one top-level parameter ('tasks'), but the description does not explain the structure or fields of each task object. With 0% schema description coverage for the top-level, the description should compensate but only says 'Tasks', leaving field semantics to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Atomically update 1-100 Tasks'. It clearly distinguishes from the singular sibling tool 'personal_os_update_task' by emphasizing batch size and atomicity.
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 context: use for bulk updates (1-100 tasks) and requires confirmation. However, it does not explicitly name the alternative for single-task updates or mention 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?
The description discloses normalization and the duplicate equivalence rule, which goes beyond the annotations. However, it does not specify whether a duplicate attempt errors, returns the existing tag, or creates a new record, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover the essential purpose and key duplicate rule without any redundant or distracting information. Every word 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?
For a simple CRUD create tool, it is quite complete: it specifies creation, optional fields, and the normalization/duplicate behavior. The only notable gap is the lack of return-value information and precise duplicate-handling behavior, but these are not critical for a tool of this simplicity.
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 lists all parameters (name, description, emoji, color) and notes that the last three are optional. With 0% schema description coverage, it partially compensates, but it adds no deeper meaning beyond what the schema already provides (e.g., formats or purpose of color/emoji).
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 ('Create'), the resource ('Tag'), and key optional attributes (description, emoji, color). The phrase 'normalized owner-scoped' adds specificity and distinguishes it from sibling tools like update_tag or delete_tag.
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?
While it doesn't explicitly name alternatives, the create verb and the duplicate rule ('Case/whitespace-equivalent names are duplicates') imply that agents should check for existing tags before creating to avoid duplicates. This provides clear context without formal exclusions.
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 already mark destructiveHint=true and readOnlyHint=false. The description adds valuable context: deletion is permanent, irreversible, and notes bypass trash (unlike tasks). This goes beyond raw annotations but doesn't cover other potential behaviors like side effects on related items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loaded with 'CONFIRMATION REQUIRED' and packed with all essential info. No wasted words, perfectly sized for the operation.
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 one-parameter destructive tool with strong annotations and no output schema, the description covers the key points: permanence, irreversibility, no trash. It doesn't address error cases or preconditions, but those are less critical given the simple scope.
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?
Only one parameter (note_id, uuid) exists, and the schema is self-explanatory. The description doesn't mention it explicitly, but 'this Note' ties it to the resource. With 0% schema coverage, the description adds no extra meaning, though the simplicity of the parameter makes this acceptable.
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 this Note') with specific scope ('Note'), and emphasizes 'Permanently and irreversibly' plus 'Notes do not use Trash', distinguishing it from archive/restore and trash-related tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: notes have no trash, so this is the permanent deletion path. It doesn't explicitly name alternatives like 'archive_note' for recoverable removal, but the no-trash statement strongly implies when to use vs avoid. Minor lack of explicit exclusions.
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 already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is covered. The description adds meaningful behavioral context beyond annotations by specifying that 'a foreign or wrong-typed Container is returned as not found', disclosing an important edge case and access-control constraint. This is valuable supplementary information.
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, well-structured sentence that leads with the main action and then adds a concise edge-case clarification. Every word contributes to the meaning, with no redundancy 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 low complexity (one parameter, no output schema, clear annotations), the description provides sufficient context: it states what the tool does, the owning constraint, and the not-found behavior for foreign/wrong-typed containers. It does not mention the return format, but for a simple get operation this is not a significant omission.
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 is the primary source for parameter meaning. Although it does not explicitly state 'collection_id is the UUID of the collection to retrieve', the tool name and singular parameter make it clear. The 'owned' and 'wrong-typed' constraints add semantic context about acceptable IDs, providing some compensation 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 a specific verb and resource: 'Get one owned Collection'. The edge case 'a foreign or wrong-typed Container is returned as not found' distinguishes this from sibling getters like get_container and get_project, clarifying that it only retrieves owned collections. This is a precise and unambiguous purpose.
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 context: it is for retrieving a single owned collection by ID, and explicitly warns that foreign or wrong-typed containers will result in a not-found response, indicating when not to use it. However, it does not explicitly name alternative tools like get_container for those other types, so it lacks a direct exclusion statement.
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 already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context: foreign or wrong-typed IDs are returned as not found rather than raising errors, and ownership is part of lookup semantics.
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 concise sentence with a semicolon-separated addition, front-loaded with the core action and no filler. Every word adds meaning.
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 single-parameter getter with strong annotations, the description covers purpose, ownership scope, and the not-found edge case. No output schema exists, but the implication that the Project object is returned is sufficient for a getter.
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. While 'owned Project' and 'wrong-typed Container' provide some semantic context for the project_id parameter, the description does not explicitly explain the parameter's UUID format or that it identifies the project to retrieve; the schema's field name and format carry most of that burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'Project' and scope 'owned', clearly distinguishing it from list operations and from get_container/get_task siblings. The added note about foreign/wrong-typed Containers being treated as not found further clarifies what this tool does not return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states this is for retrieving a single owned Project by ID, and the 'wrong-typed Container' note signals it is not appropriate for Container IDs. It does not explicitly name alternatives like list_projects or get_container, but the usage context is evident.
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 already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds context by reassuring that no sensitive data is exposed and that the check is for the authenticated API. This goes beyond the annotations and provides useful behavioral insight.
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, information-dense sentence with no redundancy. It front-loads the primary action and adds a concise privacy qualifier. Every word 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?
For a parameterless health-check tool with no output schema, the description covers the essential purpose and a key behavioral guarantee. It does not detail the response format, but that is arguably unnecessary for such a simple tool. The description is sufficient given the tool's simplicity and rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. With no parameters to document, the baseline is 4 per the guidelines. The description does not need to add parameter semantics, and it does not attempt to.
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 ('check') and resource ('API availability'), making the tool's purpose immediately clear. It is unambiguous and distinct from sibling tools, which are all CRUD operations on entities. The phrase 'without exposing sensitive data' further clarifies the safety scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to verify API availability, likely before other operations, but does not explicitly state when to use it versus alternatives. No exclusions or alternative tool references are provided. The intended usage is inferable from the context but not explicitly stated.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable context by specifying the 'active owned' filter and 'normalized display order', which are not derivable from annotations. It does not contradict annotations and provides sufficient behavioral detail for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and conveys scope and ordering without any wasted words. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with rich annotations, the description covers the key behavioral aspects (active, owned, order). No output schema exists, so return format details are not required. The description is complete enough for its simplicity, though it could theoretically mention that it returns a list of tag objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so parameter semantics are not applicable. The description adds meaning by explaining the default filtering and ordering behavior (active, owned, normalized display order), which goes beyond the empty schema. This aligns with the baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with resource 'Tags' and specifies scope 'active owned' and ordering 'normalized display order', distinguishing it from sibling listing tools like list_notes and list_tasks. This is a specific and unambiguous 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?
The description implies usage for viewing active owned tags but provides no explicit guidance on when to use it vs alternatives. It does not mention exclusions (e.g., archived tags) or reference sibling tools, so only implied usage is present.
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 already convey the write/not-destructive nature, so the description adds value by disclosing that children are also restored ('applicable children'). This goes beyond the annotations, though the term 'applicable' is somewhat vague and could be more explicit about recursion or scope.
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 seven words, front-loaded with the verb and resource. It contains zero filler and conveys the essential action and scope, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with annotations and no output schema, the description is largely complete. It states the action and scope (children restoration) but leaves 'applicable' undefined, which could be clarified further. However, the core usage is clear and no major operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (container_id) with no description, so the description must compensate. It does not explicitly name container_id but the context ('Restore an archived Container') clearly implies the parameter is the container's identifier. The schema provides format (uuid), so the parameter is not ambiguous. The description adds the 'applicable children' nuance but not directly about the 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 restores an archived Container and its applicable children, using a specific verb ('Restore') and resource ('Container'). It distinguishes from sibling restore tools targeting other entity types (e.g., restore_task, restore_collection) and from container operations like archive_container or delete_container.
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 use when a Container is archived and needs to be restored. It does not explicitly mention alternatives or exclusions, but the resource-specific wording and the 'archived' qualifier provide clear context. The lack of explicit alternatives is mitigated by the unambiguous entity focus.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, and the description adds the Trash-recovery context and ownership scope, which is useful. It does not disclose edge-case behavior (e.g., what happens if the task is not in trash) or permission requirements, but the annotation coverage reduces the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and resource, and the second sentence provides a crucial distinction without redundancy. Every word 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?
For a simple action with one parameter and no output schema, the description sufficiently conveys the tool's purpose and domain. It could mention error conditions (e.g., task not in trash) or return format, but the explicit 'from Trash' and annotations make it reasonably 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 single parameter task_id is self-evident from the tool name and description. The description's 'owned Task' adds a semantic constraint (the task must be owned) beyond the schema's type/format, providing meaningful context. With only one parameter, this is sufficient.
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 states 'Restore an owned Task from Trash' with a specific verb, resource, and scope. It explicitly distinguishes from archive restoration ('This is Trash recovery, not archive restoration.'), clearly differentiating from sibling tools like unarchive_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 gives clear context (Trash recovery) and an explicit exclusion (not archive restoration), which helps the agent choose this over unarchive_task. However, it does not fully elaborate on when to use it or mention alternatives for other resource types, though the name pattern and sibling list make those implicit.
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation nature is disclosed externally. The description adds that only partial updates are performed (not full replacement) and that the tag must be owned and active, but does not explain side effects, failure modes, or return behavior. This is moderate context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately identifies the action and object. Every word adds meaning—'partially', 'owned active', 'including its optional description'—with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple partial-update tool with 5 parameters (1 required), no output schema, and annotations already indicating mutation/non-destructive behavior, the description covers the core purpose and key constraints. It doesn't address error handling or permission failures, but the basic usage context is sufficiently 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?
With 0% schema description coverage, the description carries more weight. 'Partially update' conveys that only provided fields are changed, which is essential semantics for the tag_id required parameter. It also explicitly calls out description as optional. However, it does not elaborate on name, color, or emoji semantics beyond what the schema types already define, so it doesn't fully compensate for the lack of param-level 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's function with a specific verb ('update') and resource ('Tag'), and adds constraints ('owned active') and scope ('partially') that distinguish it from sibling update tools (e.g., personal_os_update_task, personal_os_update_container). It also mentions the optional description field, leaving no ambiguity about what can be modified.
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 context: use this to modify an existing, owned, active tag rather than creating, archiving, or deleting one. It does not explicitly name alternative tools or provide when-not-to-use guidance, but the 'partially update' and 'owned active' constraints give clear boundary conditions.
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 already declare read-only, idempotent, and non-destructive behavior. The description adds value by disclosing that only 'owned' containers are returned and that the result is a hierarchy grouped into specific categories. This goes beyond annotation hints, though it doesn't detail response format 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 a single sentence, perfectly concise and front-loaded with the action and resource. Every word contributes meaningful context, and there is no redundancy 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?
For a parameterless, read-only list tool, the description adequately conveys the key behavior: returning an owned, hierarchical container structure grouped by the specified categories. It lacks an output schema, so a bit more detail about the return shape could be useful, but the low complexity and annotations cover most gaps.
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 and schema coverage is 100% (vacuously). The description adds no parameter-specific semantics, but with no parameters, there is nothing to explain. The baseline of 4 for zero-parameter tools 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 tool's function: listing the owned Container hierarchy. It specifies the exact grouping categories, which distinguishes it from sibling list tools like personal_os_list_tasks or personal_os_list_projects. The verb 'List' and resource 'Container hierarchy' are 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to view container hierarchies in a particular grouping). It does not explicitly mention alternatives or exclusions, but the grouping details make the intended use obvious. The lack of explicit 'use this instead of X' guidance prevents a perfect 5.
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?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful PATCH semantics: only supplied fields are changed, which prevents agents from assuming full-object replacement. It also discloses the 'owned active' constraint, which is not apparent from the schema. It does not describe return values or error behavior, but the annotations already cover safety as non-destructive and writable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the operation and its key semantic. No filler or redundant repetition of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple PATCH operation with four flat parameters and no output schema, the description supplies the essential context (partial update, ownership/status requirement). It does not mention what the response contains, but the tool is straightforward and the annotations cover the write/non-destructive nature. Slightly more detail about return values could push it to 5, but 4 is appropriate given the low 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 description coverage is 0%, so the description must compensate. The statement 'Only supplied fields change' is essential for interpreting the optional parameters (name, sort_order, description): omitting them means leave unchanged. This is not inferable from the schema alone. The parameter names are self-explanatory, so no further per-field elaboration is needed.
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') and the resource ('owned active Collection'), and adds the critical distinction of 'Partially update' and 'Only supplied fields change'. This separates it from other update tools by specifying the partial/PATCH behavior and the ownership/status precondition.
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 phrase 'Partially update an owned active Collection' gives clear context for when to use this tool: when you need to modify fields on a collection without replacing the entire object. However, it does not explicitly mention alternatives like 'archive_collection' for state changes or 'create_collection' for new collections, so it lacks explicit exclusions.
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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds value by specifying the content scope (enums, filters, actions, limits, lifecycle capabilities), which goes beyond what annotations provide. No contradiction exists.
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, front-loaded with the verb 'Read,' and enumerates the content without any filler or redundant wording. Every word earns its place.
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 low complexity (0 parameters, no output schema) and strong annotations, the description is complete. It clearly states what the tool reads and the categories of information it returns, leaving no significant gaps for an agent to misinterpret.
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, so the baseline is 4. The description does not need to explain parameter semantics, and it correctly adds no irrelevant parameter 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 uses a specific verb 'Read' and identifies a clear resource: the authoritative enums, filters, actions, limits, and lifecycle capabilities of Personal OS. This distinguishes it from sibling tools that operate on tasks, notes, tags, etc., making the tool's purpose immediately 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 clearly communicates that this tool is the authoritative source for capabilities, implying it should be used to discover valid enums and actions before calling other tools. However, it does not explicitly state when not to use it or name alternatives, though the context makes the use case obvious.
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?
Annotations mark the operation as destructive, but the description adds critical behavioral nuance: it preserves existing associations and is restorable. This clarifies that the destructive hint does not mean permanent data loss or broken relationships, providing value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one succinct sentence of 10 words, front-loaded with the verb and resource, with no unnecessary content. Every word 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?
For a single-parameter archive operation, the description covers the core action, the association-preserving guarantee, and reversibility, which is sufficient. It does not address edge cases like re-archiving an already archived tag or the tag's visibility after archiving, but these are minor gaps.
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 schema has a single tag_id parameter with no description. The description's 'Archive a Tag' makes it evident that tag_id identifies the tag to archive, and the parameter name is self-explanatory, so the description adequately compensates for the 0% schema description coverage.
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 specifies the action ('Archive'), the resource ('a Tag'), and a key distinguishing feature ('preserving existing associations'). It also notes reversibility, differentiating it from delete_tag and other archive operations on different entity 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 when to use this tool: when you need to archive a tag without severing its links and may want to restore it later. It provides context but does not explicitly name alternatives like delete_tag or restore_tag, nor mention prerequisites such as the tag existing.
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:

[![personal-os-mcp MCP server](https://glama.ai/mcp/servers/likalg/personal-os-mcp/badges/card.svg)](https://glama.ai/mcp/servers/likalg/personal-os-mcp)

Score Badge

Copy to your README.md:

[![personal-os-mcp MCP server](https://glama.ai/mcp/servers/likalg/personal-os-mcp/badges/score.svg)](https://glama.ai/mcp/servers/likalg/personal-os-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/likalg/personal-os-mcp'

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