Integrates with Apple's ecosystem through Apple Sign-In authentication and CloudKit services for secure access to user data stored in iCloud containers
Provides direct integration with iCloud CloudKit services for managing personal productivity data within the addTaskManager iOS/macOS app, including tasks, projects, ideas, and collections stored in the user's iCloud container
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@addTaskManager MCP Server create a task to review the quarterly report in Assess"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that integrates with the addTaskManager iOS/macOS app, implementing the ADD (Assess-Decide-Do) framework created by Dragos Roua.
This MCP server provides AI assistance for your addTaskManager productivity workflow while respecting the strict realm-based restrictions of the ADD framework:
Assess Realm: Create and edit tasks/projects/ideas, but cannot assign contexts or due dates
Decide Realm: Assign contexts, due dates, and alerts, but cannot edit content
Do Realm: Mark items as complete only (read-only otherwise)
Related MCP server: OmniFocus MCP Server
Secure Apple Sign-In integration
CloudKit.js authentication for personal data access
User-specific data isolation
assess_create_task - Create new tasks with editable content
assess_edit_task - Edit task content
assess_create_project - Create new projects
assess_edit_project - Edit project title
assess_create_idea - Capture new ideas
assess_create_collection - Create new collection
assess_create_context - Create new context
assess_edit_idea - Edit idea title
assess_add_task_to_project - Add an existing task to a project
assess_add_task_to_idea - Add an existing task to an idea
assess_remove_task_from_project - Remove a task assigned to a project
assess_remove_task_from_idea - Remove a task assigned to an idea
assess_archive_task_to_collection - Archive a task to an existing collection
assess_archive_project_to_collection - Archive a project to an existing collection
decide_assign_context - Assign contexts to tasks/projects
decide_set_project_interval - Set a project interval (start date and end date)
decide_set_task_due_date - Set due date to a task
decide_set_task_alert - Set task alerts
decide_move_task_to_do - Move task to Do realm
decide_move_task_to_assess_from_decide - Move task to Assess realm
decide_move_project_to_do - Move project to Do realm
decide_move_project_to_assess_from_decide - Move project to Assess realm
do_mark_task_as_done - Mark tasks as completed
do_mark_project_as_done - Mark projects as completed
get_tasks_by_realm - Filter tasks by realm
get_projects_by_realm - Filter projects by realm
get_ideas - Get all ideas
get_collections - Get all collections
get_tasks_by_context - Filter by context
get_stalled_items_in_decide - Find stalled items (task + projects) in Decide
get_undecided_items_in_decide - Find undecided items (task + projects) in Decide
get_ready_items_in_decide - Find ready to do items (task + projects) in Decide
get_tasks_today_in_do - Find tasks done today in Do
get_tasks_tomorrow_in_do - Find tasks done tomorrow in Do
get_tasks_soon_in_do - Find tasks done soon in Do
get_tasks_overdue_in_do - Find tasks overdue in Do
moveToRealm - Move a task or project to any realm (assess/decide/do)
npm install -g @dragosroua/addtaskmanager-mcp-servergit clone https://github.com/dragosroua/addtaskmanager-mcp-server.git
cd addtaskmanager-mcp-server
npm install
npm run buildThe server supports both development and production configurations. Copy .env.example to .env and configure:
# Environment
NODE_ENV=production # or development
# FORCE_CLOUDKIT=true # Force CloudKit in development
# CloudKit Configuration (Required)
CLOUDKIT_CONTAINER_ID=iCloud.com.yourapp.zentasktic
CLOUDKIT_API_TOKEN=your_api_token_here
CLOUDKIT_ENVIRONMENT=production # or development
CLOUDKIT_AUTH_METHOD=user # or server-to-server
# Security Configuration (Production)
ENCRYPTION_KEY=your_32_byte_encryption_key_here
ALLOWED_ORIGINS=https://yourapp.com,https://localhost:3000
RATE_LIMIT_WINDOW_MS=900000 # 15 minutes
RATE_LIMIT_MAX_REQUESTS=100
AUDIT_LOGGING=true
SESSION_TIMEOUT_MS=86400000 # 24 hours
# Optional: For server-to-server authentication
# CLOUDKIT_SERVER_KEY=your_server_key_id
# CLOUDKIT_PRIVATE_KEY_PATH=/path/to/private/key.p8
# CLOUDKIT_PRIVATE_KEY_PASSPHRASE=your_passphrase
# Optional: Custom redirect URI
# CLOUDKIT_REDIRECT_URI=https://yourapp.com/auth/callbackLog into CloudKit Dashboard
Select your addTaskManager container
Go to API Access → Server-to-Server Keys
Create a new JavaScript API token
Add your web app's domain to allowed origins
Copy the API token to CLOUDKIT_API_TOKEN
Add to your Claude Desktop MCP configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"addTaskManager": {
"command": "node",
"args": ["/path/to/addtaskmanager-mcp-server/dist/index.js"],
"env": {
"NODE_ENV": "production",
"CLOUDKIT_CONTAINER_ID": "iCloud.com.yourapp.zentasktic",
"CLOUDKIT_API_TOKEN": "your_api_token_here",
"CLOUDKIT_ENVIRONMENT": "production",
"ENCRYPTION_KEY": "your_32_byte_encryption_key_here"
}
}
}
}For development:
{
"mcpServers": {
"addTaskManager": {
"command": "npm",
"args": ["run", "dev"],
"cwd": "/path/to/addtaskmanager-mcp-server",
"env": {
"NODE_ENV": "development",
"CLOUDKIT_CONTAINER_ID": "iCloud.com.yourapp.zentasktic",
"CLOUDKIT_API_TOKEN": "your_api_token_here"
}
}
}
}Implement Apple Sign-In on your web app
Get user's CloudKit web auth token
Call authenticate_user with the token
Start using realm-specific operations
Example authentication flow:
// After Apple Sign-In success
const authResult = await mcp.callTool('authenticate_user', {
webAuthToken: user.cloudKitWebAuthToken
});
// Now you can use other tools
const tasks = await mcp.callTool('get_tasks_by_realm', {
realm: 'assess'
});The server enforces these ADD framework restrictions:
✅ Create/edit task content (title, body)
✅ Create projects and ideas
❌ Assign contexts or due dates
❌ Mark as complete
✅ Assign contexts to tasks/projects
✅ Set due dates and alerts
✅ Move items between realms
❌ Edit task/project content
❌ Mark as complete
✅ Mark tasks/projects as complete
✅ View items (read-only)
❌ Edit any content
❌ Assign contexts or dates
# Clone and install
git clone https://github.com/dragosroua/addtaskmanager-mcp-server.git
cd addtaskmanager-mcp-server
npm install
# Setup environment
cp .env.example .env
# Edit .env with your CloudKit credentials
# Development mode with TypeScript compilation
npm run dev
# Production build
npm run build
# Start built server
npm start
# Code quality
npm run lint
npm run typecheck
# Test (when available)
npm testsrc/
├── config/
│ └── production.ts # Environment-based configuration
├── services/
│ ├── CloudKitService.ts # CloudKit integration
│ └── UserAuthService.ts # User authentication
├── types/
│ └── cloudkit.ts # TypeScript type definitions
└── index.ts # Main MCP server implementationUses ESM modules (type: "module" in package.json)
TypeScript compiled to dist/ directory
Supports both development and production CloudKit environments
Environment-based configuration with security considerations
Comprehensive type definitions for CloudKit integration
AI Assistant (Claude Desktop) → MCP Server → CloudKit Services
↓
Environment Config
Security Controls
User Authentication
↓
ADD Framework Rules
↓
addTaskManager Data
(User's iCloud Container)MCP Server: Model Context Protocol server implementation
CloudKit Integration: Production-ready CloudKit Web Services client
Authentication: Apple ID-based user authentication with session management
Security Layer: Encryption, rate limiting, audit logging, CORS protection
ADD Framework: Realm-based business logic enforcement
Type Safety: Comprehensive TypeScript definitions
Environment-Based Security: Different security profiles for development/production
User Authentication: Apple ID authentication with CloudKit web auth tokens
Session Management: Secure session handling with configurable timeouts
Data Encryption: Configurable encryption keys for sensitive data
Rate Limiting: Configurable request rate limiting with user-specific limits
CORS Protection: Configurable allowed origins for web app integration
Audit Logging: Comprehensive operation logging for security monitoring
Data Isolation: Users can only access their own addTaskManager data
Realm Enforcement: ADD framework rules prevent unauthorized operations
The ADD (Assess-Decide-Do) framework was created by Dragos Roua as an alternative to GTD (Getting Things Done). It emphasizes:
Sequential Processing: Items flow through realms in order
Cognitive Load Management: Each realm has specific, limited functions
Balanced Productivity: Maintains efficiency while preserving creativity and well-being
Learn more: dragosroua.com
Add an existing task to an idea in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task | |
| ideaRecordName | Yes | Record name of the idea |
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 action is 'Add,' implying a mutation, but doesn't describe effects like whether this creates a link, updates statuses, requires permissions, or has side effects. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resources, making it easy to parse quickly without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like effects, permissions, or return values, and lacks usage context compared to siblings. For a tool that modifies data in a system with many related tools, more information is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any meaning beyond the schema, such as explaining what 'Record name' entails or providing examples. Baseline 3 is appropriate since the schema does the heavy lifting, but no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resources ('existing task to an idea in Assess realm'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'assess_add_task_to_project' or 'assess_remove_task_from_idea', which would require more specific context about what 'adding' entails in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't explain when to choose this over 'assess_add_task_to_project' or how it relates to 'assess_remove_task_from_idea'. The description lacks context about prerequisites or typical scenarios for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an existing task to a project in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task | |
| projectRecordName | Yes | Record name of the project |
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 indicates a mutation ('Add') but doesn't disclose permissions needed, side effects (e.g., if task is removed from another project), error conditions, or response format. This leaves significant gaps for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, though it could be slightly more structured by including usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., idempotency, errors), prerequisites, and what the tool returns. Given the complexity of modifying project-task relationships, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond implying the parameters refer to existing records ('existing task', 'project'), which is already suggested by the schema's 'Record name' descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resources ('existing task to a project'), specifying the realm ('Assess realm'). It distinguishes from siblings like 'assess_create_task' (creation vs. adding existing) and 'assess_remove_task_from_project' (add vs. remove). However, it doesn't explicitly differentiate from 'assess_add_task_to_idea', which has a similar structure but different target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for adding tasks to projects in the Assess realm, but it doesn't mention prerequisites (e.g., task/project must exist), exclusions, or direct comparisons to siblings like 'assess_add_task_to_idea' or 'assess_remove_task_from_project'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive a project to a collection.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRecordName | Yes | Record name of the project | |
| collectionRecordName | Yes | Record name of the collection |
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. 'Archive' implies a state change (likely making the project inactive or moving it to archival storage), but the description doesn't specify whether this is reversible, what permissions are required, whether it affects associated tasks, or what happens to the project's data. For a mutation tool with zero annotation coverage, this is a significant gap in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resources, making it immediately understandable. Every word earns its place by conveying essential information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool (implied by 'Archive') with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like reversibility, side effects, or error conditions, nor does it explain what the tool returns. For a tool that modifies data, this lack of context leaves significant gaps for an AI agent to understand its full impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema itself ('projectRecordName' and 'collectionRecordName'). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain what constitutes a valid record name, format requirements, or relationship constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Archive') and target resources ('a project to a collection'), providing a specific verb+resource combination. It distinguishes from some siblings like 'assess_create_project' or 'assess_edit_project' by focusing on archiving rather than creation or modification. However, it doesn't explicitly differentiate from the closely related 'assess_archive_task_to_collection' tool, which archives tasks instead of projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is no mention of prerequisites (e.g., existing project and collection), when archiving is appropriate versus deletion or other status changes, or how this differs from similar tools like 'assess_archive_task_to_collection' or 'decide_move_project_to_do'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archive a task to a collection.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task | |
| collectionRecordName | Yes | Record name of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Archive' implies a mutation (likely moving or marking a task), but it doesn't disclose if this is reversible, requires specific permissions, affects task status, or has side effects (e.g., removing from other lists). The description lacks behavioral details 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resources, making it easy to parse quickly. No unnecessary words or redundancy are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It doesn't explain what 'archive' entails behaviorally, what the result looks like, or potential errors. For a tool that likely changes state, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('taskRecordName', 'collectionRecordName') clearly documented in the schema. The description adds no additional meaning about parameters beyond implying they are required for the archive operation. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Archive a task to a collection' clearly states the action (archive) and target resources (task, collection), but it's vague about what 'archive' means operationally. It distinguishes from obvious siblings like 'assess_create_task' or 'assess_edit_task', but doesn't clarify how it differs from similar tools like 'assess_add_task_to_idea' or 'assess_archive_project_to_collection' in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't specify if this is for completed tasks, how it relates to 'assess_add_task_to_idea/project', or what happens if a task is already archived. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new collection in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| collectionName | Yes | Collection name |
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 creation operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether collections are unique, what happens on duplicate names, or the response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple creation tool and front-loads the key information (action and resource).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, no output schema, and multiple sibling tools, the description is incomplete. It lacks behavioral context, usage guidance, and details about the result. The agent would need to guess about permissions, error handling, and how this integrates with other Assess tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. With 100% schema description coverage (the schema documents the single parameter 'collectionName' as 'Collection name'), the baseline is 3. The description doesn't elaborate on naming constraints, format, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new collection in Assess realm'), making the purpose understandable. However, it doesn't distinguish this tool from other 'create' siblings like assess_create_context, assess_create_idea, assess_create_project, and assess_create_task, which all create different resource types in the same realm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, when collections should be created, or how this relates to sibling tools like get_collections (for listing) or assess_archive_project_to_collection (for archiving).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new context in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| contextName | Yes | Context name (max 30 chars) |
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. While 'Create' implies a write operation, the description doesn't specify permissions required, whether this is idempotent, what happens on duplicate names, or what the response includes. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates a new resource (a mutation) with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'context' is, how it fits into the Assess realm, what happens after creation, or any error conditions. For a creation tool in a system with many sibling tools, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'contextName' documented as 'Context name (max 30 chars)'. The description adds no additional parameter semantics beyond what's in the schema, such as naming conventions or examples. With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new context in Assess realm'), making the purpose understandable. However, it doesn't differentiate this tool from similar creation tools like 'assess_create_collection', 'assess_create_idea', 'assess_create_project', and 'assess_create_task' that also create resources in the Assess realm, 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.
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 explain what a 'context' is in the Assess realm, how it differs from other resources like collections or projects, or when to choose this over other creation tools. This leaves the agent with minimal context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a new idea (always starts in Assess realm).
| Name | Required | Description | Default |
|---|---|---|---|
| ideaName | Yes | Idea name/details (max 1500 chars) | |
| collectionRecordName | No | Optional recordName of the parent collection. |
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 creates a new idea and specifies it 'always starts in Assess realm', which adds some workflow context. However, it lacks critical details such as permissions required, whether the creation is reversible, what happens to the idea after creation, or any rate limits. For a creation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Capture a new idea') and adds contextual detail ('always starts in Assess realm') without unnecessary elaboration. Every word serves a purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like permissions, reversibility, or response format, and doesn't fully guide usage relative to siblings. While concise, it doesn't compensate for the missing structured data, leaving gaps in understanding how to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('ideaName' and 'collectionRecordName'). The description doesn't add any parameter-specific details beyond what's in the schema, such as examples or formatting nuances. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Capture') and resource ('a new idea'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'assess_edit_idea' by specifying creation vs. editing, though it doesn't explicitly differentiate from other 'create' tools like 'assess_create_project' or 'assess_create_task' beyond mentioning the 'Assess realm' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with '(always starts in Assess realm)', suggesting this tool is for initial idea creation in a specific workflow stage. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'assess_create_project' or 'assess_edit_idea', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| projectName | Yes | Project name/description (max 1500 chars) | |
| startDate | No | Optional start date (ISO format) | |
| collectionRecordName | No | Optional recordName of the parent collection. |
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 creation operation but doesn't mention permissions required, whether this is a mutating operation (implied but not explicit), what happens on success/failure, or any rate limits. For a creation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple creation operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'project' entails in the Assess realm, what happens after creation, or what the tool returns. Given the complexity of project management systems and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are documented in the schema itself. The description doesn't add any additional parameter context beyond what's already in the schema, making the baseline score of 3 appropriate. No parameter-specific guidance is provided in the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new project in Assess realm'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'assess_create_collection' or 'assess_create_idea', which would require mentioning what makes a project distinct from those other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'assess_create_collection' or 'assess_create_idea', nor does it mention prerequisites or context for project creation. It simply states what the tool does without indicating appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in Assess realm (content editing, no contexts/dates).
| Name | Required | Description | Default |
|---|---|---|---|
| taskName | Yes | Task name/description (max 1000 chars) | |
| startDate | No | Optional start date (ISO format) | |
| taskPriority | No | Optional task priority (1-5, default 3) | |
| projectRecordName | No | Optional recordName of the parent project. | |
| collectionRecordName | No | Optional recordName of the parent collection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions 'content editing' and 'no contexts/dates', which adds some context about constraints, but fails to disclose critical traits like required permissions, mutation effects (e.g., whether it's idempotent), error handling, or response format. For a creation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it states the action, domain, and key constraint clearly. It's appropriately front-loaded and concise, making every word count without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a creation operation with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or return values, and while schema covers parameters, the overall context for safe and effective use is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific semantics beyond implying 'no contexts/dates' (which relates to startDate but isn't detailed). It doesn't explain relationships between parameters like projectRecordName and collectionRecordName, so it meets the baseline 3 without adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new task') and the domain ('in Assess realm'), with a specific scope limitation ('content editing, no contexts/dates'). It distinguishes from siblings like 'assess_create_project' or 'assess_create_idea' by focusing on tasks, but doesn't explicitly differentiate from 'assess_edit_task' or 'assess_add_task_to_project' beyond the creation aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'content editing, no contexts/dates', hinting at when not to use it for contexts/dates, but lacks explicit when-to-use scenarios, prerequisites, or alternatives. It doesn't clarify when to choose this over siblings like 'assess_add_task_to_idea' or 'assess_create_project', leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit idea content in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| ideaRecordName | Yes | Record name of the idea to edit | |
| ideaName | No | Updated idea name |
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 edits idea content, implying a mutation operation, but doesn't disclose critical traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Edit idea content') and domain ('Assess realm'). It avoids unnecessary words and gets straight to the point. However, it could be slightly more structured by explicitly listing editable fields or usage context, but it earns high marks for brevity and clarity within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), doesn't explain return values or error handling, and offers minimal guidance. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially compared to siblings that might have overlapping functionalities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters: 'ideaRecordName' (record name of the idea to edit) and 'ideaName' (updated idea name). The description adds no additional meaning beyond the schema, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Edit idea content') and domain ('Assess realm'), which clarifies the basic purpose. However, it's vague about what 'content' entails (e.g., name, description, status) and doesn't differentiate from siblings like 'assess_edit_project' or 'assess_edit_task' beyond specifying 'idea' as the resource. It avoids tautology by not restating the name/title but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for editing ideas in the Assess realm, but it doesn't mention prerequisites (e.g., existing ideas), exclusions, or comparisons to siblings like 'assess_create_idea' or 'assess_archive_task_to_collection'. Without such context, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit project content in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRecordName | Yes | Record name of the project to edit | |
| projectName | No | Updated project name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Edit' implies a mutation, but it doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling, or rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it's front-loaded with minimal detail, which could benefit from more substance to improve clarity without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, error cases, return values, and differentiation from siblings, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond implying editing of 'project content,' which loosely maps to the parameters but doesn't clarify semantics like format constraints or interactions between them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Edit') and resource ('project content in Assess realm'), which is clear but vague. It doesn't specify what 'content' includes (e.g., name, description, status) or how it differs from siblings like 'assess_edit_idea' or 'assess_edit_task', leaving the purpose somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't clarify if this is for updating project metadata versus other operations like archiving or moving realms, nor does it mention prerequisites such as needing an existing project record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit task content in Assess realm (taskName, priority).
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task to edit | |
| taskName | No | Updated task name/description | |
| taskPriority | No | Updated task priority (1-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 an edit operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling (e.g., if the task doesn't exist), or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Edit task content') and includes key details (realm and fields). There's no wasted verbiage, but it could be slightly more structured (e.g., separating purpose from usage). Overall, it's appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, error cases, or return values, which are crucial for safe invocation. While the schema covers parameters well, the overall context for using this tool effectively is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (taskRecordName, taskName, taskPriority) with descriptions and constraints. The description adds minimal value by listing 'taskName, priority' as editable fields, but doesn't provide additional semantics beyond what the schema specifies. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Edit task content') and specifies the resource ('task') and realm ('Assess'), along with the editable fields ('taskName, priority'). It distinguishes from siblings like 'assess_create_task' (creation vs. editing) and 'assess_archive_task_to_collection' (editing vs. archiving), though it doesn't explicitly contrast them. The purpose is specific but could be more detailed on scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., that the task must exist), exclusions, or comparisons to siblings like 'assess_edit_idea' or 'assess_edit_project'. Usage is implied by the action 'edit,' but no explicit context or decision criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a task from an idea in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task | |
| ideaRecordName | Yes | Record name of the idea |
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 'Remove' which implies a mutation, but does not disclose behavioral traits such as permissions required, whether the task is deleted or unlinked, side effects, or error handling. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and to the point, with no unnecessary words. However, it could be more structured by including key details like behavioral traits, but given its brevity, it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool with 2 parameters. It lacks information on what the tool returns, error conditions, or important behavioral context, making it inadequate for an agent to use effectively without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('taskRecordName' and 'ideaRecordName') adequately. The description does not add any meaning beyond what the schema provides, such as explaining what 'Record name' entails or format examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Remove') and target resource ('a task from an idea in Assess realm'), which is clear but vague about what 'remove' entails (e.g., unlinking vs. deleting). It distinguishes from some siblings like 'assess_add_task_to_idea' but not clearly from 'assess_remove_task_from_project', which has similar structure but different target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'assess_remove_task_from_project' or other task/idea management tools. The description implies usage for removing tasks from ideas in the Assess realm, but lacks context on prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a task from a project in Assess realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task | |
| projectRecordName | Yes | Record name of the project |
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 the action without behavioral details. It does not disclose whether this is destructive (likely yes, but unconfirmed), permission requirements, side effects (e.g., task remains in system), error conditions, or response format. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core action and context, making it easy to parse quickly. Every element ('Remove', 'task from a project', 'in Assess realm') earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., destructiveness, permissions), error handling, or what happens post-removal. Given the complexity of modifying project-task relationships, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning about parameters (e.g., format of record names, relationship between task and project). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target ('a task from a project'), with the specific context 'in Assess realm' providing domain scope. It distinguishes from siblings like 'assess_remove_task_from_idea' by specifying 'project' instead of 'idea', but does not explicitly contrast with other removal or editing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites (e.g., task must exist in project), exclusions, or compare to siblings like 'assess_edit_task' or 'assess_archive_task_to_collection', leaving the agent to 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.
Authenticate user with Apple ID to access their addTaskManager data
| Name | Required | Description | Default |
|---|---|---|---|
| webAuthToken | Yes | CloudKit web auth token from Apple Sign-In |
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 authentication but fails to describe critical traits such as what happens on success/failure, whether it returns a session token, if it's idempotent, or any rate limits/errors. This leaves significant gaps for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, though it could be slightly more structured by separating usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (authentication with potential side effects), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, or error handling, making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents the 'webAuthToken' parameter fully. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain how to obtain the token or its format), meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Authenticate user') and the resource ('Apple ID to access their addTaskManager data'), providing a specific purpose. However, it doesn't explicitly differentiate this authentication tool from potential alternatives or explain why Apple ID is used over other methods, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by implying this tool is used for authentication to access data, but it lacks explicit instructions on when to use it (e.g., before other operations), when not to use it, or alternatives. No context or prerequisites are mentioned, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign contexts to tasks/projects in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| itemRecordName | Yes | Record name of the task or project | |
| itemType | Yes | Type of item (Task or Project) | |
| contextRecordName | Yes | Record name of the context to assign |
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 'assigns' contexts, implying a mutation operation, but doesn't describe what this entails—whether it overwrites existing contexts, requires specific permissions, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 operation with no annotations and no output schema), the description is incomplete. It doesn't cover behavioral aspects like permissions or side effects, nor does it explain the outcome of the assignment. For a tool that modifies data in a system with many sibling tools, more context is needed to ensure proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (itemRecordName, itemType, contextRecordName) with their types and constraints. The description adds no additional meaning beyond what the schema provides, such as explaining what 'Record name' refers to or how contexts relate to tasks/projects. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign contexts') and target ('to tasks/projects in Decide realm'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_tasks_by_context' or 'assess_create_context', which handle related but different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 existing tasks/projects and contexts), nor does it contrast with sibling tools that might handle context-related operations differently, such as 'assess_create_context' for creating contexts or 'get_tasks_by_context' for retrieving tasks by context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move project to Assess realm from Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRecordName | Yes | Project record name |
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 is a 'move' (implying mutation), but doesn't describe what this entails—whether it changes project status, affects associated tasks, requires permissions, or has side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the key action and is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral implications, success/failure outcomes, and how it fits into the broader workflow with siblings, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'projectRecordName' clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and the resource ('project'), specifying the source ('from Decide realm') and destination ('to Assess realm'). It distinguishes from some siblings like 'decide_move_project_to_do' by specifying the target realm, but doesn't explicitly differentiate from similar tools like 'moveToRealm' or 'decide_move_task_to_assess_from_decide'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, conditions for moving projects, or when to choose this over other tools like 'moveToRealm' or 'assess_archive_project_to_collection'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move project to Do realm from Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRecordName | Yes | Project record name |
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 the action is a move operation, implying mutation, but lacks details on permissions required, side effects (e.g., what happens to associated tasks), reversibility, or error conditions. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., effects, permissions) and output information, which are critical for an agent to use it correctly. The high schema coverage helps minimally, but overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'projectRecordName' documented in the schema. The description adds no additional parameter information beyond implying the project is moved, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and the resource ('project'), specifying the source realm ('Decide') and destination realm ('Do'). It distinguishes from siblings like 'decide_move_project_to_assess_from_decide' by specifying the destination, though it doesn't explicitly contrast with 'moveToRealm' which might be a generic version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., project must be in Decide realm), exclusions, or compare with similar tools like 'moveToRealm' or 'decide_move_project_to_assess_from_decide', 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.
Move task to Assess realm from Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Task record name |
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 action ('Move') but doesn't explain what 'Move' entails (e.g., does it modify task status, trigger notifications, or have side effects?), required permissions, error conditions, or response format. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the core action ('Move task') and efficiently specifies the realms involved. Every element earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., what 'Move' means operationally), error handling, and what happens post-move. While the schema covers the single parameter, the overall context for safe and effective use is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'taskRecordName' documented as 'Task record name'. The description adds no parameter-specific information beyond implying that the task must be in the Decide realm. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and the resource ('task'), specifying the source ('Decide realm') and destination ('Assess realm'). It distinguishes this tool from other move operations like 'decide_move_task_to_do' by specifying the target realm. However, it doesn't fully differentiate from 'moveToRealm' (a sibling tool), which might handle similar functionality more generically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 task must be in the Decide realm), exclusions, or comparisons to sibling tools like 'moveToRealm' or other realm-specific moves. The agent must infer usage from the name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move task to Do realm from Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Task record name |
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 performs a 'Move' operation, implying mutation, but does not disclose any behavioral traits such as permissions required, side effects (e.g., if the task's status changes), error conditions, or what happens if the task is already in the Do realm. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Move task to Do realm from Decide realm') with zero wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It does not address behavioral aspects like success/failure responses, error handling, or system state changes, which are critical for an agent to use the tool effectively in a workflow with other realm-management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'taskRecordName' documented as 'Task record name'. The description does not add any meaning beyond this, such as explaining what constitutes a valid record name or format. Since schema coverage is high, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and the resource ('task'), specifying the direction from 'Decide realm' to 'Do realm'. It distinguishes this tool from other realm-moving tools like 'decide_move_project_to_do' by focusing on tasks, but does not explicitly differentiate from 'moveToRealm' or other task-moving siblings like 'decide_move_task_to_assess_from_decide'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites (e.g., tasks must be in the Decide realm), exclusions, or compare to similar tools like 'moveToRealm' or 'decide_move_task_to_assess_from_decide', leaving the agent to 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.
Set project interval (start date and end date) in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRecordName | Yes | Record name of the project | |
| startDate | Yes | Start date in ISO format | |
| endDate | Yes | End date in ISO format |
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 'Set' operation (implying mutation) but doesn't describe what happens on success/failure, whether changes are reversible, permission requirements, or side effects. For a mutation tool with zero annotation coverage, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple setter tool and front-loads the essential information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral implications. While the schema covers parameters well, the overall context for safe and effective use is insufficient given the tool's complexity as a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (projectRecordName, startDate, endDate). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set project interval') and specifies the resource ('project') and scope ('in Decide realm'). It distinguishes this tool from siblings like 'decide_set_task_due_date' by focusing on projects rather than tasks, but doesn't explicitly contrast with other project-related tools like 'assess_edit_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., project must exist), when not to use it, or how it differs from similar tools like 'assess_edit_project' which might also modify project dates. The context 'in Decide realm' is helpful but insufficient for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set task alerts in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Task record name | |
| alertDateTime | Yes | Alert date and time in ISO format for localNotification |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a write operation ('Set') but doesn't disclose behavioral traits like whether this requires authentication, if alerts are reversible, what happens on invalid inputs, or rate limits. The description adds minimal context beyond the basic action, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, though it could be slightly more informative without losing conciseness. Overall, it's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on what the tool returns (e.g., success confirmation, error messages) and behavioral aspects like side effects or error handling. For a mutation tool with two required parameters, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description doesn't add any meaning beyond the schema (e.g., it doesn't explain 'taskRecordName' format or 'alertDateTime' implications). Baseline 3 is appropriate since the schema adequately documents parameters, but no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Set task alerts') and domain ('Decide realm'), which clarifies the basic purpose. However, it's vague about what 'alerts' entail (e.g., notifications, reminders) and doesn't distinguish this from sibling tools like 'decide_set_task_due_date' or 'decide_set_project_interval', which also involve task/project settings in the same realm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., task must exist), exclusions, or compare to related tools such as 'decide_set_task_due_date' (which might handle due dates without alerts) or general task management tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set due date for a task in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Record name of the task | |
| endDate | Yes | Due date in ISO format |
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 but only states the basic action. It doesn't mention whether this is a mutation (implied by 'Set'), permission requirements, side effects, error conditions, or response format, leaving significant behavioral gaps for a tool that modifies data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words—it directly states the tool's purpose without redundancy. It's appropriately sized for a simple tool and front-loaded with essential information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., what happens on success/failure), doesn't explain the 'Decide realm' context, and provides no usage guidance, making it inadequate for an agent to use this tool confidently in a complex environment with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the schema provides. Since schema description coverage is 100% (both parameters are well-documented with types and formats), the baseline score of 3 is appropriate—the schema does the heavy lifting, but the description doesn't enhance understanding of the parameters' roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set due date') and target resource ('for a task in Decide realm'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'decide_set_task_alert' or 'decide_set_project_interval' that also modify task/project properties in the Decide realm, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 comparisons to similar tools like 'assess_edit_task' which might also handle due dates, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark projects as completed in Do realm.
| Name | Required | Description | Default |
|---|---|---|---|
| projectRecordName | Yes | Project record name |
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 the action ('Mark projects as completed') but lacks critical behavioral details: whether this is a destructive/mutative operation, what permissions are required, how completion affects project status (e.g., moves it out of 'Do' realm), error conditions, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Mark projects as completed') and specifies the context ('in Do realm'). Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral impact (e.g., what 'completed' means operationally), error handling, or return values. For a tool that changes project state, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'projectRecordName' documented in the schema. The description adds no additional parameter semantics beyond implying it operates on projects. Since the schema fully describes the parameter, the baseline score of 3 is appropriate—the description doesn't compensate but doesn't need to given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Mark') and resource ('projects'), specifying the action and target. It distinguishes from siblings like 'do_mark_task_as_done' by focusing on projects rather than tasks, but doesn't fully differentiate from other project-related tools like 'assess_archive_project_to_collection' in terms of purpose. The purpose is clear but could be more specific about what 'completed' entails in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., projects must be in the 'Do' realm), exclusions (e.g., cannot mark archived projects), or compare to siblings like 'assess_archive_project_to_collection' or 'decide_move_project_to_do'. The agent must infer usage from the tool name and context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark tasks as completed in Do realm.
| Name | Required | Description | Default |
|---|---|---|---|
| taskRecordName | Yes | Task record name |
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 marks tasks as completed, implying a mutation operation, but doesn't disclose critical details like whether this requires specific permissions, if changes are reversible, what happens to task status, or error conditions. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 operation with no annotations and no output schema), the description is incomplete. It lacks behavioral details, usage context, and output information, making it inadequate for an agent to confidently invoke the tool without additional assumptions or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'taskRecordName' documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark tasks as completed') and the target ('in Do realm'), which is a specific verb+resource combination. It distinguishes from siblings like 'do_mark_project_as_done' by specifying 'tasks' vs 'project', but doesn't fully differentiate from other task-related tools like 'assess_edit_task' or 'decide_move_task_to_do' in terms of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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., tasks must be in the 'Do' realm), exclusions, or comparisons to sibling tools like 'assess_edit_task' or 'decide_move_task_to_do', 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.
Get all collections.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Get all collections' implies a read-only operation, but it doesn't specify whether this requires authentication, how data is returned (e.g., format, pagination), or any rate limits. For a tool with zero annotation coverage, this lack of detail is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'Get all collections' is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what 'collections' are, how results are structured, or any behavioral constraints. For a tool in a complex server with many siblings, more context is needed to ensure the agent can invoke it correctly and interpret outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate since there are no parameters to describe. This meets the baseline of 4 for tools with zero parameters, as no additional semantic value is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all collections' clearly states the verb ('Get') and resource ('collections'), making the purpose immediately understandable. It distinguishes this from sibling tools that perform assessments, authentication, decisions, or operations on other resources like ideas, projects, and tasks. However, it doesn't specify what 'collections' contain or their scope, which keeps it from being fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 any prerequisites, such as authentication, or differentiate it from similar tools like 'assess_create_collection' or 'assess_archive_project_to_collection'. Without context, an agent might struggle to choose this tool appropriately among the many sibling tools listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all ideas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Get all ideas' implies a read operation but lacks details on permissions, rate limits, pagination, or response format. It doesn't specify whether this returns all ideas unconditionally or if there are scoping constraints, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get all ideas.'), but this brevity borders on under-specification rather than efficient communication. It's front-loaded but lacks necessary elaboration for a tool with no annotations or output schema, failing to earn its place with substantive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a retrieval tool with no annotations, no output schema, and many sibling tools, the description is incomplete. It doesn't explain what 'ideas' are, how results are returned, or any behavioral traits, making it inadequate for an AI agent to use this tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the schema fully documents the lack of inputs. The description doesn't add parameter details, which is appropriate here, but it could hint at implicit filters or scoping. Given zero parameters, a baseline of 4 is justified as the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all ideas' is a tautology that essentially restates the tool name 'get_ideas' without adding meaningful specificity. It doesn't distinguish this tool from its many sibling tools (like 'get_collections', 'get_projects_by_realm', etc.) beyond the resource type, nor does it clarify what 'ideas' represent in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 numerous sibling tools for retrieving different resources (e.g., 'get_collections', 'get_projects_by_realm'), there's no indication of context, prerequisites, or exclusions for using 'get_ideas'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter projects by realm.
| Name | Required | Description | Default |
|---|---|---|---|
| realm | Yes | Realm to query (maps to realmId 1, 2, or 3) |
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 filtering but doesn't specify whether this is a read-only operation, what permissions are required, how results are returned (e.g., list format, pagination), or any side effects. For a tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for a simple filtering tool, making it easy to parse without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter set, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of projects, their properties), behavioral aspects like error handling, or how it fits into the broader context of sibling tools. For a tool with minimal structured data, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'realm' parameter fully documented via enum and description. The description adds no additional meaning beyond what the schema provides, such as explaining the mapping of realms to realmIds or usage examples. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Filter projects by realm' states the basic action (filter) and resource (projects) with a constraint (by realm), but it's vague about what 'realm' means and doesn't distinguish this tool from sibling tools like 'get_tasks_by_realm' or 'get_ideas' that also retrieve domain objects. It lacks specificity about what kind of filtering or output is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_ideas' or 'get_tasks_by_realm', nor does it mention prerequisites or context for filtering projects. It implies usage by stating the action but offers no explicit when/when-not instructions or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find ready to do items (tasks + projects) in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 finds items but doesn't describe what 'ready to do' means, how results are returned (e.g., format, pagination), or any operational constraints (e.g., permissions, rate limits). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized for a simple tool with no parameters, though it could be slightly more structured by front-loading key terms like 'Find ready items' more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks details on what 'ready to do' entails, how results are structured, and differentiation from siblings, making it functional but not fully informative for an AI agent in a complex toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 there are no parameters to document. The description appropriately doesn't discuss parameters, which is correct for this case, earning a baseline score of 4 as it doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and the target resources ('ready to do items (tasks + projects) in Decide realm'), which is specific and informative. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_stalled_items_in_decide' or 'get_undecided_items_in_decide', which reduces its differentiation value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool is appropriate, what prerequisites might exist, or how it differs from similar sibling tools like 'get_stalled_items_in_decide' or 'get_undecided_items_in_decide', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find stalled items (tasks + projects) in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but doesn't describe behavioral traits like what 'stalled' means operationally, whether this is a read-only operation, potential rate limits, authentication needs, or the format of returned data. This is inadequate for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple query with 0 parameters) and the absence of annotations and output schema, the description is minimally adequate. It specifies the resource and realm but lacks details on what 'stalled' entails, return format, or behavioral context, leaving gaps in completeness for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it meets the baseline expectation. No additional parameter information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and the target resources ('stalled items (tasks + projects) in Decide realm'), which provides specific verb+resource information. However, it doesn't explicitly differentiate from sibling tools like 'get_ready_items_in_decide' or 'get_undecided_items_in_decide' that also operate on items in the Decide realm, 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.
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, exclusions, or compare to sibling tools such as 'get_ready_items_in_decide' or 'get_undecided_items_in_decide', leaving usage context entirely implied 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.
Filter by context.
| Name | Required | Description | Default |
|---|---|---|---|
| contextRecordName | Yes | Record name of the context to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers zero behavioral information. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it returns all tasks or paginated results, what format the output takes, or any error conditions. For a tool with no annotation coverage, this represents a complete failure to disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just three words. While this conciseness comes at the expense of completeness, the description itself contains no wasted words and is perfectly front-loaded with its core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and multiple similar sibling tools, the description is completely inadequate. It doesn't explain what 'context' means in this system, what format the filtered tasks are returned in, whether this is a read-only operation, or how it differs from other task retrieval tools. The agent would struggle to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'contextRecordName' well-documented in the schema as 'Record name of the context to filter by'. The description adds no additional parameter information beyond what's already in the schema, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Filter by context' is tautological - it essentially restates the tool name 'get_tasks_by_context' without specifying what resource is being filtered. While 'tasks' is implied from the name, the description doesn't explicitly state that this tool retrieves tasks filtered by context, nor does it differentiate from sibling tools like 'get_tasks_by_realm' or 'get_tasks_today_in_do'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With multiple task-retrieval siblings (get_tasks_by_realm, get_tasks_today_in_do, get_tasks_tomorrow_in_do, get_tasks_overdue_in_do, get_tasks_soon_in_do), the description offers no indication of what distinguishes this context-based filtering from other filtering approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filter tasks by realm.
| Name | Required | Description | Default |
|---|---|---|---|
| realm | Yes | Realm to query (maps to realmId 1, 2, or 3) |
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 'Filter tasks by realm,' which implies a read-only query operation, but doesn't disclose behavioral traits such as whether it returns all tasks or paginated results, error conditions, or any rate limits. The description is minimal and lacks essential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's function without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter with full schema coverage, the description is incomplete. It doesn't explain what the tool returns (e.g., task list format), error handling, or usage context, leaving significant gaps for an agent to understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'realm' fully documented in the schema (including enum values and mapping). The description adds no additional meaning beyond the schema, such as explaining what 'realm' represents in the system context. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Filter tasks by realm' clearly states the action (filter) and resource (tasks), but it's vague about scope and doesn't differentiate from sibling tools like get_tasks_by_context or get_projects_by_realm. It specifies the filtering dimension (realm) but lacks detail about what 'tasks' encompasses in this system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_tasks_by_context or other task-filtering siblings. The description implies usage for realm-based filtering but doesn't mention prerequisites, exclusions, or specific contexts where this is preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tasks overdue in Do realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'Find tasks overdue in Do realm', implying a read-only query, but doesn't disclose behavioral traits such as authentication requirements, rate limits, return format, pagination, or what constitutes 'overdue'. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place by specifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a query with no parameters but likely returning task data), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'overdue' means, the return format, or any constraints, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 lack of inputs. The description doesn't need to add parameter semantics, and it doesn't contradict the schema. Baseline is 4 for 0 parameters, as the description appropriately doesn't discuss inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Find tasks overdue in Do realm' clearly states the action (find) and resource (tasks overdue in Do realm). It distinguishes from siblings like 'get_tasks_by_realm' or 'get_tasks_today_in_do' by specifying 'overdue' and 'Do realm', but doesn't explicitly contrast with similar tools like 'get_tasks_soon_in_do' or 'get_tasks_today_in_do' beyond the 'overdue' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, exclusions, or compare with siblings like 'get_tasks_by_realm' or 'get_tasks_today_in_do', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tasks due soon in Do realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mentions 'Find tasks due soon' but doesn't specify what 'soon' means, how results are returned (e.g., format, sorting, pagination), or any limitations (e.g., access permissions, rate limits). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a query operation with no parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'soon' entails, how results are structured, or any behavioral nuances, which could hinder an agent's ability to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter information, so it meets the baseline expectation without compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and resource ('tasks due soon in Do realm'), making the purpose understandable. However, it doesn't explicitly differentiate from similar sibling tools like 'get_tasks_today_in_do' or 'get_tasks_overdue_in_do' beyond the 'soon' qualifier, which could be ambiguous about the exact timeframe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_tasks_today_in_do' or 'get_tasks_by_realm'. The description implies usage for tasks due soon in the Do realm but lacks explicit context, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tasks due today in Do realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read operation ('Find') but doesn't disclose behavioral traits such as permissions needed, rate limits, return format, or pagination. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's simplicity, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 params, no output schema, no annotations), the description is minimally complete but lacks depth. It states what the tool does but misses behavioral context and usage guidelines, making it adequate but with clear gaps for an agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 for adequately handling the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'tasks due today in Do realm', making the purpose specific and understandable. It distinguishes from some siblings like 'get_tasks_by_realm' or 'get_tasks_overdue_in_do' by specifying the due date constraint, though not explicitly compared.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_tasks_by_realm' or 'get_tasks_tomorrow_in_do'. It lacks explicit context, prerequisites, or exclusions, leaving usage unclear relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find tasks due tomorrow in Do realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but doesn't disclose behavioral traits like whether it returns all tasks or paginated results, error conditions, or performance characteristics. For a read operation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema, no annotations), the description is adequate but minimal. It lacks details on return format (e.g., list structure, fields) or error handling, which would be helpful for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description doesn't need to explain parameters, and it appropriately doesn't mention any. Baseline for 0 parameters is 4, as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Find'), resource ('tasks'), and scope ('due tomorrow in Do realm'). It distinguishes from siblings like 'get_tasks_by_realm' (general realm tasks) and 'get_tasks_today_in_do' (today vs tomorrow), providing precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need tasks due tomorrow in the Do realm. It doesn't explicitly state when not to use it or name alternatives, but the specificity helps differentiate from siblings like 'get_tasks_overdue_in_do' or 'get_tasks_soon_in_do'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find undecided items (tasks + projects) in Decide realm.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'finds' items, implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, how results are returned (e.g., pagination, format), or any rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly conveys what the tool does in a clear and structured manner, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no annotations, no output schema), the description is adequate as a minimum viable explanation. It specifies the resource type and realm, but lacks details on return values, authentication needs, or behavioral traits. For a read operation with no structured output schema, more context on what is returned would be beneficial, but it's not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). With no parameters to document, the description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as it avoids redundancy while clearly indicating the tool operates without inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and the target resources ('undecided items (tasks + projects) in Decide realm'), which provides a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_ready_items_in_decide' or 'get_stalled_items_in_decide', which also retrieve items from the Decide realm with different filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 it over sibling tools like 'get_ready_items_in_decide' or 'get_stalled_items_in_decide', nor does it specify any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a task or project to a specific realm.
| Name | Required | Description | Default |
|---|---|---|---|
| itemRecordName | Yes | Record name of the task or project to move | |
| itemType | Yes | Type of item to move | |
| realmId | Yes | Target realm (assess=1, decide=2, do=3) |
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 'Move' implies a mutation operation, the description doesn't address important behavioral aspects: whether this requires specific permissions, whether the move is reversible, what happens to dependent items, or what the response looks like. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose with zero wasted words. It's appropriately sized for a simple operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral implications, error conditions, or what happens after the move operation. Given the complexity of moving items between realms (which likely affects workflow state), more context about the operation's effects and constraints would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters with their types, enums, and descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining the relationship between parameters or providing usage examples. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move') and target resources ('a task or project to a specific realm'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'decide_move_project_to_assess_from_decide' or 'decide_move_task_to_assess_from_decide', which appear to perform similar realm-moving operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 multiple sibling tools that appear to handle realm transitions (e.g., 'decide_move_project_to_assess_from_decide', 'decide_move_task_to_assess_from_decide'), there's no indication of when this general 'moveToRealm' tool should be preferred over those more specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
assess_add_task_to_ideaassess_add_task_to_projectassess_archive_project_to_collectionassess_archive_task_to_collectionassess_create_collectionassess_create_contextassess_create_ideaassess_create_projectassess_create_taskassess_edit_ideaassess_edit_projectassess_edit_taskassess_remove_task_from_ideaassess_remove_task_from_projectauthenticate_userdecide_assign_contextdecide_move_project_to_assess_from_decidedecide_move_project_to_dodecide_move_task_to_assess_from_decidedecide_move_task_to_dodecide_set_project_intervaldecide_set_task_alertdecide_set_task_due_datedo_mark_project_as_donedo_mark_task_as_doneget_collectionsget_ideasget_projects_by_realmget_ready_items_in_decideget_stalled_items_in_decideget_tasks_by_contextget_tasks_by_realmget_tasks_overdue_in_doget_tasks_soon_in_doget_tasks_today_in_doget_tasks_tomorrow_in_doget_undecided_items_in_decidemoveToRealmThe tools have clear purposes within their realms (Assess, Decide, Do) and operations (create, edit, move, get), but there is significant overlap in functionality across realms. For example, multiple 'move' tools exist for tasks and projects between realms, and many 'get' tools filter by similar criteria (realm, context, date), which could cause confusion about which to use for specific queries.
Most tools follow a consistent snake_case pattern with a clear structure: realm_verb_noun or verb_noun_in_realm. However, there are minor deviations like 'authenticate_user' (no realm prefix) and 'moveToRealm' (camelCase, inconsistent with others), which slightly disrupt the overall consistency.
With 38 tools, the count is excessive for a task management server, leading to potential bloat and confusion. Many tools could be consolidated (e.g., multiple 'get' filters into one with parameters), and the high number suggests over-specialization rather than a well-scoped set, making it heavy for agents to navigate.
The tool set provides comprehensive coverage for task management across Assess, Decide, and Do realms, including CRUD operations (create, edit, get), lifecycle management (move, archive, mark as done), and filtering by various criteria (realm, context, date). No obvious gaps are present; agents can handle full workflows from idea capture to completion.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dragosroua/addtaskmanager-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
