Harvest MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific Harvest API resources and actions. The naming convention makes it immediately clear which resource (clients, projects, tasks, time entries, users) and which operation (list, get, create, update, delete, restart, stop, report) each tool performs. There is no ambiguity or overlap between tools.
Naming Consistency5/5
All tools follow a perfectly consistent 'harvest_verb_noun' pattern (e.g., harvest_list_clients, harvest_create_time_entry). The two exceptions (about and version) are clearly meta-tools for server information and maintain readability. The naming convention is predictable and systematic throughout the toolset.
Tool Count5/5
With 17 tools, this server provides comprehensive coverage of Harvest's core time-tracking and project management functionality. Each tool serves a specific, necessary purpose in the domain (client/project/task/user management, time entry lifecycle, reporting). The count is well-scoped for the complexity of the Harvest API without being overwhelming.
Completeness5/5
The toolset provides complete CRUD/lifecycle coverage for time entries (create, list, update, delete, restart/stop timers, generate reports) and comprehensive read/list operations for all core resources (clients, projects, tasks, users, project/task assignments). There are no obvious gaps for time-tracking workflows, and the about/version tools provide necessary meta-information.
Average 2.9/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'filtering options' and pagination via parameters, but fails to describe key behaviors such as authentication requirements, rate limits, error handling, or what the output looks like (e.g., list format). This is inadequate for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence is redundant and adds no value—it merely references the tool itself for details, which is tautological. This wastes space and fails to front-load useful information, making it inefficient and poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, output format, and usage context. For a list tool with filtering, more information is needed to guide effective use, making it insufficient for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the parameters (is_active, page, per_page). The description adds no additional meaning beyond implying filtering exists, which is already covered. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List all clients with filtering options', which provides a clear verb ('List') and resource ('clients'). However, it doesn't distinguish this tool from sibling tools like 'harvest_list_projects' or 'harvest_list_users' beyond the resource type, making it somewhat vague in comparison. The purpose is understandable but lacks specific differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions filtering options but doesn't specify contexts, prerequisites, or exclusions. For example, it doesn't clarify if this is for administrative tasks or general client lookup, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits like permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields. The reference to 'about' for details doesn't add meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence ('Use about...') is redundant and doesn't add value, as it merely points to another tool without providing useful information. This wastes space and reduces effectiveness, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context like what the tool returns, error conditions, or how it interacts with sibling tools. The reference to 'about' doesn't compensate for these gaps, making it inadequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond what's in the schema, such as explaining relationships between parameters or providing examples. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing time entry' which provides a clear verb ('Update') and resource ('time entry'), but it doesn't differentiate from sibling tools like harvest_create_time_entry or harvest_delete_time_entry beyond the basic action. It's not tautological but lacks specific distinction from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like harvest_create_time_entry or harvest_delete_time_entry. It only references using 'about' for parameters, which doesn't address usage context or prerequisites. No explicit when/when-not statements are included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read-only operation, it doesn't specify authentication requirements, rate limits, pagination behavior (beyond what parameters suggest), error conditions, or what the output contains. The reference to 'about' for details is insufficient for immediate understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but inefficiently structured. The first sentence is functional but basic. The second sentence about using 'about' adds questionable value as it's a meta-reference that doesn't help the agent understand the tool itself. While not verbose, the content doesn't maximize its limited word count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'task assignments' are in this context, what the output format looks like, or how results are structured. The reference to another tool for details doesn't compensate for these gaps in the primary description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters adequately. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List task assignments for a project', which clearly indicates the verb (list) and resource (task assignments) with a scope (for a project). However, it doesn't differentiate from sibling tools like 'harvest_list_project_assignments' or 'harvest_list_tasks', leaving ambiguity about what specifically distinguishes this tool from related listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions using 'about' for detailed workflow and examples, but this is a meta-reference rather than practical usage advice. There's no indication of prerequisites, when-not-to-use scenarios, or comparisons with sibling tools like 'harvest_list_project_assignments' or 'harvest_list_tasks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'filtering options' and pagination (implied by 'page' and 'per_page' in schema), but does not cover critical aspects like authentication requirements, rate limits, error handling, or return format. For a list tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: one stating the purpose and another directing to another tool for details. It is front-loaded with the main function, but the second sentence is somewhat redundant since parameters are already in the schema. Overall, it is efficient with minimal waste, though the reference to 'about' could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 3 parameters with full schema coverage, the description is incomplete. It lacks details on behavioral traits (e.g., pagination behavior, error responses) and does not explain return values or usage context. For a tool with filtering and pagination, more guidance is needed to ensure the agent can use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for 'is_active,' 'page,' and 'per_page.' The description adds no additional parameter semantics beyond what the schema provides, such as default values or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately documents parameters without extra help from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List all tasks with filtering options,' which provides a clear verb ('List') and resource ('tasks') with scope ('all'). However, it does not differentiate from sibling tools like 'harvest_list_task_assignments' or 'harvest_list_time_entries,' making it somewhat vague in comparison. The purpose is understandable but lacks specificity relative to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a directive to 'Use about {"tool": "harvest_list_tasks"} for detailed parameters and examples,' which implies usage guidance but does not explicitly state when to use this tool versus alternatives like 'harvest_list_task_assignments.' No context, exclusions, or prerequisites are provided, leaving the agent with minimal guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Restart a stopped time entry timer') which implies a mutation operation, but doesn't disclose critical behavioral traits such as required permissions, whether it affects billing or reporting, error conditions (e.g., if the timer isn't stopped), or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence clearly states the tool's purpose, and the second provides a reference for more details. There's no unnecessary verbosity, and the information is front-loaded, though the second sentence could be more integrated into the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (restarting a timer) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error handling, or response format, and relies on external references ('about') for details. For a tool that modifies state, this lack of context is inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter semantics beyond what the input schema provides. The schema has 100% coverage with a clear description for the 'id' parameter ('Time entry ID'), so the baseline score is 3. The description doesn't explain what constitutes a valid time entry ID, how to obtain it, or any constraints, leaving all parameter documentation to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Restart a stopped time entry timer') which is clear but somewhat vague. It specifies the resource type ('time entry timer') but doesn't differentiate from sibling tools like 'harvest_stop_timer' or 'harvest_update_time_entry' beyond the basic verb difference. The purpose is understandable but lacks specificity about what distinguishes this restart operation from other time entry modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the timer must be stopped), exclusions, or comparisons to sibling tools like 'harvest_stop_timer' or 'harvest_update_time_entry'. The reference to 'about {"tool": "harvest_restart_timer"}' suggests external documentation but doesn't offer actionable usage context within the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Delete') but fails to mention critical traits like whether deletion is permanent, requires specific permissions, has side effects, or involves rate limits. The reference to another tool for 'detailed usage and warnings' suggests missing information, but doesn't compensate adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but inefficiently structured. The first sentence is clear, but the second sentence adds clutter by referencing another tool without providing actionable guidance, reducing overall conciseness. It could be more front-loaded and eliminate the redundant reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It mentions deletion but omits essential context like success/failure responses, error handling, or confirmation requirements. The reference to another tool hints at gaps, failing to provide a self-contained understanding for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'id' clearly documented as 'Time entry ID to delete'. The description adds no additional meaning beyond this, such as format examples or validation rules. Given the high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a time entry'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'harvest_update_time_entry' or 'harvest_list_time_entries' beyond the obvious action difference, missing explicit scope or constraint distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'harvest_update_time_entry' for modifications or 'harvest_list_time_entries' for viewing. It lacks context about prerequisites, permissions, or scenarios where deletion is appropriate, offering only a vague reference to another tool for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get details' but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what details are returned. This leaves significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes a second sentence referencing another tool for examples, which adds minimal value and could be considered redundant. It's front-loaded with the core purpose but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what details are returned, error cases, or prerequisites, making it inadequate for a tool that fetches project data without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'id' parameter. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'details of a specific project', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'harvest_list_projects' or 'harvest_list_project_assignments', 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'harvest_list_projects' for listing multiple projects. It only references another tool 'about' for examples, which doesn't clarify usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions listing assignments but fails to describe key behaviors: it doesn't specify if this is a read-only operation (implied but not stated), how pagination works with the 'page' and 'per_page' parameters, what the output format looks like, or any rate limits or authentication requirements. The reference to another tool for 'detailed usage' is vague and unhelpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but inefficiently structured. The first sentence is clear, but the second sentence ('Use about...') is redundant and doesn't add value for an AI agent, as it references an external tool without context. This wastes space that could be used for more useful information, such as behavioral details or usage guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a list operation with pagination parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain the return values, pagination behavior, or how to interpret results. The reference to another tool for 'detailed usage' is insufficient, leaving gaps that could hinder an AI agent's ability to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'page' and 'per_page' parameters. The description adds no additional semantic information about these parameters beyond what the schema provides. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List project assignments for the current user.' It specifies the verb ('List'), resource ('project assignments'), and scope ('for the current user'). However, it doesn't explicitly distinguish this tool from similar siblings like 'harvest_list_projects' or 'harvest_list_task_assignments', which could cause confusion about what exactly is being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It only references using another tool ('about') for detailed usage, which is not helpful for an AI agent deciding when to invoke this tool. There's no explicit guidance on when to use this tool versus alternatives like 'harvest_list_projects' or 'harvest_list_task_assignments', nor any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'filtering options' and pagination (implied by 'page' and 'per_page' parameters), but doesn't describe important behaviors like rate limits, authentication requirements, response format, or whether this is a read-only operation (though 'List' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but contains redundant information - it references the tool name itself in the about instruction. The first sentence is useful, but the second sentence about 'about' adds no value for AI agent selection and could confuse rather than help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 4 parameters and no output schema, the description is insufficient. It doesn't explain what information is returned about projects, how pagination works in practice, or typical use cases. With no annotations and no output schema, more context about the operation would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond stating 'filtering options' exists, which the schema already shows through 'is_active' and 'client_id'. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('projects') with scope ('all'), making the purpose immediately understandable. However, it doesn't specifically differentiate from sibling tools like 'harvest_list_clients' or 'harvest_list_tasks' beyond mentioning 'projects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'harvest_get_project' (for single project details) or 'harvest_list_project_assignments' (for project assignments). It mentions 'filtering options' but doesn't specify use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'filtering' and pagination parameters, but doesn't disclose critical behavioral traits like whether this is a read-only operation (implied by 'List'), rate limits, authentication requirements, or what happens with invalid parameters. The description is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but contains redundant elements. The first sentence is useful, but the second sentence about 'about' tool is unnecessary and doesn't add value for an AI agent. The structure could be improved by front-loading more specific information about filtering scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (user objects, pagination metadata), error conditions, or important constraints like the 'max 100' in the schema. For a list tool with filtering and pagination, more context is needed about the response format and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds minimal value by mentioning 'filtering' generically, but doesn't provide additional context beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'users in the account', making the purpose understandable. It distinguishes from siblings like 'harvest_get_current_user' (single user) and 'harvest_list_clients' (different resource). However, it doesn't specify what 'filtering' entails beyond the schema parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'harvest_get_current_user' for a single user or other list tools for different resources. It mentions filtering but doesn't explain when filtering is appropriate versus using other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Stop a running time entry timer') but lacks critical details: whether this requires specific permissions, what happens to the stopped time (e.g., saved or discarded), error conditions (e.g., if timer isn't running), or response format. The reference to 'about' for examples doesn't compensate for these gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes a redundant meta-reference ('Use about...') that doesn't add value for tool selection. The first sentence is clear, but the second sentence is unnecessary clutter. It could be more front-loaded by omitting the about reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It doesn't explain what the tool returns, error handling, or side effects. For a tool that modifies state, more context is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'id' documented as 'Time entry ID'. The description adds no parameter-specific information beyond what's in the schema, such as format examples or where to obtain the ID. This meets the baseline of 3 since the schema adequately covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Stop') and resource ('a running time entry timer'), making the purpose immediately understandable. It distinguishes from siblings like 'harvest_restart_timer' by specifying 'stop' versus 'restart', though it doesn't explicitly contrast with other time entry tools like 'harvest_update_time_entry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions using 'about' for workflow details, but this is a meta-reference rather than practical usage advice. There's no indication of prerequisites (e.g., only works on running timers) or when to choose this over other time entry operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation tool, implying a write operation, but doesn't mention potential side effects (e.g., whether it affects billing, requires permissions, or has rate limits). It also doesn't describe the response format or error conditions, leaving the agent with incomplete behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose. However, the second sentence referencing 'about' for details is somewhat redundant since the schema already provides parameter information, slightly reducing efficiency. Overall, it's well-structured with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a write operation with 5 parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, error handling, or what the tool returns upon success. For a creation tool in a time-tracking context, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 5 parameters with clear descriptions (e.g., 'Date of the entry (YYYY-MM-DD)'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters (e.g., project_id and task_id must correspond). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new time entry') and resource ('time entry'), which is specific and unambiguous. It distinguishes from siblings like harvest_update_time_entry or harvest_delete_time_entry by focusing on creation. However, it doesn't explicitly differentiate from all siblings (e.g., harvest_restart_timer might also involve time tracking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing valid project/task IDs), when not to use it (e.g., for updating existing entries), or direct alternatives like harvest_update_time_entry. The reference to 'about' is for parameter details, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool generates reports but doesn't describe what 'detailed' entails, output format, pagination, permissions required, rate limits, or whether it's read-only. The mention of the 'about' tool for examples adds some context but is insufficient for a mutation/read operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that directly address purpose and additional resources. It's front-loaded with the core function and avoids unnecessary elaboration. However, the second sentence could be more integrated with the tool's usage rather than being a standalone reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 5 parameters (though well-documented in schema), the description is incomplete. It doesn't cover behavioral aspects like what 'detailed' reports include, output format, or how it differs from list tools. For a report-generation tool with filtering options, more context on results and usage is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no specific parameter semantics beyond implying date-range filtering and referencing the 'about' tool for examples. It doesn't explain parameter interactions or provide usage examples, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate detailed time reports for date ranges.' This specifies the action (generate), resource (time reports), and scope (date ranges). It distinguishes from siblings like harvest_list_time_entries by focusing on reports rather than raw entries, though it doesn't explicitly contrast with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions using the 'about' tool for filtering options and examples, but doesn't specify when to use this tool versus siblings like harvest_list_time_entries or harvest_list_users. No explicit when/when-not scenarios or alternative recommendations are provided, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves user information, implying a read-only operation, but doesn't specify authentication requirements, rate limits, error handling, or what 'authenticated user' entails. The mention of 'about' for response format adds some context but is vague and doesn't fully compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the second sentence about using 'about' for response format is somewhat vague and could be more directly informative. It's front-loaded with the core purpose, but the additional sentence doesn't fully earn its place by providing clear value, making it slightly inefficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on authentication, response structure, or error cases. Without an output schema, the mention of 'about' for format is helpful but insufficient for full completeness, leaving gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. This meets the baseline for tools with no parameters, as it doesn't mislead or omit necessary param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about the authenticated user.' It specifies the verb ('Get') and resource ('authenticated user'), making the action explicit. However, it doesn't distinguish this from sibling tools like 'harvest_list_users' or 'harvest_get_project', which could provide similar user or entity information, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions using 'about' for response format details, but this is not a usage guideline for selecting this tool over siblings like 'harvest_list_users'. There is no indication of context, prerequisites, or exclusions for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'optional filters' and hints at pagination via parameters, but fails to describe key behaviors such as rate limits, authentication requirements, error handling, or the format of returned data. For a list tool with 6 parameters, this leaves significant gaps in understanding how the tool operates beyond basic filtering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the purpose, and the second directs to another tool for examples. It's front-loaded with the core functionality. However, the second sentence is somewhat redundant as it doesn't add operational value, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a list tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, pagination behavior, or error cases, leaving the agent with insufficient context to use the tool effectively. The reference to 'about' for examples doesn't compensate for these gaps in the description itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all 6 parameters with clear descriptions. The description adds no additional parameter semantics beyond stating 'optional filters,' which is already implied by the schema. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't compensate or add extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'List time entries with optional filters,' which specifies the verb ('List') and resource ('time entries'). It distinguishes itself from siblings like 'harvest_create_time_entry' or 'harvest_update_time_entry' by focusing on listing rather than mutating. However, it doesn't explicitly differentiate from other list tools like 'harvest_list_projects' or 'harvest_list_users,' which slightly reduces specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing time entries with filters, but it lacks explicit guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for general queries or if 'harvest_time_report' might be better for aggregated data. The reference to 'about' for examples provides some context, but no clear when/when-not rules are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly indicates this is a read-only operation ('Get') that returns information, not a mutation. However, it doesn't specify response format, error conditions, or rate limits, leaving some behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the complete purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides adequate context about what information is retrieved. However, it doesn't specify what 'version information' includes (e.g., server version, API version, build date), leaving some ambiguity about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, earning a baseline score of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get') and resource ('version information about the Harvest MCP server'), distinguishing it from sibling tools like 'about' or other Harvest-specific operations. It precisely communicates what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving server version information, but provides no explicit guidance on when to use this tool versus alternatives like 'about' or other system-info tools. Usage context is inferred rather than stated, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's dual behavior (general vs. specific info) but doesn't disclose important behavioral traits like whether this is a read-only operation, what format the information returns in, or if there are any rate limits or authentication requirements. The description adds some context but leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured in two sentences. The first sentence states the overall purpose, and the second provides specific usage instructions. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (dual behavior based on parameter presence) and lack of both annotations and output schema, the description is incomplete. While it explains when to use the tool and what the parameter does, it doesn't describe what information is actually returned, which is critical for a metadata tool. The description covers basic usage but leaves important contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents the single optional 'tool' parameter. The description adds valuable semantic context by explaining what happens with and without the parameter, which goes beyond the schema's technical specification. For a tool with only one parameter, this provides good additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get detailed information') and resources ('Harvest MCP server and its tools'). It distinguishes itself from all sibling tools, which perform CRUD operations on Harvest entities, while 'about' provides metadata about the server itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: call without parameters for general server info, or with a 'tool' parameter for specific tool documentation. This clearly defines when to use each variant and distinguishes it from alternatives like 'version' (which likely provides only version info) or other Harvest-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/standardbeagle/harvest-mcp'

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