reclaim-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (tasks, habits, events, focus blocks) with clear action verbs, but some overlap exists between list_events and list_personal_events (both list events) and between mark_habit_done/skip_habit (both modify habit instances). Descriptions help clarify differences, but an agent might occasionally confuse these pairs.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, using snake_case exclusively (e.g., create_task, list_habits, update_focus_settings). The pattern is predictable with verbs like create, get, list, update, delete, mark, start, stop, lock, unlock, reschedule, prioritize, restart, skip, enable, disable, and verify, making the set easy to navigate.
Tool Count3/5
With 32 tools, the count feels heavy for a task/habit/calendar management server, bordering on excessive. While the domain is broad (covering tasks, habits, events, focus time, analytics, and settings), some tools could potentially be consolidated (e.g., mark_habit_done and skip_habit), making the surface more complex than necessary for typical agent workflows.
Completeness5/5
The tool set provides comprehensive CRUD/lifecycle coverage for all core domains: tasks (create, get, list, update, delete, complete, restart, prioritize, start, stop, add_time), habits (create, get, list, update, delete, enable, disable, mark_done, skip), events (list, get), focus blocks (lock, unlock, reschedule, update_settings), and analytics (user, focus). No obvious gaps exist, enabling full agent interaction with Reclaim.ai's features.
Average 3.4/5 across 32 of 32 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 15 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it deletes a habit and returns True on success. It doesn't disclose critical behavioral traits like whether deletion is permanent, requires specific permissions, has side effects (e.g., on related tasks), or error conditions, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action ('Delete a smart habit') and uses a structured Args/Returns format efficiently. However, the Args section repeats the parameter name without adding meaningful semantics, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 1 parameter) and no annotations, the description is incomplete: it lacks behavioral details, usage context, and parameter explanation. The presence of an output schema mitigates this by documenting the return value, but overall coverage remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the input schema: it names the parameter ('lineage_id') and specifies it's for deletion, but doesn't explain what a 'lineage_id' is, how to obtain it, or its format. With 0% schema description coverage, this partial compensation is inadequate for full clarity, warranting a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a smart habit'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling 'delete_task' or explain what makes a 'smart habit' different from other deletable entities, missing full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'disable_habit' or 'delete_task'. The description lacks context about prerequisites (e.g., whether the habit must exist or be active) or consequences, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a deletion operation, implying it's destructive, but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has side effects on related data, or includes rate limits. The description is minimal and lacks crucial context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. It's efficient with no wasted words, though the lack of usage context slightly reduces its 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 tool's destructive nature, no annotations, and an output schema (implied by 'Returns: True if deleted successfully'), the description is minimally adequate. It covers the basic operation and parameter, but for a deletion tool, it should include more about consequences, alternatives, and error handling to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds basic semantics by explaining 'task_id' as 'The task ID to delete', which clarifies the parameter's purpose. However, it doesn't provide format details, validation rules, or examples, leaving gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a task from Reclaim.ai'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'delete_habit' or explain why one would delete a task versus other task-related operations like 'mark_task_complete' or 'stop_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'delete_habit', 'mark_task_complete', and 'stop_task', there's no indication of when deletion is appropriate versus completion or stopping, nor any prerequisites or constraints mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions the tool lists events but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination behavior (beyond the limit parameter), or whether it's a read-only operation. The description is minimal on behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose statement followed by Args and Returns sections. The description is appropriately sized with no redundant information, though the Args section could be slightly more detailed given the 0% schema coverage.
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 3 parameters with 0% schema coverage and no annotations, the description provides basic parameter info and mentions the return type. However, it lacks details on authentication, error handling, and behavioral constraints. The existence of an output schema helps, but the description could be more complete for a list operation with filtering parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides basic semantics for all three parameters (start/end as datetime filters, limit as maximum return count) and mentions the default for limit. However, it doesn't explain format details beyond 'ISO format' or constraints like valid ranges, which leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'Reclaim-managed personal events', specifying the types (tasks, habits, focus time). It distinguishes from general 'list_events' by focusing on personal events, but doesn't explicitly differentiate from 'list_tasks' or 'list_habits' which are more specific siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_tasks', 'list_habits', or 'list_events'. The description mentions it lists personal events but doesn't clarify when this broader view is preferable to the more specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action 'mark as complete' but doesn't mention side effects (e.g., if completion triggers notifications or updates analytics), permissions required, or error conditions. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured Args and Returns sections. It's efficient with minimal waste, though the Returns section could be more informative given the output schema exists.
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 a mutation tool with no annotations, 0% schema coverage, but an output schema, the description is partially complete. It covers the basic action and parameter, but lacks behavioral context and usage guidance, making it adequate but with clear gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'task_id' identifies the task to mark as complete, but doesn't explain format constraints or provide examples. Since there's only one parameter, the baseline is 4, but the lack of detail beyond basic identification reduces it to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'mark as complete' and the resource 'task', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'update_task' or 'restart_task', which might also modify task status, so it misses full sibling distinction.
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 'update_task' (which might allow status changes) or 'restart_task' (which could reset completion). The description lacks context about prerequisites or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool reschedules a focus block and mentions optional parameters trigger AI rescheduling, but lacks critical details: whether this requires specific permissions, if changes are reversible, potential rate limits, or what happens to overlapping events. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose; every sentence earns its place by clarifying parameters and output, though the AI reschedule note could be more 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?
Given the tool's moderate complexity (4 parameters, mutation operation) and no annotations but an output schema, the description is partially complete. It explains parameters and mentions the return type, but lacks behavioral context (e.g., permissions, effects) and doesn't fully leverage the output schema to detail the 'Planner action result' structure, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'calendar_id' contains the focus block, 'event_id' identifies it, and optional 'start_time'/'end_time' use ISO format with AI fallback. However, it doesn't clarify parameter interactions (e.g., if both times are null) or provide examples, leaving some semantic gaps despite covering all 4 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 tool's purpose with a specific verb ('reschedule') and resource ('focus time block'), and distinguishes it from siblings like 'lock_focus_block' or 'unlock_focus_block' by focusing on time adjustment rather than access control. However, it doesn't explicitly differentiate from other time-related tools like 'add_time_to_task' or 'update_task', which could involve similar time management concepts.
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 doesn't mention prerequisites (e.g., needing an existing focus block), exclusions (e.g., not for non-focus events), or comparisons to siblings like 'update_task' or 'lock_focus_block' that might handle related time adjustments. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool marks a task as IN_PROGRESS and starts a timer, which implies mutation and state change, but doesn't disclose critical behavioral traits like permissions needed, whether it's idempotent, error conditions (e.g., if task is already in progress), or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured clearly, though the return description could be more specific. There's minimal waste, but slight room for improvement in brevity.
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 one parameter with 0% schema coverage and an output schema exists (which covers return values), the description is partially complete. It explains the basic action and parameter, but lacks behavioral details (e.g., side effects, errors) and usage guidelines, making it adequate but with clear gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds that 'task_id' is 'The task ID to start working on', providing basic meaning beyond the schema's type (integer). However, it doesn't explain format constraints (e.g., valid ID ranges) or examples, leaving gaps. With one parameter, this is minimally adequate but not comprehensive.
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 ('Start working on a task') and specifies the effect ('marks as IN_PROGRESS and starts timer'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'restart_task' or 'stop_task', which prevents a perfect score.
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 doesn't mention prerequisites (e.g., task must exist and not already be in progress), exclusions, or comparisons to similar tools like 'restart_task', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a write operation ('Log time') but doesn't disclose behavioral traits like authentication needs, rate limits, whether time logging is reversible, or how it affects task status. The description adds minimal context beyond the basic action.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose for a simple tool. Every sentence adds value, though the 'Returns' line could be more concise given the output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 3 parameters with 0% schema coverage, and an output schema present, the description is minimally adequate. It covers the basic action and parameters but lacks behavioral context for a mutation tool. The output schema reduces the need to explain return values, but more guidance on usage and constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all three parameters: 'task_id' identifies the task, 'minutes' specifies duration, and 'notes' adds optional context. This adds significant value beyond the bare schema types, though it doesn't detail constraints like valid minute ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Log time spent') and resource ('on a task'), specifying it uses Reclaim's planner API. It distinguishes from siblings like 'start_task' or 'stop_task' by focusing on time logging rather than task lifecycle management. However, it doesn't explicitly differentiate from all possible time-related operations in the sibling set.
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 doesn't mention prerequisites (e.g., task must exist), exclusions, or compare with similar tools like 'mark_task_complete' or 'update_task' that might also track time. Usage is implied only by the tool name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool enables a habit and returns an empty dict on success, but lacks critical behavioral details: whether this requires specific permissions, if it's idempotent, what happens if the habit isn't disabled, or any side effects like notifications. The description is minimal and leaves key behaviors unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place, though the 'Args' and 'Returns' labels are slightly redundant given the structured schema fields.
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 moderate complexity (a mutation with no annotations) and the presence of an output schema (implied by 'Returns: Empty dict on success'), the description is partially complete. It covers the basic purpose and parameter meaning but lacks behavioral context and usage guidelines, making it adequate but with clear gaps for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'lineage_id' by specifying it's 'The habit lineage ID to enable'. With 0% schema description coverage and only one parameter, this compensates adequately by explaining what the parameter represents, though it doesn't detail format or constraints beyond the type.
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 ('enable a disabled habit') and the outcome ('to resume scheduling'), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'disable_habit' or 'update_habit' beyond the obvious opposite 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the habit must be disabled), exclusions, or comparisons with sibling tools like 'disable_habit' or 'update_habit' that might affect habit status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns analytics and recommendations, but doesn't specify whether this is a read-only operation, requires authentication, has rate limits, or details about the response format beyond a vague list. This is a significant gap for a tool that likely involves data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by 'Args' and 'Returns' sections. Every sentence adds value, though the 'Returns' section could be slightly more detailed. It's front-loaded with the core functionality.
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 (analytics retrieval with 2 parameters), no annotations, and an output schema present, the description is moderately complete. It covers the purpose and parameters well, but lacks behavioral context and usage guidelines. The output schema likely handles return values, so the description's vagueness there is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'start' and 'end' are dates in ISO format and provides examples (e.g., '2026-01-01'), clarifying the parameter usage effectively. With 2 parameters and no schema descriptions, this compensation is adequate.
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's purpose as 'Get focus time insights and recommendations,' which specifies the verb ('Get') and resource ('focus time insights and recommendations'). It distinguishes from most siblings that deal with tasks, habits, or events, though it doesn't explicitly differentiate from 'get_user_analytics' which might overlap in analytics scope.
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 doesn't mention when to prefer it over 'get_user_analytics' or other analytics-related tools, nor does it specify prerequisites or context for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format ('List of habit objects with lineageId, title, enabled, recurrence, etc.'), which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a list operation with no parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and one describing the return. It is front-loaded with the main action. However, the second sentence could be more structured (e.g., using a bullet list for clarity), and some minor verbosity exists in 'etc.'
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 has 0 parameters, an output schema exists, and no annotations, the description is moderately complete. It covers the purpose and return values, but lacks context on usage scenarios, behavioral traits like data freshness or limitations, and sibling differentiation, which could enhance completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is appropriate given the schema completeness. A baseline of 4 is assigned as it meets the requirement without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('smart habits from Reclaim.ai'), making the purpose explicit. However, it does not distinguish this tool from sibling list tools like 'list_tasks' or 'list_events', which would require mentioning specific characteristics of habits versus 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 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. For example, it does not clarify if this is for retrieving all habits versus filtered subsets, or how it differs from other list operations in the sibling set. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'elevates to high priority' and 'triggers rescheduling', implying mutation, but doesn't disclose permissions, side effects, or whether changes are reversible. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose in the first sentence, followed by structured 'Args' and 'Returns' sections. Every sentence earns its place with no wasted words, making it efficient 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 a mutation tool with no annotations, 1 parameter, and an output schema (which covers return values), the description is partially complete. It explains the action and parameter but lacks behavioral details like side effects or error conditions, making it minimally adequate.
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%, but the description adds value by explaining 'task_id' as 'The task ID to prioritize'. However, with only 1 parameter, the baseline is 4, but it doesn't fully compensate for the lack of schema details, such as format or constraints, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('prioritize') and resource ('a task'), specifying it elevates to high priority and triggers rescheduling. However, it doesn't explicitly differentiate from siblings like 'update_task' which might also affect priority, leaving 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?
No guidance is provided on when to use this tool versus alternatives like 'update_task' or 'restart_task', which might also affect task priority or scheduling. The description lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it correctly identifies this as an update operation, it fails to mention important behavioral aspects such as required permissions, whether changes are reversible, error conditions, or how partial updates are handled. The description is minimal and lacks crucial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for 'Args' and 'Returns', making it easy to parse. While it's somewhat lengthy due to the 11 parameters, every sentence adds value by explaining parameter purposes and formats. The front-loaded purpose statement is clear, though the parameter section dominates the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, mutation operation) and absence of annotations, the description does a good job explaining parameters but falls short on behavioral context. The presence of an output schema means the description doesn't need to detail return values, but it should provide more guidance on usage scenarios, error handling, and system behavior during updates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics with detailed explanations for all 11 parameters, including format specifications ('HH:MM'), units ('minutes'), and allowed values ('DAILY, WEEKLY, MONTHLY, YEARLY'). This is particularly valuable since the schema has 0% description coverage and no enums, making the description essential for understanding parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing smart habit'), which is specific and unambiguous. However, it doesn't differentiate this tool from its sibling 'update_task' or explain what distinguishes a 'smart habit' from other entities in the system, preventing a perfect score.
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 like 'create_habit', 'delete_habit', 'disable_habit', or 'enable_habit'. It mentions the tool updates existing habits but doesn't specify prerequisites, constraints, or typical use cases, leaving the agent with insufficient context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states this is an update operation (implying mutation) and mentions optional parameters, but doesn't disclose permissions needed, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields (e.g., are they preserved or reset?). The description lacks context on authentication, side effects, or response behavior beyond the basic return statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief introductory sentence followed by organized 'Args' and 'Returns' sections. Every sentence adds value: the intro states the purpose, and parameter descriptions clarify usage. It's appropriately sized for a 5-parameter tool, though the intro could be more front-loaded with key behavioral details instead of just restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 5 parameters), lack of annotations, and presence of an output schema (which handles return values), the description is moderately complete. It covers parameters well but lacks behavioral context like permissions, side effects, or error handling. For a mutation tool with no annotations, more disclosure on safety and prerequisites would improve completeness, though the output schema reduces the need to explain returns.
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—which it does effectively by documenting all 5 parameters with clear semantics. It explains 'task_id' as the identifier to update, optional fields like 'title' and 'duration_minutes', format for 'due_date' (ISO), and enum values for 'status'. This adds substantial meaning beyond the bare schema, though it doesn't cover validation rules or interdependencies between 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 verb 'Update' and resource 'existing task in Reclaim.ai', making the purpose unambiguous. It distinguishes from siblings like 'create_task' (creation) and 'delete_task' (deletion), though it doesn't explicitly contrast with similar tools like 'update_habit' or 'update_focus_settings'. The description is specific about what gets updated but doesn't mention scope limitations.
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 doesn't mention prerequisites (e.g., needing an existing task ID), when not to use it (e.g., for creation vs. update), or direct alternatives among siblings like 'mark_task_complete' for status changes or 'prioritize_task' for priority updates. Usage is implied through parameter descriptions 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation but doesn't mention permission requirements, error handling (e.g., what happens if task_id doesn't exist), rate limits, or whether this is a read-only operation. The description is minimal and leaves critical behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three brief sentences that each serve distinct purposes: stating the core function, explaining the parameter, and describing the return value. The structure with labeled sections (Args, Returns) makes it easy to parse. No wasted words 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 retrieval tool with an output schema, the description covers the basics: what it does, what parameter it needs, and what it returns. However, with no annotations and multiple sibling tools, it lacks important context about when to use it, error conditions, and behavioral constraints. The presence of an output schema reduces the need to describe return values in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter 'task_id' and clarifies it's 'The task ID to retrieve', adding meaningful context beyond the schema's type declaration. With 0% schema description coverage and only one parameter, this provides adequate compensation. The 'Args' section clearly maps to the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'a single task by ID', making the purpose specific and understandable. It distinguishes from sibling tools like 'list_tasks' by specifying retrieval of a single item rather than a collection. However, it doesn't explicitly contrast with other getters like 'get_event'.
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 doesn't mention when to choose 'get_task' over 'list_tasks' for multiple tasks, or when to use it in conjunction with update/delete operations. There's no context about prerequisites or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks server status but doesn't add context like what 'running' entails (e.g., health metrics, response time), potential side effects, or error handling. This leaves gaps in understanding its behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function with no wasted words. It is front-loaded and appropriately sized for a simple tool, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, simple purpose) and the presence of an output schema (which handles return values), the description is minimally complete. However, it lacks details on behavioral aspects like what the check involves or how it differs from siblings, leaving room for improvement in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could briefly note the lack of inputs for clarity. A baseline of 4 is assigned as it adequately handles the zero-parameter case without redundancy.
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's purpose with a specific verb ('Check') and resource ('server'), explaining it verifies if the server is running. However, it doesn't differentiate from sibling tools like 'verify_connection', which might serve a similar purpose, preventing a perfect score.
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 'verify_connection' in the sibling list. It lacks explicit context, prerequisites, or exclusions, offering only a basic functional statement without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions listing tasks but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination (beyond the 'limit' param), or whether this is a read-only operation. The description is minimal and misses key operational details.
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 front-loaded with the core purpose, followed by clear sections for 'Args' and 'Returns'. It uses minimal sentences that each add value, with no redundant information, 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.
Completeness3/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 (one parameter) and the presence of an output schema (which handles return values), the description is adequate but incomplete. It lacks context on usage guidelines and behavioral transparency, which are important for a listing tool with sibling alternatives, making it just minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining the 'limit' parameter's purpose ('Maximum number of tasks to return') and default value, which compensates for the 0% schema description coverage. With only one parameter, this is sufficient to achieve a high score, though it doesn't detail format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('completed and archived tasks from Reclaim.ai'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from the sibling 'list_tasks' tool, which might list tasks with different statuses, leaving some ambiguity about sibling distinction.
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 like 'list_tasks' or other task-related tools. It lacks context about prerequisites, exclusions, or comparative use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies mutation, the description doesn't mention permission requirements, whether changes are reversible, rate limits, or error conditions. The return statement mentions 'Updated focus settings' but doesn't describe what that contains or confirmation 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 perfectly structured and concise. It starts with a clear purpose statement, then provides well-organized parameter documentation in bullet-like format, and ends with a return statement. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters and no annotations, the description does well on parameter documentation but lacks behavioral context. The existence of an output schema helps (so return values don't need description), but critical information about permissions, side effects, and error handling is missing. It's adequate but has clear gaps for a write operation.
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 provides excellent parameter documentation. It clearly explains all 6 parameters with meaningful descriptions, including the enum values for 'defense_aggression'. The only minor gap is not explaining that only 'settings_id' is required while others are optional with null defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('focus time settings'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'get_focus_settings' or explain what makes 'update' distinct from other focus-related 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?
No guidance is provided about when to use this tool versus alternatives. There's no mention of prerequisites (like needing existing settings), when not to use it, or how it relates to sibling tools like 'get_focus_settings' or 'lock_focus_block'. The agent must infer usage context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves settings, implying a read-only operation, but doesn't mention authentication requirements, rate limits, or potential side effects. For a tool with zero annotation coverage, this is insufficient to fully inform the agent about its 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 extremely concise and well-structured. The first sentence clearly states the purpose, and the second sentence provides return value information. There's no wasted text, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 0 parameters, 100% schema coverage, and an output schema exists (which handles return values), the description is reasonably complete. It explains what the tool does and what it returns. However, it could be more complete by mentioning authentication needs or differentiating from siblings, given the lack of 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 input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which is efficient. A baseline of 4 is applied since it doesn't add unnecessary information, but it's not a perfect 5 because it doesn't explicitly acknowledge the lack of 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 tool's purpose: 'Get current focus time settings for the user.' It specifies the verb ('Get') and resource ('focus time settings'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'update_focus_settings' or 'get_focus_insights', which prevents a perfect score.
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. There's no mention of when it should be used over 'get_focus_insights' or 'update_focus_settings', nor any context about prerequisites or typical use cases. This leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool performs a mutation ('Restart') and returns an updated task state, but doesn't disclose behavioral traits such as permissions required, whether the operation is idempotent, error conditions (e.g., invalid task_id), or side effects. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the basic action.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by structured 'Args' and 'Returns' sections. Each sentence earns its place by providing essential information without redundancy. It could be slightly more concise by integrating the sections into a single paragraph, but the structure aids readability.
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 (a mutation with 1 parameter), no annotations, and an output schema exists (implied by 'Returns' note), the description is moderately complete. It covers the purpose and parameters but lacks behavioral details like error handling or side effects. The output schema should document return values, so the description doesn't need to explain those, but overall it's adequate with clear gaps in transparency.
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 1 parameter with 0% description coverage, so the description must compensate. It provides the parameter 'task_id' and clarifies it's 'The task ID to restart', adding meaning beyond the schema's type (integer). This adequately covers the single parameter, though it doesn't specify format constraints (e.g., positive integers). With 0 parameters, baseline would be 4, but here it's effectively met due to full parameter explanation.
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 ('Restart') and target resource ('a completed/archived task'), with the specific outcome of returning it to active scheduling. It distinguishes from siblings like 'start_task' or 'mark_task_complete' by focusing on reactivation rather than initiation or completion. However, it doesn't explicitly differentiate from tools like 'update_task' that might also modify task states.
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 tasks that are 'completed/archived', suggesting when to use it (for reactivation) but not explicitly when not to use it or alternatives. It doesn't mention prerequisites (e.g., task must exist and be in a restartable state) or compare to siblings like 'update_task' for state changes. The guidance is contextual but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), which implies non-destructive behavior, but doesn't cover aspects like authentication needs, rate limits, error handling, or data freshness. The description adds minimal behavioral context beyond the basic purpose, leaving significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by organized sections for Args and Returns. Each sentence adds value, such as parameter details and return information, with no wasted words. However, the formatting with bullet points in the description text slightly reduces conciseness, but it remains 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?
Given the tool's moderate complexity (3 parameters, analytics focus) and the presence of an output schema (which handles return values), the description is fairly complete. It covers the purpose, parameter semantics, and return overview. However, with no annotations, it lacks behavioral details like permissions or limits, and it doesn't fully address usage guidelines, leaving some gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% schema description coverage. It explains that 'start' and 'end' are dates in ISO format with examples, and 'metric_name' has specific enum values (DURATION_BY_CATEGORY, DURATION_BY_DATE_BY_CATEGORY). This fully compensates for the schema's lack of descriptions, providing clear semantics for all three 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 tool's purpose: 'Get personal productivity analytics for the current user.' It specifies the verb ('Get') and resource ('personal productivity analytics'), and distinguishes it from siblings like get_focus_insights or list_completed_tasks by focusing on analytics rather than raw data. However, it doesn't explicitly differentiate from get_focus_insights, which might also provide analytics, keeping it from a perfect score.
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 doesn't mention when to choose get_user_analytics over get_focus_insights or other sibling tools, nor does it specify prerequisites or exclusions. The usage context is implied (e.g., for analytics on user productivity), but no explicit guidelines are 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?
With no annotations provided, the description carries the full burden. It discloses that time is ignored in date parameters and explains the 'thin' parameter's effect on returned data, adding useful behavioral context. However, it lacks details on permissions, rate limits, pagination, or error handling, leaving gaps for a mutation-free 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 well-structured and appropriately sized. It front-loads the core purpose, then efficiently documents parameters and returns in clear sections. Every sentence adds value without redundancy, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no annotations, but with output schema), the description is largely complete. It explains parameters and return values adequately. The output schema existence means return details aren't needed, but slight gaps remain in behavioral transparency (e.g., error cases).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all parameters: clarifies date/time handling for 'start' and 'end', explains optional filtering for 'calendar_ids' and 'event_type', and details the 'thin' parameter's impact. This goes well beyond the bare schema, though it doesn't fully document all possible 'event_type' values.
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's purpose: 'List calendar events within a time range.' It specifies the verb ('List') and resource ('calendar events'), but doesn't explicitly differentiate from sibling tools like 'list_personal_events' or 'get_event', which prevents a perfect score.
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. The description doesn't mention sibling tools like 'list_personal_events' or 'get_event', nor does it specify prerequisites, exclusions, or typical use cases beyond the basic functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it pauses a timer and keeps the task active (not deleting or completing it). However, it doesn't mention side effects (e.g., impact on task state, user permissions needed), rate limits, or error conditions, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose and key behavior, followed by structured Args and Returns sections. Every sentence adds value, though the Returns section could be more informative given the output schema exists.
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 a mutation tool with no annotations, 0% schema coverage, but an output schema, the description is moderately complete. It covers purpose and basic behavior but lacks details on side effects, prerequisites, or error handling. The output schema reduces the need to explain return values, but more context is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying 'task_id' as 'The task ID to stop working on', clarifying its role. With only one parameter, this is sufficient, though it doesn't detail format constraints (e.g., integer range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('stop working on') and resource ('a task'), with specific behavioral details ('pauses timer, keeps task active'). It distinguishes from sibling tools like 'mark_task_complete' (which would finalize) and 'restart_task' (which would resume), though it doesn't explicitly name these 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 context by mentioning 'pauses timer, keeps task active', suggesting this is for temporarily halting work rather than completing or deleting. However, it doesn't explicitly state when to use this vs. alternatives like 'mark_task_complete' or 'restart_task', nor does it mention prerequisites (e.g., task must be active).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool creates a habit for 'auto-scheduling', it doesn't describe what that means operationally, what permissions might be required, whether the creation is immediate or scheduled, or any side effects. The description provides basic functional information but lacks important behavioral context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for Args and Returns, making it easy to parse. While comprehensive, it maintains efficiency by avoiding redundancy and keeping explanations focused. Every sentence serves a clear purpose in documenting the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 11 parameters with 0% schema coverage and no annotations, the description does an excellent job of documenting the input parameters. The presence of an output schema means the description doesn't need to explain return values. The main gap is the lack of behavioral context and usage guidelines for this creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all 11 parameters. Each parameter gets clear explanations of its purpose, format examples, defaults, and constraints, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new smart habit') and resource ('for auto-scheduling'), distinguishing it from sibling tools like 'create_task' or 'update_habit'. It provides a complete picture of what the tool does beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like 'create_task' or 'update_habit'. The description doesn't mention prerequisites, dependencies, or contextual factors that would help an agent decide when this is the appropriate tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool 'locks' a focus block to prevent rescheduling, which implies a mutation, but does not disclose behavioral traits like required permissions, whether the lock is reversible, rate limits, or what 'updated event state' entails. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections add necessary structure without redundancy, though the Returns section could be slightly more detailed given the lack of output schema context.
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 (mutation with 2 parameters), no annotations, and an output schema present (though not detailed in the description), the description is moderately complete. It covers the purpose and parameters but lacks behavioral context and detailed return value explanation, which the output schema might address but isn't described here.
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%, but the description adds meaning by explaining that 'calendar_id' identifies the calendar containing the focus block and 'event_id' specifies the focus block event to lock. This compensates well for the lack of schema descriptions, though it doesn't detail format constraints (e.g., integer/string specifics).
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 specific action ('Lock a focus time block') and the resource ('focus time block'), distinguishing it from sibling tools like 'unlock_focus_block' and 'reschedule_focus_block'. It precisely defines what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it prevents rescheduling, but does not explicitly say when to use this tool versus alternatives like 'unlock_focus_block' or 'reschedule_focus_block'. No exclusions or prerequisites are mentioned, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only minimally addresses behavior. It mentions the tool creates a task and returns the created object, but doesn't disclose important traits like authentication requirements, rate limits, error conditions, or what 'auto-scheduling' entails operationally.
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 efficiently structured with a clear purpose statement followed by well-organized parameter explanations and a returns section. Every sentence serves a purpose with zero wasted words, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation) and the presence of an output schema, the description is mostly complete. It explains all parameters thoroughly and states the return type. However, it lacks behavioral context that would be important for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear explanations for all 7 parameters. Each parameter gets a concise definition including format requirements (ISO date string), defaults, and meaning (e.g., 'Minimum time block size'), adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new task'), target system ('in Reclaim.ai'), and purpose ('for auto-scheduling'), which distinguishes it from siblings like update_task or list_tasks. It provides a complete verb+resource+context combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_task or prioritize_task, nor are there any prerequisites mentioned. The description only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the behavioral trait of pausing scheduling without deletion (non-destructive), which is good. However, it doesn't mention permissions needed, whether changes are reversible, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. Every sentence earns its place with no wasted words, 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?
Given a single parameter with no schema descriptions and an output schema (returns True), the description adequately covers the parameter meaning and return value. For a mutation tool with no annotations, it could benefit from more behavioral context like error handling or side effects.
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 0% description coverage for the single parameter, but the description adds the meaning of 'lineage_id' as 'The habit lineage ID to disable', which fully compensates. This provides clear semantic context beyond the bare schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'disable' and resource 'habit', explaining it pauses scheduling without deletion. It distinguishes from 'delete_habit' by specifying non-destructive action, though could be more explicit about sibling differentiation.
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 wanting to pause a habit temporarily rather than delete it, but doesn't explicitly state when to use vs. alternatives like 'enable_habit' or 'delete_habit'. No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action ('unlock') and outcome ('allow rescheduling'), but does not disclose behavioral traits such as required permissions, whether this is reversible, side effects on other events, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: a purpose statement, parameter explanations, and return value note. It is front-loaded with the main action, though the 'Args' and 'Returns' sections are slightly verbose but still 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?
Given the tool has an output schema (returns a 'Planner action result with updated event state'), the description does not need to detail return values. It covers the purpose and parameters adequately, but as a mutation tool with no annotations, it could benefit from more behavioral context like error conditions or dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains the purpose of both parameters ('calendar_id: The calendar ID containing the focus block', 'event_id: The focus block event ID to unlock'), adding meaning beyond the input schema which has 0% description coverage. This compensates well for the schema gap, though it could specify data formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('unlock a focus time block') and the outcome ('allow it to be rescheduled'), distinguishing it from siblings like 'lock_focus_block' (opposite action) and 'reschedule_focus_block' (which likely requires unlocking first). It uses precise verbs and identifies the resource type.
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 a focus block needs to be rescheduled, but does not explicitly state when to use this tool versus alternatives like 'reschedule_focus_block' directly or other event management tools. It provides some context but lacks explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the default exclusion of completed tasks and provides parameter details, but lacks information on permissions, rate limits, pagination, or error handling. It adds some context but does not fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but has output schema), the description is fairly complete. It covers purpose, parameters, and return values, but could improve by addressing behavioral aspects like authentication or error cases, though the output schema reduces the need for return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters: 'status' as comma-separated task statuses with examples, and 'limit' as maximum number of tasks with a default. This adds significant meaning beyond the bare schema, though it could detail format constraints more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('List') and resource ('active tasks from Reclaim.ai'), and distinguishes it from siblings by noting it excludes completed tasks by default. This differentiates it from tools like 'list_completed_tasks' and 'get_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 by specifying it lists active tasks and excludes completed ones by default, which implicitly guides usage. However, it does not explicitly state when to use alternatives like 'list_completed_tasks' or 'get_task' for specific needs, missing explicit exclusions or named 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?
With no annotations provided, the description carries the full burden. It implies a mutation operation ('mark as done'), which is useful, but lacks details on permissions, side effects (e.g., impact on habit streaks), error conditions, or rate limits. The mention of 'updated events and series info' in returns adds some behavioral context, but more specifics would improve 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 front-loaded with the core purpose in the first sentence, followed by usage guidance and parameter/return details in a structured format. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter with 0% schema coverage and an output schema present, the description does well by explaining the parameter's semantics and hinting at return values. However, as a mutation tool with no annotations, it could benefit from more behavioral details (e.g., idempotency, error handling) to be fully complete, though the output schema mitigates some 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?
Schema description coverage is 0%, so the description must compensate. It explains the 'event_id' parameter by specifying it's 'of the specific habit instance' and sourced 'from list_personal_events', adding meaningful context beyond the bare schema. However, it doesn't detail format constraints (e.g., UUID, string length) or validation rules, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('mark as done'), the resource ('habit instance'), and distinguishes it from siblings like 'skip_habit' or 'mark_task_complete' by focusing on habit completion rather than skipping or task-related actions. The verb+resource combination is precise 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 it ('to mark today's scheduled habit event as completed') and references a sibling tool ('list_personal_events') as the source for the event_id. However, it doesn't explicitly state when NOT to use it (e.g., vs. 'skip_habit' for skipping) or mention alternatives for non-today events, which keeps it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action (fetching user info) and return format (connection status with user details), which covers basic behavior. However, it doesn't mention authentication requirements, rate limits, error conditions, or whether this is a read-only operation, leaving gaps in behavioral 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 perfectly concise with two sentences: the first states the purpose and action, the second describes the return format. Every word earns its place, and information is front-loaded with no redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description provides adequate context about what the tool does and what it returns. However, with no annotations and a read operation that likely requires authentication, the description could benefit from mentioning authentication requirements or error handling for a more complete picture.
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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and output. This aligns with the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('verify API connection by fetching current user info') and distinguishes this tool from siblings by focusing on connection verification rather than task/habit management. It explicitly mentions the resource being accessed (current user info), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (verifying API connection) but doesn't explicitly state when to use this tool versus alternatives like 'health_check' or other user-related tools. It provides clear functional context but lacks explicit comparison or exclusion guidance for sibling 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?
With no annotations provided, the description carries the full burden. It describes the core behavior (skipping without marking done) but lacks details on permissions, side effects, error conditions, or rate limits. It's adequate but has gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and parameter/return details in a structured format. Every sentence adds value with zero waste, 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 single-parameter mutation tool with no annotations but an output schema, the description covers purpose, usage, and parameter meaning adequately. However, it could benefit from more behavioral context (e.g., idempotency, error handling) given the lack of 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 schema has 0% description coverage, but the description compensates by explaining the single parameter's purpose ('The event ID of the specific habit instance to skip'). This adds meaningful context beyond the bare schema type, though it doesn't specify format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('skip a habit instance') and resource ('today's scheduled habit event'), distinguishing it from sibling tools like mark_habit_done. It precisely defines what the tool does without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('skip today's scheduled habit event without marking it done') and distinguishes it from the alternative action of marking as done, which is handled by the sibling tool mark_habit_done. This provides clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a read operation (implied by 'Get'), specifies potential error conditions (404 for Reclaim-managed events), and explains the return format ('Event object with full details'). However, it doesn't mention rate limits, authentication needs, or pagination, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by usage notes and parameter details. Every sentence adds value: the first states the purpose, the second provides critical usage guidance, and the parameter/return sections clarify inputs and outputs without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is complete. It covers purpose, usage guidelines, parameter meanings, and return values. The output schema existence means the description doesn't need to detail the Event object structure, and it adequately addresses the gaps from missing annotations and low schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains all three parameters: calendar_id ('The calendar ID containing the event'), event_id ('The event ID to retrieve'), and thin ('If True, return minimal event data'). This adds meaningful context beyond the bare schema, though it doesn't specify data formats (e.g., integer vs. string expectations) or provide examples.
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 specific action ('Get a single event'), identifies the required resources ('by calendar ID and event ID'), and distinguishes from siblings like list_events and list_personal_events by focusing on individual retrieval rather than listing. The verb+resource combination is precise 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Works best with events from list_events') and when not to use it ('Reclaim-managed events from list_personal_events may return 404'), directly naming sibling alternatives. This helps the agent choose between get_event and other event-related tools like list_events or list_personal_events.
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:

[![reclaim-mcp-server MCP server](https://glama.ai/mcp/servers/universalamateur/reclaim-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/universalamateur/reclaim-mcp-server)

Score Badge

Copy to your README.md:

[![reclaim-mcp-server MCP server](https://glama.ai/mcp/servers/universalamateur/reclaim-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/universalamateur/reclaim-mcp-server)

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/universalamateur/reclaim-mcp-server'

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