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., "@EARLY App MCP Server Show today's time entries"
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 unofficial Model Context Protocol (MCP) server that provides access to the EARLY app time tracking public API.
EARLY is a time tracking application with a comprehensive public API. This MCP server enables AI assistants to interact with time tracking data through the public EARLY API.
create_time_entry - Create a new time entry with flexible time parameters
edit_time_entry - Edit an existing time entry
get_time_entries - Get time entries for a date range
delete_time_entry - Delete a time entry by ID
start_timer - Start tracking time for a project
stop_timer - Stop the currently running timer
get_active_timer - Get information about the currently running timer
update_active_timer - Update the description of the currently running timer
list_activities - Get all activities
create_activity - Create a new activity (project)
update_activity - Update an existing activity
archive_activity - Archive or delete an activity
generate_report - Generate summary reports for time entries
get_current_user - Get current user information
early://time-entries/today - Today's time entries with detailed JSON data
early://time-entries/week - Current week's time entries
early://activities - All activities (active + inactive + archived)
early://activities/active - Only active activities
Related MCP server: TimePRO MCP Server
No installation required! Use npx to run the server:
npx @janfincke/early-mcp-server{
"mcpServers": {
"early-time-tracker": {
"command": "npx",
"args": [
"@janfincke/early-mcp-server"
],
"env": {
"EARLY_API_KEY": "your-early-api-key-here",
"EARLY_API_SECRET": "your-early-api-secret-here"
}
}
}
}Get your API credentials from the EARLY desktop app: Settings → Developer → API Keys
Comprehensive documentation is available at janfincke.github.io/early-mcp-server including:
Getting Started Guide - Installation and setup
Tools Reference - Complete documentation for all 6 tools
Integration Guide - Claude Desktop and MCP client setup
Troubleshooting - Common issues and solutions
Base URL: https://developers.early.app/
Documentation: Postman Collection
Authentication: API Key (assumed)
Fork the repository
Create a feature branch
Make your changes
Add tests
Submit a pull request
MIT License - see LICENSE file for details.
Archive or delete an activity
| Name | Required | Description | Default |
|---|---|---|---|
| activityId | Yes | The ID of the activity to archive/delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true, so the destructive nature is known. The description adds 'archive or delete' but is ambiguous and does not explain reversible effects or what happens to 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?
The description is a single short sentence, but it sacrifices clarity for brevity. It could be more informative without significant length increase.
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 a simple input, the description still fails to explain the effect of archiving vs deleting, how it differs from other destructive actions, or any side effects. Incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter activityId. The description adds no additional meaning beyond the schema, so baseline score 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 'Archive or delete an activity' is somewhat unclear because it presents two possible actions without specifying when each occurs or if they are the same. It does not distinguish from sibling tools like delete_time_entry or update_activity.
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 update_activity or delete_time_entry. 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.
Create a new activity (project)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new activity/project | |
| color | No | Color code for the activity | |
| billable | No | Whether the activity is billable | |
| clientId | No | Client ID to associate with the activity | |
| description | No | Description of the activity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint to false, indicating non-destructive behavior. The description adds no extra behavioral context beyond the fact that it creates an activity, such as permissions or side effects. Since it does not contradict annotations, a score of 2 is warranted.
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 is front-loaded and efficient. It is not overly verbose, but could be slightly more informative without becoming wordy.
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 all parameters are well-documented in the schema and there is no output schema, the description is adequate. The parenthetical '(project)' adds helpful context to disambiguate from other activity types. However, it does not mention return behavior or post-creation steps.
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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for each 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 'Create a new activity (project)', using a specific verb and resource. It distinguishes from sibling tools like update_activity or archive_activity by focusing on creation.
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 creation context but provides no explicit guidance on when to use this tool versus alternatives like update_activity or list_activities. There are no when-not or exclusion criteria mentioned.
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 entry with flexible time parameters
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | No | End time in ISO 8601 format (e.g., 2024-01-10T17:00:00) | |
| duration | No | Duration in minutes (alternative to specifying start/end times) | |
| projectId | Yes | The ID of the activity to track time for | |
| startTime | No | Start time in ISO 8601 format (e.g., 2024-01-10T09:00:00) | |
| description | Yes | Description of the work being done |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the creation intent, which is consistent with the destructiveHint=false annotation (creation is non-destructive). However, it does not disclose behavioral details such as permissions required, whether duplicate entries are allowed, or what the response format is.
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 is front-loaded and easy to parse. It is concise but not overly terse.
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 absence of an output schema and the existence of sibling tools that could be confused, the description is incomplete. It does not explain important constraints (e.g., cannot specify both duration and start/end) or what the tool returns upon success.
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 baseline is 3. The description adds minimal value beyond the schema, only hinting at flexibility without clarifying the mutual exclusivity between duration and start/end times.
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 'Create a new time entry', which clearly specifies the verb and resource. It mentions 'flexible time parameters', hinting at alternatives in time specification but does not explicitly differentiate from siblings like 'start_timer' or 'edit_time_entry'.
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 such as 'start_timer' (for starting a running timer) or 'edit_time_entry' (for updating). Usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a time entry by ID
| Name | Required | Description | Default |
|---|---|---|---|
| timeEntryId | Yes | The ID of the time entry to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint: true. Description does not add extra behavioral details beyond the annotation, but annotations cover the core trait.
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?
One short sentence, front-loaded with action. Could be slightly more informative but is concise and not 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?
For a simple delete operation with one parameter and annotations indicating destructiveness, the description is complete enough. No output schema 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 coverage is 100% with a clear description for timeEntryId. Description does not add additional meaning beyond what the schema already 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?
Description clearly states 'Delete a time entry by ID' with a specific verb and resource, distinguishing it from sibling tools like create_time_entry and edit_time_entry.
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 edit_time_entry or get_time_entries. Missing context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing time entry
| Name | Required | Description | Default |
|---|---|---|---|
| endTime | No | New end time in ISO 8601 format | |
| startTime | No | New start time in ISO 8601 format | |
| activityId | No | New activity ID to assign this entry to | |
| description | No | New description/note for the entry | |
| timeEntryId | Yes | The ID of the time entry to edit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'destructiveHint: false' annotation indicates the operation is non-destructive, and the description is consistent. However, the description adds no additional behavioral context, such as whether it is a partial update or if validation occurs. Lack of contradiction between description and 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 sentence, concise and to the point. It is appropriately sized for a simple mutation tool, though it could be slightly expanded 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 5 parameters and no output schema, the description is insufficient. It does not clarify whether the tool performs a partial update (patch) or requires all fields, nor does it mention return behavior. This lack of completeness could lead to misunderstandings for the 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 description of parameters is already in the schema. The tool description adds no extra meaning beyond the schema, achieving 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?
The description 'Edit an existing time entry' clearly states the verb (edit) and resource (time entry). It distinguishes from siblings like 'create_time_entry' (create new) and 'delete_time_entry' (delete). However, it could be more precise about what fields are editable.
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 'create_time_entry' or 'delete_time_entry'. The description does not explain prerequisites or context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a summary report of time entries for a given period
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | End date in YYYY-MM-DD format | |
| projectId | No | Filter by activity ID (optional) | |
| startDate | Yes | Start date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate that. The description adds 'summary report' but lacks details on behavior such as performance implications or data aggregation approach. It provides minimal extra value over 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?
A single, well-structured sentence that clearly communicates the core purpose. No unnecessary words, and it is front-loaded with the action.
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, the description should explain what the report contains or returns (e.g., format, data included). It does not, leaving the agent to guess. Also lacks context like report type (PDF, CSV, etc.). The description is insufficient for confident 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%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema provides; it only mentions the period generally.
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 generates a summary report of time entries for a given period, using specific verb 'generate' and resource 'report'. It effectively distinguishes from sibling tools like get_time_entries which list 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 guidance on when to use this tool versus alternatives. Given siblings include get_time_entries, the description should indicate that generate_report is for aggregated summaries while get_time_entries is for raw lists, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently running timer
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, and the description does not contradict this. However, it adds no additional behavioral context beyond what annotations already convey, such as behavior when no timer is active.
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, front-loaded sentence with no wasted words, perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is basic. It omits specifics about what 'information' is returned (e.g., activity name, elapsed time), which could help the agent understand the 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?
There are no parameters, so schema coverage is 100%. The description does not add parameter semantics but the baseline for zero parameters is 4, and it is acceptable.
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 'information about the currently running timer', effectively distinguishing it from sibling tools like start_timer and stop_timer.
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 or when not to use this tool. While usage is implied by the simple no-parameter design, the description lacks explicit context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently authenticated user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds no additional behavioral context beyond stating the tool gets information, which is consistent. No contradictions, but no added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is optimally 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?
Although the tool is simple, the description lacks details about the returned data structure. There is no output schema, so the agent might benefit from knowing what fields are included (e.g., name, email). However, it is minimally adequate for a straightforward getter.
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%, so the description does not need to explain parameters. Baseline is 4 for zero-parameter tools.
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 retrieves information about the currently authenticated user. It is specific with verb 'Get' and resource 'information about the currently authenticated user', and it distinguishes from sibling tools like archive_activity or create_time_entry.
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 other tools or alternatives. It does not mention when to use or not use it, nor does it reference any 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 entries for a date range
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | No | End date in YYYY-MM-DD format. Defaults to today if not specified. | |
| projectId | No | Filter entries by activity ID | |
| startDate | No | Start date in YYYY-MM-DD format. Defaults to today if not specified. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the agent knows it's a read operation. The description adds no further behavioral context such as default behavior for optional parameters, pagination, or data limits. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence front-loads the primary purpose. No wasted words, but could benefit from slight elaboration on filtering options.
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 three optional parameters and no output schema, the description is adequate but incomplete. It does not specify that projectId can filter entries, nor does it describe the output format or field details.
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 for all three parameters. The description mentions 'date range' but does not add meaning beyond the schema. With high schema coverage, 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 'Get time entries for a date range' clearly states the verb (get), resource (time entries), and scope (date range). This distinguishes it from sibling tools like create_time_entry and delete_time_entry.
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_active_timer or list_activities. The description implies usage for reading time entries within a date range but does not provide when-not-to-use or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all activities
| Name | Required | Description | Default |
|---|---|---|---|
| activeOnly | No | If true, only return active activities. Defaults to false (returns all activities). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the read-only nature is clear. The description adds no further behavioral context (e.g., pagination, rate limits, or what 'all activities' entails). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the core action. No wasted words or 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 simplicity of the tool (one optional parameter, no output schema), the description is nearly complete. However, it could specify the scope of 'all activities' (e.g., per user or workspace) for full clarity.
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 activeOnly, which is well-described in the schema. The description adds no additional meaning beyond the schema, so 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 'Get all activities' clearly identifies the verb (Get) and resource (activities), distinguishing it from sibling tools like create_activity or archive_activity. However, it lacks specificity about scope (e.g., current user or workspace).
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_time_entries or get_active_timer. The description does not mention filtering, prerequisites, or scenarios where other tools are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start tracking time for an activity
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes | The ID of the activity to start tracking | |
| description | No | Optional description of the task you are working on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavior like what happens if a timer is already running, side effects, or return values, and annotations only indicate non-destructiveness.
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 one sentence, concise, and front-loaded, but it could benefit from more detail without being 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 the lack of output schema and behavioral details, the description does not sufficiently inform the agent about the tool's full behavior, especially regarding active timer conflicts.
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, so the description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'start tracking' and resource 'time for an activity', clearly distinguishing it from sibling tools like stop_timer and get_active_timer.
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 vs alternatives, such as prerequisites or conditions (e.g., existing timer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the currently running timer
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint: false, and the description adds nothing beyond stating the action. Since the tool has no parameters or complex behavior, the description suffices but does not enhance transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb and resource. Every word contributes to meaning.
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 parameters and no output schema, the description fully captures its purpose. Sibling tools provide context, making the definition 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?
The tool has zero parameters, and schema coverage is 100% trivially. The description does not need to add parameter information, so a 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 'Stop the currently running timer' clearly identifies the verb and resource, distinguishing it from sibling tools like start_timer or get_active_timer. It is specific and not a tautology.
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 the tool is for stopping an active timer, but lacks explicit guidance on when not to use it or mention of alternatives. For a zero-parameter tool, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the description of the currently running timer
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | New description/note for the active timer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=false. The description adds that it updates the description, consistent with a non-destructive operation. However, it does not disclose behavior if no timer is running or whether it overwrites or appends.
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, efficiently conveying the core action.
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 is simple with one parameter and no output schema. The description covers the basic purpose but omits error conditions (e.g., no active timer) and return value, leaving gaps for agent 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?
Input schema has 100% coverage with a clear description for the 'description' parameter. The tool description does not add extra 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 clearly states the verb 'update' and the resource 'description of the currently running timer', distinguishing it from sibling tools like start_timer, stop_timer, and get_active_timer.
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 for updating the active timer's description but provides no guidance on when to use it vs alternatives, nor does it state prerequisites (e.g., timer must be running) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing activity
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New name for the activity | |
| color | No | New color code for the activity | |
| billable | No | New billable status | |
| clientId | No | New client ID | |
| isActive | No | Set activity as active (true) or inactive (false) | |
| activityId | Yes | The ID of the activity to update | |
| description | No | New description for the activity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'destructiveHint' annotation already indicates non-destructiveness, but the description adds no additional behavioral context (e.g., auth requirements, side effects, reversibility).
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, which is concise but lacks substance. It could include more useful information without being 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 7 parameters, no output schema, and minimal annotations, the description is too sparse. It omits return value, prerequisites, and failure behavior.
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 provides full parameter descriptions (100% coverage), so the description adds no extra meaning. 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 clearly states the verb 'update' and the resource 'activity', and distinguishes it from sibling tools like 'create_activity' and 'archive_activity' by specifying 'existing'.
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, archive). The agent is left to infer usage from context.
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.
v2.0.1archive_activitycreate_activitycreate_time_entrydelete_time_entryedit_time_entrygenerate_reportget_active_timerget_current_userget_time_entrieslist_activitiesstart_timerstop_timerupdate_active_timerupdate_activityEach tool targets a distinct action on a specific resource (activities, time entries, timer, user). No two tools have overlapping purposes, and descriptions clearly differentiate them.
All tools follow a consistent verb_noun pattern in snake_case (e.g., create_activity, start_timer). No mixing of conventions.
14 tools cover the core operations for a time-tracking and activity management server without being excessive. Each tool serves a clear function.
The set covers CRUD for activities and time entries, plus timer management and reporting. Missing individual get-by-ID tools (e.g., get_activity, get_time_entry) but these are minor gaps that agents can work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server exposing klokin time-tracking operations (employees, time entries, stores) to AI clients.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/janfincke/early-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
