Basecamp Classic MCP Server

by Boian

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., projects, todo lists/items, messages, comments, people, milestones, time entries). No two tools appear to perform the same function; even paired operations like complete_todo_item vs complete_milestone are clearly differentiated by resource type.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_projects, create_todo_item, complete_milestone). The verbs (list, get, create, update, delete, complete, uncomplete) are used uniformly across resource types, making the set predictable and readable.
Tool Count4/5
With 23 tools, the server is on the heavier side but still well-scoped for Basecamp Classic's broad feature set. Each area (projects, todos, messages, comments, people, milestones, time entries) has enough tools to be useful, though a few like get_current_person could be seen as extras.
Completeness3/5
The server covers full lifecycle for todo items and provides create/read for messages and time entries, but lacks create/update/delete for projects, messages, comments, and milestones. This leaves notable gaps in CRUD coverage, though the read-focused scope may be intentional.
Average 3.7/5 across 23 of 23 tools scored. Lowest: 3.1/5.
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 Apache 2.0.
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 must fully disclose behavioral traits. It only states the action and parameter, with no mention of idempotency, return behavior, or error conditions, such as what happens if the item is already complete or does not exist.
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 followed by a terse argument list. It is front-loaded with the action and contains no filler or redundancy.
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?
Even with an output schema covering return values, the description lacks essential behavioral context: no annotations, no side effects stated, and minimal parameter guidance. The tool's overall behavior is underspecified for an agent to use reliably.
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 no descriptions (0% coverage). The description's 'The numeric to-do item ID' restates the parameter name and integer type without adding meaningful semantics, such as where the ID comes from or any constraints.
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 opens with 'Mark a to-do item as complete,' which is a specific verb and resource. This clearly distinguishes the tool from siblings like uncomplete_todo_item and complete_milestone, as it explicitly mentions 'to-do item' and the 'complete' action.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention that this tool is for completing existing to-do items or that uncomplete_todo_item would be used to revert the action, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral transparency. It only states the core action and does not disclose side effects, idempotency, permission requirements, or error behavior for this mutation tool.
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 concise and well-structured: a clear action statement followed by a compact args list. Every sentence earns its place without unnecessary detail.
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?
The tool is simple with one parameter and an output schema, and the description covers the action and parameter. However, it lacks behavioral context such as prerequisites or side effects, making it only minimally adequate for a mutation tool.
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 has 0% description coverage, but the description includes an Args section explaining todo_item_id as 'The numeric to-do item ID.' This adds some meaning, though it largely restates the property name and type, providing minimal enrichment.
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 'Mark a to-do item as incomplete' clearly states the verb and resource. It is unambiguous and naturally differentiates from sibling tools like complete_todo_item by specifying the opposite action.
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. The description does not mention complete_todo_item or update_todo_item, nor does it specify scenarios such as reverting a completed item.
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, the description carries the full burden of disclosing behavior, but it only states the basic action. It does not mention whether the operation is reversible, idempotent, requires special permissions, or what side effects occur beyond marking complete.
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 at two sentences, with no wasted words. It front-loads the purpose and includes a simple Args section. It earns its place despite being brief.
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?
For a simple one-parameter mutation tool with an output schema, the description is minimally viable but lacks usage context and behavioral details. It would be more complete if it mentioned reversibility or relationship to 'uncomplete_milestone,' but the simplicity of the operation keeps it at a passing level.
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 repeats the parameter name and adds 'numeric' to clarify the type, but the schema already defines 'milestone_id' as an integer. This adds minimal semantic value beyond the schema, but the single parameter is self-explanatory enough to warrant a baseline score.
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 action: 'Mark a milestone as complete.' The verb 'Mark' and resource 'milestone' are specific, and the sibling tool 'uncomplete_milestone' confirms this is the inverse operation, distinguishing it from similar tools.
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 like 'uncomplete_milestone' or 'list_milestones.' The description only states the action without any context, prerequisites, or exclusions.
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?
The readOnlyHint annotation already signals a safe read operation. The description's 'List all' aligns with this but adds no additional behavioral context beyond what annotations provide—such as pagination, ordering, or authorization requirements. No contradiction with annotations.
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: one sentence for the purpose and a brief Args section. Every word earns its place, with no filler or repetition.
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?
Given the tool's simplicity (single required parameter, no nested objects) and the presence of an output schema, the description sufficiently covers what the tool does and what input is needed. It doesn't discuss edge cases, but none are critical for a straightforward read-only list operation.
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 restates the parameter name and calls project_id 'numeric,' which merely repeats the schema's type 'integer.' It adds minimal meaning beyond what the schema already specifies.
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 uses a specific verb ('List') and resource ('all to-do lists for a project'), clearly distinguishing it from sibling tools like get_todo_list (singular) and list_todo_items (items). It lacks an explicit mention of alternatives, but the scope is clear.
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 when to use the tool (to retrieve all to-do lists for a given project) but provides no explicit guidance on when not to use it or how it compares to related tools like get_todo_list. It gives the required context (project_id) but no exclusions or alternative recommendations.
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, the description carries full behavioral disclosure burden. It only states the action without revealing side effects, required preconditions, or error conditions. For a mutation tool, this is a minimal disclosure.
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, with a single accurate statement and a clear argument list. It wastes no words and is easy to parse.
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?
Given the tool's simplicity (one parameter, straightforward action) and the presence of an output schema, the description is mostly complete. However, it could mention that it sets the milestone's status to incomplete, but this is implied by the wording.
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 clarifies the only parameter (milestone_id) as 'The numeric milestone ID', which adds meaning beyond the bare schema type. Since schema description coverage is 0%, this explanation compensates somewhat but remains minimal.
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 'Mark a milestone as incomplete' uses a specific verb and resource, clearly stating the tool's action. It naturally distinguishes from the sibling tool 'complete_milestone' by indicating the opposite operation.
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 like 'complete_milestone'. The description lacks any context about typical use cases or prerequisites.
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, the description carries the full burden, but it only explains parameter semantics. It does not disclose side effects, required permissions, whether notifications are actually sent, or what happens if the list does not exist. The 'notify' parameter is mentioned but not elaborated on.
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 with a one-sentence summary, followed by a clean Args list. Every sentence provides useful information with no redundancy.
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?
The tool has 5 parameters and an output schema, so the description adequately covers parameter roles. However, it lacks usage context such as typical workflows, prerequisites (e.g., the todo list must exist), or behavior when required parameters are invalid. It is minimally viable but not rich.
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?
Schema description coverage is 0%, so the description fully compensates by providing a clear explanation for each parameter. It correctly notes optionality for responsible_party_id and due_at, and adds format details (YYYY-MM-DD) and the meaning of notify. This is valuable beyond the bare schema.
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 begins with 'Create a new to-do item in a to-do list,' using a specific verb and resource. This clearly distinguishes it from sibling tools like update_todo_item, complete_todo_item, and delete_todo_item.
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 explicit guidance is given about when to use this tool versus alternatives, nor are conditions or prerequisites mentioned. The description implies creation use but offers no exclusions or comparisons to sibling 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?
The readOnlyHint annotation already indicates a safe read operation. The description adds only the vague term 'recent' without defining order, limit, or pagination, so it contributes little behavioral transparency beyond what the annotation 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?
The description is concise, with two sentences that immediately state the purpose and document the parameter. It is front-loaded with no unnecessary information.
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 simple one-parameter read-only tool with an output schema, the description is largely sufficient. However, 'recent' is ambiguous and the description does not clarify message count, ordering, or any limits, leaving some gap in completeness.
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 provides a brief explanation of the only parameter ('The numeric project ID'), which adds meaning to the schema's bare integer type. With 0% schema description coverage, this minimal explanation is necessary and somewhat sufficient.
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 lists recent messages/posts for a project, using a specific verb and resource. This distinguishes it from siblings like get_message (single message) and create_message (writing).
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 when needing recent messages for a project but doesn't explicitly discuss alternatives or exclusions. It provides enough context for straightforward use but lacks explicit guidance on when to prefer this tool over related ones.
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?
The description only says 'Delete' which is already implied by the tool name and the destructiveHint annotation. It adds no additional behavioral context such as irreversibility, permission requirements, or side effects.
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, front-loading the action in the first sentence and then listing the single argument with a brief explanation. No filler or redundancy.
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 delete operation with one parameter and an output schema, the description covers the essential purpose and argument. It omits any note about permanence or error behavior, but given the destructiveHint and output schema, these are not critical 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 description explicitly explains 'todo_item_id: The numeric to-do item ID', providing semantic meaning beyond the raw schema type of integer. This compensates for the 0% schema description coverage.
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 'Delete a to-do item' with a specific verb and resource, and the tool name reinforces this. It is unambiguous and distinct from sibling tools like update or complete.
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 complete_todo_item or update_todo_item. It simply states the action without explaining prerequisites or exclusions.
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?
The description aligns with the readOnlyHint annotation by indicating a read operation, and adds that the response includes the body. It does not disclose error behavior or edge cases, but the read-only annotation already covers the safety profile for this simple getter.
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 well-structured: a single purpose sentence followed by a clear Args section. Every word earns its place, and there is no redundant or irrelevant content.
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?
Given the tool's low complexity (one parameter), an output schema, and a readOnly annotation, the description covers the essential invocation details. It lacks an explicit comparison to list_messages, but for a simple getter this is sufficient for an agent to select and call the tool correctly.
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 provides no description for message_id, so the description compensates by explaining it as 'the numeric message ID.' This adds meaningful semantic context beyond the integer type, clearly indicating the parameter identifies which message to retrieve.
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 gets a specific message/post and its body, identifying the verb and resource. The word 'specific' implies a single-record fetch, distinguishing it from list_messages, though it does not explicitly name the sibling alternative.
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?
Usage is implied by 'specific message' and the required message_id argument, indicating this is for retrieving one known message. However, there is no explicit guidance on when to use this instead of list_messages or other alternatives.
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?
The readOnlyHint annotation already indicates a safe read operation, and the description's 'Get details' is consistent. It adds the 'Basecamp Classic' context but does not disclose error handling, return format, or any constraints beyond what the annotation implies. Adequate but not rich.
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, with two short lines and zero filler. The Args listing is structured and directly to the point.
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?
Given the tool's simplicity (one ID parameter, read-only, output schema provided), the description is sufficient. It could have referenced list_projects as the alternative for retrieving all projects, but that is not essential for correct invocation.
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 has 0% description coverage, so the description must compensate, but it only says 'The numeric project ID', which largely restates the integer type. It does not explain where the ID comes from or any constraints, leaving the parameter under-explained.
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 'Get details for a specific Basecamp Classic project', using a specific verb and resource. This distinguishes it from list_projects (which lists all projects) and other 'get' sibling tools by focusing on a single project.
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?
Usage is implied: use this tool when you have a project_id and need details for one project. However, there is no explicit guidance on when not to use it or mention of alternatives like list_projects for fetching multiple projects.
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?
The description is consistent with the readOnlyHint annotation and adds the scope of returning all items. However, it does not disclose potential ordering, pagination, or filtering behavior. Since readOnlyHint already covers safety, the added behavioral context is minimal but not contradictory.
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: one sentence for the primary action and one line for the argument. It is front-loaded and contains no irrelevant 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?
With an output schema present and a readOnlyHint annotation, the description does not need to explain return values. It covers the essential behavior and the sole parameter. It lacks explicit alternative tools or edge-case behavior, but for a simple list tool this is sufficient.
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 provides only the type `integer` for `todo_list_id`, with no description. The description compensates by explaining that it is 'The numeric to-do list ID,' clarifying its meaning as the identifier of the parent list.
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 lists all to-do items in a to-do list, using a specific verb and resource. It is distinguishable from sibling tools like `list_todo_lists` and `get_todo_list`, though it does not explicitly name them as alternatives.
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 usage is implied by naming the required `todo_list_id` parameter, but there is no explicit guidance on when to use this tool versus related list/get tools. For a simple one-parameter read, this is adequate but not explicit.
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?
The description adds no behavioral context beyond the readOnlyHint annotation. It simply repeats the purpose and the parameter, without explaining response details, authorization needs, or error behavior. Since annotations already cover the read-only nature, the description provides no additional transparency value.
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 two lines with a clean 'Args:' structure. It is highly concise, with every word contributing to meaning and no redundant content.
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 get-by-ID tool with a readOnlyHint and an output schema, the description covers the purpose and parameter adequately. It lacks explicit usage alternatives, but the tool's low complexity and effective parameter documentation make it sufficiently complete.
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 description explicitly defines person_id as 'The numeric person ID', adding semantic meaning to the schema's bare 'integer' type. For a single parameter, this clarification is sufficient to guide correct usage.
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 'Get details for a specific person' clearly states a read operation for a single resource. The words 'specific person' distinguish it from list_people or get_current_person, and the verb 'get' aligns with the sibling naming pattern.
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 when you have a person_id and need details, but it does not explicitly state when to prefer this over list_people or get_current_person. No exclusionary or alternative guidance is provided, leaving usage to be inferred from the parameter.
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?
Annotations already include readOnlyHint=true, so the read-only nature is covered. The description adds that the result includes items ('with its items'), which is useful context beyond the annotation, but it does not disclose details like pagination, auth requirements, or rate limits. This is consistent with the annotation.
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 two short sentences: first states the action, second documents the argument. Every word earns its place with no redundancy or filler, making it appropriately concise and front-loaded.
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 get-by-ID tool with one parameter, an output schema, and readOnlyHint annotation, the description sufficiently covers the main purpose and parameter semantics. It could have added a note about return behavior or errors, but the existing output schema and the nature of the tool make it reasonably complete.
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 description must compensate. It does so by explaining that todo_list_id is 'The numeric to-do list ID', which adds meaning beyond the schema's raw integer type. However, this is still basic and does not provide additional constraints or context beyond identifying the parameter's role.
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 'Get a specific to-do list with its items' clearly states a specific action (get) on a specific resource (a to-do list) and distinguishes it from sibling tools like list_todo_lists and list_todo_items by indicating it targets a single list and includes items.
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?
Usage is implied through the phrase 'a specific to-do list' and the required todo_list_id parameter, suggesting it is for fetching one list by ID. However, there is no explicit guidance on when to use this instead of list_todo_lists or list_todo_items, and no mention of alternative tools.
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?
The annotation readOnlyHint=true already covers the safety profile, so the description does not need to reiterate that it is read-only. The description adds the qualifier 'all', indicating that no filtering is applied, which is a slight behavioral context. However, it does not disclose other behavioral traits such as pagination, ordering, or whether completed milestones are included. The description is consistent with the annotation, and there is no contradiction.
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 two sentences: one for the purpose and one for the argument. It is extremely concise, front-loaded with the core action, and contains no fluff or repetition. Every word earns its place.
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?
Given the tool is a simple read-only list with a single parameter and an output schema, the description is nearly sufficient. It clearly identifies the resource and scope, and the output schema is present to define the return value. It does not mention edge cases like empty projects or error conditions, but for a straightforward list operation, this is acceptably complete.
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 one parameter, project_id, with type integer and no description (0% coverage). The description adds 'The numeric project ID', which clarifies the meaning slightly but mostly restates the type. For a simple single parameter, this is adequate but not rich. It compensates for the missing schema description, so a baseline of 3 is appropriate.
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 'List all milestones for a project' clearly states the action (list) and the resource (milestones) with a specific scope (for a project). It is distinct from sibling tools like list_projects and list_todo_items, and there is no ambiguity about what this tool does.
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: you need a project_id to list milestones for that project. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. There are no sibling tools for listing milestones, so the lack of explicit alternatives is not a major gap, but the guidance is minimal.
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 present, so the description carries full responsibility. It discloses parameter-specific behaviors such as 'use 0 to unassign' and 'notify the assigned person', but does not mention permissions, reversibility, partial update semantics, or return values.
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 compact and well-structured, with the purpose stated first and parameters listed in an easily scannable format. No filler or redundant information.
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?
Parameter semantics are well covered, but the description lacks broader context such as whether omitted fields are preserved, required permissions, or error behavior. The presence of an output schema mitigates return value explanation but does not cover behavioral semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions (0% coverage), so the description fully compensates by providing clear semantics for each parameter, including the date format for due_at and the special value 0 for responsible_party_id.
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 'Update an existing to-do item', specifying a concrete verb and resource. This distinguishes it from sibling tools like create_todo_item, complete_todo_item, and delete_todo_item.
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?
Usage is implied by the verb 'update', but there is no explicit guidance on when to choose this tool over alternatives like complete_todo_item or delete_todo_item. No prerequisites or exclusions are mentioned.
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 present, so the description carries the full burden. It discloses that HTML is allowed in the body, which is useful, but it does not mention return values, idempotency, failure modes, or permissions.
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 concise and front-loaded, starting with the purpose and followed by brief parameter descriptions. No unnecessary content.
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 two-parameter create tool with an output schema present, the description covers the essential purpose and parameters. The phrase 'message/post' is slightly ambiguous, but the overall context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters: message_id as a numeric ID and body as the comment body with HTML allowed. This adds clear meaning beyond the raw schema.
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 'Add a comment to a message/post' with a specific verb and resource. It distinguishes this tool from siblings like create_message or list_comments by specifying the comment target.
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, nor are prerequisites (e.g., message must exist) or exclusions mentioned. The description only states what the tool does.
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?
readOnlyHint annotation is present, and the description does not contradict it. The description adds the scope of 'account' but provides no additional behavioral context like pagination, ordering, or rate limits. With annotations covering safety, a score of 3 is appropriate.
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 sentence, free of unnecessary words, and immediately front-loads the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 no parameters, an output schema, and a read-only annotation, the description is complete. It tells the user exactly what it does (lists all people) and the scope.
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, so the baseline is 4. The description adds no parameter-specific information, but none is needed since there are no parameters.
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 uses a specific verb ('List') and resource ('all people') with clear scope ('in the Basecamp Classic account'). It clearly distinguishes from siblings like get_person (single person) and get_current_person (current user).
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 explicit guidance on when to use this tool vs alternatives. While it's implied that this is for retrieving all people, the description doesn't mention when not to use it or reference sibling tools like get_person.
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?
Annotations already declare readOnlyHint=true, and the description adds the project scoping constraint. However, it does not disclose any additional behavior such as pagination, sorting, or error handling. The value added beyond annotations is minimal.
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. It contains a one-sentence summary followed by a structured Args block for the parameter, with no wasted words.
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 one parameter and an output schema, the description is nearly complete. It states the purpose and parameter. It lacks any mention of edge cases or response specifics, but the output schema likely covers return shape.
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%, but the description's 'The numeric project ID' adds little meaning beyond the property name 'project_id' and its integer type. It is essentially a restatement, so it fails to compensate for the lack of schema descriptions.
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 'List all time entries for a project,' which is a specific verb (list) and resource (time entries) with a scope (project). This distinguishes it from siblings like create_time_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for listing time entries for a specific project, identified by project_id. It does not explicitly mention when not to use it or alternatives, but the context is sufficient for typical listing scenarios.
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, the description carries the burden of disclosing behavioral traits. It adds meaningful context like 'HTML allowed' for body and explains the semantics of 'private', which goes beyond the schema. However, it does not disclose permissions, error behavior, reversibility, or any side effects beyond creating the message. Thus, it provides partial but not complete transparency.
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 front-loaded with a one-sentence summary followed by a compact, well-organized Args list. Every element is necessary, and there is no redundant fluff. The structure makes it easy to scan and understand the tool quickly.
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?
The description and schema together provide sufficient parameter context, and an output schema exists so return format is covered elsewhere. However, it lacks some operational context such as whether the project must already exist, if any permissions are required, or how private messages behave for other project members. These are minor gaps for a straightforward create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It does: every one of the 5 parameters is described with meaningful semantics (e.g., project_id is numeric, category_id is optional, private indicates message privacy, body allows HTML). This exceeds the schema's type-only information and fully clarifies each parameter's role.
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 states 'Create a new message/post in a project' with a clear verb and resource, and the parameter list further defines what is created. It clearly distinguishes from sibling tools like create_todo_item or create_comment by specifying messages/posts.
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 implicitly conveys usage: this is for creating messages/posts in a project. However, it does not explicitly state when to use this over alternatives or mention any prerequisites (e.g., project must exist, category must be valid). The absence of exclusions or alternative tool references keeps this at an implied-usage level rather than explicit guidance.
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 useful behavior such as person_id defaulting to current user and optional todo_item_id association. However, it does not mention side effects, validation rules, or error conditions, which are important for a mutation tool.
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 concise with a single clear purpose sentence followed by an organized Args list. Each parameter description is necessary because the schema lacks descriptions, so every line earns its place.
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?
All six parameters are documented, and the output schema exists so return values are not needed. The description covers the essentials for logging time, though it lacks details about validation or failure modes, which is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining every parameter: project_id as numeric, date format, hours with example, description, person_id default, and todo_item_id optional. This adds meaning beyond the bare schema.
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 'Log a time entry on a project' with a specific verb and resource. This distinguishes it from sibling tools like list_time_entries (read) and other create tools (create_todo_item, create_message) by focusing on time entry logging.
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 by naming the action, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No when/when-not guidance is given, though the tool name and context make the purpose evident.
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?
Annotations provide readOnlyHint=true, so the read-only nature is disclosed. The description adds no additional behavioral context such as ordering, pagination, or error handling, but the annotation covers the key safety trait.
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 two short sentences: purpose first, then argument definition. It is front-loaded and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter operation, the presence of an output schema, and the readOnlyHint annotation, the description adequately covers purpose and parameter meaning. No additional complexity requires further explanation.
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?
Schema coverage is 0%, but the description explicitly defines message_id as 'The numeric message ID', clarifying the parameter's referent beyond just its name and integer type. This compensates for the lack of schema descriptions.
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 uses a specific verb 'List' with a clear object 'comments' and scope 'on a message/post', immediately distinguishing it from siblings like 'create_comment' and 'list_messages'.
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?
Usage is implied by the tool's name and required message_id parameter, but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of when not to use it.
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?
The readOnlyHint annotation already indicates a safe read operation, lowering the bar. The description adds the specific scoping to the current authenticated person, but provides no additional behavioral context beyond that.
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, front-loaded sentence with no wasted words. It conveys the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a zero-parameter read operation with an output schema available, the description is fully sufficient. It requires no explanation of parameters or return values.
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?
There are zero parameters, so the description is not responsible for explaining parameter semantics. The baseline of 4 applies because no parameters exist to describe.
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 uses a specific verb ('Get') and clearly names the resource ('currently authenticated person's details'). It distinguishes itself from siblings like get_person (which fetches by ID) and list_people (which lists all people).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for accessing the authenticated user's own details, which is distinct from siblings. However, it does not explicitly state when not to use it or mention alternatives.
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?
Beyond the readOnlyHint annotation, the description adds the behavioral qualifier 'active', indicating that archived or inactive projects are filtered out. It also names the specific API version (Basecamp Classic). While it doesn't detail pagination or response format, the output schema covers that, and the description adds useful context.
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, front-loaded sentence: 'List all active Basecamp Classic projects.' Every word is meaningful, and there is no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with an output schema, the description is complete. It states what the tool returns (all active projects) and the domain (Basecamp Classic). The output schema handles return value details, and annotations handle safety. No additional context is needed.
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, so the baseline is 4. The description adds no parameter-specific details, which is appropriate since there are none to describe. It contributes clarity about the fixed scope of the operation.
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 specifies the exact action (List), resource (projects), and scope (all active Basecamp Classic projects). This clearly distinguishes it from sibling tools like get_project, which retrieves a single project, and list_todo_lists, which targets a 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (when you need all active projects), but it does not explicitly mention alternatives or exclusion criteria. For example, it does not say 'use get_project for a single project' or note that archived projects are excluded. The context is sufficient for a simple list tool, but no explicit guidance is provided.
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-classic-mcp MCP server](https://glama.ai/mcp/servers/Boian/basecamp-classic-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Boian/basecamp-classic-mcp)

Score Badge

Copy to your README.md:

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

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