Basecamp MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting different resources like messages, projects, todos, and cache. However, get_messages and get_message_with_comments could be slightly confusing as both retrieve messages, though the latter includes comments. Overall, the overlap is minimal and descriptions clarify the differences.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, such as clear_cache, create_message, and get_projects. This uniformity makes the set predictable and easy for an agent to parse and understand.
Tool Count5/5
With 10 tools, the server is well-scoped for Basecamp operations, covering key areas like projects, messages, todos, and cache management. Each tool serves a clear purpose without feeling excessive or insufficient for the domain.
Completeness4/5
The toolset provides good coverage for reading and updating Basecamp data, including CRUD-like operations for messages and todos, and project/schedule retrieval. A minor gap exists in creating or updating projects, schedules, or comments, but core workflows are supported.
Average 3/5 across 10 of 10 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 states the tool retrieves information, implying it is read-only, but does not confirm this or describe other traits like error handling, rate limits, or authentication needs. The description adds minimal value beyond the basic purpose.
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 with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary details. Every word earns its place.
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 retrieval operation with one parameter), lack of annotations, and no output schema, the description is incomplete. It does not explain what 'detailed information' includes, how results are structured, or potential errors. The description is too minimal for adequate agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% description coverage. It does not explain the 'project_id' parameter, such as its format, source, or constraints. With low schema coverage, the description fails to compensate, leaving the parameter undocumented.
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's purpose as 'Get detailed information about a specific project,' which is clear but vague. It specifies the verb 'Get' and resource 'project,' but lacks detail on what 'detailed information' entails. It does not distinguish from siblings like 'get_projects' (likely listing) or 'get_todos' (different resource).
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 does not mention prerequisites, context, or exclusions, such as how it differs from 'get_projects' (which might list multiple projects) or when to use it over other retrieval tools. Usage is implied only by the name and description.
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 ('Get schedules') but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, returns paginated results, or what happens on errors. For a 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 and front-loaded with a single sentence ('Get schedules from a project.'), which efficiently states the purpose without unnecessary words. However, it lacks structure for additional details like usage or parameters, making it slightly under-specified rather than perfectly structured.
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 low complexity (1 parameter, no annotations, but has an output schema), the description is incomplete. It doesn't cover behavioral aspects or parameter semantics, but the presence of an output schema reduces the need to explain return values. This makes it minimally viable but with clear gaps in context.
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 meaning beyond the input schema, which has 1 parameter with 0% schema description coverage. It doesn't explain what 'project_id' is, how to obtain it, or its format. With low coverage, the description fails to compensate, but since there's only one parameter, the baseline is adjusted to 3 as it's minimally adequate for a simple tool.
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's purpose ('Get schedules from a project') with a clear verb ('Get') and resource ('schedules'), but it's vague about scope—it doesn't specify whether it retrieves all schedules, filtered ones, or their details. It distinguishes from some siblings like 'get_projects' or 'get_todos' by resource type, but not clearly from 'get_project_details' which might overlap in context.
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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid project_id, or compare to other tools like 'get_project_details' that might include schedule information. The description implies usage for retrieving schedules but offers no exclusions or 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 the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read operation, but doesn't cover permissions, rate limits, error handling, or what 'with all comments' entails (e.g., format, depth). This leaves significant gaps for a tool with parameters.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse.
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, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain the return values (e.g., message structure, comment format), error cases, or behavioral nuances needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about 'project_id' or 'message_id' (e.g., what they reference, valid ranges, or relationships), failing to compensate for the coverage gap.
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 ('Get') and resource ('a specific message with all comments'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_messages' or 'get_project_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.
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 'get_messages' or 'get_project_details'. It mentions no prerequisites, exclusions, or specific contexts, 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.
Behavior3/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 tool creates a message and clears the cache, which implies mutation and side effects, but lacks details on permissions, error handling, or response format. This is a minimal but adequate disclosure for a basic create operation.
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 state the action and side effect. It's front-loaded with the primary purpose, though it could be slightly more structured by separating the cache-clearing effect into a distinct note.
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 with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on parameter semantics, behavioral traits like error cases, and what the tool returns, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the parameters (project_id, subject, content), such as their meaning, constraints, or examples, failing to compensate for the coverage gap and leaving parameters undocumented.
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 ('Create') and resource ('a new message in a project'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_messages' or 'get_message_with_comments', which would require mentioning it's for creation rather than retrieval.
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 an existing project), exclusions, or comparisons to sibling tools like 'get_messages' for reading messages, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It states the tool gets statistics, implying a read-only operation, but doesn't specify if it requires permissions, what format the statistics are in, whether it's real-time or cached data, or any rate limits. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get statistics about the cache.' It's front-loaded with the core action and resource, with no unnecessary words or redundancy. This is maximally concise while conveying the essential purpose.
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 for a tool that retrieves data. It doesn't explain what statistics are returned, their format, or any behavioral context like error handling. For a data-fetching tool with zero structured support, more detail is needed to be fully helpful.
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 doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the lack of inputs.
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 'Get statistics about the cache' clearly states the action (get) and resource (cache statistics), making the purpose understandable. However, it lacks specificity about what statistics are included and doesn't distinguish this tool from potential sibling cache operations like 'clear_cache', which is mentioned in the sibling list.
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, timing considerations, or compare it to sibling tools like 'clear_cache' or other data retrieval tools in the list. Usage is implied as needed for cache statistics, but no explicit context is given.
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 indicates a read operation ('Get') but lacks details on permissions, rate limits, pagination, or error handling. The description is too vague to fully inform behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, using two sentences efficiently. However, it could be slightly more structured by explicitly listing parameters or usage contexts, but it avoids unnecessary verbosity.
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 has an output schema (which covers return values), the description doesn't need to explain outputs. However, with no annotations, 3 parameters (one required), and 0% schema coverage, the description is incomplete—it lacks details on parameter meanings, behavioral constraints, and usage context, making it only minimally adequate.
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 0%, so the schema provides no parameter descriptions. The description mentions filtering by completion status, which adds some meaning for the 'completed' parameter, but it doesn't explain 'project_id' or 'list_id' semantics. This partial compensation results in a baseline score.
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 ('Get todo items') and the target resources ('from a project or specific todo list'), which is specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_projects' or 'update_todo', missing full 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 minimal guidance by mentioning optional filtering by completion status, but it doesn't specify when to use this tool versus alternatives like 'get_projects' or 'update_todo', nor does it outline prerequisites or exclusions for usage.
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 discloses the primary behavior (updating completion status) and a side effect (clearing todo cache for the project), which is useful context. However, it lacks details on permissions, error handling, rate limits, or what the response looks like (no output schema). For a mutation tool with zero annotation coverage, this is a moderate gap.
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 appropriately sized and front-loaded: two concise sentences that directly state the action and side effect. Every sentence earns its place by providing essential information without redundancy or fluff.
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 (mutation with 3 parameters), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It covers the basic purpose and a side effect but lacks details on parameters, return values, error cases, or usage context. For a tool that modifies data, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'completion status' which maps to the 'completed' parameter, but doesn't explain 'project_id' or 'todo_id' (e.g., what they reference or how to obtain them). The description adds minimal meaning beyond the schema, failing to fully address the coverage gap for all three parameters.
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: 'Update a todo item's completion status.' This specifies the verb ('update'), resource ('todo item'), and field ('completion status'). It distinguishes from siblings like 'get_todos' (read-only) and 'clear_cache' (different operation). However, it doesn't explicitly differentiate from potential similar update tools (none in the sibling list).
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 clearing cache as a side effect but doesn't specify prerequisites, when not to use it, or compare it to other update operations. With siblings like 'get_todos' and 'get_projects', there's no indication of workflow or context for choosing this tool.
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 of behavioral disclosure. It adds useful context about caching ('Results cached for 2 minutes'), which informs performance and data freshness. However, it lacks details on permissions, error handling, pagination, or response format, leaving 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences: 'Get recent messages from a project. Results cached for 2 minutes.' Every word adds value, with no redundancy or unnecessary details, making it efficient and easy to parse.
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 that an output schema exists, the description does not need to explain return values. However, with no annotations, 2 parameters (one required), and 0% schema coverage, the description is incomplete. It covers the basic action and caching but misses parameter explanations and broader behavioral context, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning parameters are undocumented in the schema. The description does not explain the parameters at all—it mentions neither 'project_id' nor 'limit,' nor their roles or constraints. This fails to compensate for the schema's lack of documentation, leaving parameters ambiguous.
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 recent messages from a project.' It specifies the verb ('Get') and resource ('messages from a project'), making the action and target explicit. However, it does not distinguish this tool from sibling tools like 'get_message_with_comments' or 'create_message,' which reduces clarity in a crowded toolset.
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 caching ('Results cached for 2 minutes'), but this does not help differentiate it from siblings such as 'get_message_with_comments' or 'get_projects.' There is no mention of prerequisites, exclusions, or specific contexts for usage.
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 it indicates this is a destructive operation ('Clear all cached data'), it doesn't specify what types of data are affected, whether the operation is reversible, what permissions are required, or what happens after execution. The description adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two brief sentences that each serve a clear purpose: the first states the core action, the second provides usage context. There's zero wasted language, and the most important information ('Clear all cached data') is front-loaded for immediate comprehension.
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 operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'cached data' encompasses, what systems or components are affected, whether there are side effects, what confirmation or response to expect, or any limitations or risks. The agent lacks crucial information to use this tool safely and effectively.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents the empty parameter structure. No additional parameter information is needed or provided.
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 ('Clear all cached data') and resource ('cached data'), making the purpose immediately understandable. It distinguishes from siblings like 'get_cache_stats' by focusing on deletion rather than retrieval. However, it doesn't explicitly differentiate from other potential cache-related tools beyond the sibling list provided.
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 provides implied usage guidance with 'Useful for debugging or forcing fresh data', suggesting when this tool might be appropriate. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the sibling tools, leaving some ambiguity about optimal usage scenarios.
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 and discloses important behavioral traits: it's a read operation (implied by 'List'), and it explicitly mentions the 5-minute caching behavior which affects freshness of results. This goes beyond what the empty input schema provides.
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?
Two clear, efficient sentences with zero waste. The first states the core purpose, the second adds important behavioral context about caching. Every word earns its place in this appropriately sized description.
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 simple list tool with 0 parameters and an output schema, the description is reasonably complete. It covers the purpose and key behavioral trait (caching). However, it could mention what information is returned about projects or how results are structured, though the output schema may cover this.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, maintaining focus on what the tool does rather than how to call it.
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 ('Basecamp projects'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_project_details' or 'get_todos' which also retrieve project-related information, so it doesn't achieve full sibling distinction.
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 'get_project_details' for specific project information or 'get_todos' for project tasks. The cache mention hints at performance considerations but doesn't constitute usage guidance for tool selection.
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:

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

Score Badge

Copy to your README.md:

[![basecamp-mcp MCP server](https://glama.ai/mcp/servers/kbhalerao/basecamp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kbhalerao/basecamp-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/kbhalerao/basecamp-mcp'

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