Provides tools for managing Basecamp projects, including retrieving project details, messages, todos, and schedules, as well as creating messages and updating todo completion status.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Basecamp MCP Server show me my incomplete todos for the website redesign project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect your Basecamp workspace to Claude and other AI tools via the Model Context Protocol.
Go to Basecamp and log in
Click your profile → "Settings" → "Personal access tokens" (or "Integrations & apps" → "API credentials")
Create a new token (it needs "all access")
Copy the token
Find your Account ID in the URL when you're in your workspace (e.g., https://3.basecamp.com/ACCOUNT_ID)
export BASECAMP_API_TOKEN="your_token_here"
export BASECAMP_ACCOUNT_ID="your_account_id_here"Or create a .env file in the project root (add to .gitignore):
BASECAMP_API_TOKEN=your_token_here
BASECAMP_ACCOUNT_ID=your_account_id_hereuv syncuv run python -m basecamp_mcp.serverOr run it directly:
uv run python src/basecamp_mcp/server.pyRelated MCP server: Basecamp MCP Server
get_projects - List all Basecamp projects
get_project_details - Get detailed info about a project
get_messages - Get recent messages from a project
get_message_with_comments - Get a specific message with all comments
get_todos - Get todo items (with optional filtering by completion)
create_message - Create a new message in a project
update_todo - Mark a todo as complete/incomplete
get_schedules - Get schedules from a project
clear_cache - Clear all cached data
get_cache_stats - View cache statistics
basecamp://projects - List of all projects
basecamp://project/{project_id}/summary - Project summary with recent activity
The server uses SQLite for persistent caching with TTL (Time To Live):
Projects: 5 minutes cache
Messages: 2 minutes cache
Todos: 2 minutes cache
Project details: 10 minutes cache
Use get_cache_stats to see cache hit rates and size, or clear_cache to force fresh data.
BaseCampMCP/
├── src/
│ └── basecamp_mcp/
│ ├── __init__.py
│ ├── server.py # Main MCP server with tools & resources
│ └── cache.py # SQLite cache manager
├── pyproject.toml # Project configuration
└── README.mdTo use with Claude Desktop:
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the Windows equivalent
Add the server:
{
"mcpServers": {
"basecamp": {
"command": "uv",
"args": ["run", "--with", "mcp", "python", "-m", "basecamp_mcp.server"],
"cwd": "/Users/kaustubh/Documents/BaseCampMCP"
}
}
}Restart Claude Desktop
# Run with verbose logging
uv run python -m basecamp_mcp.serverThe cache database is stored in basecamp_cache.db in your working directory. You can inspect it with:
sqlite3 basecamp_cache.db
sqlite> SELECT key, hits, expires_at FROM cache ORDER BY hits DESC;GET /projects.json - List projects
GET /projects/{id}.json - Get project details
GET /projects/{id}/messages.json - List messages
GET /projects/{id}/messages/{message_id}.json - Get message
GET /projects/{id}/messages/{message_id}/comments.json - Get comments
GET /projects/{id}/todos.json - List todos
GET /projects/{id}/todolists/{list_id}/todos.json - Get todos from list
PUT /projects/{id}/todos/{todo_id}.json - Update todo
POST /projects/{id}/messages.json - Create message
GET /projects/{id}/schedules.json - List schedules
MIT
Clear all cached data. Useful for debugging or forcing fresh data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Create a new message in a project. Clears message cache for this project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| subject | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 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.
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.
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.
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.
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.
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.
Get statistics about the cache.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Get recent messages from a project. Results cached for 2 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a specific message with all comments.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| message_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 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.
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.
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.
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.
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.
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.
Get detailed information about a specific project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
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.
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.
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.
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.
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.
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.
List all Basecamp projects. Results are cached for 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get schedules from a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get todo items from a project or specific todo list. Optionally filter by completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| list_id | No | ||
| completed | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Update a todo item's completion status. Clears todo cache for this project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| todo_id | Yes | ||
| completed | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0clear_cachecreate_messageget_cache_statsget_message_with_commentsget_messagesget_project_detailsget_projectsget_schedulesget_todosupdate_todoScored across 10 tools
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.
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.
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.
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.
Your Aurentia workspace — projects, CRM, tasks, deliverables — in Claude, Cursor or any MCP client.
Connect AI tools to Trilo workspaces — manage tasks, messages, pages, calendars, meetings, and more.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
