Model Context Protocol server for Rize — automatic time tracking for professionals and teams.
Connect your AI assistant (Claude, ChatGPT, Cursor, etc.) to your Rize account to manage time entries, clients, projects, contracts, profitability, and team members through natural language.
Category | Tools | Description |
User |
| Authenticated user profile, org info, and tool documentation |
Time Entries |
| Full CRUD for time entries with date range, client, project, task, and label filters |
AI Suggestions |
| Generate, review, and approve AI-powered time entry suggestions |
Time Analysis |
| Hours breakdown by client/project/task/label, app usage, and tracking events |
Clients |
| Manage client records in your workspace |
Projects |
| Manage projects under clients |
Tasks |
| Manage tasks under projects |
Labels |
| View workspace labels for categorization |
Team |
| Team roster, roles, rates, and invitations |
Contracts |
| Billing contracts with clients (hourly, retainer, fixed fee, hybrid) |
Profitability |
| Revenue, costs, margins, budget burn, and monthly trends |
Billing |
| Log expenses and recognized revenue against contract periods |
Notes |
| Add notes to time entries or dictate time in natural language |
Related MCP server: timely-mcp-server
Connect directly in Claude's MCP integration settings using the server URL:
https://mcp.rize.io/mcpClaude will handle OAuth authentication automatically — no API key needed.
Sign up at rize.io and generate an API key from Settings > API.
npm install -g rize-mcp-serverOr clone and build from source:
git clone https://github.com/rize-io/mcp-server.git
cd mcp-server
npm install
npm run buildClaude Desktop — add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"rize": {
"command": "npx",
"args": ["-y", "rize-mcp-server"],
"env": {
"RIZE_API_KEY": "your-api-key"
}
}
}
}Claude Code — add to your project's .mcp.json or ~/.claude/mcp.json:
{
"mcpServers": {
"rize": {
"command": "npx",
"args": ["-y", "rize-mcp-server"],
"env": {
"RIZE_API_KEY": "your-api-key"
}
}
}
}Cursor — add to Cursor settings under MCP Servers:
{
"rize": {
"command": "npx",
"args": ["-y", "rize-mcp-server"],
"env": {
"RIZE_API_KEY": "your-api-key"
}
}
}Pre-built workflows that combine multiple tools for common tasks. Use these as prompts with your connected Rize MCP server.
Skill | Description |
Summarize hours by client and project for the week with daily breakdown and gap detection | |
Analyze org-wide and per-contract profitability, flag at-risk contracts and margin trends | |
Compare team members' hours against capacity, surface utilization and burnout risk | |
Gather billable time entries and expenses for a client and period, formatted for invoicing | |
Analyze app usage and focus patterns to find productivity improvements | |
Walk through AI-generated time entry suggestions — approve, reject, edit, or regenerate |
"What did I work on today?"
"How much time did I spend on Project X this week?"
"Generate time entries for yesterday"
"Show me my team's utilization this week"
"What's the profitability on the Acme contract?"
"Create a new project called Q3 Marketing under client Acme"
"Show me my app usage for the last 7 days"
"Review my pending time entry suggestions"
The server connects to the Rize GraphQL API using Bearer token authentication. All time parameters use ISO 8601 format and respect the user's configured timezone.
Node.js 20+ (for local stdio mode)
Rize account (rize.io)
MIT
Create a new client
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Client name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only repeats the tool's name. No disclosure of side effects, permissions, or what happens upon successful creation.
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 very short but lacks structure and detail. It is concise but does not fully earn its place; it is essentially a tautology.
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 low complexity (one required parameter, no output schema), the description is minimally adequate. However, it would benefit from mentioning the result of the 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 coverage is 100% for the single parameter 'name', which has a baseline description. The tool description adds no additional context beyond the schema, resulting in a baseline score of 3.
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?
Clearly states 'Create a new client' with verb and resource. Distinguishes from sibling tools that act on different resources (project, session, task).
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 on when to use this tool vs alternatives. Does not mention prerequisites or 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 project
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'Create a new project' without disclosing behavioral traits such as whether it creates in a default workspace, allows duplicate names, requires authentication, or returns an ID. This lack of detail reduces 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, short sentence that conveys the essential action. It is concise with no unnecessary words or repetition.
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 simple tool with one parameter and no output schema, the description is minimally adequate. However, it omits important context like expected return values, error conditions, or side effects, leaving gaps in completeness.
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 covers 100% of parameters (one 'name' field described as 'Project name'). The description does not add any additional meaning beyond what the schema already provides, meeting the baseline for high coverage but not exceeding it.
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 'Create a new project' clearly states the action (create) and resource (project). It distinguishes well from sibling tools like create_client, create_session, and create_task, as each targets a different entity.
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 (e.g., when to create a project vs. update one). No prerequisites, constraints, or conditions are mentioned, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new time session
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) | |
| sessionType | Yes | Session type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'create', not disclosing effects on existing sessions, whether it creates a running or completed session, or any prerequisites. No behavioral details are given.
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 concise sentence. However, it is slightly under-specified. It earns no extra points for brevity at the expense of completeness.
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 should explain return values, side effects, or prerequisites. It only states the creation action, leaving the agent underinformed.
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 coverage is 100% with clear descriptions for each parameter (ISO8601 format, enum values). The description adds no additional meaning beyond what the schema provides.
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 'Create a new time session' is a clear verb+resource combination. It distinguishes the tool's basic purpose but does not differentiate it from related tools like 'start_session_timer' or 'extend_current_session'.
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. The description does not explain when manual creation is preferred over starting a timer or extending a session.
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
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Task name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Create a new task'. This fails to disclose any behavioral traits such as side effects, required permissions, or whether the task is created immediately or queued.
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 with one short sentence, but given the context of 27 sibling tools, it could benefit from more detail to improve scannability and usefulness.
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 simple tool with no output schema and one parameter, the description is incomplete. It lacks explanation of what constitutes creating a task (e.g., minimal required fields, behavior, return value).
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 a single parameter 'name' described as 'Task name'. The description adds no additional meaning beyond the schema, so it meets the baseline of 3.
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 'create' and the resource 'task', making the primary action evident. However, it does not differentiate from sibling tools like 'create_client' or 'create_project', which also perform create operations on different resources.
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 'create_client' or 'update_task'. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a client
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Client ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Delete' implies destruction, but there is no mention of irreversibility, cascading effects, permissions, or recovery options.
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, concise sentence with no wasted words. It could be slightly expanded for context 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 low complexity (one parameter, no output schema), the description is minimally adequate. However, it lacks behavioral context about consequences of deletion, which is essential for a destructive action.
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% for the single parameter 'id' with description 'Client ID'. The description adds no additional meaning beyond the schema, so baseline 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 'Delete a client' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_client, update_client, and other delete operations for different resources.
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 conditions for deletion, prerequisites, or consequences. It only states the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a project
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Delete a project', implying destructiveness, but lacks details on irreversibility, cascading effects on tasks or time entries, and required permissions. With no annotations, the burden is on the description to disclose these 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 very concise (3 words), but it lacks structure and important context. It is not front-loaded with essential information that would help the agent decide to use it.
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 destructive nature and the absence of annotations and output schema, the description is insufficient. It does not address what happens to associated tasks, sessions, or time entries, nor does it mention error conditions like invalid IDs.
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 provides 100% coverage with a description for the single parameter 'id' ('Project ID'). The tool description adds no additional meaning beyond that, so it meets the baseline of 3.
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 'Delete a project' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_project, update_project, and delete_task. It is unambiguous about the action and object.
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. There is no mention of prerequisites (e.g., project must have no active tasks) or scenarios where deletion should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a task
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates destruction but omits critical details like whether deletion is hard or soft, required permissions, or side effects on related 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?
At one sentence, it is extremely concise but under-specified. Conciseness should not sacrifice completeness; this misses critical 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 simple tool with one parameter and no output schema, the description still lacks completeness. It does not mention return values, constraints, or consequences of deletion.
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 coverage is 100% with the 'id' parameter described as 'Task ID'. The description adds nothing beyond the schema, but given full coverage, the baseline 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 'Delete a task' is a tautology that merely restates the tool name without specifying the scope or type of task. It does not distinguish this from actions like marking a task as complete.
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 update_task or other deletion tools. The context signals list related siblings but the description offers no direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend the current session by specified minutes
| Name | Required | Description | Default |
|---|---|---|---|
| minutes | Yes | Minutes to extend |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the session must be active, any side effects, or error conditions (e.g., extents past limit). The mutation intent is clear but important behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no redundancy or unnecessary words. It efficiently conveys the tool's purpose without extraneous 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 the simplicity of the tool (one parameter, no output schema, no annotations), the description is minimally adequate. However, it lacks context about the session state (e.g., must be active) or constraints on minutes, which are reasonable expectations for a mutation 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 description for 'minutes' ('Minutes to extend') matches the tool description exactly. With 100% schema coverage, the description adds no extra meaning beyond what the schema already provides, meeting the baseline of 3.
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 'extend' and the resource 'current session' with specific detail 'by specified minutes'. It is unambiguous and distinct from sibling tools like start_session_timer or stop_session_timer, though no explicit differentiation 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?
No guidance is given on when to use this tool versus alternatives (e.g., creating a new session vs. extending). The description does not mention prerequisites or scenarios, 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 apps and websites usage within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose any behavioral traits (e.g., read-only, side effects, permissions). Fails to add value 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?
Single sentence, no redundancy, efficiently conveys the core action and 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?
For a simple get tool with well-documented parameters, description is adequate but missing output details and behavioral context. Could be more complete for agent confidence.
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 coverage is 100% with parameters 'startTime' and 'endTime' described as ISO8601 strings. Description adds no additional parameter meaning beyond 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?
Description clearly states verb 'get', resource 'apps and websites usage', and context 'within a time range'. Distinguishes from siblings which target different resources.
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 vs alternatives. The description implies it's for time-range queries, but lacks 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.
Get time spent by category within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It indicates a read operation but does not disclose potential limitations, aggregation behavior, or data format. Missing details on what 'time spent' includes (e.g., billable vs. non-billable).
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?
Single sentence of 10 words, no redundancy, front-loaded with the key action and resource. Efficient and scannable.
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?
Adequate for a simple two-param tool, but lacks explanation of return format or how categories are defined relative to other entities. Without output schema, agents need more context to interpret results 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 coverage is 100% with descriptions for both parameters (ISO8601 strings). Description adds no extra meaning beyond what the schema already provides, meeting baseline.
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?
Description clearly states the verb (Get), the resource (time spent by category), and the scope (within a time range). It distinguishes from sibling tools like get_client_time_entries which filter by client, not category.
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 on when to use this tool versus alternatives such as get_summary or other time entry tools. Lacks context for when category-based filtering is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific client by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Client ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Get' without mentioning permissions, error handling, or what happens if ID is not found.
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?
Single concise sentence with no extraneous 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 simple get-by-ID tool, description is adequate but could mention that it returns the full client object.
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 coverage is 100% for the single parameter 'id', and the description adds no extra meaning beyond the schema's 'Client ID'.
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 'Get' and the resource 'client', and distinguishes from siblings like 'get_clients' (plural) and 'get_client_time_entries'.
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?
Description provides no guidance on when to use this tool vs alternatives like 'get_clients' for listing all clients.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all clients with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Pagination cursor | |
| first | No | Limit results | |
| query | No | Search query | |
| statuses | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description does not disclose pagination behavior, default limits, authentication needs, or whether results are ordered. 'List all' is ambiguous with optional filters.
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?
Extremely concise single sentence, front-loaded with purpose. Could be considered under-specified but no wasted words.
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?
No output schema provided; description doesn't hint at return format, pagination handling, or structure. With 4 parameters and no behavioral guidance, it feels 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?
Schema coverage is 100%, baseline is 3. Description adds no extra meaning beyond schema; 'optional filtering' is implicit.
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?
Description clearly states verb 'List', resource 'clients', and capability 'optional filtering'. Distinguishes from sibling 'get_client' (singular) and CRUD 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 on when to use this tool over alternatives like 'get_client' (single client) or when filtering is appropriate. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get time entries by client within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose behavior such as return format, authentication requirements, or any side effects. The description adds minimal transparency about the tool's 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 concise sentence with no unnecessary words, but it could be 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?
With no output schema and no annotations, the description is too minimal. It does not explain how the tool filters by client or what the return structure is, leaving significant gaps 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?
Schema description coverage is 100% with both parameters having clear descriptions in the schema. The description does not add additional meaning beyond what the schema provides, so baseline score applies.
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 'Get time entries by client within a time range,' which is clear about the general action, but it contradicts the input schema that has no client identifier parameter, making it ambiguous how the client is specified.
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 siblings like get_project_time_entries or get_task_time_entries, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently active session
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states 'get', implying a read operation, but does not mention any side effects, authentication needs, or what constitutes a session.
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 conveys the core functionality without any extraneous information. It is appropriately concise and front-loaded.
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 simple getter with no parameters, the description is adequate but minimal. It does not describe the return value or provide context on what 'session' includes, which would be helpful given no output schema.
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 zero parameters with 100% coverage, so the description cannot add meaning beyond the schema. The description does not introduce any parameter info, but no parameters exist, so this is acceptable per the baseline.
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 and resource: 'Get the currently active session'. It uses a specific verb and resource, distinguishing it from sibling tools like get_sessions which likely lists all sessions.
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 does not contrast with get_sessions or extend_current_session to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current authenticated user profile
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description indicates a read operation (get) but does not disclose any behavioral traits such as authentication requirements or side effects. It is minimally adequate for a simple retrieval 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, direct sentence with no wasted words, efficiently conveying the tool's purpose.
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 simplicity of the tool (no parameters, no output schema), the description sufficiently covers what the tool does and what it returns, though it could mention the output format.
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?
There are no parameters, and the schema coverage is 100%. The description adds no parameter information, but with zero parameters, the baseline score of 4 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 specifies the verb 'Get' and the resource 'current authenticated user profile', and it distinguishes from sibling tools that deal with clients, projects, tasks, etc.
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 (getting current user profile) but does not provide explicit guidance on when to use this tool versus alternatives, though alternatives are not directly relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific project by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'get', implying a read operation. It does not disclose error handling (e.g., if project not found), authentication requirements, or return behavior, leaving the agent uninformed.
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 with no unnecessary words. While concise, it could be more structured by front-loading key information like the return type.
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 (one parameter, no output schema, no annotations), the description is adequate but lacks details about return values or error responses that would make it fully complete.
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 coverage is 100% with the 'id' parameter described as 'Project ID'. The description adds no further meaning beyond the schema, which is acceptable for a single required parameter.
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 (get) and resource (project) and the required parameter (ID). It distinguishes itself from sibling tools like get_projects (plural) and create_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?
No guidance on when to use this tool versus alternatives like get_projects, create_project, or update_project. The description lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Pagination cursor | |
| first | No | Limit results | |
| query | No | Search query | |
| statuses | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only says 'list all projects', but does not disclose whether it is read-only, pagination details, or rate limits. Behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words) and front-loaded. Every word earns its place, though it could include slightly more context without becoming verbose.
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 4 optional parameters, no output schema, and no annotations, the description is too minimal. It does not explain pagination behavior, result format, or how filtering works together.
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 descriptions cover 100% of the 4 parameters, so baseline is 3. The description adds no additional meaning beyond the schema, but it does not need to since the schema is complete.
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 tool lists all projects with optional filtering. It uses a specific verb and resource, but does not differentiate from the sibling tool 'get_project' which retrieves a single 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?
There is no guidance on when to use this tool versus alternatives like 'get_client' or 'get_tasks'. No context about prerequisites or limitations is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get time entries by project within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states what the tool does, with no details on pagination, ordering, rate limits, or response behavior for empty ranges.
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?
Single sentence, 9 words, no redundant information. Front-loaded with purpose.
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?
Tool is simple with 2 required parameters and full schema coverage. However, no output schema is provided, and description omits common context like result format or pagination, leaving gaps.
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 coverage is 100%; both parameters have descriptions in the schema. The description adds no additional meaning beyond stating 'within a time range', which is already implicit from the 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?
Description clearly states the action ('Get'), the resource ('time entries'), and the scope ('by project within a time range'). This distinguishes it from siblings like get_client_time_entries or get_task_time_entries.
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 siblings. Does not mention when not to use or mention alternative tools like get_client_time_entries for client-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sessions within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral details such as whether sessions are time ranges, overlapping logic, or return format. The minimal description fails to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, but it could be slightly more structured (e.g., noting scope or no filtering).
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 simple read tool with no output schema, the description is incomplete—missing return type (e.g., list of session objects), pagination info, or scope. It does not fully cover what the agent needs to know.
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 coverage is 100% with clear ISO8601 descriptions. The description adds no extra meaning beyond implying the parameters define the time range, so baseline of 3 applies.
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 sessions within a time range' clearly specifies the action (get) and resource (sessions) with a time constraint, distinguishing it from sibling tools like get_current_session or session timers.
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 on when to use this tool versus alternatives (e.g., get_current_session for current session, or time entry tools). The description does not mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get productivity summary (total, focus, meeting, break time) within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
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 only implies a read operation ('Get') but does not explicitly state that it is non-destructive, requires any authentication, or has rate limits. It adds no behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, efficiently conveying the core purpose. It front-loads the action and resource. However, it could be slightly more structured by listing the categories explicitly at the start.
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 (2 parameters, no output schema), the description covers the input constraint and hints at the output categories. It is nearly complete for an agent to understand usage, though it lacks explicit mention of the output format or that it is a read 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?
The input schema already describes both parameters ('startTime' and 'endTime') as ISO8601 strings with 100% coverage. The description does not add new information about the parameters beyond stating 'within a time range', which does not enhance understanding. Baseline 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 uses a specific verb ('Get') and specifies the resource ('productivity summary') along with the categories included ('total, focus, meeting, break time') and the constraint ('within a time range'). This clearly distinguishes it from sibling tools like 'get_sessions' or 'get_clients'.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites, context, or exclusions. It only states what the tool does without any decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific task by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states 'Get' implying a read-only operation, but does not disclose error conditions (e.g., if task not found), access requirements, or side effects. Minimal transparency 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 no extraneous 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?
While adequate for a simple retrieval with one parameter, the description lacks details about the expected return value (e.g., a task object) or error handling, which would be valuable given no output schema.
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 coverage is 100% for the single parameter 'id' with description 'Task ID'. The description adds no additional meaning beyond what the schema already provides, meeting the baseline for high 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 'Get a specific task by ID' clearly states the action (Get), resource (task), and the specific method (by ID). It distinguishes from sibling tools like get_tasks (which retrieves all tasks) and other get_* 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 explicit guidance on when to use this tool versus alternatives like get_tasks or get_task_time_entries. The description implies use when an ID is known, but provides no exclusions or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tasks with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Pagination cursor | |
| first | No | Limit results | |
| query | No | Search query | |
| statuses | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It does not disclose pagination behavior, retrieval scope (e.g., all tasks for the user or a project), or any side effects. The word 'list' implies read-only, but this is not explicit.
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 at 4 words. While it is not wasteful, it may be too brief given the tool has 4 parameters and no output schema. It is front-loaded with the core action, but could include more detail without harming 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 lack of output schema and the presence of many sibling tools, the description is incomplete. It does not explain pagination, default behavior when no filters are applied, what 'all tasks' means, or how filters interact. A more complete description would address these gaps.
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 (each parameter has a basic description). The tool description adds nothing beyond the schema, so the baseline score of 3 is appropriate. The schema descriptions are minimal (e.g., 'Search query' without specifying fields), but the tool description does not improve 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 'List all tasks with optional filtering' clearly states the verb (list) and resource (all tasks), and hints at filtering capability. However, it does not explicitly distinguish from the sibling tool 'get_task' which retrieves a single task, but the name makes the distinction obvious.
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_task' or which filtering parameters to use in different contexts. The description simply states the capability without any contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get time entries by task within a time range
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | Yes | End time (ISO8601) | |
| startTime | Yes | Start time (ISO8601) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, rate limits, or authentication requirements. It merely restates the basic function without adding safety or side-effect 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 sentence, efficiently conveying core functionality. However, it sacrifices potential additional context that could aid understanding without significant verbosity.
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 output schema and no annotations, the description lacks details about return format or the 'by task' filtering mechanism (only implied by name). It is adequate for a simple tool but leaves gaps for an agent deciding between similar 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 already describes both parameters (startTime, endTime) with ISO8601 format, achieving 100% coverage. The description adds no additional meaning or usage constraints (e.g., time zones, inclusiveness), so baseline score applies.
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 'Get' and the resource 'time entries by task within a time range', making the purpose distinct from sibling tools like get_client_time_entries and get_project_time_entries.
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 get_project_time_entries or get_client_time_entries. The description implies task-specific filtering but does not outline context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new focus session timer
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks detail on behavioral traits such as whether it can start a timer if one is already active, if it requires a current session, or if it is idempotent. No annotations are provided to fill this 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 concise sentence that front-loads the key action. No extraneous information is 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 the simple nature of the tool (no parameters, no output schema), the description is somewhat complete but omits important behavioral context like timer state management and interactions with other session 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 tool has no parameters, and the schema coverage is 100% (since there are no properties). The description does not need to add parameter details, so the baseline of 4 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 (start a new focus session timer) with a specific verb and resource. However, it does not differentiate from sibling tools like 'create_session' or 'stop_session_timer', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'extend_current_session' or 'create_session'). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the current session timer
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states 'stop' implying mutation, but does not disclose prerequisites (e.g., active session required), side effects, or error conditions. This is insufficient for safe invocation.
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, complete sentence with no extraneous information. Every word is necessary.
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 output schema, no annotations, and the presence of related siblings, the description is adequate but not rich. It omits expected return behavior and conditions for success/failure, making it minimally complete for a simple action.
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 zero parameters and schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline for 0 params is 4, and the description meets it.
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 ('stop') and the resource ('current session timer'), which is specific and distinct from siblings like 'start_session_timer' and 'extend_current_session'.
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 (e.g., only if a timer is active) or alternatives. Siblings exist but are not mentioned, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing client
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Client ID | |
| name | No | New name | |
| color | No | Color hex code | |
| status | No | Status (active, archived) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It does not indicate side effects (e.g., partial vs full update), required permissions, or whether changes are reversible. The description 'Update an existing client' adds no insight beyond the tool's name.
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 with a single sentence. While it could benefit from slightly more detail, it contains no redundant information and is well-structured. However, minimalism here sacrifices clarity.
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 mutates a resource and has no output schema, the description does not explain return values, error behavior, or whether the update is partial. This leaves agents with incomplete context for correct invocation.
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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's field descriptions. Since the schema already explains each parameter adequately, the description does not need to compensate.
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 'update' and resource 'client', which distinguishes it from sibling tools like create_client or delete_client. However, it does not specify which fields can be updated, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., create_client for new clients, or update_project for projects). The description does not mention prerequisites or cases where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing project
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID | |
| name | No | New name | |
| color | No | Color hex code | |
| status | No | Status (active, archived) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility. It only states 'Update an existing project' without disclosing that the tool modifies specific fields (name, color, status), whether it returns the updated object, or any side effects. The agent lacks information on idempotency or error 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 and avoids redundancy. However, it is overly terse and could benefit from additional context, making it efficient but insufficient.
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?
The tool has 4 parameters, no output schema, and no annotations. The description fails to mention return values, potential errors, or parameter constraints beyond schema. It is not complete enough for an agent to confidently 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 coverage is 100%, with each parameter already described. The description adds no new meaning beyond the schema's parameter descriptions. It is adequate but does not enhance 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 verb 'update' and resource 'project', distinguishing it from create, delete, and get project siblings. However, it does not explicitly differentiate itself from other update tools like update_client or update_task.
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. There is no mention of prerequisites, such as requiring the project to already exist, or exclusions like not updating non-existent projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing task
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID | |
| name | No | New name | |
| color | No | Color hex code | |
| status | No | Status (active, archived) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like mutation, return value, or permissions. It only says 'update', which implies mutation, but lacks any further detail.
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?
Single sentence, front-loaded, no extraneous words. Very efficient.
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 output schema and simple parameters, the description should at least hint at return value or required permissions. It is too sparse for a mutation 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?
Input schema has 100% description coverage for parameters, so the schema already explains each parameter. The description adds no extra semantics, meeting the baseline.
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?
Description clearly states 'Update an existing task', specifying verb and resource. However, it does not distinguish from other update tools like update_client or update_project beyond the resource name, which is implicit.
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 on when to use this tool versus alternatives, no exclusions or context provided.
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.
v1.0.0create_clientcreate_projectcreate_sessioncreate_taskdelete_clientdelete_projectdelete_taskextend_current_sessionget_apps_and_websitesget_categoriesget_clientget_client_time_entriesget_clientsget_current_sessionget_current_userget_projectget_project_time_entriesget_projectsget_sessionsget_summaryget_taskget_task_time_entriesget_tasksstart_session_timerstop_session_timerupdate_clientupdate_projectupdate_taskEach tool targets a specific entity and action (e.g., client, project, task, session), with clear scope. No two tools have overlapping purposes; even the many 'get' tools are differentiated by the resource they retrieve.
All tools follow a consistent `verb_entity` pattern in snake_case (e.g., `create_client`, `get_clients`, `stop_session_timer`). No mixing of conventions.
28 tools is on the high side, but each covers a distinct operation across multiple entities (clients, projects, tasks, sessions, time entries, categories). The count feels appropriate for a comprehensive time-tracking server.
CRUD operations exist for clients, projects, and tasks. Session management includes start, stop, extend, and current session tracking. Queries cover time entries by entity, categories, apps/websites, and summary. Minor gaps: no delete or update for sessions, but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rize-io/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
