Basecamp MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Several tools have overlapping purposes, such as basecamp_read vs. basecamp_get_card/basecamp_get_todo, basecamp_comment vs. basecamp_comment_with_file, and basecamp_trash_recording vs. basecamp_trash_card/basecamp_trash_project. Agents may struggle to choose the correct tool without deep domain knowledge.
Naming Consistency4/5
Most tools follow the predictable pattern basecamp_<verb>_<noun> (e.g., list_projects, create_card, update_todo). Minor deviations include basecamp_comment, basecamp_read, basecamp_comment_with_file, and the index_* group, which uses a slightly different prefix style.
Tool Count1/5
With 88 tools, the server is extremely bloated. Many tools are redundant or overly granular (e.g., list_cards vs. list_card_ids, multiple index helpers). The count far exceeds what is needed for a coherent MCP server, likely overwhelming agents.
Completeness4/5
The tool surface covers almost all major Basecamp resources: projects, card tables, todos, messages, vaults, documents, uploads, schedule, campfires, and people. Minor gaps exist, such as no direct campfire line update or message deletion, but generic trash/archive/activate tools partially fill these.
Average 3.2/5 across 88 of 88 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it says nothing about side effects, whether updates are partial or full replacement, permission requirements, or response behavior. It fails to disclose any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than concise effectiveness. The single sentence adds no value beyond the tool name and thus does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, this description is completely inadequate. The agent has no information to correctly invoke the tool or understand what the update affects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage, and the description does not compensate at all. It does not mention due_on, assignee_ids, content, starts_on, or any other parameter, leaving their semantics entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a to-do' is a tautology that restates the tool name without adding any specifics such as which fields are updatable or how this differs from basecamp_update_todolist or basecamp_complete_todo. It provides no verb beyond the name and no resource detail beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like basecamp_create_todo, basecamp_complete_todo, or basecamp_update_todolist. There is no mention of prerequisites, typical scenarios, or exclusions.
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 provided, and the description discloses nothing about side effects, reversibility, permissions, or what 'adding an on-hold section' actually does to the column. This leaves the agent blind to 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is brief, but it is under-specified rather than appropriately sized. It lacks the necessary detail to be useful, making the brevity a drawback rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two required parameters, no output schema, and no annotations, the description should explain the tool's effect on the column and any prerequisites. It does none of this, making it far from complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not clarify the roles of project_id or column_id. The agent must infer their meaning from the names alone, which is insufficient for correct invocation.
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 clear action ('Add') and identifies the resource ('a column') and the object ('an on-hold section'). It is specific enough to convey the basic operation, though it does not explicitly differentiate from sibling tools like remove_column_on_hold.
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, no alternatives, and no exclusions. It simply states the action without any context about when it applies.
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?
With no annotations provided, the description carries the full burden of disclosing side effects, permissions, return behavior, or whether partial updates are supported. The one-line description offers none of this, effectively providing no behavioral transparency beyond the verb 'update',' which implies mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with no filler words. However, it is under-specified: it sacrifices necessary operational detail for brevity, making it minimally viable but not well-structured for a tool with many parameters and no other documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is grossly incomplete. It does not describe what fields can be updated, which fields are required, what the response looks like, or how this relates to other schedule entry operations, leaving substantial ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 8 parameters (e.g., what 'starts_at', 'all_day', or 'participant_ids' mean or how they interact). The agent is left with only parameter names and types, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a schedule entry/event'), which distinguishes it from sibling tools like create_schedule_entry and get_schedule_entry. However, it does not explicitly mention that this is an existing record or elaborate on what fields can be updated, so it is clear but not maximally specific.
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 gives no guidance on when to use this tool versus alternatives such as creating or listing schedule entries. It does not state prerequisites, exclusions, or provide examples of appropriate use, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Update an existing document' without revealing whether the operation is partial or full, what the response includes, whether it requires specific permissions, or if it is reversible. For a mutation tool, this lack of context is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It omits crucial information about parameters and behavior, so the brevity is not effective. It does not earn its place because the sentence lacks substance needed for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain required parameters (project_id, document_id), the effect of optional ones (title, content), or any return behavior. A more complete description would outline these to guide the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in the schema), and the description adds no meaning beyond the parameter names. The tool description does not even mention the parameters (title, content, project_id, document_id) or explain their roles. Since the description must compensate for low schema coverage and fails to do so, this dimension scores poorly.
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 'Update an existing document' uses a specific verb and resource, making it clear that this tool modifies an existing document. However, it does not distinguish itself from the many other update tools (e.g., update_project, update_card) beyond the resource name, nor does it clarify what 'document' refers to exactly. This is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or alternative tools for different scenarios (e.g., creating a new document with create_document). There is no explicit or implied usage context beyond the action itself.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update an existing message,' which merely restates the tool's name and provides no insight into side effects, permission requirements, reversibility, or error behavior. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no irrelevant words, but it is under-specified rather than appropriately sized. A single sentence that adds minimal information over the tool name is not effective, though it has no structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the four parameters, no annotations, and no output schema, the description is contextually incomplete. It does not explain partial update behavior (e.g., only content or only subject), what the response might contain, or any error conditions. The agent lacks essential context for reliable 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?
The input schema has 0% description coverage, so the description must compensate by explaining parameter meaning. It does not mention that content and subject are the updatable fields, nor does it clarify the roles of project_id and message_id beyond what the parameter names themselves imply. This leaves the agent to infer semantics purely from property names.
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 identifies the action (update) and the resource (existing message), which distinguishes it from sibling tools like create_message or pin_message. However, it does not specify which fields can be updated, leaving some scope ambiguity.
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 about when to use this tool versus alternatives. There is no mention of prerequisites, such as the need for an existing message_id, or that this tool is the appropriate choice for modifying message content or subject. The description simply states what it does without contextual usage advice.
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 must disclose behavioral traits. It only conveys that it performs an update (a mutation), but gives no information about partial updates, required permissions, reversibility, or effects on related resources. This is insufficient for an agent to know the tool's 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and front-loaded, which is good, but it sacrifices necessary information. It is not a well-structured summary of functionality; it's barely a sentence.
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?
Despite being a simple tool, the lack of output schema and annotations places the burden on the description. Four parameters are undocumented, and no context is given about the update behavior. The description is inadequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. It doesn't clarify that name and description are updatable fields, while project_id and todolist_id are identifiers. The description adds no meaning beyond the raw schema.
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 states the verb 'Update' and the resource 'to-do list', clearly identifying the operation and distinguishing it from other resource-specific update tools (e.g., update_todo, update_project). However, it lacks any detail about what aspects of the todo list can be updated, making it less informative than it could be.
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 the many sibling update tools. There is no mention of prerequisites, typical use cases, or alternatives.
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 must disclose behavioral traits. It does not state whether archiving is reversible, destructive, or requires specific permissions. The phrase 'any recording' is broad and could mislead about scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short, front-loaded sentence with no redundancy. However, it is under-specified for the task, which limits its usefulness despite the efficient form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information about return values, side effects, or what 'archive' entails in Basecamp.
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 covers only 50% of parameters (recording_id has description, project_id does not). The description adds no parameter semantics, failing to explain the role of project_id or relationship between the IDs.
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 'archive' and clearly identifies the resource as 'Basecamp recording'. It distinguishes from siblings like 'trash_recording' and 'activate_recording' by implying a different action, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'trash_recording' or 'activate_recording'. There are no usage scenarios, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The phrase 'Get details' implies a read operation, but it does not disclose what details are returned, whether any special permissions are required, or how errors are handled. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it omits essential information such as the required parameter and the nature of the returned data. While it is not verbose, it sacrifices clarity for brevity, making it only minimally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple structure (one parameter, no output schema), but the description still fails to note that 'person_id' is required or what kind of details are provided. With no annotations and no output schema, the agent has almost no context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines only 'person_id' as a required string, but there is no description in the schema (0% coverage). The tool description does not mention 'person_id' at all, leaving the agent to guess the format or source of the ID. This is a complete lack of semantic guidance for the sole parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get details about a specific person.' It specifies a verb ('Get') and a resource ('details about a specific person'), which distinguishes it from list-oriented siblings like basecamp_list_people. The name and description align well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is intended for fetching a single person by ID, nor does it contrast with list tools or explain prerequisites. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get', indicating a read operation, but gives no information about return format, error behavior, authentication needs, or any side effects. The description is too sparse to meaningfully convey behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is suitably front-loaded and free of fluff. However, it is under-specified, making it more a placeholder than informative content; thus it earns a mid-range score.
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?
The tool has a simple read-by-ID signature, but with no annotations and no output schema, the description should clarify what the returned schedule entry looks like or any relevant contextual details. The one-sentence description leaves the agent without enough information to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the required parameters (entry_id and project_id) or explain their semantics. The description adds no value beyond the bare schema, and with no parameter explanation, an agent would lack guidance on what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'schedule entry/event', which distinguishes it from sibling tools like list, create, and update schedule entries. It communicates the core purpose of retrieving a single specific schedule entry, though it could be more explicit that it fetches by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single schedule entry, contrasting with sibling listing tools, but it does not explicitly state when to use this over alternatives or any prerequisites. The context is clear for a simple get operation, but no direct exclusions or alternative references are provided.
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 is the only source for behavioral disclosure, but it merely restates the action without explaining idempotency, error conditions, side effects, or required permissions. It adds no insight beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff, making it highly concise and front-loaded. It could be longer, but the current length is appropriate for the simplicity of the action, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description is minimally adequate for a basic action, but it fails to mention return behavior, idempotency, or the relationship to sibling tools like basecamp_uncomplete_step. This makes it incomplete for an agent selecting among many related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (project_id, step_id) with no descriptions, and the description does not explain their purpose, format, or relationships. With 0% schema coverage and no elaboration, the agent must rely on parameter name inference alone.
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') and the resource ('step') with the outcome ('completed'), making it unambiguous. It is easily distinguishable from sibling tools like basecamp_uncomplete_step, which reverses the 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?
The description provides no guidance on when to use this tool versus alternatives, such as when to use basecamp_uncomplete_step to undo completion or basecamp_update_step for broader modifications. No context or prerequisites are mentioned.
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?
With no annotations provided, the description must disclose behavioral traits, but it merely restates the action without any additional context. It doesn't mention permissions, idempotency, side effects, or return values. This is essentially a tautology of the tool name and provides no value beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is front-loaded with the verb and resource, making it easy to parse. While it is very brief, it is appropriate for a simple action and does not contain any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a one-line description. It provides no information about post-creation behavior, errors, permissions, or return payload. Given the context of similar tools and the lack of surrounding details, the description is severely under-specified for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters ('Project name' and 'Project description'), so the baseline is 3. The tool description adds no extra meaning beyond the schema, as it simply indicates the overall action without detailing parameter relationships or 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 clearly states the action ('Create') and the resource ('Basecamp project'), which is specific and distinguishable from sibling tools such as basecamp_get_project, basecamp_update_project, and basecamp_trash_project. 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like basecamp_create_card or basecamp_create_todo. It lacks any mention of prerequisites, typical use cases, or situations where another tool would be more appropriate. The context of sibling tools implies it is the creation endpoint for projects, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies mutation (grant/revoke) but does not mention any side effects, permission requirements, reversibility, or behavior when both grant and revoke arrays are provided. This is a significant gap for a management 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 a single, front-loaded sentence with no filler words. It is maximally concise and clear at a surface level.
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?
This is a mutation tool with moderate complexity (arrays for grant/revoke) and no output schema. The description omits crucial context like whether both grant and revoke can be used together, what happens on failure, or required fields. It is too minimal for an agent to invoke correctly without additional assumptions.
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 coverage is 67% (grant and revoke have descriptions, project_id does not). The description adds little beyond reiterating 'grant' and 'revoke', and it does not clarify the format or purpose of project_id or the person IDs. Since coverage is not high and the description does not compensate, the meaning of parameters remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('grant or revoke') and the resource ('project access for people'), which distinguishes it from sibling tools like listing or getting people. It is specific about the operation, though it could more explicitly mention project_id.
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, such as when to use list_people to check current access or create_project to set initial membership. The description simply states the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavioral traits, but it only states the action without explaining consequences (e.g., whether the card is soft-deleted, recoverable, or affects dependent records). It does not add meaningful context beyond the tool's name and input schema.
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, concise sentence with no wasted words. It front-loads the action and resource effectively, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It does not mention the operation's side effects, reversibility, required permissions, or what happens after the card is trashed, leaving the agent without sufficient context to use the tool safely.
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 zero description coverage, and the description does not compensate by explaining the parameters. While 'project_id' and 'card_id' are somewhat self-explanatory, the description adds no additional meaning about their roles, relationships, or required values, so it fails to bridge the low schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move a card to trash' clearly identifies the action and resource (card), and it is distinguishable from sibling tools like basecamp_trash_project and basecamp_trash_recording because it specifically targets cards. However, it does not explicitly contrast with these alternatives, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as basecamp_trash_recording or basecamp_archive_recording. It implies usage when a card needs to be trashed but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer the appropriate scenario.
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 exist, so the description carries the full burden. It only states the basic create action without disclosing side effects, permission requirements, or return behavior. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the verb and resource. It is efficient and free of fluff, though it could add more useful context without becoming verbose.
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?
With no output schema, no annotations, and a 4-parameter schema (one undocumented), the description is too minimal. It does not explain what the created column looks like, what is returned, or any prerequisites, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information. While the schema covers 75% of parameters with descriptions, project_id is undocumented, and the description does not clarify its role or the relationship between 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 clearly states the action (create), the resource (column), and the context (in a card table). It distinguishes from sibling tools like create_card or update_column by specifying the entity type.
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 about when to use this tool versus alternatives such as update_column or list_columns. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the tool returns project details from an index, but does not state whether it is read-only, whether the index may be stale, whether it can fail if the project is not indexed, or any other behavioral traits. This is minimal transparency for a tool with no annotation support.
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 redundant words. It efficiently conveys the primary purpose and key output components, earning its place without unnecessary fluff. It is appropriately sized for a tool with one parameter.
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?
While the description lists the return elements, it lacks necessary context for an agent to confidently select this tool among many similar siblings. There is no explanation of the 'index' concept, no usage scenarios, no relation to other index tools (e.g., 'basecamp_index_build'), and no output schema. The context is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, 'project_id', with a description 'Project ID', covering 100% of the schema. The description repeats 'project ID' but adds no extra semantic meaning, such as format, required state, or relation to the index. Since schema coverage is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get project details') and resource ('from index'), and enumerates the contained elements ('project ID, card tables, columns'). It partially distinguishes from the sibling tool 'basecamp_get_project' by specifying the data source, though it does not explicitly explain the difference between the index and the API.
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 such as 'basecamp_get_project' or other index-related tools. There are no exclusions, prerequisites, or context about whether the index must be built first. The description only implies that this is an index-based lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states a project is updated but does not disclose side effects, whether it rebuilds or increments the index, if it requires any preconditions, or whether it is destructive. Agents have no clues about performance implications or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a tool with one parameter, though it could add a bit more context without becoming verbose.
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 tool, the description is minimally viable. It states the action and target. However, without annotations or an output schema, it lacks context about what the index is, what changes occur, and when to use it relative to the sibling index tools. Given the complexity, more would be helpful but not strictly required.
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 covers 100% of the parameter with a clear description ('Project ID to update in index'). The tool description adds no additional meaning beyond the schema, so the baseline of 3 applies. No missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'index' for a specific project. It distinguishes from siblings like basecamp_index_build (which likely builds the whole index) and basecamp_index_get_project (which retrieves). However, what exactly 'index' refers to is not explained, keeping it slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this tool updates the index for a single project rather than all projects, nor does it reference any sibling tool. The name implies 'specific project' but the description doesn't explicitly contrast with index_build or others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'move' and 'status change,' but omits details like required permissions, side effects on card position, whether the move is reversible, or what happens to watchers. Minimal behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It is concise and front-loaded, but the parenthetical '(status change)' is arguably redundant. Still, it earns its place as a compact statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain required inputs, return values, or any edge cases. The context of sibling tools and complexity demand much more detail.
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 schema covers 50% of parameters (position and to_column have descriptions), but card_id and project_id are left unexplained. The description does not compensate by explaining these values or their roles. It only mentions 'card' and 'column' generally, adding no meaning beyond the field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: moving a card to a different column. It uses a specific verb+resource and includes a clarifying parenthetical. It is distinct from sibling tools like move_column or update_card because it explicitly targets cards.
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 on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or scenarios where another tool (e.g., update_card) might be more appropriate. It only states what it does, not when to choose it.
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 the full burden. It only states what the tool does but discloses no behavioral traits: no mention of network activity, read-only nature, error handling, input format requirements, or return structure. The description is too minimal to be transparent.
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 that front-loads the action and resource. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema), the description states the purpose and the kind of IDs returned. However, it does not describe the return format or behavior on invalid URLs, which would be important for an agent relying solely on this description. It is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only that the 'url' parameter is a Basecamp URL. It does not explain what URL formats are accepted, whether full or partial URLs work, or provide examples. The description partially compensates but lacks the detail needed for reliable invocation.
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 ('Parse') with a clear resource ('Basecamp URL') and explicit output ('extract IDs (account, project, card/todo)'). It clearly distinguishes this utility tool from the many CRUD and read operations in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention typical use cases like preparing IDs for subsequent Basecamp calls, nor does it state exclusions or prerequisites. The description is purely functional without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It states an action ('remove') but does not explain side effects, permission requirements, reversibility, or the impact on cards in the on-hold section. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no verbose or redundant content. It is concise and to the point, though it sacrifices explanatory detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, the description is too sparse. It lacks parameter explanations, usage context, and behavioral notes. With no output schema or annotations, the agent has insufficient information to confidently invoke this tool.
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%, and the description does not mention the parameters project_id or column_id. While the parameter names are self-explanatory, the description fails to clarify their relationship or provide any additional meaning beyond the 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 uses a specific verb 'remove' and identifies the exact resource ('column') and the object being removed ('on-hold section'). This clearly distinguishes it from the sibling tool basecamp_set_column_on_hold, which likely adds the on-hold section.
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 its alternatives, such as set_column_on_hold or other column operations. It lacks context on prerequisites, intended scenarios, or exclusions.
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 provided, and the description does not disclose any behavioral traits such as side effects, error conditions, or prerequisites. It simply states the action without any additional 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, focused sentence that states the tool's purpose without extraneous information.
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?
The description is minimal and lacks usage guidelines, behavioral details, and output expectations. For a tool with no annotations, this is insufficient context for an agent to fully understand the operation's implications.
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 describes message_id but not project_id, and the description adds no parameter semantics. With 50% schema coverage, the description does not compensate for the undocumented project_id parameter.
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 'Unpin a message from the message board' clearly states the action (unpin) and resource (message), distinguishing it from sibling operations like basecamp_pin_message.
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 or how it relates to alternatives like basecamp_pin_message. The only context is the tool name itself, which implies the inverse operation, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only says 'update', which implies mutation, but doesn't state whether it's a partial update, what happens to unspecified fields, required permissions, or the response format. This is insufficient for a write operation without annotation support.
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 concise sentence that directly conveys the tool's core purpose without redundancy or irrelevant detail.
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?
This is a mutation tool with no annotations, no output schema, and only 50% schema coverage. The description is minimal and does not explain required identifiers, update semantics, or expected response, leaving significant gaps for an agent to safely invoke it.
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 coverage is 50%: title and description have descriptions, but project_id and column_id do not. The description mentions the two updatable fields, aligning with the schema, but adds no extra meaning about the identifiers or update semantics. It provides modest added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (update) and resource (column) and specifies the updatable fields (title or description). It distinguishes itself from column-related siblings like basecamp_change_column_color or basecamp_move_column by focusing on metadata fields.
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 other column update tools. It does not mention alternatives such as change_column_color or move_column, nor does it explain the context for updating a column's title/description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Rename' implies a mutation, but there is no mention of permissions, reversibility, side effects, or return value. The agent is left without crucial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient but under-specified. It earns a middle score because it is not verbose, but it lacks the substance needed to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple mutation tool with 3 required parameters and no output schema, but the description provides almost no context. It does not explain how to use the parameters, what the operation entails, or what the outcome is. The description is too minimal for reliable 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 description coverage is only 33% (only 'title' is described). The description does not compensate for the undocumented 'project_id' and 'vault_id' parameters. It adds no meaning beyond what the schema already provides.
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 'Rename a vault (folder)' uses a specific verb ('rename') and resource ('vault'), clearly distinguishing this from sibling tools like create_vault, get_vault, or list_vaults. It succinctly states the core action and object.
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 such as basecamp_create_vault or basecamp_get_vault. The description simply states the action without any context 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?
With no annotations, the description carries the full burden for behavioral disclosure. 'Get details' implicitly indicates a read-only operation, but it does not mention permissions, error behavior, or retrieval constraints. It adds minimal context beyond the verb.
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 is highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what 'details' are returned and any prerequisites (e.g., project context). It does neither, leaving gaps about return format and error scenarios.
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 schema has 0% description coverage, and the description does not explain the meaning or relationship of project_id and todo_id. It only says 'specific to-do', which hints at todo_id but leaves project_id unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the target resource ('a specific to-do'), distinguishing it from list/update/complete operations. It lacks explicit mention of alternative tools but the verb+resource is specific and unambiguous.
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 basecamp_list_todos or basecamp_update_todo. The description only states what it does, not when it should be chosen.
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 exist, so description must disclose behavior. It only says 'Get details', which implies read-only but omits what details are returned, whether authentication/project access is required, or error behavior for missing upload. Under-specified for a get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler, but it is also extremely minimal. It earns its place but adds little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter info, the description does not provide enough context about return values (what 'details' includes) or preconditions. It is barely adequate for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero descriptions for project_id and upload_id, and the description does not clarify their roles. An agent must guess that project_id scopes the upload and upload_id identifies it, which is not explicitly stated.
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 a specific action ('Get details') on a specific resource ('a specific file upload'), which distinguishes it from sibling tools like list_uploads or create_upload.
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?
No explicit guidance on when to use this tool vs alternatives; the word 'specific' implies it's for a single upload by ID, but it doesn't mention list_uploads for finding IDs or that it's the read counterpart to create_upload.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'all' steps, implying a full list, but does not disclose pagination, ordering, whether completed steps are included, authentication needs, or error behavior. This is minimal beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It concisely states the action and resource, fitting the tool's simplicity.
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 list tool, the description provides the essential purpose but lacks detail on the return format (no output schema), permissions, or how steps relate to other Basecamp entities. It is minimally viable but leaves the agent to infer important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. 'card_id' and 'project_id' are self-explanatory names, but the description does not explain their relationship or required format. With low coverage, the description must compensate, which it fails to do.
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 (List) and the resource (steps/checklist items on a card). It distinguishes itself from sibling tools like basecamp_add_step, basecamp_update_step, and basecamp_complete_step by focusing on the listing 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. There are many list-related siblings (e.g., basecamp_list_cards, basecamp_list_todos, basecamp_get_card), but the description does not mention the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire burden. It reveals a mutating action ('mark') but fails to disclose idempotency, permissions, or effects when the step is already incomplete. A simple state-change description without further detail is insufficient for full 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 a single, front-loaded sentence with no wasted words. It states the action and target clearly and compactly.
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 two-parameter mutation tool, the description provides the core action but lacks any information about return values, edge cases, or contextual usage. Given the lack of annotations and output schema, this minimal description is average—it hints at functionality but leaves many operational details unknown.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the parameters. It implies 'step_id' via the word 'step' but provides no explanation of 'project_id' or the relationship between the two parameters, leaving the agent to guess from names alone.
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 ('mark') and resource ('step') with a clear state change ('incomplete'), making the tool's purpose unambiguous. It inherently distinguishes itself from the sibling 'basecamp_complete_step' by naming 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 its counterpart or when an action is appropriate (e.g., for reverting a completion). The description implies a state-changing operation but offers no context, preconditions, or alternatives.
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 for behavioral disclosure. It simply states 'Add a new step to a card' and provides no details about permissions, idempotency, default state of the step (e.g., incomplete), reversibility, or what the response returns. This is minimal and offers no insight beyond the action itself.
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 concise sentence that directly states the tool's purpose. It is front-loaded and contains no filler. While brief, it earns its place by clearly conveying the core function.
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?
This is a mutation tool with 5 parameters, no annotations, and no output schema. The description is extremely minimal and fails to provide necessary context such as required parameters, how to obtain project/card IDs, what the created step includes, or how to verify success. Given the tool's complexity, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters. Schema coverage is 60%, with title, due_on, and assignees having descriptions, but card_id and project_id are undocumented. Since coverage is not high (>80%), the description should compensate for missing parameter semantics, but it does not. It adds no value beyond the 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 'Add a new step to a card' clearly states a specific verb (Add), the resource (a step), and the target (a card). It distinguishes this tool from siblings like basecamp_list_steps, basecamp_update_step, and basecamp_complete_step, which handle different operations on steps.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites such as needing existing project/card IDs or parent context. The verb 'Add' implies creation, but there is no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Change the color' and lists valid colors (which duplicates the schema enum), but does not disclose permissions, reversibility, side effects, or behavior on invalid input.
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, action-first sentence with no unnecessary words. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too minimal. It does not explain how to obtain project_id/column_id, what happens after the change, or whether the operation is reversible, making it incomplete for an agent to use confidently.
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 schema description coverage is only 33% (color), and the description merely repeats the enum values already in the schema. It provides no explanation for project_id or column_id, leaving the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Change') and the specific resource ('card table column'), which distinguishes it from sibling tools like move, watch, or update column. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as basecamp_update_column for other column properties. It also omits prerequisites like needing project_id and column_id from existing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the ability to include attachments but does not disclose potential side effects, permission requirements, or response behavior. The action 'Post' implies a write, but no further context is given.
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, front-loaded with the primary action and scope. No wasted words.
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 and the schema covers parameters, but the description lacks guidance on choosing this over the similar basecamp_comment_with_file tool and omits behavioral details such as response output, which is not covered by an output schema. Given its simplicity, it is minimally adequate but not fully 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 provides 100% coverage with descriptions for all three parameters. The description's mention of 'attachment_sgids' largely restates the schema field, adding no new semantic information beyond what is already documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (post a comment) and target resources (any Basecamp card or todo). It is specific and unambiguous, though it does not explicitly differentiate from the similarly named sibling basecamp_comment_with_file.
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 basecamp_comment_with_file or other comment-related tools. The description implies usage but does not provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the creation action without disclosing side effects, permissions, or the need for a parent todoset. It also does not describe the response format or error behavior, leaving the agent to infer the operation's implications.
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 of eight words, efficiently communicating the core purpose without redundancy. It is front-loaded and to the point, with no wasted words.
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?
This is a simple create operation with a fully documented schema, but the description lacks important context such as the hierarchical relationship between projects, todosets, and todolists, as well as the return value. It is adequate for a straightforward tool but leaves gaps for an agent without prior Basecamp knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all parameters, providing a baseline of 3. The description adds no additional information about parameter meaning or relationships; it merely says 'in a project' without explaining the todoset_id parameter or its necessity.
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 'Create a new to-do list in a project' clearly states the action (create), resource (to-do list), and context (project). It distinguishes from sibling tools like create_todo by specifying 'list', but it does not explicitly differentiate from other Basecamp create tools or mention the todoset hierarchy.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like update_todolist or create_todo, nor does it mention prerequisites such as the required todoset_id or how to obtain it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. However, it only states the action ('Delete') without noting that deletion is likely permanent, whether special permissions are needed, or how it affects related data. This leaves significant ambiguity for an agent.
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 that wastes no words. It clearly states the verb and resource, making it easy for an agent to quickly grasp the tool's core function.
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?
While the operation is conceptually simple, the description lacks critical context such as expected outcome (e.g., success/failure response), irreversibility, and how to obtain required IDs. With no output schema and no annotations, the description is too sparse to fully support 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 description coverage is only 33% (only line_id has a description). The tool description adds no extra meaning for project_id or campfire_id, and does not explain how they relate to the line being deleted. The agent must infer their purpose from parameter names alone.
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 the specific verb 'Delete' and clearly identifies the resource as 'a chat message/line from a Campfire'. This distinguishes it from sibling tools like create_campfire_line and list_campfire_lines, which serve different purposes.
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 offers no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, such as whether the line must belong to a specific campfire or project. There is no exclusionary context or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get detailed information' without mentioning whether the operation is read-only, requires specific permissions, or returns a particular structure. The 'get' verb implies safety, but no explicit transparency is given.
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 with no unnecessary words. It efficiently communicates the core purpose without fluff, which is appropriate for a simple get operation.
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 (one required parameter, no output schema, no annotations). The description is adequate but minimal: it states what the tool does but does not clarify what 'detailed information' includes or how to distinguish this from related project tools. It is a minimum viable description but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'project_id', which is fully described in the schema. The description adds no extra meaning beyond 'specific project', so it does not enhance parameter understanding beyond the structured schema.
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 clear verb ('Get') and resource ('detailed information about a specific project'), making the primary purpose obvious. It does not explicitly differentiate from sibling tools like basecamp_find_project or basecamp_get_project_dock, but the 'specific project' wording implies single-record retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as basecamp_list_projects or basecamp_find_project. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get', implying read-only, but does not explain the implications of 'from index' (e.g., potential staleness, indexing requirements, performance). Missing important 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 clear sentence with no unnecessary words. It is front-loaded and appropriately sized for a simple read operation.
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 one-parameter tool with no output schema, the description conveys the basic action and result. However, it leaves the 'index' concept unexplained and does not mention any prerequisites or return format, leaving gaps for an agent to fully understand when and how to use it.
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 covers the single parameter (project_id) with a description 'Project ID', achieving 100% coverage. The tool description adds no extra parameter details, but schema coverage is high, so baseline 3 applies.
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 'Get' and resource 'all columns for a project', indicating the tool retrieves columns. It mentions 'from index', suggesting a distinct data source, but does not clarify how this differs from sibling tools like basecamp_list_columns. Clear but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does, with no mention of conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states the action but does not disclose pagination, ordering, rate limits, permission requirements, or what data is included (e.g., whether attachments or system messages are included). Without any behavioral context, the agent cannot anticipate the tool's exact behavior beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the primary verb and object. Every word earns its place, with no fluff or repetition. It is optimally concise for a simple list operation.
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?
With no annotations, no output schema, and no parameter descriptions, the description is the only source of context. While the tool is simple, the description omits critical usage details such as parameter roles, return format, and any pagination or filtering behavior. Compared to similar tools with richer annotations, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the parameters. The phrase 'in a Campfire' loosely relates to campfire_id, but project_id is left unexplained. The parameter names themselves are self-explanatory, but the description adds no additional meaning beyond the schema's property names, failing to compensate for the complete 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') and resource ('chat messages/lines in a Campfire'), clearly distinguishing this tool from siblings like basecamp_list_campfires (lists campfires) and basecamp_create_campfire_line (creates a line). It also clarifies the synonym 'lines' for chat messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is the tool for retrieving Campfire chat history, nor does it exclude other list tools or suggest a preferred scenario. Usage is only implied by the name and basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It states the basic action but does not mention side effects, whether it is destructive, permission requirements, reversibility, or how the operation affects other steps. This is a significant gap 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 a single, concise sentence that front-loads the verb and immediately conveys the action. There is no fluff or unnecessary detail, making it appropriately sized for the simple operation described.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is insufficiently complete. It does not explain expected behavior on success or failure, whether the position is zero-indexed (though schema does), or any constraints. For a mutation tool, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 3 of 4 parameters (75%), but the description adds no additional meaning beyond the schema. It does not clarify the purpose of project_id or any relationships between parameters beyond what is already stated. Since coverage is below 80%, the description should compensate, but it does not.
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 'Change the position of a step within a card' uses a specific verb ('Change') and resource ('position of a step within a card'), clearly distinguishing it from sibling tools like list_steps, add_step, update_step, and move_card. It is unambiguous about what the 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as update_step or move_card. It does not state prerequisites, exclusions, or mention any related tools. The intended use is only implied by the tool's name and action, not explicitly described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It does not mention whether the action is reversible, destructive to project contents, or requires special permissions, which are critical details for a trash operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, and efficient sentence: 'Move a project to trash.' Every word earns its place, and the structure is perfectly concise for the tool's straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is minimal but omits essential context about side effects, reversibility, and relationship to other trash/archive tools. This is inadequate for an agent deciding whether to invoke this destructive action.
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 one required parameter (project_id) with no description, and schema description coverage is 0%. The description does not compensate by explaining what project_id refers to or how it should be obtained, leaving the parameter's semantics under-specified.
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 (move to trash) and the resource (project), using a specific verb and object. It distinguishes from sibling tools like basecamp_trash_card and basecamp_trash_recording by explicitly targeting projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Start watching/subscribing' but does not disclose side effects, reversibility, permission requirements, or what notifications will be sent. The action implies a state change but lacks detail.
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 concise sentence, front-loaded with the action and resource. It contains no superfluous information and is easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation-like action with no annotations and no output schema, the description is too minimal. It does not mention return values, prerequisites (e.g., column existence), or side effects. The tool's simplicity does not excuse the lack of contextual information.
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%, and the description does not mention the required parameters (project_id, column_id) or explain their relationship. The parameter names are minimally self-explanatory, but no additional semantics are provided.
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 ('Start watching/subscribing') applied to a specific resource ('a column') with the purpose ('for notifications'). It distinguishes from sibling tools like basecamp_unwatch_column, which is the reverse 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 given on when to use this tool versus alternatives, such as when unwatching or when to use other column tools. The description only states what it does, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Reactivate' indicates a mutation, but the description does not explain side effects, whether it restores associated items, permission requirements, or the return value. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and target. There is no redundancy or fluff, making it efficient and front-loaded.
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?
As a mutation tool with no annotations and no output schema, the description should provide more context about the operation's effects and any prerequisites. It does not mention what 'activate' entails, what happens if the recording isn't trashed/archived, or the response format, leaving the agent under-informed for a destructive-reversal action.
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 tool description adds no parameter semantics beyond the input schema. The schema already describes recording_id, while project_id remains self-explanatory but undocumented. With schema coverage at 50%, the description fails to compensate for the missing project_id context or offer any additional usage details.
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 the specific verb 'Reactivate' and identifies the resource as 'Basecamp recording', also scoping to 'trashed or archived' states. This clearly conveys the tool's purpose and inherently distinguishes it from sibling tools that trash or archive recordings, though it does not explicitly name those alternatives.
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 by specifying the target state ('trashed or archived'), implying this tool is for undoing those operations. However, it does not explicitly state when not to use it or mention alternative tools, so it stops short of a 5.
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 responsibility for disclosing behavioral traits. It only states the action without mentioning potential side effects, idempotency (e.g., what happens if the todo is already completed), authentication requirements, or error behavior. This is a significant gap 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 a single, front-loaded sentence with no wasted words. It immediately states the action and resource, making it highly efficient for an agent to parse and understand.
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 two-parameter mutation, the description is minimally viable. It lacks information about behavior under edge cases (e.g., already completed todos) and does not mention any response or success criteria. However, given the tool's simplicity and the clarity of its purpose, this is adequate but not comprehensive.
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 for explaining parameters. The parameter names project_id and todo_id are somewhat self-explanatory, but the description adds no details about their formats, relationships, or how to obtain valid values. It does not aid in correct invocation beyond what the schema names imply.
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 as completed' uses a specific verb and resource, clearly distinguishing it from siblings like basecamp_uncomplete_todo and basecamp_update_todo. It precisely conveys the action and target, which is all needed for a simple state-change 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the existence of inverse operations like basecamp_uncomplete_todo or any prerequisites (e.g., todo must exist, permissions needed). There is no context provided beyond the bare action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'create' and offers no details about side effects, required permissions, return values, or idempotency. This is a significant transparency gap 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 a single, clear sentence with no wasted words. It conveys the core purpose effectively and is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description is too minimal. It fails to mention required parameters, date/time format requirements, or any context about how the schedule entry is structured. The description does not provide sufficient information for an agent to correctly invoke the tool without relying entirely on the schema.
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 coverage is 78%, so most parameters already have descriptions. The tool description adds no extra meaning to the parameters. Since coverage is close to the high threshold, the schema does the heavy lifting, and the description does not need to compensate much.
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 verb 'create' and the resource 'calendar event in the schedule', which distinguishes it from sibling tools that list, get, or update schedule entries. It is specific and unambiguous.
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 gives no guidance on when to use this tool versus alternatives like update_schedule_entry or list_schedule_entries. It only states what it does, not when to prefer it over siblings or any 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 of disclosing behavioral traits. It only states the action 'Create' without mentioning side effects like notifications, permission requirements, or how assignees are handled. No context is added beyond the basic verb.
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, tightly worded sentence with no filler. It is front-loaded with the key information and earns its place as a concise summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description is too sparse. It fails to explain the relationship between project_id and todolist_id, the expected workflow, or any return value. The minimal text leaves the agent to infer critical context from the schema alone.
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 75%, leaving project_id and todolist_id without explicit descriptions, though their names are self-explanatory. The tool description adds no parameter information, relying on the schema to define fields like content, due_on, and assignee_ids. This is adequate but not enhanced.
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 ('Create') and the target resource ('a new to-do in a to-do list'), which distinguishes it from sibling tools like create_todolist (creating a list) and update_todo. The phrasing is direct and unambiguous.
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 about when to use this tool versus alternatives. It does not mention prerequisites such as having an existing to-do list or project, nor does it clarify situations where one might prefer update_todo or complete_todo instead.
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 states 'List all columns' with no additional behavioral context. It does not disclose whether it returns paginated results, whether it is read-only, any access requirements, or what happens if the table is empty. The verb 'list' suggests a read operation but no explicit reassurance is given.
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 concise sentence that conveys the core purpose without unnecessary words. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (2 simple parameters, no output schema), and the description minimally covers the purpose and implied return (a list). However, it lacks any details about the response format, error conditions, or relationship to sibling tools. It is adequate for a simple list operation but does not provide the richness expected for full contextual completeness.
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%, and the description adds no meaning to 'project_id' and 'table_id'. While the parameter names are self-explanatory, the description does not clarify their roles (e.g., that project_id identifies the project and table_id identifies the card table) or any formats. The description does not 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 'List all columns in a card table' clearly states the action (list), the resource (columns), and the scope (all columns in a card table). It is specific enough to distinguish from sibling tools like basecamp_list_cards (lists cards) and basecamp_get_column (gets a single column).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when to prefer it over basecamp_index_get_columns or basecamp_get_column, or any exclusions. The usage is only implied by the verb 'list' and resource 'columns'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action ('List all to-do lists') and does not mention the status filter, pagination, ordering, or the requirement to specify a todoset. No extra behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 8-word sentence, extremely concise and front-loaded. It contains no wasted words, but the brevity sacrifices necessary context, such as the todoset required parameter. It is efficient but slightly under-specified.
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 list operation with no output schema and no annotations, the description is minimally adequate. It states the resource and action, but does not explain the nesting of to-do lists within a to-do set or mention the available status filter. The schema covers parameters, but the description leaves the operational context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value by implying project_id ('in a project') but does not clarify todoset_id or status semantics beyond what the schema already provides. Since the schema is thorough, this is adequate.
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 to-do lists in a project' with a specific verb and resource. It distinguishes itself from siblings like get_todolist (single to-do list) and list_todos (todos within a list). The scope is clear despite the slight imprecision of 'in a project' versus within a specific todoset.
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 about when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing a todoset ID), exclusions, or scenarios where a different tool would be more appropriate. Sibling differentiation is absent.
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 for disclosing behavior. It only states the action and targets, omitting details about required permissions, side effects, reversibility, or the constraint that start_date and end_date must be paired. This is minimal behavioral 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 a single, concise phrase that immediately conveys the verb, resource, and key targets. It is front-loaded and contains no unnecessary words, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and a pairing constraint, the description is too sparse. It does not mention that project_id is required, that at least one field should be provided, or the start/end date pairing rule. It fails to give enough operational context for an agent to use it correctly without relying solely on the schema.
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 83%, so most parameters are already documented. The description repeats the field names (e.g., name, description, access policy, schedule dates) but adds no new meaning beyond the schema. It neither clarifies the enum values nor the pairing requirement, so it provides baseline value only.
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 updates a project and lists the specific editable attributes (name, description, access policy, schedule dates). This distinguishes it from related tools like create_project, get_project, and trash_project, which have different verbs and scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is for existing projects, how it differs from index_update_project, or any prerequisites. The description simply states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('create') without revealing effects such as whether the operation requires specific permissions, whether a duplicate title is allowed, whether the document is immediately visible, or what the API response contains. For a mutating tool, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the action and object without any filler or redundancy. It is appropriately front-loaded and efficient, providing the core purpose in a scannable format. No unnecessary details dilute the message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters, no annotations, and no output schema, this description is overly sparse. It fails to mention that a project must exist, that the vault must belong to the project, or what the tool returns after creation. The description alone would not fully equip an agent to invoke the tool correctly without relying on external knowledge.
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 schema description coverage is 50%; title and content have descriptions, but vault_id and project_id do not. The description adds no parameter-level meaning beyond the phrase 'in the vault', which hints at vault_id but leaves project_id unexplained. It does not compensate for the undocumented parameters, making it hard for an agent to understand why both IDs are required.
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 ('Create') and resource ('new document') with a location ('in the vault'), clearly distinguishing it from sibling tools like update_document or create_message. The phrase 'new document' implies a distinct Basecamp resource type, and 'vault' disambiguates from other containers.
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 gives a clear but implied usage context: you use this when you want to create a document in a vault. However, it does not explicitly contrast with alternatives like create_message, create_todo, or create_upload, nor does it mention prerequisites such as the need for a valid project_id and vault_id. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention permissions, success/failure behavior, side effects, or any meaningful operational traits, leaving the agent underinformed.
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 that states the action and resource without any wasted words. It is appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with three required parameters, no annotations, and no output schema, this description is too sparse. It omits usage context, leaves project_id unexplained, and provides no behavioral or response details, making it minimally adequate but with significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes title and parent_vault_id, but project_id lacks a description. The description adds no extra meaning for any parameter, particularly failing to clarify what project_id refers to or how to obtain it, so it does not compensate for the 67% schema 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 the action (create) and resource (a sub-vault/folder within a vault), distinguishing it from other vault-related tools like updating or listing vaults. The parenthetical '(folder)' adds immediate clarity.
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 the tool is for creating nested vaults but gives no explicit when-to-use scenario or alternatives. There is no mention of when not to use it or what other tools could be used instead, leaving the context only lightly implied.
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 the full burden of behavioral disclosure. It only states 'Get detailed information', which implies a read operation but does not specify return structure, scope, error behavior, or authentication needs. This is a significant gap for a tool with no annotation safety hints.
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 filler or redundancy. Every word earns its place, making it maximally concise while still conveying the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description needs to explain return values or provide more context, but it does not. The phrase 'detailed information' is vague and gives no hint about what fields or data the response contains. For a two-parameter retrieval tool, the description is too sparse to be fully self-sufficient.
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, but it does not. It adds no meaning to 'card_id' or 'project_id' beyond their names, and it does not explain their roles or format. The schema field names are self-explanatory but the description provides no additional semantic value.
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 the specific verb 'Get' with the resource 'card' and explicitly targets 'a specific card', making it clear this is a single-card retrieval operation. This distinguishes it from sibling tools like basecamp_list_cards, which handle listing. No ambiguity remains about the tool's core function.
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 phrase 'specific card' implies this tool is for retrieving one card's details rather than listing, but no explicit when-to-use or alternative guidance is provided. There are no stated exclusions, prerequisites, or mentions of related tools like basecamp_list_cards for finding card IDs. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the purpose and does not mention any side effects, required permissions, return format, or error behavior. For a read-only operation, this is a minimal disclosure but lacks context that could help the agent anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does. No unnecessary words or repetitive content. It is clear and efficient.
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 get-style tool with schema fully covering parameters, the description is adequate but not rich. It does not explain what 'details' means or what is returned, but given the absence of an output schema and the simplicity of the operation, it is minimally complete. However, it could benefit from noting that it returns the full todolist object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The parameter descriptions in the schema ('Project ID', 'To-do List ID') are minimal and essentially restate the parameter names, adding little semantic depth. The tool description does not add any parameter-level meaning beyond what the schema provides.
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' with a clear resource 'details of a specific to-do list'. The word 'specific' distinguishes it from list-like siblings such as 'list_todolists' and indicates a single-item retrieval by ID.
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 about when to use this tool versus alternatives. It does not mention that this should be used when you have a todolist ID, or that list_todolists should be used for browsing. Sibling tools exist but no differentiation is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the 'index' and 'fast lookup', which suggests a local, possibly stale cache, but it does not disclose that the index must be built first (via basecamp_index_build), that results may not reflect live data, or what the return format is. These are significant missing behavioral traits.
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: 'Search projects by name in the index (fast lookup)'. It is concise, clear, and contains no wasteful words. Every component earns its place.
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 (one parameter, no output schema), but the description leaves out important context: that the index is a separate artifact that must be built and maintained, and what the search returns (e.g., project IDs, full project objects). For an agent to use this correctly, it needs to know the index workflow and the expected result shape.
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 already fully describes the single 'query' parameter as a fuzzy match on project name (100% schema coverage). The description aligns with this by confirming the search is by name, but it adds no extra semantic detail such as case sensitivity, minimum length, or wildcard support. Baseline 3 is appropriate.
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 searches for projects by name ('Search projects by name'), specifying the resource (projects) and the action (search). It adds 'in the index (fast lookup)', which hints at a distinct behavior from other project-related tools, but it does not explicitly differentiate from sibling tools like basecamp_find_project or basecamp_list_projects.
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 phrase 'fast lookup' implies this is intended for quick project name searches, but the description provides no explicit guidance on when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. Coverage of usage context is minimal and mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the operation, but does not disclose behavior such as whether the list includes archived/trashed documents, pagination, ordering, error cases, or what fields the returned documents contain.
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 entire description is a single short sentence, front-loaded with action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is underspecified. It fails to describe return values, pagination, or any behavioral caveats. While the tool is simple, the description leaves the agent guessing about what 'documents' means and what the response looks like.
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 coverage is only 50% (only vault_id has a description). The description adds minimal parameter insight—it mentions 'vault' but does not explain that project_id is a parent project or what relationships are required. It does not compensate for the undocumented project_id parameter.
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 documents in a vault (Docs & Files)' uses a specific action ('List') and resource ('documents'), with clear scope ('in a vault') and a clarifying parenthetical. It clearly distinguishes this from get/create/update document tools by indicating it's a list operation.
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: if you need to list all documents in a vault, use this. However, it provides no explicit guidance on alternatives or exclusions, such as noting that get_document retrieves a single document or that uploads are handled separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List all messages' without detailing pagination, ordering, return format, or any side effects. There is no indication of whether the operation is read-only, requires authentication, or has limits. This lack of contextual detail undermines 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 a single, straightforward sentence: 'List all messages in a message board'. It is front-loaded with the verb and resource, contains no redundant information, and is perfectly concise for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is minimally adequate. It explains the core purpose but omits any details about return value expectations, edge cases, or additional context that would help an agent fully understand the tool's behavior. It is not severely lacking, but there is room for improvement.
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 50%, with only message_board_id having a description. The description adds context by saying 'in a message board', which aligns with message_board_id, but it does not explain project_id or the relationship between project and board. This provides marginal value over the schema, not enough to fully compensate for the gap.
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 'List all messages' with a specific resource 'message board', and it distinguishes this from sibling tools like basecamp_get_message (singular) and basecamp_create_message. The scope ('all messages') is explicit, leaving no ambiguity about what the 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 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 basecamp_get_message or basecamp_list_campfire_lines. It simply states what it does, without any mention of prerequisites, exclusions, or alternative scenarios. This leaves the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It says 'List all schedule entries' but omits that a schedule_id is required (per schema), which scopes to a single schedule, not the entire project. It also doesn't mention that filters (start_date, end_date, status) alter the result set, making 'all' potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action. It is well-structured and avoids redundancy, though it could incorporate a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 2 required, and no output schema, the description is too sparse. It does not mention the mandatory schedule_id, the available filter parameters, or the expected return shape. Given the sibling tool basecamp_get_schedule_entry exists, more context is needed to avoid confusion.
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 80% (start_date, end_date, status have descriptions), so baseline is 3. The description itself adds no parameter-level information beyond the word 'project' which aligns with project_id. It does not clarify the required schedule_id or how filters interact, but the schema partially covers this.
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 ('schedule entries' / 'calendar events') and scopes it to a project, clearly distinguishing it from sibling tools like get_schedule_entry or create_schedule_entry. It communicates the core action unambiguously.
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 (when listing schedule entries in a project) but does not explicitly mention alternatives or when not to use it. Sibling tools like basecamp_get_events or basecamp_get_schedule_entry could be relevant, but no exclusion or preference guidance is provided.
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 adds the useful detail that all uploads are returned and the scope is a vault, which implies a read-only operation. However, it does not mention return format, pagination, or any permissions required, which limits 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 a single, straightforward sentence with no filler words. It is front-loaded with the action and resource, making it easy to parse quickly.
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?
The tool has only two parameters, but no output schema and no annotations. The description is too terse to cover the necessary context: it omits parameter semantics, return value expectations, and any edge cases. An agent would need to look elsewhere for basic invocation details.
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 schema covers only 50% of parameters (vault_id has a description, project_id does not). The description does not explain the relationship between project_id and vault_id, nor does it clarify what project_id is for. This leaves a significant gap for an agent trying to invoke the tool correctly.
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 ('List') and the resource ('all file uploads' in a vault), which distinguishes it from sibling tools like basecamp_get_upload or basecamp_list_documents. It precisely scopes the tool to vaults, leaving no ambiguity about what it operates on.
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 basecamp_get_upload or basecamp_list_vaults. There are no exclusions or prerequisites mentioned, leaving the agent to infer usage solely from the verb 'list' and the resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'list' without clarifying whether it returns direct children only, whether it is read-only, or what the response format looks like. For a list operation, this leaves ambiguity about hierarchy depth and pagination.
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 that directly states the tool's purpose with no wasted words. It is concise and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no output schema, and many sibling tools, a bare one-line description is insufficient. It does not explain project_id, usage context, or what the response contains, leaving gaps for an AI agent to invoke it correctly.
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 covers 50% of parameters (vault_id has a description) but project_id is undocumented. The description itself does not explain either parameter, so the agent lacks clarity on why project_id is required and how it relates to the vault.
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 a specific action ('List') on a specific resource ('all sub-vaults (folders) within a vault'). It also adds clarity by equating sub-vaults with folders, which distinguishes it from sibling tools like basecamp_get_vault or basecamp_create_vault.
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: to list sub-vaults, use this tool. However, there is no explicit guidance on when to prefer this over alternatives, no exclusions, and no mention of prerequisites like needing the correct project_id.
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?
Annotations are absent, so the description must carry the full burden. It only explains the core action but fails to disclose any side effects, permissions, reversibility, or constraints (e.g., whether pinning replaces an existing pin, whether the message must be in a specific board). This is a mutation tool, so more transparency is expected.
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 redundant or irrelevant content. It efficiently conveys the tool's purpose without waste, making it easy to parse 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 tool is simple with only two parameters, no output schema, and no annotations. The short description sufficiently communicates the immediate effect. While it lacks caveats about side effects or return behavior, the low complexity means this description is reasonably complete for invoking the tool.
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 50% (only message_id is described). The tool description adds no parameter details. project_id is undocumented and unexplained. For partial coverage, the description should compensate, but it does not mention either parameter, leaving ambiguity for the agent.
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 'Pin' and clearly states the resource: 'a message to the top of the message board'. This distinguishes it from related tools like basecamp_unpin_message. It is unambiguous and directly reflects the tool's primary function.
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, prerequisites, or conditions. The description merely states the action without any contextual instruction. Users must infer usage from the tool name and siblings (e.g., unpin_message).
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 behavioral disclosure. It states the primary effect (changing watch/subscription state) but does not disclose any side effects, permissions, reversibility, scope (e.g., current user only), or that the column itself is not deleted. This is minimal and provides little beyond the tool name.
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?
A single, front-loaded sentence with no wasted words. 'Stop watching/subscribing' conveys the action efficiently and the slash adds clarity without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and sparse parameter docs, the one-line description is too minimalist. It lacks any context about prerequisites (e.g., column must exist), whether the action is reversible, or what the user should expect after execution.
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 schema has zero description coverage for its two parameters, and the description does not mention project_id or column_id at all. It forces the agent to infer from parameter names alone, which may be insufficient in a broader workflow.
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 'Stop watching/subscribing' with a specific resource ('a column'), making it unambiguous and distinguishing it from the sibling tool basecamp_watch_column which starts watching. It avoids tautology by using a different verb than the tool name.
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 one wants to cease watching a column, but provides no explicit guidance on when to use it versus the alternative basecamp_watch_column, nor any prerequisites or exclusions. This is implied rather than 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?
With no annotations provided, the description must disclose behavioral traits. It only states the action, failing to mention side effects (e.g., whether existing description/name is overwritten), permission requirements, or what happens when only one of the two fields is updated.
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 redundant words. It is highly concise and appropriately sized for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is too sparse. It lacks information on return values, error conditions, and practical usage scenarios, leaving an agent under-informed for successful 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 description coverage is 50%; the tool description adds context for 'description' and 'base_name' but does not clarify the required identifiers (project_id, upload_id). The description does not fully compensate for the missing schema documentation.
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 identifies the action ('Update'), the resource ('file upload'), and specific fields ('description or name'), effectively distinguishing it from sibling tools like basecamp_get_upload or basecamp_create_upload.
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 verb 'Update' implies when to use it, but there is no explicit guidance on when to choose this tool over alternatives, nor any mention of prerequisites or exclusions. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only adds 'full content' as a detail about the return, but does not state whether the operation is read-only, what happens if the document is not found, or any side effects. This is minimal for a tool without annotation support.
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 redundancy. Every word earns its place, stating exactly what the tool does without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, so the description's limited detail is somewhat acceptable. However, the absence of parameter explanations and usage guidance makes it less than complete for an agent that may need to understand how to invoke it correctly in different contexts.
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% and the description adds no parameter context beyond the schema's property names. The two parameters (project_id, document_id) are self-explanatory from their names, but the description does not clarify their purpose, format, or relationships, leaving a gap that the schema does not fill.
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 a specific verb ('Get'), a resource ('document'), and a qualifier ('specific', 'full content'), making the tool's purpose unambiguous. It distinguishes from sibling tools like list_documents or create_document by emphasizing retrieval of a single document with full content.
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 through the phrase 'specific document with full content', suggesting it is for retrieving a single document rather than listing or creating documents. However, it does not explicitly mention alternatives or exclusionary conditions, so the guidance remains implied rather than explicit.
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 clearly implies a read-only operation via 'Get', but does not disclose any auth requirements, error behavior, or what 'full content' includes. This is minimal but not misleading.
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?
One sentence, six words, front-loaded with the action. No unnecessary words.
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 get-by-ID tool, the description is minimally complete: it tells you what it does and vaguely what it returns. However, the absence of any detail about return structure or error cases leaves gaps, especially for an agent unfamiliar with the Basecamp API.
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 coverage is 0%, so the description must compensate, but it only mentions 'specific message' without explaining project_id and message_id roles or formats. The parameter names are self-explanatory, but the description adds no value beyond the 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 uses the specific verb 'Get' with a clear resource 'specific message' and adds 'with full content' to indicate the scope, distinguishing it from list_messages and other message actions like create/update/pin.
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 on when to use this tool versus alternatives. It does not mention list_messages for listing, or how to obtain message_id, or when this is preferable to other get 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, which is helpful, but the description does not mention potential pagination, whether archived/inactive people are included, or any authentication requirements. It is minimally transparent but not misleading.
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 unnecessary words. It efficiently communicates the core function without requiring the agent to parse extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and the absence of annotations or an output schema, this description is too sparse. It does not clarify what 'people' includes (e.g., client vs. internal, active vs. archived), how the optional project_id affects results, or what the response looks like. This leaves the agent with insufficient context for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single parameter (project_id) at 100%, so the baseline is 3. The tool description adds no extra meaning beyond 'all people', but it does not need to since the parameter is well-documented in the 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 uses a specific verb ('List'), identifies the resource ('people'), and specifies the scope ('in the organization'). This clearly distinguishes it from siblings like list_pingable_people and get_person, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention related tools like list_pingable_people or get_person, nor does it specify when the optional project_id filter should be used, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It simply says 'List all Basecamp projects' without noting that 'all' actually defaults to active projects only, nor that passing 'active' is rejected. This is a notable gap in describing the tool's actual behavior, though part of it is captured in the schema parameter description.
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 zero wasted words. It is maximally concise while still conveying the core action and target resource.
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 tool is simple with one optional parameter and no output schema. The schema thoroughly covers the status behavior, and the description's short length is acceptable for a list operation. However, it could have explicitly stated the default active filter to avoid initial confusion, so it's not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'status' has a detailed description explaining defaults, allowed values, and rejection of 'active'. The tool description adds no parameter information, so the baseline 3 is appropriate since the schema carries the burden.
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 Basecamp projects' uses a specific verb and resource, clearly distinguishing this tool from related siblings like basecamp_get_project (single project) and basecamp_find_project (search). The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it lists active projects by default or how to list archived/trashed ones, nor does it compare with find_project or get_project. The only usage hint is in the input schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It only states what the tool does, but does not explain position semantics, effects on column ordering, permissions, or reversibility. This is a significant gap 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 a single sentence that is direct and front-loaded. No fluff 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?
The tool has 5 parameters, no output schema, and a complex domain (card table columns). The description is too thin to guide correct invocation, especially given ambiguous parameter definitions and a lack of explanation about how source_id, target_id, and position interact.
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 high (80%), so the baseline is 3. The description adds no additional meaning beyond the schema and does not clarify the confusing relationship between card_table_id and target_id, nor the meaning of position beyond its own schema description.
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 ('move/reorder') and the resource ('column within a card table'), which distinguishes it from sibling tools like move_card or update_column. It is specific and non-tautological.
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 the description—it is for reordering columns—but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context is minimal.
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 burden. It discloses the read-only nature via the verb 'Read' and mentions optional comments/images, but lacks details on return format, error handling, or pagination. This is minimal but not misleading.
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 with no fluff. The primary purpose is front-loaded, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what the tool returns (e.g., resource content, comments, image URLs). It does not mention response structure or potential errors, and with many sibling tools, lacks usage context to route the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds 'optional comments and images' which maps to include_comments and include_images, and 'any Basecamp URL' aligns with the url parameter, but it does not provide syntax or format details beyond the 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 the verb 'Read' and resources 'card or todo', with optional comments and images. It distinguishes itself from sibling tools like basecamp_get_card and basecamp_get_todo by supporting any Basecamp URL, making it a more generic reader.
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 when-to-use or alternative guidance is provided. The description implies usage through 'Supports any Basecamp URL' but does not explicitly compare to specialized getters or mention exclusions, leaving the agent to infer when to select this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states 'Update an existing card' and lists fields, but does not explain whether updates are partial or full, how attachments are appended, any permission requirements, side effects like notifications, or error behavior. This is a significant gap 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 a single, front-loaded sentence beginning with the verb and resource, followed by a compact parenthetical list of fields. No redundant words, and it efficiently conveys the tool's primary purpose and capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is too sparse. It does not state required parameters, return value, or any usage context. It merely lists editable fields, leaving the agent to infer how to properly invoke the tool for different scenarios.
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?
Despite low schema coverage (13%), the description maps several parameter names to meaningful terms: 'assignees' for assignee_ids, 'due date' for due_on, 'completion' for completed, and 'attachments' for attachment_sgids. This adds value beyond the raw schema. However, it omits format details (e.g., due_on date format) and doesn't mention required identifiers (project_id, card_id), though those are self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: updating an existing card, and enumerates the specific modifiable fields (title, content, assignees, due date, completion). This distinguishes it from sibling tools like create_card, move_card, or trash_card by explicitly focusing on update operations for cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., card must already exist, need project_id), or contrast with basecamp_create_card or basecamp_move_card. The usage context is only implied by the verb 'update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the ability to include images/videos, but does not explain mutation consequences, permission requirements, or what happens on success/failure. This is minimal coverage for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. Every word adds value, stating the core purpose and a key capability in an efficient manner.
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 create tool, the description is adequate but sparse. It does not explain return values (no output schema) or provide any safety/permission caveats. Given the lack of annotations, a bit more context (e.g., 'This will immediately post the message to the chat') would improve 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?
Schema description coverage is 50%, with content and attachment_sgids described, but project_id and campfire_id left undefined. The description adds a hint that attachments can be images or videos, which partially compensates for the missing parameter context. However, it does not clarify the required IDs, so the added value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Post') and resource ('a new message to a Campfire chat'). It is unambiguous and distinguishes from sibling tools like listing or deleting campfire lines.
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 a clear use case (posting to a Campfire), but does not explicitly state when to use it over alternatives or provide any exclusions. It lacks the explicit 'when/when-not' guidance seen in higher-quality descriptions.
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 full burden of behavioral disclosure. It indicates a read operation ('Get details') but does not elaborate on response format, required permissions, or any side effects. For a simple getter, this is minimally sufficient but lacks richer 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, focused sentence with no unnecessary words. It is appropriately sized and immediately conveys the tool's core function.
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?
The tool lacks an output schema and annotations, so the description should clarify what 'details' include and any prerequisites. It omits this information, leaving the agent with an incomplete picture of the tool's behavior and expected return.
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%, and the description does not explain the purpose of project_id and campfire_id. While parameter names are somewhat self-explanatory, the description offers no additional semantic guidance, failing to compensate for the missing 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 'Get details of a specific Campfire chat' uses a specific verb ('Get') and a resource ('Campfire chat'), clearly distinguishing it from sibling tools like basecamp_list_campfires. It is concise and unambiguous.
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: use this when you need details of a single Campfire. However, it does not explicitly mention alternatives (e.g., when to use list_campfires) or any exclusions, so it relies on the agent to infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It only says 'Get recent activity/events' and does not disclose whether the operation is read-only (though 'Get' implies it), whether pagination or rate limits apply, or what constitutes an event. This is a significant gap for a tool with no annotation safety net.
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, well-structured sentence that front-loads the verb and resource and clearly states the scope. There is zero redundancy, and every word contributes meaning.
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 only two optional parameters and no output schema, so the description is the primary source of context. It explains the purpose and scope, but it does not mention the nature of the returned events, ordering, or how the limit parameter behaves beyond what the schema states. For a simple list-style tool, this is adequate but not 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 100%, with both parameters documented. The description adds a little context by framing the scope as 'account or a specific project,' but this mostly mirrors the schema's 'Optional: Get events for a specific project.' The value over the schema is minimal, so the baseline score 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 clearly states the tool gets recent activity/events with an explicit scope (account or specific project). The verb 'Get' and resource 'events' are specific, and it distinguishes itself from siblings like basecamp_list_messages or basecamp_list_todos by focusing on the activity feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recent activity, but it provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or recommended scenarios, so the agent must infer that this is the go-to for events/activity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the tool gets a todoset and that it contains all lists, but does not explain return format, error behavior, or authentication requirements. Limited behavioral 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 a single, concise sentence that is front-loaded with the essential information. It is appropriately sized for a simple get operation with one parameter.
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 (one parameter, no output schema), and the description provides the core purpose. However, it does not describe what the returned todoset looks like beyond containing lists, which could be important for a tool with no output schema. Adequate but minimal.
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 fully describes the single parameter (project_id) with 100% coverage. The description adds no further parameter details, which aligns with the baseline score of 3 for high schema 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 uses a specific verb ('Get') and resource ('To-do Set for a project'), and adds context that it contains all todo lists, which distinguishes it from sibling tools like get_todolist. This clearly communicates the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(contains all todo lists)' implies when to use this tool versus getting a single list, but there is no explicit guidance on alternatives or when not to use it. The usage context is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It only mentions 'fast lookup' without clarifying read-only nature, error handling if no match is found, or the fuzzy match semantics (which appear only in the schema). There is no mention of side effects or return format.
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?
A single well-structured sentence that is front-loaded with the verb 'find'. It is concise and contains no unnecessary words.
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 two-parameter lookup with no output schema, the description conveys the essential purpose. However, it omits behavior on no match and the expected return value. With no annotations, it is minimally adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The tool description does not add new meaning beyond the schema, but the schema's 'fuzzy match' note for column_name provides useful detail. 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 uses a specific verb 'find', identifies the resource 'column', and scopes it 'within a project'. It also adds 'fast lookup' which distinguishes it from siblings like basecamp_list_columns and basecamp_get_column, making the tool's purpose unmistakable.
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 description: find a column by name. However, there is no explicit guidance on when to choose this over alternatives like basecamp_get_column (likely by ID) or basecamp_list_columns (all columns). No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only indicates the action 'trash' without disclosing whether it is permanent, requires special permissions, or cascades to related data. The lack of safety or reversibility details is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the action and resource. Every word adds needed context (the generic nature and examples), with no filler or 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?
For a simple two-parameter tool with no output schema, the description is adequate but sparse. It doesn't mention whether the trash is reversible, what response to expect, or how this tool relates to sibling trash tools, so some contextual information is missing.
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 coverage is 50%: recording_id has a description, project_id does not. The description adds context that recording_id can refer to any recording type, but it does not explain how to identify the project or format the IDs, leaving some ambiguity for the undocumented project_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 the action 'Trash' and the resource 'any Basecamp recording' with examples (card, todo, message, document), which distinguishes it from narrower sibling tools like basecamp_trash_card and basecamp_trash_project. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for any recording type via 'any Basecamp recording', but it does not explicitly mention alternatives or exclusion cases. It leaves the agent to infer when to use this vs. the more specific trash 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?
No annotations are provided, so the description carries full burden. It discloses that the tool returns an attachable_sgid, which is useful, but it does not mention permissions, side effects, file size limits, error handling, or whether the upload is reversible. As a mutation tool, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and includes the key return value. There is no redundant information or fluff; every word contributes to understanding the tool's purpose and outcome.
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 relatively simple (3 flat params, no output schema), and the description covers the main purpose and return value. However, it does not clarify prerequisites (e.g., file existence, permissions), how the upload ties to a specific Basecamp project, or when to use this over similar upload tools. Given the lack of annotations, a bit more context would be helpful, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters (file_path, caption, file_name), so the schema already documents the parameters. The description does not add specific parameter semantics beyond the schema, but it does introduce the concept of an attachable_sgid, which relates to the output rather than parameters. Baseline 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 clearly states the tool's function: 'Upload a file (image, video, document) to Basecamp.' This uses a specific verb ('upload') and resource ('file'), and distinguishes itself from siblings by emphasizing the returned attachable_sgid for use in rich text, a unique capability.
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 the tool is used when you need a file attachment for comments/messages by mentioning the sgid, but it does not explicitly state when to use this tool versus alternatives like basecamp_create_upload or basecamp_comment_with_file. No explicit exclusions or alternatives are named, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Post a new message' without explaining permission needs, return values, side effects, or prerequisites like pre-uploading attachments. This is insufficient for a create tool with minimal annotation support.
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, front-loaded sentences with no redundant words. The first sentence states the core action and target, and the second adds a key capability. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and five parameters, the description lacks information about return format, prerequisites (e.g., project existence, attachment upload order), or potential side effects. It is adequate for a basic invocation but incomplete as a full tool contract.
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 60%, and the description adds meaning by explicitly stating that images and videos can be included (related to attachment_sgids) and that the message targets a message board. However, it does not clarify project_id or message_board_id beyond the names, so it only partially compensates for the schema gaps.
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 the specific verb 'Post' and clearly identifies the resource as 'message/announcement to the message board,' distinguishing it from sibling tools like basecamp_comment, basecamp_update_message, and basecamp_list_messages. It also mentions the capability to include images and videos, adding specificity.
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 creating new messages on a specific message board, providing clear context. However, it does not explicitly state when not to use it or mention alternatives such as basecamp_comment for replies or basecamp_update_message for edits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'Build full index' but does not mention side effects, whether it overwrites an existing index, performance implications, or authentication requirements, leaving the tool's operational behavior opaque.
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, well-structured sentence with the verb front-loaded, no redundant words, and all essential information about scope and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the minimal schema, the description omits critical context such as whether this is a one-time setup, how the index is stored or refreshed, and its relationship to the many other index-related sibling tools. Without annotations or an output schema, this is a significant gap.
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 per the guidelines. The description correctly implies no inputs are needed, and the empty schema adds no further burden.
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 ('Build'), the resource scope ('all projects, card tables, and columns'), and the intended benefit ('for fast lookups'). This distinguishes it from sibling tools like basecamp_index_search and basecamp_index_update_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?
The description implies a full-index build that complements partial-update tools like basecamp_index_update_project, but it does not explicitly state when to use this tool versus alternatives or mention any 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?
With no annotations, the description carries the full burden, but it only states a list operation, which inherently suggests read-only. It does not disclose whether filters affect results, whether pagination occurs, or any default behavior regarding archived/completed to-dos, leaving some ambiguity.
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, short, front-loaded sentence. Every word is meaningful, and it immediately conveys the core function without 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?
The description does not mention the optional filters (status, completed) or what the default return set comprises (e.g., active only). Since no output schema exists, it also does not describe the structure of returned to-dos, making the description less complete than it could be for a 4-parameter 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 input schema provides descriptions for all four parameters, giving 100% coverage. The tool description adds no additional parameter context beyond what the schema already states, so it neither helps nor hurts.
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 identifies the action ('List') and the specific resource ('all to-dos in a to-do list'), distinguishing it from single-todo retrieval (get_todo) and creation (create_todo). It unambiguously answers what the 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 for retrieving a collection of to-dos within a given list, but it does not provide explicit guidance on when to choose this over alternatives like get_todo, nor any exclusionary conditions. This leaves the agent to infer from the tool name and context.
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 must fully disclose behavior. It accurately states the action, but it does not mention prerequisites, side effects, or return values. For a simple toggle, the description is minimal but not misleading.
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 filler. Every word earns its place, and the structure is entirely appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is largely adequate, but it omits context such as whether the todo must currently be completed, whether the operation is reversible (obvious), and what the response looks like. No output schema means the agent gets no return-format information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add any meaning beyond the parameter names (todo_id, project_id) and types (string) in the schema. With 0% schema description coverage, the agent has to rely on these self-evident names without further clarification.
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') and the resource ('a to-do') with the resulting state ('incomplete'). This distinguishes it from siblings like basecamp_complete_todo and basecamp_update_todo.
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?
There is no explicit guidance on when to use this tool versus alternatives, but the name and description imply it is for reverting a to-do to an incomplete state. It does not mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'update' but does not clarify whether fields are replaced or merged, whether there are side effects, required permissions, or what happens on success/failure. This is a significant gap 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 a single, front-loaded sentence with no filler. Every word contributes to meaning, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema, yet the description is just a phrase. It omits the required identifiers, any usage context, and outcome details. This leaves the agent with insufficient information to invoke the tool safely.
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 maps 'title, due date, or assignees' directly to schema properties (title, due_on, assignees), which clarifies which parameters are content vs. the locating identifiers (project_id, step_id). With only 60% schema description coverage, this semantic grouping adds useful meaning beyond the 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 uses the specific verb 'update' and names the resource 'step' plus the exact modifiable fields (title, due date, assignees). This clearly differentiates it from sibling tools like basecamp_complete_step and basecamp_reposition_step, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It only implies usage by listing the updatable fields, but does not mention prerequisites, exclusions, or alternative tool names. This is implied usage at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must explain behavior. It only mentions fuzzy matching but does not disclose whether it returns a single project or a list, what happens if no match is found, or any authentication requirements. This is a significant gap for a search 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 a single, focused sentence that clearly communicates the tool's purpose without unnecessary detail. It is concise and front-loaded.
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 well-documented parameter, but the description lacks information about the return format or behavior on no matches. Given the absence of an output schema and annotations, the description should provide more context to be fully 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 100% with a clear parameter description ('Project name or partial name to search for'). The tool description adds the 'fuzzy matching' concept, but it largely reinforces the schema rather than providing substantial new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find a project by name using fuzzy matching'. It specifies the verb (find), resource (project), and method (by name, fuzzy matching), which distinguishes it from siblings like basecamp_get_project (likely by ID) and basecamp_list_projects.
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 implies the tool should be used when you have a partial or fuzzy project name and need to locate a project. It provides clear context but does not explicitly mention alternatives or exclusions, such as 'use basecamp_get_project if you know the ID'.
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 burden. It communicates a read-only intent ('Get'), but does not disclose behaviors such as what details are returned, error handling, or permission requirements. Minimal but not misleading.
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, concise sentence that is front-loaded with the key verb and object. It contains no redundant or filler words, earning a top score for brevity.
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 getter with two required parameters and no output schema, the description is mostly complete. It could have mentioned that the vault must belong to the specified project, but the core purpose is adequately conveyed without overloading the description.
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%, and the description adds no parameter-level context. Although the parameter names 'vault_id' and 'project_id' are self-explanatory, the description does not compensate for the lack of schema descriptions, leaving the agent to infer that both are needed to locate the vault.
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 ('Get details') and the target resource ('vault'), even clarifying that a vault is a folder. It also distinguishes from sibling 'list_vaults' by specifying 'a specific' vault, indicating a single-resource retrieval.
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 the tool is used when you need details of one vault by ID, but does not explicitly state when to prefer it over list_vaults or other getters. No exclusions or prerequisites are mentioned, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns detailed information and mentions specific response fields (subscribers, color, cards count). However, it does not explicitly state that it is a read-only operation or describe any side effects, though 'Get' strongly implies a safe read. Some behavioral context is added beyond the schema.
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 that efficiently conveys the tool's purpose and key response details without any wasted words. It earns its place by adding specific examples of returned 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?
For a simple getter with two string parameters and no output schema, the description is adequate but incomplete. It names response fields but lacks parameter semantics and explicit read-only or error behavior. Given no annotations, this leaves some gaps for the agent to infer.
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 for the undocumented parameters. It only says 'a specific column', which implicitly references column_id but does not explain the role of project_id or provide any parameter-level guidance. This is a significant gap for a tool with two undocumented 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 clearly states the verb 'Get' and the resource 'detailed information about a specific column', with specific examples of the information included (subscribers, color, cards count). This clearly distinguishes it from sibling tools like list_columns (which lists all columns) and other column mutations.
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 that this is for retrieving details of a single column, which implies use when you need specific column data rather than a list. It doesn't explicitly exclude alternatives, but the naming and wording make the intended use clear.
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 must convey behavioral context. It explains the output (total projects, columns, last update time) but does not explicitly state that the operation is read-only, nor does it mention any prerequisites, performance implications, or whether the stats are cached. This is a minor gap for a read-only stats 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 entire description is a single sentence, front-loaded with the verb and object. There is no redundant information, and every word contributes to understanding the tool's purpose.
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 (no params, no output schema), the description covers the main return fields but is slightly thin on context like whether the statistics are live or from a cached index. Still, for its low complexity, it is mostly adequate.
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 and the input schema is empty. The description doesn't need to explain parameters; it already adds value by clarifying what statistics are returned, which is sufficient for a parameterless tool.
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 the specific verb 'Get' followed by the resource 'index statistics' and lists the exact data returned (total projects, columns, last update time). This clearly distinguishes it from sibling index tools like index_build or index_search, which perform different actions.
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 the many sibling index tools (e.g., index_get_project, index_get_columns). It does not mention alternatives or scenarios where this tool is preferred, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that it lists campfires visible to the current user, but it does not disclose whether the operation is read-only, the return format, ordering, pagination, or any side effects. For a simple list operation, some mention of return value or safety would improve 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 a single, front-loaded sentence that gets straight to the point. It includes the essential clarifier '(group chats)' and the scope qualifier 'visible to the current user' without any filler or redundant 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?
The tool is simple with no input schema and no output schema. The description adequately conveys the core function and scope. It could be enhanced by stating the return type (e.g., 'returns a list of campfire objects'), but given the low complexity and lack of annotations, the description is nearly complete as is.
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 description cannot add parameter-level meaning. Per the rubric, a baseline of 4 is given for tools with no parameters, and the description appropriately stays concise without attempting to document nonexistent 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 clearly states the action ('List') and the resource ('all Campfires'), and includes a parenthetical explanation that defines the term. It also qualifies the scope with 'visible to the current user', distinguishing this from similarly named tools like 'basecamp_list_campfire_lines' which lists lines within a campfire, and 'basecamp_get_campfire' which fetches a single campfire.
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 the tool is used when you need to enumerate campfires for the current user, but it doesn't explicitly mention when not to use it or point to alternatives such as 'basecamp_get_campfire' for a single campfire. The context is clear but not fully elaborated with exclusions or 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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that attachments can be included via attachment_sgids, which is a useful extra. However, it does not mention permissions, side effects, or return value, which would be valuable for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose, and no redundant filler. Every word earns its place.
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 description is sufficient for a straightforward create tool, but with no output schema, it omits what the agent can expect as a return value (e.g., created card object). Given the tool has 7 parameters and sits among many sibling tools, a bit more context on prerequisites or results would improve 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?
Schema coverage is 100%, so parameters are well-documented already. The description's mention of attachment_sgids adds a hint but does not go beyond what the schema already states (e.g., embedding in card content). No extra semantics are provided for other 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 clearly states the action ('Create a new card') and the target resource ('in a specific column'), which differentiates it from sibling tools like basecamp_update_card or basecamp_move_card. The attachment capability is also mentioned, adding useful specificity.
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 when to use the tool: when creating a card within a column. It does not explicitly list exclusions or alternatives, but the context is clear enough for an agent to differentiate from update/move operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add the key behavioral trait that the file is automatically uploaded and embedded in one step, but it doesn't mention other potential behaviors such as formatting, permissions, or error conditions. This is a moderate level of 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 concise, using just two sentences to convey the core purpose and the combined behavior. It is front-loaded with the main action and avoids unnecessary detail, earning a perfect score.
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 moderate complexity (4 params, no output schema, no annotations), the description covers the essential context of posting a comment with an attachment. It doesn't explain return values, but the output schema is absent, so that's not mandatory. It carefully positions the tool relative to siblings by emphasizing the integrated upload. Slightly more detail on preconditions or edge cases would make it more complete, but it's sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description doesn't add meaningful parameter semantics beyond the schema; it merely echoes file types already mentioned in the schema. The caption parameter is not elaborated in the description, but the schema already explains it well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Post a comment with an attached file... to any Basecamp card or todo.' It uses specific verbs and resources, and explicitly highlights the combined one-step behavior, distinguishing it from separate comment and upload tools like basecamp_comment and basecamp_upload_attachment.
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 implies when to use the tool (when you need to attach a file to a comment in one step), but it does not explicitly name alternatives or state when not to use it. This provides clear context without formal exclusions, which aligns with a score of 4.
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 that the tool returns a 'clean map' of dock tool IDs and lists the included types, which implies a read-only operation. However, it doesn't describe error behavior, permissions, or return format details beyond being a map.
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 with a clear front-loaded purpose and a practical usage note. Every phrase earns its place, with no fluff 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 simple single-parameter interface and lack of output schema, the description covers the needed bases: what the tool does, what it returns (a map of dock IDs), and what it's for. It lacks explicit return type details, but the term 'map' plus the enumerations provide enough context for an agent to invoke it correctly.
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 provides 100% coverage with a description for project_id ('Project ID'). The tool description doesn't add any further detail about parameter formats or constraints, so it adds no value beyond the 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 uses the specific verb 'Get' with the resource 'dock tool IDs for a project' and enumerates the dock types. This clearly distinguishes it from sibling tools like basecamp_get_project or basecamp_get_todoset, making the tool's unique purpose obvious.
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 second sentence explicitly states 'Use this to quickly find tool IDs needed by other endpoints,' giving clear context for when to call this tool. It doesn't name alternatives or exclusions, but the stated use case is sufficient for basic guidance.
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?
There are no annotations, so the description carries the full burden. It explains the filtering criterion (pingable/mentionable) and scope ('on this Basecamp account'), but fails to disclose return format, pagination, permissions, or any other behavioral traits. For a list operation, this is a minimal disclosure and leaves room for surprises.
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, tightly worded sentence that conveys the essential purpose without filler. It is front-loaded with the action and resource, making it easy to scan. 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?
The tool is simple (zero parameters, no output schema), and the description does a reasonable job for such a tool. It specifies scope and meaning. However, it could add a brief note about what the response contains (e.g., list of names/IDs) to be fully complete. Still, given the simplicity, the gap is minor.
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 schema requires no explanation. The description adds no parameter-specific detail, but none is needed. Baseline 4 is appropriate given there are no parameters to elaborate on.
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 clearly identifies the resource: 'all people who can be pinged (mentioned) on this Basecamp account'. This distinguishes it from sibling tools like basecamp_list_people, which likely returns a broader set of people, and basecamp_get_person, which targets a single person.
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 implies the use case: you need the list of mentionable people on the account. It provides clear context for when to use this tool, though it does not explicitly name alternatives or exclusion criteria. The phrasing 'can be pinged (mentioned)' signals its specific purpose without listing sibling 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?
Annotations are absent, so the description must disclose behavioral traits. It does reveal the key prerequisite (the attachable_sgid from a prior step), but does not mention permissions, reversibility, or error behavior. Since it is a create operation, the main dependency is covered, but other aspects remain undisclosed.
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 that immediately states the action and the required prior step. There is no filler or redundant 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?
The description plus schema covers the essential parameters and the workflow. It could mention what happens after creation (e.g., return value), but given the tool's simplicity and 80% schema coverage, it is adequately 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 80%, so the baseline is 3. The description reinforces the role of attachable_sgid by placing it in a sequence, but adds no new parameter-level information beyond what the schema already provides.
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 'Create' with a resource 'file upload' and a location 'in a vault'. It also distinguishes itself from sibling tool basecamp_upload_attachment by clarifying that this is the placement step after obtaining the attachable_sgid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the workflow: first use basecamp_upload_attachment to get an attachable_sgid, then use this tool to place it in a vault. This provides clear when-to-use guidance and differentiates it from the upload tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses the auto-paginating behavior, the aggregation into a single array, and the effect of single_page. It does not mention output fields or error conditions, but the key non-obvious behavior (pagination) is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and every phrase adds value. It explains the default behavior, the edge case (224-card column), and the alternative mode without fluff.
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 list tool with four params and no output schema, the description covers the essential behavioral aspects and parameter usage. It lacks an explicit note about return format, but the aggregation behavior is described. Given the tool's simplicity, it is 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?
Schema description coverage is 50% (page and single_page have descriptions, project_id and column_id do not). The description adds meaningful semantics beyond the schema by explaining default values and the intent of single_page for UI-style pagination. Though it doesn't clarify the ID parameters, these are self-evident.
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 a clear verb+resource: 'List cards in a column.' It is specific and distinguishes itself from sibling tools like basecamp_list_card_ids (which lists only IDs) and basecamp_get_card (which gets one card). The scope is unambiguous.
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 includes guidance on when to use the default auto-paginating behavior versus passing single_page for UI pagination. It does not explicitly mention alternatives like list_card_ids or when not to use this tool, but the pagination explanation provides clear context for usage.
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?
No annotations are provided, so the description carries the full burden. It discloses that it returns a specific compact set of fields, that the payload is much smaller than list_cards, and that it always auto-paginates. It does not mention auth requirements or error handling, but for a read-only listing tool, the disclosed behavior is sufficient and adds context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key purpose, and every clause adds value (fields, size comparison, use case, pagination). No wasted words.
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?
Despite having only 2 parameters and no output schema, the description explains the return fields, the use case for iteration, and the auto-pagination behavior. It provides enough context for an agent to select and invoke the tool appropriately in most scenarios.
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?
With 0% schema description coverage, the description must compensate. It does not explicitly explain project_id or column_id, but the tool name and description ('every card in a column') make them intuitively clear. However, it falls short of fully documenting parameter semantics, so the baseline is 3.
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 this is a compact card listing tool for a column, returning a specific subset of fields. It distinguishes itself from sibling basecamp_list_cards by highlighting the reduced payload and returning only IDs and a few fields, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says it is the right tool when you just need to walk IDs (e.g., to feed basecamp_get_card in a loop), and contrasts with list_cards by noting the payload is ~5% of that tool. This gives clear when-to-use guidance and implies when not to use it (when full card details are needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/vapvarun/basecamp-mcp-server'

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