The Harvest MCP Server enables AI assistants like Claude to integrate with Harvest's API for time tracking and project management. With this server, you can:
Users: List all users and get detailed information about specific users
Time entries: View time entries with filtering options, create new entries, and start/stop timers
Projects: List projects with filtering options and retrieve detailed project information
Clients: List clients and access detailed client information
Tasks: View and filter tasks
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., "@Harvest MCP Server show me my time entries from yesterday"
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.
This MCP (Model Context Protocol) server provides integration with the Harvest time tracking and project management API. It allows Claude and other MCP-compatible AI assistants to interact with your Harvest account, helping you manage time entries, projects, clients, and more.
The server provides the following functionality:
List users
Get user details
List time entries with filtering options
Create new time entries
Start/stop timers
Query time entry details
Get unsubmitted timesheets (time entries not yet submitted for approval)
List projects with filtering options (by client, is_active, updated_since, page, per_page)
Retrieve detailed project information
Create new projects
Update existing projects (also used to archive: pass is_active=False)
Delete projects (destructive — also deletes the project's time entries and expenses, though invoices are retained; archiving is recommended instead)
List task assignments (account-wide or scoped to a project)
Retrieve detailed task assignment information
Create new task assignments (link a task to a project)
Update existing task assignments
Delete task assignments (only when no time entries are logged against them)
List user assignments (account-wide or scoped to a project)
Retrieve detailed user assignment information
Create new user assignments (link a user to a project)
Update existing user assignments
Delete user assignments (only when no time entries or expenses are logged against them)
List clients with filtering options
Retrieve detailed client information
List available tasks with filtering options
List estimates with filtering options (by client, state, date range, updated_since)
Retrieve detailed estimate information
Look up an estimate by its user-facing number (e.g. "79")
List messages associated with an estimate
Create new estimates with line items
Update existing estimates (add/update/delete line items via _destroy)
Change estimate state (send, accept, decline, re-open) without sending email
Send estimate messages (emails the estimate to recipients)
Delete estimates
Related MCP server: Harvest MCP Server
Python 3.10 or higher
Harvest account with API access
Harvest API key and Account ID
Create or edit your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows (MSIX installs — the default from claude.ai/download): %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json
Windows (older/non-MSIX installs): %APPDATA%\Claude\claude_desktop_config.json
Add the Harvest MCP server configuration:
{
"mcpServers": {
"harvest": {
"command": "uv",
"args": [
"run",
"--directory",
"change_directory",
"harvest-mcp-server.py"
],
"env": {
"HARVEST_ACCOUNT_ID": "account_id",
"HARVEST_API_KEY": "api_key"
}
}
}
}Restart Claude Desktop.
Verify the integration by looking for the hammer icon in Claude's interface.
Once connected, you can ask Claude about your Harvest data with queries like:
"Show me my time entries from last week"
"List all my active projects"
"Start a timer for project [project_id] and task [task_id]"
"Show me all active clients"
"List all available tasks"
"Get my unsubmitted timesheets from this month"
"Show me unsubmitted time entries for user [user_id]"
"Show me all accepted estimates from this quarter"
"Find the estimate numbered [number]"
"Create a draft estimate for client [client_id] with these line items..."
"Mark estimate [id] as sent"
"Email estimate [id] to client@example.com"
"Create a new project called [name] for client [client_id], billed by Project, no budget"
"Archive project [project_id]"
"Assign task [task_id] to project [project_id] as billable"
"Make user [user_id] a project manager on project [project_id]"
"List everyone assigned to project [project_id]"
You can modify the server code to add more functionality or customize the existing tools to better suit your workflow. The server uses FastMCP, which makes it easy to add new tools by simply adding new functions with the @mcp.tool() decorator.
API Errors: Make sure your Harvest API key and Account ID are correct and have the necessary permissions.
Connection Issues: Verify that your Claude Desktop configuration has the correct path to the server script.
Missing Dependencies: Ensure you've installed all required packages in your Python environment.
You can run the server in read-only mode by setting the HARVEST_READ_ONLY environment variable to true. This disables all write operations (creating time entries, starting/stopping timers, creating/updating/deleting estimates, changing estimate state, sending estimate messages, and creating/updating/deleting projects, task assignments, and user assignments) while keeping all read operations available.
{
"mcpServers": {
"harvest": {
"command": "uv",
"args": [
"run",
"--directory",
"change_directory",
"harvest-mcp-server.py"
],
"env": {
"HARVEST_ACCOUNT_ID": "account_id",
"HARVEST_API_KEY": "api_key",
"HARVEST_READ_ONLY": "true"
}
}
}
}When read-only mode is enabled, any attempt to call a write tool will return an error message explaining that the server is in read-only mode and how to enable write access.
This server requires your Harvest API credentials to function. Make sure to:
Keep your API key secure
Do not share your claude_desktop_config.json file
Consider using a dedicated API key with limited permissions for this integration
Create a new time entry.
Args:
project_id: The ID of the project to associate with the time entry
task_id: The ID of the task to associate with the time entry
spent_date: The date when the time was spent (YYYY-MM-DD)
hours: The number of hours spent
notes: Optional notes about the time entry
| Name | Required | Description | Default |
|---|---|---|---|
| hours | Yes | ||
| notes | No | ||
| project_id | Yes | ||
| spent_date | Yes | ||
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'creates' without behavioral details. It doesn't disclose whether this requires specific permissions, if it's idempotent, what happens on validation errors, or what the response looks like (though no output schema exists).
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 appropriately sized with a clear purpose statement followed by parameter explanations. The 'Args' section is well-structured, though the parameter explanations could be more detailed given the 0% schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks behavioral context, error handling information, and sufficient parameter details to fully understand tool operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds basic semantics for all 5 parameters in the 'Args' section, explaining what each represents. However, it doesn't provide format details beyond 'YYYY-MM-DD' for spent_date or constraints like valid hour ranges, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'new time entry', making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'start_timer' or 'stop_timer' which also relate to time tracking, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing projects/tasks), compare to 'start_timer' for real-time tracking, or specify when this is appropriate versus other time-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific client.
Args:
client_id: The ID of the client to retrieve
| Name | Required | Description | Default |
|---|---|---|---|
| client_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states the tool retrieves client details but doesn't cover aspects like authentication requirements, rate limits, error handling, or what 'detailed information' entails, leaving significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated clearly in the first sentence. The parameter documentation is concise and directly relevant, though the formatting with 'Args:' could be slightly more integrated for optimal structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves detailed information. It doesn't explain what 'detailed information' includes, how results are structured, or potential limitations, making it insufficient for the agent to fully understand the tool's context and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates by documenting the single parameter 'client_id' and its purpose ('The ID of the client to retrieve'). This adds meaningful context beyond the basic schema, though it doesn't specify format constraints or examples, keeping it at a baseline level.
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's purpose with a specific verb ('Get') and resource ('detailed information about a specific client'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'list_clients' or 'get_user_details', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_client_details' over 'list_clients' for broader client information or 'get_user_details' for user-specific data, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific project.
Args:
project_id: The ID of the project to retrieve
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'retrieves' information, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, or what happens if the project_id is invalid. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: a clear purpose statement and a parameter explanation. It's front-loaded with the main action, and the parameter note adds necessary context without redundancy. There's minimal waste, though the structure could be slightly more polished (e.g., bullet points).
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 (1 parameter, no nested objects) but lack of annotations and output schema, the description is minimally adequate. It covers the basic purpose and parameter, but doesn't address return values, error cases, or behavioral traits, leaving the agent with incomplete context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that project_id is 'The ID of the project to retrieve', which clarifies the parameter's purpose beyond the schema's basic type (integer). However, it doesn't provide format details (e.g., numeric range or source) or address other potential parameters, resulting in a baseline score.
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 resource 'detailed information about a specific project', which is specific and actionable. It distinguishes from siblings like list_projects (which lists multiple projects) by focusing on a single project's details. However, it doesn't explicitly name the sibling distinction, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_projects or get_user_details. It lacks context about prerequisites (e.g., needing a project ID) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve details for a specific user.
Args:
user_id: The ID of the user to retrieve
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation but doesn't mention whether it requires authentication, what permissions are needed, whether it's idempotent, what happens if the user_id doesn't exist, or what format/details are returned. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that directly address purpose and parameters. The 'Args:' section is clearly structured, though the formatting could be more integrated. Every sentence serves a purpose with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and only basic schema coverage, the description is incomplete. It doesn't explain what 'details' are returned, how errors are handled, or any behavioral characteristics. While it covers the parameter meaning adequately, it leaves too many contextual gaps for effective tool selection and 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?
The description adds meaningful context for the single parameter 'user_id' by specifying it's 'The ID of the user to retrieve'. With 0% schema description coverage (the schema only provides title and type), this description compensates well by explaining what the parameter represents. However, it doesn't provide format examples or constraints beyond what's implied.
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 ('Retrieve') and resource ('details for a specific user'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_users' or 'get_client_details', which would require mentioning it fetches detailed information for a single user rather than listing multiple users or retrieving different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_user_details' over 'list_users' for user information, or how it differs from other 'get_*_details' tools for different entities. There's also no information about prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List clients with optional filtering.
Args:
is_active: Pass true to only return active clients and false to return inactive clients
| Name | Required | Description | Default |
|---|---|---|---|
| is_active | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions optional filtering but doesn't describe return format, pagination, sorting, authentication requirements, rate limits, or what 'list' entails (e.g., all fields vs. summary). The description is minimal and lacks critical behavioral context for a tool with mutation siblings.
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 appropriately brief with two sentences and a parameter explanation section. It's front-loaded with the main purpose and efficiently documents the parameter. No wasted words, though the structure could be slightly improved by integrating the parameter explanation more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and siblings that include mutation tools, the description is incomplete. It doesn't address return values, error conditions, or how this read operation fits with write operations like 'create_time_entry'. For a list tool in a system with time tracking and project management, more context about client relationships would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'is_active' by explaining what true/false values return, which compensates for the 0% schema description coverage. It clarifies the parameter's purpose beyond the schema's basic type information, though it doesn't cover default behavior when null.
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 'List' and resource 'clients', making the purpose specific and understandable. It distinguishes from siblings like 'get_client_details' by focusing on listing rather than retrieving details. However, it doesn't explicitly differentiate from other list tools like 'list_projects' or 'list_users' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use 'list_clients' over 'get_client_details' for detailed client information, or how it relates to other list tools. There are no prerequisites, exclusions, or context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List projects with optional filtering.
Args:
client_id: Filter by client ID
is_active: Pass true to only return active projects and false to return inactive projects
| Name | Required | Description | Default |
|---|---|---|---|
| client_id | No | ||
| is_active | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions optional filtering but doesn't describe what 'list' entails - whether it returns all projects, is paginated, requires authentication, has rate limits, or what format the output takes. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with a clear two-part structure: a purpose statement followed by parameter explanations. The parameter section uses bullet-like formatting that's easy to parse. Every sentence adds value, though the initial statement could be slightly more specific about what 'list' entails.
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 moderate complexity (2 optional parameters), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameters well, but lacks information about output format, authentication requirements, error conditions, or typical use cases. For a list operation with filtering, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the input schema, which has 0% description coverage. It explains both parameters clearly: 'client_id' filters by client ID, and 'is_active' with specific guidance about passing true/false values. This fully compensates for the schema's lack of descriptions and provides necessary semantic context for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('projects'), making the purpose understandable. It distinguishes from siblings like 'get_project_details' by indicating this returns a list rather than details of a single project. However, it doesn't explicitly differentiate from other list tools like 'list_clients' or 'list_tasks' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list_projects' over 'get_project_details' for detailed information, or how it relates to other list tools like 'list_clients' or 'list_tasks'. There's no context about prerequisites, typical use cases, or limitations.
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.
Args:
is_active: Pass true to only return active tasks and false to return inactive tasks
| Name | Required | Description | Default |
|---|---|---|---|
| is_active | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions optional filtering but doesn't cover critical aspects like whether this is a read-only operation, pagination behavior, rate limits, or authentication needs. For a list tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear summary sentence followed by parameter details. It avoids unnecessary fluff, though the structure could be slightly improved by front-loading key information more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and lack of annotations or output schema, the description is minimally adequate. It explains the basic functionality and parameter, but misses broader context like return format, error handling, or integration with sibling tools, leaving gaps 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?
With schema description coverage at 0%, the description compensates by explaining the single parameter 'is_active' in detail, including its boolean nature and effect on filtering. This adds meaningful semantics beyond what the bare schema provides, though it doesn't cover potential edge cases or default behavior.
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 'List' and resource 'tasks' with optional filtering, making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like list_clients or list_projects, which follow a similar pattern, so it misses the highest score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like list_time_entries and list_projects, there's no indication of context or exclusions, leaving the agent to infer usage based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List time entries with optional filtering.
Args:
user_id: Filter by user ID
from_date: Only return time entries with a spent_date on or after the given date (YYYY-MM-DD)
to_date: Only return time entries with a spent_date on or before the given date (YYYY-MM-DD)
is_running: Pass true to only return running time entries and false to return non-running time entries
| Name | Required | Description | Default |
|---|---|---|---|
| from_date | No | ||
| is_running | No | ||
| to_date | No | ||
| user_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions optional filtering but fails to describe critical behaviors like pagination, rate limits, authentication requirements, or the format of returned data. This leaves significant gaps for a tool that likely returns multiple entries.
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 appropriately sized and front-loaded, with a clear purpose statement followed by parameter details. It avoids unnecessary fluff, though the parameter explanations could be slightly more integrated into the flow rather than listed as bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a list operation with filtering, no annotations, and no output schema, the description is incomplete. It lacks information on return format, pagination, error handling, or how results are ordered, which are essential for an agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial value beyond the input schema, which has 0% schema description coverage. It clearly explains the semantics of all four parameters (user_id, from_date, to_date, is_running), including date format (YYYY-MM-DD) and boolean usage, fully compensating for the schema's lack of descriptions.
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's purpose as 'List time entries with optional filtering,' which is a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from potential sibling tools like 'list_tasks' or 'list_users,' which reduces it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_clients' or 'list_projects,' nor does it specify prerequisites or exclusions for filtering time entries, leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all users in your Harvest account.
Args:
is_active: Pass true to only return active users and false to return inactive users
page: The page number for pagination
per_page: The number of records to return per page (1-2000)
| Name | Required | Description | Default |
|---|---|---|---|
| is_active | No | ||
| page | No | ||
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation ('List') but doesn't disclose behavioral traits such as authentication requirements, rate limits, or pagination details beyond parameter names. Some context is given (e.g., pagination parameters), but key aspects like response format or error handling 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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are concise and necessary, though the structure could be slightly improved by integrating guidelines to avoid a separate 'Args' section without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers parameters well but lacks usage guidelines, behavioral details like authentication, and output information, making it minimally viable but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% coverage (no descriptions in schema). It explains each parameter's purpose: 'is_active' filters by user status, 'page' handles pagination, and 'per_page' specifies record limits with a range (1-2000). This fully compensates for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all users in your Harvest account'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_user_details' or 'list_clients', which would require a 5.
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_user_details' for specific users or 'list_clients' for different resources. The description only states what the tool does without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a new timer.
Args:
project_id: The ID of the project to associate with the time entry
task_id: The ID of the task to associate with the time entry
notes: Optional notes about the time entry
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| project_id | Yes | ||
| task_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Start a new timer') but omits critical details: whether this requires authentication, what happens if a timer is already running (e.g., stops previous timer, returns error), rate limits, or what the response contains. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by parameter explanations. The structure is front-loaded with the main action, and each sentence adds value. Minor improvement could come from integrating parameter details more seamlessly, but overall it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to explain behavioral aspects (e.g., timer conflicts, response format), usage context relative to siblings, or parameter dependencies. For a tool that likely interacts with other time-tracking functions, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief explanations, adding meaning beyond the schema's titles. However, it lacks details like format constraints (e.g., integer ranges for IDs), what happens if notes are omitted (default is null), or how project/task IDs relate to other tools. This provides basic but incomplete semantic context.
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 timer') and resource ('timer'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'create_time_entry' or 'stop_timer', which could cause confusion about when to use each tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_time_entry' or 'stop_timer'. It lacks context about prerequisites (e.g., whether a timer must be stopped first) or typical scenarios for starting timers, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running timer.
Args:
time_entry_id: The ID of the running time entry to stop
| Name | Required | Description | Default |
|---|---|---|---|
| time_entry_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Stop a running timer' implies a mutation operation, it doesn't disclose important behavioral traits: whether this requires specific permissions, what happens to the stopped time entry (is it saved, editable, deleted?), whether there are side effects, or what the response contains. The description provides minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that directly address purpose and parameters. The structure is front-loaded with the core action first, followed by parameter details. There's no wasted text, though the parameter documentation could be slightly more integrated rather than appearing as a separate 'Args:' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides basic completeness but has significant gaps. It covers the core action and parameter meaning adequately, but lacks information about behavioral consequences, error conditions, return values, and integration with sibling tools. Given the complexity of stopping a timer (which likely has side effects), the description should do more to contextualize 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?
With 0% schema description coverage and only one parameter, the description adds crucial semantic context by explaining that 'time_entry_id' refers to 'The ID of the running time entry to stop'. This clarifies what the parameter represents beyond just being an integer ID. However, it doesn't specify where to obtain this ID or provide format examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Stop') and target resource ('a running timer'), distinguishing it from sibling tools like 'start_timer' and 'list_time_entries'. It provides a complete verb+resource combination that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that a timer must be running), doesn't specify what happens after stopping (e.g., whether time is logged), and doesn't differentiate from related operations like pausing or editing time entries. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_time_entryget_client_detailsget_project_detailsget_user_detailslist_clientslist_projectslist_taskslist_time_entrieslist_usersstart_timerstop_timerEvery tool has a clearly distinct purpose targeting specific resources and actions. For example, create_time_entry vs. start_timer vs. stop_timer handle different aspects of time tracking, while list_* tools retrieve collections and get_* tools fetch individual details. No tools appear to overlap or cause confusion.
All tools follow a consistent verb_noun pattern with snake_case throughout. The naming is highly predictable: list_* for collections, get_* for details, create_* for creation, and start_/stop_ for timer actions. There are no deviations in style or convention.
With 11 tools, this server is well-scoped for time tracking and project management. Each tool earns its place by covering essential operations like CRUD for time entries, listing resources, and timer control. The count is neither too sparse nor bloated for the domain.
The tool surface provides strong coverage for core time tracking workflows, including creating/listing time entries, managing timers, and accessing clients, projects, tasks, and users. A minor gap exists in missing update/delete operations for time entries and other resources, but agents can work around this with the available tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Manage Avaza projects, tasks, timesheets, expenses, invoices, and scheduling from AI assistants.
Time tracking and invoicing for AI agents and their humans: track, log and bill work by agent.
Read time entries, projects, clients, tasks and invoices; log and update tracked time.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/taiste/harvest-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
