WayStation MCP Server

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation3/5
While most tools target a specific resource and action, there is notable overlap across similar tools (e.g., readLinearProject includes all issues while listLinearIssues also lists issues, and listAsanaProjects/readAsanaProject/listAsanaTasks/task searching have blurred boundaries). Tool names and descriptions help disambiguate, but the sheer number of parallel CRUD operations across many apps increases the chance of selecting the wrong one.
Naming Consistency3/5
The naming generally follows a consistent pattern of verb + provider + resource (e.g., listJiraProjects, createLinearIssue), but the verbs are inconsistent: getMiroBoard vs readJiraProject vs fetchPostgreSQLSchema, and create vs add vs post for similar actions (createJiraComment, addJiraComment, postMiroNote). Also, helloWayStation and openWayStation deviate from the convention, making the set feel somewhat mixed.
Tool Count1/5
With 71 tools, the server is far beyond the typical well-scoped range. Although it aggregates many integrations, the high count reflects a broad but shallow surface across 15+ services. This is an extreme number that will overwhelm agents and complicate tool selection.
Completeness3/5
The tool surface covers core workflows for a wide array of apps (Jira, Linear, Asana, Gmail, etc.) but has notable gaps: no delete operations in most apps, no update for Miro/Notion docs, and read-only database access. Some integrations lack essential actions (e.g., Teams cannot read channel history, Office docs cannot be created/edited). Overall, the set is broad but not deep, with agents likely hitting dead ends for modifications beyond basic creation and updates.
Average 3.7/5 across 71 of 71 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 contradicts the schema by labeling workspace as optional and mentions a completion status filter that does not exist in the schema, misleading the agent.
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, reasonably concise sentence with the primary action front-loaded. It does not waste many words, though the inaccurate qualifier slightly detracts.
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 omits key details such as return format, pagination, search behavior, and any constraints. The misleading filter information leaves the tool under-specified for an agent with no annotations or output schema.
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 all parameters with descriptions, providing a baseline of 3. However, the description adds inaccurate 'completion status' context not represented in the schema, reducing semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for tasks matching a search term, distinguishing it from list/read Asana tools. However, it mischaracterizes workspace as an optional filter when it is actually required, undermining precision.
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 searchAsanaTasks versus listAsanaTasks or readAsanaTask. The description does not state exclusion criteria 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 merely states the action without mentioning side effects, permissions, rate limits, or response behavior. For a creation tool, this lack of context leaves the agent unsure about what happens after the call.
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 a clear verb and object, making it easy to parse. It is appropriately concise, though the phrase 'with the specified details' is somewhat filler and adds little value. Overall, it is efficient and not 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?
Given that the tool has 7 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what the function returns upon success, whether errors are expected, or how the parameters interact. This is insufficient context for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a 100% coverage of parameters, each with a description, so the baseline is 3. The tool description adds no additional parameter context beyond the generic 'specified details', which is already evident from the schema. It neither enhances nor detracts from schema information.
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 ('Creates a new issue') and the target resource ('in Linear'), which distinguishes it from tools for other platforms. However, it does not elaborate on distinguishing characteristics from other Linear tools like updateLinearIssue or createLinearComment, but the core purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It only implies its use for creating Linear issues, but does not mention when not to use it or reference sibling tools such as updateLinearIssue for modifications. No prerequisites or contextual cues 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 provided, the description carries full responsibility for behavioral disclosure. It states 'Retrieves tasks' but does not clarify read-only nature, pagination, limits, authentication requirements, or how filters interact (AND/OR). This leaves significant behavioral assumptions.
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 front-loads the action and lists the key filters. Every word contributes meaning, making it concise and 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?
The tool has no output schema and no annotations, so the description should explain return values and behavioral context. It only says 'tasks' without addressing response format, sorting, pagination, or how it differs from searchAsanaTasks. The lack of these details makes it incomplete for an AI agent to confidently use 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?
Schema description coverage is 100%, so the schema already documents all parameters in detail. The description adds minimal value by summarizing the filter types, but does not provide additional meaning beyond what the schema already contains.
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 retrieves tasks from Asana with specific filters (project, assignee, completion status). It distinguishes from list-type siblings (e.g., listAsanaProjects) and task-specific tools (readAsanaTask), but does not differentiate from searchAsanaTasks, which likely serves a similar purpose.
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 explicit guidance on when to use this tool versus alternatives such as searchAsanaTasks. It implies basic filtered listing but does not mention when a more powerful search tool would be appropriate.
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 burden of behavioral disclosure. It states 'Retrieves' implying a read-only operation, but does not detail any behavioral traits such as pagination, sorting, default limits, rate limits, or authentication requirements. The description adds minimal transparency beyond what the tool name implies.
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 conveys the primary action. It is front-loaded and free of filler, though it could be slightly expanded to include scope 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 simple list tool with one optional parameter and no output schema, the description is minimal but lacks essential context. It does not clarify what 'issues' means in scope (all issues, team issues, user issues), nor does it mention that results may be limited or ordered. The ambiguity with listMyLinearIssues leaves the agent without enough information for confident invocation.
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 documents the single 'limit' parameter with a default and description, resulting in 100% schema coverage. The description adds no parameter semantics of its own, but since the schema covers everything, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Retrieves a list of issues from Linear' clearly states the action (retrieves) and the resource (list of issues), which is unambiguous at a basic level. However, it does not distinguish this from the sibling tool listMyLinearIssues, which also retrieves Linear issues, so it lacks 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 is provided on when to use this tool versus alternatives like listMyLinearIssues or readLinearIssue. There is no mention of scope (e.g., all issues vs. current user's issues), prerequisites, or typical use cases, leaving the agent to guess which tool is appropriate.
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 that it searches, without mentioning read-only safety, result format, pagination, ranking, or authentication requirements. This is a minimal statement that adds little beyond the tool's basic function.
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 immediately identifies the action and scope, making it easy to parse. It is appropriately concise for a simple search tool.
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 there is no output schema and no annotations, the description should explain what the search returns and how results are presented. It doesn't mention return type, result structure, sorting behavior, or filtering semantics beyond the schema. This is a significant gap for a tool with 3 parameters and no output 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 100%, so the baseline is 3. The description adds no extra parameter meaning beyond the schema; it references 'the query' but doesn't elaborate on syntax, while sort and filter are already documented in the input schema. The description contributes minimal value here.
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 specifies a clear action ('Searches across a Notion workspace') and resource scope ('pages, databases, and content'), which distinguishes it from sibling tools like listNotionPages or listNotionDatabases. However, it doesn't explicitly name alternatives or explain how it differs from queryNotionDatabase, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like listNotionPages, listNotionDatabases, or queryNotionDatabase. The description doesn't suggest use cases, prerequisites, or exclusions, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden for behavioral disclosure. It simply states 'Updates an existing issue' with no details on side effects, partial vs full updates, permissions, or return behavior. This is severely under-specified 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, direct sentence that immediately states the action and target. It contains no filler or redundant information, making it highly concise 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?
Given that the tool updates an existing issue with multiple mutable fields and no output schema, the description is far too terse. It fails to mention whether updates are partial or full, what happens on success, or any constraints like required transitions for status changes. This is inadequate 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 already describes all 6 parameters with 100% coverage, so the description doesn't need to add parameter details. The phrase 'provided details' adds no meaning beyond the schema, but the high schema coverage allows a baseline of 3.
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 it updates an existing Jira issue, matching the tool name and distinguishing from create/list/comment sibling tools. However, it does not explicitly differentiate from alternatives or list the updatable fields, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing issues, but provides no explicit guidance on when to use this tool versus createJiraIssue or addJiraComment. It lacks any mention of alternatives or exclusions, making the usage context only 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?
With no annotations, the description must carry the transparency burden, but it only states 'creates' without disclosing side effects, auth requirements, idempotency, or response/error behavior. For a mutation tool, this is under-specified.
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, direct sentence with no redundant words or filler. It effectively states the purpose without 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 no output schema and no annotations, the description offers no information on return values, error conditions, or how to source baseId/tableId (e.g., via listAirtableBases/listAirtableTables). This is incomplete for a tool with nested object parameters and no other contextual safety information.
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 provides descriptions for all three parameters (100% coverage), so the baseline is 3. The description's mention of 'specified fields' adds marginal clarification, but the schema's own description for 'fields' uses 'update' wording which could create confusion; the tool description does not resolve 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 ('creates') and resource ('new record'), with 'specified fields in the given table' clearly indicating the action and scope. This cleanly distinguishes it from sibling tools like listAirtableRecords and updateAirtableRecord.
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 updateAirtableRecord, nor any mention of prerequisites like how to obtain baseId or tableId. The usage context is only implicit in the verb 'creates'.
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 only states the basic action and does not disclose behaviors like pagination, whether archived projects are included, response structure, or authorization requirements.
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 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?
There is no output schema, yet the description does not explain what the returned project list contains or any pagination/ordering details. It also lacks usage guidance, making it incomplete for a tool that should stand 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?
The schema already describes workspaceId fully (100% coverage). The description merely paraphrases this as 'specified Asana workspace' without adding new detail such as format, source, or examples, so it stays at the baseline of 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 uses a specific verb 'Retrieves a list' and clearly names the resource 'projects' with a scope ('associated with the specified Asana workspace'). This distinguishes it from sibling tools like readAsanaProject or listAsanaTasks.
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 listAsanaTasks or readAsanaProject. It mentions no context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It only says 'updates', without disclosing whether it's a partial update, what happens if the issue doesn't exist, or permission requirements. Minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and contains zero redundant 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?
No output schema or annotations exist, and description lacks return value info, error handling, or edge-case behavior. For a mutation with multiple parameters, this is insufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all seven parameters. The tool description adds no parameter-specific meaning beyond 'specified changes', so 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?
Description states it 'Updates an existing issue in Linear', with a specific verb and resource. This clearly distinguishes it from sibling tools like createLinearIssue (create) and readLinearIssue (read).
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 vs alternatives. It does not mention prerequisites such as the issue existing or that createLinearIssue should be used for new issues.
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 issue must be 'existing', which implies a prerequisite, but does not disclose permissions, error behavior, return value, or that the comment is appended to the existing comment thread. This is minimal transparency 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 of eight words, with no unnecessary verbs or modifiers. It front-loads the action and resource clearly, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters and no output schema, the description is adequate but incomplete in a few respects: it does not describe the return value, error behavior, or required permissions. The schema covers parameter semantics, so the main gaps are around execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the baseline is 3. The description adds no additional parameter-level details beyond what the schema already provides, but it doesn't need to compensate for any 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 clearly states the tool's action: 'Adds a new comment to an existing Jira issue.' It uses a specific verb ('Adds') and resource ('comment' to 'Jira issue'), which distinguishes it from other Jira tools like createJiraIssue or updateJiraIssue and from comment tools on other platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states the action without mentioning prerequisites (e.g., permissions) or directing users to other comment tools (e.g., createLinearComment) for other services. The 'existing issue' hint is the only contextual cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the creation action but misrepresents custom_fields as optional when the schema marks it required, creating a contradiction with the schema. It does not mention return values, permissions, or side effects beyond creation.
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 starts with the action verb and includes the key resource and optional details. Every word contributes to understanding, with no wasted text.
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 6 parameters, a nested custom_fields object, and no output schema, the description is too minimal. It lacks information about what the tool returns, the fact that custom_fields is required, and any prerequisites like having projectId. The schema covers parameters but not the broader context needed for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter descriptions, so the baseline is 3, but the description adds misleading information by labeling custom_fields as optional when it is actually required. The description does not add meaningful semantic value beyond the schema and introduces confusion.
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 'Creates' and the resource 'a new task in the specified Asana project', distinguishing it from sibling tools like updateAsanaTask and readAsanaTask. The optional details listed (description, due date, assignee, custom fields) align with the intended use, even though custom_fields is actually required per schema.
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 use for creating tasks but does not explicitly state when to use it versus alternatives like updateAsanaTask or createAsanaComment. No exclusions or alternative tool names are provided, leaving the agent to infer context from the verb and sibling names.
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 carries the full burden of behavioral disclosure. It only restates the creation action without mentioning potential side effects, return values, permissions, or error conditions. This is comparable to the 'update_drive' example, which scored 2.
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 directly states the action and scope, earning a high score for conciseness.
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 with complete schema coverage, the description is minimally viable. However, the absence of annotations and output schema leaves gaps about what the agent should expect after invocation (e.g., returns created issue? confirmation?). It's adequate but not rich.
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 6 parameters, so the schema already documents each parameter. The description adds nothing beyond 'provided details,' not even linking the params to the Jira domain. Baseline 3 applies.
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 'Creates a new issue in a specified Jira project with the provided details' uses a specific verb ('creates'), names the resource ('Jira issue'), and indicates the project scope. It clearly distinguishes from sibling tools like updateJiraIssue and listJiraIssues.
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 updateJiraIssue or addJiraComment. The description lacks any context about preferring this for new issues or exclusions for existing ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without detailing side effects, permissions, reversibility, or failure modes. It is not misleading, but it lacks depth needed for safe invocation.
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 without any redundant or irrelevant content. It is highly concise 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?
The tool is a straightforward creation operation and the schema covers parameter descriptions, but the description omits information about return values, error cases, or how it relates to other Notion tools. Given the absence of annotations and output schema, the description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. Since schema coverage is 100%, the baseline is 3; the phrase 'with specified content' only vaguely references the content parameter and does not enrich understanding of parentType or 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 tool's function with a specific verb ('Creates'), resource ('a new page in Notion'), and scope ('with specified content'). It distinguishes itself from sibling tools like createNotionComment and readNotionPage by focusing on page creation.
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 queryNotionDatabase or listNotionPages. It does not mention use cases, prerequisites, or exclusions, leaving the agent 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a read operation ('Retrieves') and mentions optional filtering and pagination, but does not elaborate on response format, required permissions, rate limits, or error behavior. This adds some context but lacks depth.
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 main verb and resource. Every word earns its place with no redundancy or fluff.
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 with well-described parameters, the description is adequate. However, since there is no output schema, it does not clarify the return structure (e.g., an array of records) or default field behavior. It also doesn't explain Airtable formula syntax for filtering beyond the brief schema note.
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% for all 7 parameters, so the baseline is 3. The description's phrase 'optional filtering and pagination' adds minimal semantic value beyond what the schema already documents for filterByFormula, pageSize, and offset.
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 retrieves records from a specified table, with optional filtering and pagination. It distinguishes from sibling tools like listAirtableTables (which lists tables) and create/updateAirtableRecord (mutations), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description does not mention exclusions or point to other Airtable tools for different operations (e.g., creating or updating records).
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. The verb 'Retrieves' clearly indicates a read-only operation, which is a positive behavioral disclosure. However, the description lacks details about auth requirements, return format, pagination behavior, or whether it includes full message content or just thread metadata. It adds minimal value beyond the basic 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, direct, and free of unnecessary details. It front-loads the core purpose ('Retrieves a list of email threads/conversations') and the optional filtering note. 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 has no output schema, so the description should hint at what is returned, but it only says 'list of email threads/conversations.' This leaves ambiguity about whether it returns thread summaries, IDs, or full message data. Sibling readGmailThread implies this is a lightweight listing, but that is not stated. The description is adequate for a simple list tool but lacks key context about the return value.
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 all four parameters (query, labelIds, maxResults, includeSpamTrash) have adequate explanations. The description only says 'with optional filtering,' which summarizes but does not add meaning beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieves a list' and clearly identifies the resource as 'email threads/conversations from the user's Gmail account.' It distinguishes itself from the sibling tool readGmailThread by emphasizing 'list' (plural), but it does not explicitly contrast with readGmailThread or other Gmail tools, so it doesn't earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention readGmailThread for fetching a single thread or listGmailLabels for labels, nor does it state exclusions or prerequisites. The phrase 'with optional filtering' hints at use cases but is not 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?
With no annotations, the description carries full burden. The verb 'retrieves' implies read-only, and it notes the tasks can be arbitrary JSON objects. However, it doesn't disclose potential error conditions, pagination behavior, or whether project metadata is excluded.
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 short sentences, front-loaded with the core action, no redundant wording.
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 single-parameter tool with no output schema or annotations, the description explains the primary behavior and return type, but lacks an explicit statement about the return array format or limitations. It is adequate but not rich.
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 projectId with a clear description (100% coverage). The description adds no further parameter-level details, which places it at baseline.
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?
Description clearly states 'Retrieves all tasks from the specified Asana project' – a specific verb and resource. However, it does not differentiate from sibling tools like readAsanaTask or listAsanaTasks, so it doesn't fully meet the 5 standard.
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 such as listAsanaTasks or readAsanaTask. The description is purely functional and gives no contextual cues.
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 function, omitting details like authentication requirements, error handling, response structure, or any side effects. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It is concise and well-structured, achieving maximum clarity with minimal 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 read tool, the description is minimally acceptable, but it lacks context about what the returned content includes and how it differs from listing tools. With no output schema and no annotations, the agent must infer return format and safety characteristics 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?
The input schema provides full descriptions for both parameters, including the enum and default for format. The description only repeats the concept of 'specified format' without adding new meaning, so it meets the baseline for schema-covered 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 (retrieves), the resource (Notion page), and the variable format ('in the specified format'). This distinguishes it from sibling tools like listNotionPages and searchNotion, which focus on listing or searching rather than retrieving page content.
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 listNotionPages or searchNotion. It lacks context about typical use cases, prerequisites, or exclusions, 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 only states the action without revealing what the search returns, how 'matching' is determined (e.g., title vs. content, fuzzy vs. exact), or any potential limitations. This lack of detail leaves the agent guessing about the tool's runtime 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, concise sentence that conveys the essential purpose without any wasted words. It is front-loaded with the key action and resource, making it easy to parse quickly. No extraneous information or filler is present.
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 (one parameter, no annotations, no output schema), the description is minimally viable but leaves gaps. It does not explain what the search results look like, whether it returns full documents or metadata, or any search behavior specifics. This is a noticeable shortcoming for an agent that must invoke the tool correctly and interpret results.
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 a single parameter 'query' with the description 'Search query to find matching Office documents.' The tool description's mention of a 'specific query string' adds no additional semantic value beyond what the schema already provides. Since schema description coverage is 100%, the 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 clearly states the tool's function: 'Searches for Office documents matching a specific query string.' It uses a specific verb ('Searches'), identifies the resource ('Office documents'), and describes the scope ('matching a specific query string'). This effectively distinguishes it from sibling tools like listOfficeDocs or readOfficeDoc.
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 exclusions, prerequisites, or differentiate from sibling tools such as listOfficeDocs or recentOfficeDocs. Usage must be inferred solely from the tool's name and description, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add a key constraint: it only returns pages the user has access to, which is important context. However, it does not mention other behavioral aspects such as pagination, rate limits, or whether the response includes metadata. While the read-only nature is implied by 'Retrieves', there is no explicit safety 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 sentence that immediately conveys the action and resource. It avoids unnecessary words and is well-structured for quick comprehension. Every word adds value.
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 tool with no parameters and no output schema, the description is minimally viable. It explains the primary function and a key behavioral filter (access). However, it lacks differentiation from sibling tools and does not provide context on when to use this tool over others, leaving the agent to infer the appropriate use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter meanings. The baseline for zero parameters is 4, and the description does not introduce any conflicting information. It effectively communicates the tool's scope without parameter 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 clearly states the tool retrieves a list of pages in Notion, using the specific verb 'Retrieves' and the resource 'pages'. It also includes the scope 'user has access to', which is useful. However, it does not distinguish itself from sibling tools like 'searchNotion' or 'listNotionDatabases', which might also be used to find pages, so it falls 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. There is no mention of exclusions or when a different tool like 'searchNotion' would be more appropriate. The only hint is the implied use case of listing accessible pages, but this is not explicitly stated as the recommended 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 are provided, so the description carries the full burden. It only says 'retrieves and filters' without disclosing behavior like pagination limits, return format, or any side effects. The addition of schema parameters like pageSize in the schema partially covers limits, but the description itself offers minimal 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 unnecessary repetition. It directly states the action and resource, making it highly 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?
The tool has complex nested filter and sort objects, no output schema, and no annotations. The one-sentence description does not explain how to construct filters, what results look like, or when to prefer this over sibling tools, leaving significant gaps for an agent to use 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what the schema says, staying at the baseline of 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 states a specific operation: 'Retrieves and filters items from a specified Notion database.' This clearly distinguishes it from sibling tools like listNotionPages, readNotionPage, and searchNotion, which have different scopes and resources.
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 querying a database, but does not explicitly state when to use this over other tools like searchNotion or listNotionDatabases. No exclusions or alternatives are mentioned, so it's implied rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the mutation action and required column values format. It does not disclose side effects, permission requirements, reversibility, or behavior on invalid IDs, leaving 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 only two sentences, front-loaded with the core purpose, and contains no filler. Every sentence contributes useful 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?
For a mutation tool with no annotations and no output schema, the description is too sparse. It fails to mention expected return values, error conditions, or prerequisites like whether the item must exist or match the board. The provided format guidance is helpful but insufficient for complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds a notation about column_values being required and its format, but this largely duplicates the schema's required list and example. Minimal added value 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 clearly states the tool updates an existing item in a Monday board with new column values, using a specific verb and resource. It distinguishes itself from siblings like createMondayItem and createMondayUpdate by focusing on updating existing items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for updating existing items but does not explicitly compare against alternatives or state when-not-to-use. No exclusions are mentioned, but the 'existing item' phrasing provides some 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 exist, so the description must carry behavioral information. It only says 'retrieves a list' and omits pagination behavior, response structure, or access requirements, leaving the agent without 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, front-loaded sentence with no wasted words. It is appropriately concise for 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?
While the tool itself is simple, there is no output schema and the description does not outline return value structure, pagination, or limits. It tells what the tool does but not what to expect in response.
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 schema coverage is effectively 100% via an empty parameter object. The baseline for zero-param tools is 4, and no parameter explanations are needed.
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 retrieves a list of projects from Linear, using a specific verb and resource. It distinguishes itself from siblings like listLinearIssues and readLinearProject.
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 readLinearProject or listLinearTeams. There are no exclusions or context hints.
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 mentions the authenticated user's workspace, which is useful, but it does not describe the output structure, potential pagination, authorization requirements beyond authentication, or any side effects. This is insufficient for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and resource. There is no redundancy or unnecessary detail, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter tool, but the absence of annotations and output schema increases the description's responsibility. It states the basic function but does not clarify whether the result is a flat list or nested teams with channels, nor does it mention any limits or default behavior. It is minimally complete but not fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description reinforces that it operates within the authenticated user's context. With no parameters to explain, the baseline is 4, and the description adds no harm; it correctly implies no additional inputs are needed.
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 'retrieves' and the resource 'teams and channels from the authenticated user's Microsoft Teams workspace.' This distinguishes it from sibling tools like listSlackChannels or postTeamsMessage, which target other platforms or 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 does not provide explicit guidance on when to use this tool versus alternatives. While the name implies it is for listing Teams channels, there is no exclusions or mention of preferred contexts, such as 'use this before posting a Teams 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?
No annotations are provided, so the description carries the full burden. It discloses the mutating nature ('Adds') but does not mention permissions, error handling, response shape, or side effects (e.g., what happens if the board is invalid). 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 that efficiently states the verb, object, and key context with 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?
The tool has 5 parameters with full schema documentation and no output schema. The description clarifies the core action but omits details about return values, error conditions, and prerequisites (e.g., valid boardId), making it minimally complete for an agent to use 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?
Schema coverage is 100% with descriptions for all 5 parameters. The description's mentions of 'content' and 'position' are a summary rather than adding new semantics. The schema already documents defaults and constraints, so the description adds marginal 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 clearly states the tool's action with a specific verb ('Adds'), resource ('sticky note'), and target ('Miro board'), and includes position context. It distinguishes itself from sibling tools which are for other platforms.
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 a sticky note needs to be added to a Miro board, but it provides no explicit when-to-use vs. alternatives guidance or exclusions. There is no mention of alternative tools for similar actions.
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 burden. It only states the basic action of creating a comment, without mentioning potential side effects, error conditions, authentication needs, or whether the comment appears immediately. This is a mutation tool with no additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any waste or unnecessary detail. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a fully descriptive schema and no output schema, the description adequately covers the core purpose: creating a comment on a Linear issue. However, the lack of annotations and behavioral details (e.g., what happens if the issue doesn't exist) leaves a small gap, but it is not severe given the tool's simplicity.
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 'body' and 'issueId' described in the schema. The description adds no parameter information beyond what the schema already provides, which matches the baseline 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 ('Creates') and names the resource ('a new comment on an existing issue in Linear'). It clearly distinguishes from sibling tools like addJiraComment or createLinearIssue by including 'Linear' and specifying 'comment' rather than 'issue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for commenting on a Linear issue, but it provides no explicit guidance on when to use this versus alternatives (e.g., addJiraComment for Jira comments). Usage is implied by the tool's name and description, but no 'when not to use' or alternative 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 carries the full burden. It reveals that the tool creates a coment and supports threading, but it does not disclose side effects (e.g., posting publicly, notifications), permissions required, or behavior on invalid item_id. 'Creates' implies a mutation, but additional context is absent.
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 primary action and resource. It includes the optional parent_id detail without unnecessary words, earning full marks for efficiency.
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 create operation with three params and no annotations, the description covers the essential function. It lacks information about return values or error handling, but the absence of an output schema lowers the expectation. The description is adequate for a straightforward comment 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?
Schema description coverage is 100%, so parameters already have descriptions. The description adds minor value by clarifying that 'body' is a comment and that 'parent_id' enables threaded replies, but does not substantially enrich 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 states a specific verb 'Creates' and resource 'new update (comment) on the specified Monday.com item', clearly distinguishing it from sibling tools like createMondayItem (creates an item) and updateMondayItem (modifies an item). The mention of 'parent_id for threaded replies' adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating it creates comments on Monday.com items, but does not explicitly state when to prefer this tool over alternatives or when not to use it. The optional parent_id hint suggests a use case for threaded replies, but no explicit exclusions or comparisons 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 carries the full burden of behavioral disclosure. It states the create action and the column_values format, but omits details about required permissions, success/failure responses, idempotency, or side effects, leaving the agent to guess write access and return 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 exactly two sentences, front-loaded with the purpose and then the key parameter detail. Every sentence earns its place with 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?
The description covers the core action and parameter format, but lacks return value details or prerequisites (e.g., needing board and group IDs upfront). With no output schema or annotations, the agent is left without information on what the API returns after creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds a generic format template for column_values ('column_id: value'), which reinforces the schema's example. This provides extra clarity beyond the schema, though the schema alone already documents all parameters 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 a specific action ('Creates a new item') and the exact resource (Monday board and group), distinguishing it from sibling tools like updateMondayItem and createMondayUpdate. The verb and resource are 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 the usage context (creating a new Monday item) but does not explicitly mention when not to use it or recommend alternatives. It lacks explicit exclusions or comparisons to createMondayUpdate or updateMondayItem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action and the 'plain text' constraint, but omits details about permissions, failure modes, return values, or whether the comment appends to a discussion. This is minimal for an unannotated 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?
A single, front-loaded sentence that says everything necessary without redundancy. 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?
With only 2 required parameters and no output schema, the description is adequate but thin. It does not mention return values, prerequisites (e.g., page existence), or behavior when the page does not exist. For a simple create operation, some additional context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so baseline is 3. The description adds value by specifying 'plain text', which constrains the text parameter beyond the schema's 'Text content'. This helps the agent avoid using rich text or markdown.
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 ('Adds') and resource ('comment to a Notion page'), clearly differentiating it from createNotionPage and comment tools for other platforms. It unambiguously states 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 description implies usage (when you want to comment on a Notion page) but provides no explicit when-to-use vs alternatives or any exclusions. There is no mention of sibling tools or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'read-only,' which is a critical trait preventing the agent from attempting write operations. However, it does not disclose the result format, possible SQL restrictions, or error behavior, so it is not fully 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, concise sentence that front-loads the action and resource. It includes all essential information without redundancy, making it easy 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?
The tool is simple with one parameter and no output schema, and the description covers the core action and read-only nature. However, it lacks a description of the result format (e.g., array of rows), which is important for an agent to parse the output correctly. There is also no mention of query restrictions or limitations, leaving some gaps in complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single 'query' parameter as 'The SQL query to execute,' giving 100% schema coverage. The description adds the read-only context but provides no additional parameter-level detail such as whether the query must be a single statement or how to handle semicolons, so it meets the baseline without exceeding it.
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 'Executes a read-only SQL query against your PostgreSQL database and returns the results.' It specifies the verb (executes), resource (PostgreSQL database), mode (read-only), and output (results), distinguishing it from sibling tools like executeSupabaseSqlQuery and executeNeonSqlQuery by naming PostgreSQL specifically.
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 executeSupabaseSqlQuery, executeNeonSqlQuery, or fetchPostgreSQLSchema. There is no mention of prerequisites, exclusions, or recommended use cases, so the agent must rely solely on the tool name for usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it retrieves a list, with no mention of pagination, response format, result limits (beyond the schema default), or any side effects. This is a notable gap for a tool that will be invoked programmatically.
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 sentence that is front-loaded with the action and resource. Every word contributes meaning, with no fluff or repetition. It is appropriately terse for a simple list 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 (2 params, no nested objects) and the schema is rich, but there is no output schema and no annotations. The description explains the basic function but does not specify the shape of the returned list (e.g., full issue objects vs. summaries). This is adequate for basic invocation but leaves some ambiguity.
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%, and the schema already provides detailed descriptions for both parameters (jql with an example, maxResults with a default). The description adds only the conceptual framing of 'project or JQL', which is already implicit. The schema does the heavy lifting, so a 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 uses a specific verb ('Retrieves a list') and identifies the resource ('issues from a Jira project or using a JQL query'). It clearly distinguishes this from sibling tools like listJiraProjects (which lists projects) and create/update Jira issue tools.
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 indicates the tool's two primary use cases: listing issues from a project or via JQL. This provides enough context for when to use it. It does not explicitly name alternatives, but the purpose is differentiated enough among siblings.
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 ('Retrieves a list') and the ordering behavior, but lacks details on pagination, whether subfolders are included, or any access requirements. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that uses every word efficiently. It is front-loaded and immediately conveys the tool's purpose and ordering.
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 adequate for a simple listing tool with a single optional parameter, but since no output schema is present, it does not clarify the shape of the returned items (e.g., field names, types). It also does not mention related tools for alternative retrieval patterns, leaving some selection ambiguity.
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 already provides 100% coverage for the single parameter folderId, including its optionality and default behavior. The description adds no additional parameter context beyond what the schema states, so baseline score of 3 applies.
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 ('Retrieves a list'), the resource ('Office documents and folders from OneDrive'), and a distinguishing detail ('ordered by last modified date'). This differentiates it from siblings like listGoogleDocs and readOfficeDoc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing items from a folder or root, but does not explicitly state when to use this tool over alternatives like searchOfficeDocs or recentOfficeDocs. No 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?
No annotations are provided, so the description must carry the full behavioral burden. It only states that a message is sent, without disclosing potential side effects, error behavior, authentication requirements, or whether the message appears as a bot/user. 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, well-structured sentence that states the action and target concisely. It contains no fluff or redundancy, making it easy to parse 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 and the schema covers all parameters, but the description lacks information about return values or post-send behavior, and there is no output schema to compensate. It is minimally viable but leaves gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described in the input schema. The description echoes 'text message' for the message parameter but adds no additional semantic detail beyond what the schema already provides, so the baseline of 3 applies.
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 (sends), the target (Microsoft Teams channel), and the payload (a text message). It effectively distinguishes this tool from sibling tools like postSlackMessage, which target a different platform.
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 is for posting text messages to a specified Teams channel, which is clear context for when to use it. It does not explicitly mention exclusions or alternatives, but the scope is unambiguous given the domain-specific 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?
No annotations are provided, so the description carries the burden. It indicates a mutation ('Updates') and lists fields, suggesting partial updates ("with new values"). However, it does not disclose whether updates are partial or full, why custom_fields is required, error handling, or return behavior. The schema descriptions fill some gaps, but the description adds limited 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It lists fields efficiently without fluff, making it appropriate in length.
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 7 parameters, 2 required, and no output schema, the description is minimal. It covers the core purpose but does not explain required custom_fields behavior, return values, or failure modes. Adequate but with clear gaps 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?
Schema description coverage is 100%, so the baseline is 3. The description merely restates the field names without adding additional meaning beyond what the schema already provides (e.g., date format, assignee special values). No extra semantic value is added.
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: 'Updates an existing Asana task' with a specific list of updatable fields (name, notes, due date, assignee, completion status, custom fields). This distinguishes it from sibling tools like createAsanaTask (which creates) and readAsanaTask (which reads).
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 use when modifying an existing task, but does not explicitly state when to use or not use alternatives. It lacks exclusions or explicit comparisons to sibling tools like createAsanaTask, leaving usage context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('creates') and the Asana-specific 'story' terminology, but does not mention required permissions, error conditions, or effects beyond the obvious creation, leaving the agent uninformed about potential failure modes.
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 lacking any fluff or repetition of schema information. It efficiently communicates 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?
For a simple two-parameter create tool, the description covers the core action adequately. It does not mention return values, but the schema is complete and the operation is straightforward, making the description sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both taskId and text described clearly in the input schema. The description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies.
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 'Creates a new comment (story) on the specified Asana task' – a specific verb, resource, and target platform. The mention of 'Asana task' differentiates it from sibling comment tools like addJiraComment or createNotionComment.
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 makes the usage context clear: it is for adding comments to Asana tasks. While sibling tools exist for other platforms, no explicit 'when not to use' guidance is provided, but the context is unambiguous.
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 read-only nature and that results are returned, but it does not clarify whether read-only is enforced, how errors are handled, or what the result format looks like. Given that this is an SQL execution tool, these details are important for safe and correct use.
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 core action and resource. Every word earns its place, with no unnecessary detail 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?
For a simple tool with one parameter and no output schema, the description provides enough context: the action, the resource (Supabase), and the read-only constraint. However, the absence of an output schema means the description could have elaborated on the result format, and there is no mention of execution limits or error behavior. Still, the core information is present and sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'query' parameter, but the description adds meaningful semantics by specifying that the SQL query must be read-only. This extra constraint helps the agent understand what kind of SQL is acceptable, going beyond the schema's generic 'The SQL query to execute.'
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: it executes a read-only SQL query against a Supabase database and returns results. The verb 'executes' and resource 'Supabase database' are specific, and the read-only qualifier helps distinguish it from sibling tools that target PostgreSQL or Neon.
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 that this tool is used for read-only SQL queries on Supabase, but it does not explicitly contrast it with sibling tools like executePostgreSQLSqlQuery or executeNeonSqlQuery. There is no 'when to use' or 'when not to use' guidance beyond the tool's name and basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It indicates a read-only fetch via 'Fetches' and mentions 'tables and columns' as output, but it does not explicitly confirm read-only behavior, describe side effects, permissions, or error conditions. This leaves a significant transparency 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, front-loaded sentence with no redundant or extraneous words. It efficiently states the action and the 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?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description is reasonably complete: it identifies the connected Neon database and what the schema shows. However, it could have specified the return format more explicitly or clarified that it reflects the currently connected database, so it's not perfect but 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, so schema coverage is 100% vacuously. Per guidelines, the baseline for 0 params is 4. The description adds slight value by hinting at the output contents ('tables and columns'), but no parameter explanation is needed.
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 ('Fetches') and resource ('schema of the connected Neon database') with additional detail ('showing tables and columns'). It clearly differentiates from sibling tools like fetchPostgreSQLSchema and fetchSupabaseSchema by explicitly naming Neon.
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 context via 'connected Neon database' but does not explicitly state when to use this tool over alternatives such as fetchPostgreSQLSchema or fetchSupabaseSchema, nor does it mention any exclusions. Usage guidance is implied rather than spelled out.
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 indicates a read-only fetch ('Fetches the schema'), but does not disclose specifics like whether views, indexes, or constraints are included, or any permissions needed. Adequate but not detailed.
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 sentence that is immediately clear, front-loaded with the verb, and contains no redundant words. Perfectly concise for its scope.
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?
No output schema exists, so the description must stand alone. It covers the primary purpose and output ('tables and columns') but could optionally mention return format or limitations. For a simple zero-parameter schema fetch, this is largely 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?
Tool has zero parameters, so there is no parameter semantics to clarify. Baseline 4 applies per rubric guidance.
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?
Description states a specific action ('Fetches the schema') with a clear resource ('connected PostgreSQL database') and what it returns ('showing tables and columns'). Distinguishes from sibling tools like executePostgreSQLSqlQuery (which runs queries) and fetchSupabaseSchema/fetchNeonSchema (other database engines).
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. Does not mention that it's for schema exploration before querying, nor does it exclude execution or other schema-fetching tools. The context signals sibling tools but the description alone gives no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation via 'Retrieves' and notes the 'authenticated user' scope, but it does not disclose return format, pagination, or edge cases like empty favorites. Since no annotations are provided, the description carries the full burden and is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that immediately states the tool's primary function. It is front-loaded and contains no superfluous 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?
Given the tool has no parameters and no output schema, the description provides a sufficient overview of the expected return value ('a list of favorite projects and issues'). It lacks minor details such as whether projects and issues are combined or returned separately, but overall it is complete for a simple read tool.
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 is not required to explain parameter details. It correctly adds context by indicating the data is scoped to the authenticated user, going beyond the empty 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 tool retrieves a list of favorite projects and issues from Linear for the authenticated user. It uses a specific verb ('Retrieves') and resource ('favorite projects and issues') that distinguishes it from sibling tools like listLinearProjects and listMyLinearIssues.
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 listLinearProjects or listMyLinearIssues. The description simply states what it does without any context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It indicates a read-only operation via the word 'Returns', but does not mention potential caveats like pagination, ordering, authorization needs, or error behavior. For a simple list operation, this is adequate but not exhaustive.
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 extraneous words. It front-loads the action and object, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately conveys the purpose and return value ('list of all tables'). It does not detail the structure of the returned tables, but for a straightforward list operation, this is sufficient.
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 provides a clear description for baseId ('ID of the Airtable base to list tables from'), and schema coverage is 100%. The description does not add supplementary parameter context, 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 uses a specific verb ('Returns') and clearly identifies the resource ('all tables in the specified Airtable base'). It distinguishes itself from sibling tools like listAirtableBases and listAirtableRecords by explicitly focusing on tables within a base.
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 states the tool's function but does not explicitly compare it with alternatives such as listAirtableBases or listAirtableRecords. Usage context is implied through the tool name and sibling tools, but no direct when-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects. The verb 'Retrieves' clearly signals a read-only operation, and the scope 'from all workspaces' adds useful context. However, it does not mention pagination, error handling, or whether the list could be empty.
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 resource. Every word contributes to the meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description sufficiently explains the tool's purpose, return type ('a list'), and scope ('all workspaces'). It could mention behavior when no favorites exist, but this is a minor gap for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds contextual meaning about what is being fetched (favorites) but does not need to elaborate on parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves a list') and the resource ('favorite projects and tasks') from Asana. It distinguishes itself from sibling tools like listAsanaProjects and listAsanaTasks by limiting scope to favorites.
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 exclusions or compare with listAsanaProjects or listAsanaTasks, leaving the agent to infer appropriate 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.
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 of behavioral transparency. It states the core behavior (read-only retrieval of user-assigned issues) but does not disclose additional details like sorting, pagination behavior (beyond the limit param), or whether archived issues are included.
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 conveys the essential purpose with no redundant words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description gives sufficient context about the returned resource, though it omits details about the response structure. It is complete enough for straightforward usage, but slightly sparse without annotations.
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 only parameter 'limit' is fully described in the schema (100% coverage), so the description adds no extra semantics. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 ('Retrieves') and names the exact resource ('issues assigned to the authenticated user in Linear'), clearly distinguishing it from sibling tool listLinearIssues which likely returns all issues. 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for issues assigned to the current user but does not explicitly state when to use it over listLinearIssues or provide exclusions. The context is clear but guidance remains implicit.
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?
There are no annotations, so the description must carry the transparency burden. It discloses that output is readable content and metadata is stripped, but does not mention read-only safety, auth requirements, or whether messages are marked as read. This is moderately useful but leaves behavioral gaps.
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 concise sentence that front-loads the action and resource. It contains no filler or redundant phrasing.
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 read tool with a well-documented 2-parameter schema, the description adequately conveys the core purpose and output style. However, without an output schema, it only vaguely specifies the return content and does not describe overall response structure, leaving a minor gap.
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 documents both threadId and includeAttachments with descriptions, so schema coverage is 100%. The description adds no parameter-specific detail beyond what the schema provides, so baseline 3 applies.
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 'Retrieves' as a specific verb, identifies the resource as a complete email thread/conversation, and specifies the output is readable message content stripped of metadata. This clearly distinguishes it from siblings like listGmailThreads or sendGmailEmail.
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 this is for reading full thread content, but it does not explicitly contrast with listGmailThreads or state when not to use it. No clear exclusions or alternatives are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but appropriately communicates a read-only operation ('Retrieves'). It does not disclose error handling, access permissions, or pagination, but the operation is simple and the plain text output is mentioned.
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 sentence with no wasted words; front-loaded verb and 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?
For a low-complexity tool with no output schema, the description adequately explains the return value (plain text content) and purpose. Slight gap regarding error cases or permissions, but acceptable.
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 provides complete coverage for the single docId parameter with a clear description. The tool description adds no additional parameter context beyond reinforcing that the doc is identified by its ID, so baseline 3 applies.
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 (Retrieves), the specific resource (a specific Google Doc), and the output format (as plain text), which distinguishes it from sibling listGoogleDocs and readOfficeDoc.
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 reading a specific Google Doc but provides no explicit guidance on when to choose it over alternatives like listGoogleDocs or readOfficeDoc, nor any exclusion criteria.
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 is the sole source of behavioral disclosure. It does state a key behavioral trait: it returns 'all issues' (indicating no pagination or filtering). However, it does not mention whether the operation is read-only, any required permissions, or potential performance implications of retrieving all issues.
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, front-loaded sentence that efficiently states the tool's purpose and scope. There is no wasted verbiage.
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 one-parameter read tool, the description adequately covers the core behavior and result contents. It does not explain the return structure, but the absence of an output schema makes that a minor gap. It is complete enough for most use cases.
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% with projectId well described as 'The unique identifier of the Linear project.' The description adds minimal extra meaning beyond saying 'specified Linear project.' Therefore, 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 identifies the action ('Retrieves') and the resource ('specified Linear project'), and specifies the full scope: 'project metadata and all issues.' This distinguishes it from siblings like listLinearProjects (lists projects) and listLinearIssues (lists issues).
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 context: when you need both project metadata and its issues in one call. However, it provides no explicit guidance on when to use this tool instead of alternatives like readLinearIssue or listLinearIssues, nor does it mention exclusions or prerequisites.
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 transparency burden. It discloses the core behavior (retrieval) and notes items are arbitrary JSON, but it does not mention pagination, response format, or permissions. This is acceptable for a simple read but lacks depth.
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 filler. It is front-loaded with the primary action and additional context about item structure.
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 one-parameter read with no output schema, the description is largely complete. It states what the tool does and the nature of the items. It could mention the response format, but this is not a critical gap for a simple retrieval 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?
Schema coverage is 100% for the single parameter boardId, with a clear description. The description adds no extra parameter information, so the baseline score of 3 applies.
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 retrieves all items from a specified Monday board, using a specific verb and resource. It distinguishes from siblings like listMondayBoards (which lists boards) and createMondayItem (which creates items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading all items from a board, but it does not explicitly mention when to use this over alternatives or provide exclusion criteria. No direct comparison with sibling tools is made.
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. It clearly indicates a read-only retrieval by the word 'Retrieves,' but it does not disclose ordering, recency window, pagination, or authentication requirements. This is adequate for a simple zero-parameter list tool but leaves room for more 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, front-loaded sentence with no filler. It states the action and resource clearly and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema retrieval tool, the description is largely sufficient. It clearly states the purpose and resource. However, it lacks usage guidance to differentiate from sibling list/search tools, which slightly reduces completeness.
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 already covers 100% of them. The description adds no parameter-specific details, but none are needed. Baseline 4 for zero-param tools 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?
Description uses specific verb 'Retrieves' with clear resource 'recently used Office documents' and scope 'by the user.' It clearly distinguishes from sibling tools like listOfficeDocs (general list) and searchOfficeDocs (search-based) by emphasizing the 'recently used' filter.
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 listOfficeDocs or searchOfficeDocs. The description implies a use case (recent documents) but does not state when to choose it over siblings or mention any 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?
No annotations are provided, so the description carries the burden. It discloses a key behavior: only the specified fields are updated (partial update) and targets an existing record. However, it does not mention return values, error handling, or whether the record must exist, leaving some behavioral gaps.
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 action and includes essential scope. No unnecessary words or repetition, 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?
For a simple CRUD update with a complete schema (100% coverage) and no output schema, the description provides adequate context. It specifies the partial-update behavior and the requirement of an existing record. The tool is well-understood without needing extra detail on response formats or prerequisites.
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 all four parameters documented, including an example for the fields object. The description adds minimal parameter meaning beyond the schema (only 'specified fields' echoes the fields parameter), so the 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 clearly states the action (Updates), the resource (existing record in the given table), and the scope (specified fields). This distinguishes it from sibling tools like createAirtableRecord and listAirtableRecords, making the 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?
The description implies usage for modifying an existing record, but it does not explicitly contrast with createAirtableRecord or mention when NOT to use it. No alternatives or prerequisites are given, so the guidance is purely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It accurately conveys a read-only operation by saying 'Fetches' and indicates the return scope ('showing tables and columns'), but it does not discuss potential performance implications, authentication requirements, or whether the output includes detailed column types/relationships.
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 redundant information. Every word contributes to clarifying the tool's purpose and return content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema introspection tool, the description is complete enough. It states what the tool does (fetch schema) and what it returns (tables and columns), leaving no significant gaps for the intended use case.
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 there are no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter information; the schema itself confirms the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Fetches' and clearly identifies the resource as 'the schema of the connected Supabase database', further specifying the content as 'tables and columns'. This distinguishes it from sibling schema tools for other databases like fetchPostgreSQLSchema and fetchNeonSchema by naming Supabase directly.
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 fetchPostgreSQLSchema, fetchNeonSchema, or executeSupabaseSqlQuery. There is no mention of prerequisites, context, or exclusions; the only implicit signal is the read-only verb 'Fetches'.
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 transparency burden. It adds the context that results are scoped to the authenticated user, but does not disclose response format, pagination, or potential side effects. Since it's a read-only list operation, minimal disclosure is acceptable.
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 is front-loaded with the action and resource. It is concise and 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?
For a simple list tool with no parameters, the description provides the core purpose. However, there is no output schema, and the description does not mention what fields are returned or any usage caveats, making it minimally complete rather than comprehensive.
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 input schema is trivially covered. The description does not need to add parameter meaning, and with no params the baseline is 4.
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 retrieves a list of boards for the authenticated Monday user, using a specific verb and resource. It distinguishes from siblings like readMondayBoard by indicating it lists all boards rather than reading a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get the user's boards) and the auth scope is a context clue. However, it does not explicitly mention alternatives for specific board operations or any 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 provided, the description carries the full burden. 'Retrieves' clearly indicates a read-only operation, and listing issue types gives some output context. Yet it omits behavioral details like error handling, permission requirements, or the exact structure of the 'detailed information' beyond issue types, leaving 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, well-structured sentence that front-loads the main action ('Retrieves detailed information about a Jira project') and appends a specific detail ('including all available issue types with their IDs'). No unnecessary words or repetition.
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 one fully described parameter and no output schema. The description gives a general promise of 'detailed information' but only specifies issue types as an example return element. Without an output schema, the agent may be unsure of the full extent of what's returned, though the read-only nature and simple input reduce risk. Additional clarification of the returned fields 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% (the 'projectIdOrKey' parameter is clearly described in the schema). The description adds no new parameter-specific semantics, but it does imply the tool's scope aligns with that parameter. Per the rubric, a score of 3 is baseline for high schema coverage with no additional parameter details.
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 'Retrieves' and clearly identifies the resource as a Jira project, with the added detail of including issue types. This distinguishes it from sibling tools like listJiraProjects (which lists projects) and listJiraIssues (which lists issues), and aligns with the read-only intent of the tool.
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 phrase 'detailed information' implies the tool is for when a user needs in-depth data about a single project, contrasting with list tools that provide summaries. However, it does not explicitly mention when not to use it or name 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It states that the tool creates a draft and optionally supports replies to existing threads, but it does not disclose side effects, return values, authentication requirements, or that the draft is saved to the user's Gmail Drafts folder. This is basic transparency but lacks depth.
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, consisting of two sentences that front-load the core action. It avoids redundancy and clearly communicates the essential information without excess verbiage.
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 schema fully documents all parameters, and the description explains the tool's purpose and reply feature. However, since there is no output schema, the description does not clarify what the tool returns (e.g., a draft ID) or any prerequisites for use. This leaves some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 7 parameters (100% coverage), so the schema already handles parameter semantics well. The description adds minimal extra meaning by mentioning the reply-to-thread capability, but it does not elaborate further. Thus, the 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 clearly states the tool's function with a specific verb ('creates and saves') and resource ('a draft email in the user's Gmail account'). It distinguishes itself from sibling tools like sendGmailEmail by emphasizing the draft aspect and optional reply capability.
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 drafts rather than immediately sending emails ('can be edited and sent later'), which provides context for when to use it. However, it does not explicitly name alternatives or provide exclusions, preventing a score of 5.
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 correctly conveys that the tool mutates labels, but does not disclose details such as idempotency, required permissions, behavior with invalid label IDs, or consequences of calling with no add/remove arrays. The description adds some context about applicable message types but lacks deeper behavioral warnings.
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 only two sentences, front-loaded with the primary action, and contains no redundant information. Every word adds value, making it appropriately concise.
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 straightforward mutation tool with low complexity, the description provides enough context: the action, the resource, and the types of messages it applies to. However, with no output schema and no annotations, it could be more complete by mentioning return values or edge cases (e.g., empty arrays), but given the simplicity, a small gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (messageId, addLabelIds, removeLabelIds). The description adds no additional parameter-level meaning beyond the generic term 'labels', so it does not exceed the baseline expected when schema coverage is high.
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 and resource: 'Adds or removes labels from a Gmail message.' It distinguishes this from sibling Gmail tools like listGmailLabels (listing only) and sendGmailEmail (sending) by focusing specifically on label modification.
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?
Provides clear context on when to use it: 'This can be used to label drafts, sent emails, or any existing message in the user's Gmail account.' It does not explicitly exclude alternatives, but sibling tools like listGmailLabels or sendGmailEmail are clearly different operations, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('Retrieves') and that items are included, but does not mention any other behavioral traits like potential large response sizes or board access restrictions. Adequate but limited.
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?
Single sentence, front-loaded with action and resource, no filler or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no annotations, the description covers the primary purpose and output highlights (items). It could specify what 'detailed information' encompasses beyond items, but it is sufficient for a basic retrieval 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?
Schema has 100% description coverage for boardId ('The ID of the Miro board to retrieve'). The description adds no new parameter meaning beyond what the schema already provides, so baseline 3 applies.
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 ('Retrieves') and clearly identifies the resource ('specific Miro board') and scope ('including its items'). It differentiates from sibling tools like listMiroBoards, which lists boards, and other get tools for different systems.
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?
Implies usage: use when you need detailed info about a specific board by ID, contrasting with listMiroBoards for listing. No explicit exclusion or alternative mention, but the context is clear for a get-by-id tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read-only operation ('retrieves') and scopes to the authenticated user, but does not disclose potential behaviors like whether archived workspaces are included or if results are paginated. Adequate for a simple list 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, well-structured sentence with no extraneous words. It is front-loaded with the action and 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?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete in explaining what it does and its scope. It could mention the return format, but it is not essential for a list-workspaces tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter detail, but none is needed since the schema already covers all (zero) 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 tool retrieves a list of workspaces for the authenticated user from Asana, using a specific verb and resource. It distinguishes itself from siblings like listAsanaProjects by specifying the resource as workspaces.
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 context (when you need the user's workspaces) but provides no explicit guidance on when to use it vs alternatives, no prerequisites, and no exclusions. This is adequate but lacks clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that results are scoped to the authenticated user, which is useful. However, it does not mention pagination, ordering, or that this is a read-only operation (though 'Retrieves' implies safety). It lacks details about potential errors or limits, so transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word contributes meaning, with no redundant phrasing. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description provides enough context: it specifies the resource (Miro boards) and the user scope. It does not explain the structure of each board, but that is typically implied by the service domain. The lack of annotations is partially compensated by the straightforward nature of the operation.
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 schema is empty, so the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description adds no unnecessary detail about inputs.
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 retrieves a list of boards for the authenticated user. The verb 'Retrieves' is specific, and the resource is 'list of boards', which distinguishes it from sibling Miro tools like getMiroBoard (single board) and postMiroNote (creates a note).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'list of boards', but it does not explicitly state when to use this tool versus alternatives like getMiroBoard. There is no mention of scenarios where listing all boards is needed, nor any exclusion of cases where a specific board should be fetched. Usage context is clear but not directly contrasted with siblings.
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 carry the full burden of disclosing behavior. It mentions the scope ('databases the user has access to') and the read-only nature via 'retrieves', but it does not disclose return format, pagination behavior, or any limitations. For a simple list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is directly to the point. It contains no extraneous information and is fully front-loaded, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description provides enough context about the tool's purpose and scope. It could benefit from elaborating on the returned database objects, but the phrase 'list of databases' sufficiently indicates the output nature.
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 schema coverage is trivially 100%. Per the rubric, a tool with 0 parameters gets a baseline of 4 since there is no parameter semantics to clarify.
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 retrieves a list of databases the user has access to in Notion. The verb 'retrieves' and specific resource 'databases' distinguish it from sibling tools like listNotionPages (pages) and queryNotionDatabase (queries a specific database).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it does, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool mentions are provided, leaving the agent to infer from the sibling list of 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?
Without annotations, the description uses 'Retrieves' to signal a read-only operation and notes the authentication requirement. It does not disclose details about return fields, pagination, or access limits, which are relevant for a list 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, front-loaded sentence with no redundant words. It efficiently conveys the operation, resource, and scope.
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 adequately covers its purpose and scope. It could explicitly mention return fields (e.g., channel names and IDs), but it's sufficiently complete for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (zero parameters), so no parameter information is needed. The description's mention of 'public and private channels' clarifies the output scope but not parameters; the baseline of 4 for zero-param tools applies.
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 ('Retrieves a list'), the resource ('public and private channels'), and the scope ('authenticated user's Slack workspace'). It distinguishes itself from siblings like readSlackChannel (which fetches a single channel) and postSlackMessage (which sends messages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case (listing all channels the user can access) but provides no explicit guidance on when to prefer this over readSlackChannel or other list tools. Sibling context shows alternatives, but the description itself doesn't mention them, 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 burden of disclosing behavior. It accurately implies a read-only, non-destructive operation, but does not detail edge cases, return format, or permissions. For a simple read this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It immediately states the action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool, the description conveys the essential purpose and enough context for an agent to select it. However, it does not specify what 'detailed information' includes or describe the response structure, which would be useful given no output schema exists. This minor gap is acceptable for the tool's simplicity.
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 already fully documents the only parameter (taskId) with type and description, giving 100% coverage. The description merely repeats 'by its ID', adding no additional 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 clearly states the verb 'retrieves', the resource 'detailed information about a specific Asana task', and the scope 'by its ID'. This distinguishes it from sibling tools like listAsanaTasks or readAsanaProject, which target different resources or list operations.
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 is used when you have a task ID and need full details, which is clear context. However, it does not explicitly mention when not to use it or contrast with alternatives like searchAsanaTasks or listAsanaTasks, so it lacks explicit exclusion guidance.
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 full responsibility for indicating side effects. The verb 'Retrieves' clearly signals a read-only operation, and the listed return contents add useful behavioral context. However, it does not disclose potential errors, permissions, rate limits, or the exact response structure.
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 leads with the verb and resource, then efficiently lists the key data fields. There is no fluff or redundancy, making it easy for an agent 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?
Given the tool's low complexity (one parameter) and lack of an output schema, the description does a decent job by enumerating expected return contents. Still, the phrase 'related data' is vague, and the description omits any usage context or error/edge-case information, leaving minor 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?
The input schema has 100% coverage for the single parameter issueId with a clear description ('The unique identifier of the Linear issue.'). The tool description does not add any additional parameter meaning, such as the ID format or how to obtain it, but the schema already provides sufficient semantics.
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 'Retrieves' with a clear resource, 'the specified Linear issue', and lists the data returned (assignee, state, labels, comments, related data). This distinguishes it from sibling tools like listLinearIssues and listMyLinearIssues, which return collections rather than a single issue's details.
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 this tool—when you need comprehensive, detailed data for a single issue—but it does not explicitly state when to use it over listLinearIssues or how it relates to other issue tools. There is no exclusion guidance or mention of prerequisites such as needing an issue ID from a list operation.
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 behavioral burden. It discloses that the document is converted from PDF to text, which is a notable behavior, and 'retrieves' implies a read-only operation. However, it lacks details about error handling, size limits, authentication, or the exact text output structure, leaving gaps that a more thorough description could fill.
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 no wasted words. It immediately states the verb ('Retrieves'), the object ('content'), and a key qualifier ('converted from PDF'), making it concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides sufficient context: it specifies what is returned (text), the source conversion step, and the required ID. However, it could be more complete by mentioning potential issues (e.g., unsupported file types, formatting loss) or clarifying the output structure in more detail, but this is a minor gap for such a straightforward operation.
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 describes docId as 'ID of the Office document to read,' and the description reinforces this. With schema coverage at 100%, the description adds minimal new parameter meaning—only 'specific' and the conversion note, which do not substantially change how the parameter should be used. Thus, the 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 a specific action ('Retrieves the content') on a specific resource ('a specific Office document') and includes a distinctive detail ('converted from PDF'). This distinguishes it from sibling tools like listOfficeDocs, searchOfficeDocs, and readGoogleDoc, which manage or retrieve other document types.
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 context is clear: use when you have the docId and need the text content of an Office document. It implies the need for an ID, and the mention of 'converted from PDF' hints at the output format. However, it does not explicitly mention alternatives (e.g., listOfficeDocs to find IDs) or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It adds the thread-reply inclusion and clarifies the read nature ('retrieves'). However, it omits further traits such as pagination, sorting, rate limits, or required permissions. It is a minimal disclosure that provides some value but lacks depth.
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 core action and resource. Every word adds value; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read tool with 100% schema parameter coverage, the description is adequate. It does not explain return format or pagination, but these are somewhat covered by the schema defaults and the tool's purpose. It is complete enough for an agent to invoke correctly in most cases.
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 explains all parameters. The description adds no new parameter-level semantics; it simply restates the 'channel' and 'thread' concepts already present 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 clearly states the tool's function: 'Retrieves conversation history from a specified Slack channel, including thread replies.' It uses a specific verb ('retrieves') and resource ('conversation history'), and the mention of thread replies differentiates it from sibling tools like listSlackChannels and postSlackMessage.
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 needing message history from a channel. It does not explicitly name alternatives or exclusions, but the context is clear enough that an agent would understand this is for reading messages, not for listing channels or posting.
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 full responsibility for behavioral disclosure. It states the tool sends an email (a mutation) and can reply to a thread, which are essential behaviors. However, it does not mention authentication requirements, potential side effects (e.g., sending emails is irreversible), or error handling. The description adds some value but lacks richer behavioral context expected for a mutating tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action ('Sends an email directly...') and then the optional reply capability. No wasted words; every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sends an email, the description covers the core purpose and the main optional behavior (reply). With 100% schema parameter coverage and a straightforward action, the description is mostly complete. It lacks information about return values (no output schema) and error cases, but these are less critical for a send operation. The description could mention prerequisites like Gmail authentication, but overall it is sufficient for the tool's 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 provides 100% coverage with descriptive parameter comments for all 7 parameters, so the description doesn't need to explain them. The description's mention of replying to a thread adds mild context but does not go beyond what the schema already documents for threadId and inReplyTo. Baseline 3 is appropriate since the schema handles parameter semantics thoroughly.
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: 'Sends an email directly through the user's Gmail account.' It also mentions the optional reply-to-thread capability, which differentiates it from sibling tools like saveGmailDraft (which saves rather than sends) and other Gmail read/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool sends an email immediately, versus saving a draft or performing other Gmail operations. It doesn't explicitly name alternatives (e.g., 'use saveGmailDraft to save without sending'), but the phrase 'directly through the user's Gmail account' implies a send action. The reply capability is also mentioned, giving a specific use case.
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 must carry the full transparency burden. It does disclose that the message is sent in the authenticated user's workspace, but it doesn't mention permissions, delivery guarantees, rate limits, or the irreversible nature of posting a message. The basic action is clear, but additional behavioral context is lacking.
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 that states the action, the target, and the scope. Every word earns its place; there is no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description sufficiently covers the core functionality. It names the action, the target (Slack channel), and the authentication scope. The parameter schema handles the rest, so no critical 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 description coverage is 100%, so the description doesn't need to compensate. The description adds only a slight nuance by saying 'text message' which maps to the message parameter, but it doesn't explain anything 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 ('sends') and resource ('text message to a specified Slack channel'), clearly distinguishing it from read-only Slack tools like listSlackChannels and from the sibling postTeamsMessage which targets Teams.
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 establishes clear usage context: use this whenever you need to post a text message to a Slack channel in the authenticated user's workspace. It does not explicitly mention alternatives or exclusions, but the sibling tools (e.g., postTeamsMessage) are implicitly excluded by naming Slack. No prerequisites or when-not scenarios are stated, so it doesn't reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates the operation is a read (retrieves) and mentions system and custom labels, but it does not disclose authentication requirements, rate limits, or detailed return structure.
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 is front-loaded with the action. Every word contributes to understanding, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, list-all tool with no output schema, the description sufficiently conveys the tool's function and result scope. It could mention that returns label objects (e.g., id, name), but that is not critical for an agent to decide when to use it.
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 description adds contextual value by specifying that the list includes system labels like Inbox/Sent/Draft and custom labels. This goes beyond the empty schema, though it does not elaborate on label metadata format.
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 retrieves all labels in the user's Gmail account, with a specific verb ('retrieves') and resource ('labels'). It distinguishes from sibling Gmail tools by focusing on labels rather than threads, messages, or drafts.
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 the tool for listing Gmail labels, but it does not explicitly mention alternatives or when not to use it. The purpose is obvious enough that an agent can infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does disclose the authentication requirement and accessibility constraint, which is useful. However, it does not mention potential pagination, fields returned, or performance characteristics, which could be relevant for a list 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 sentence with no filler or repetition. It is appropriately sized for the tool's simplicity and front-loads the action and 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 no parameters and no output schema. The description covers the core intent and the key constraint. Minor gaps include absence of mention about pagination or the specific project fields returned, but these are not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so there are no parameters to explain. Per rubric, 0 parameters receives a baseline of 4, and the description adds appropriate context about the user's accessible projects.
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 ('Retrieves') and resource ('list of projects... from Jira'), and adds a key scope condition ('accessible to the authenticated user'). It clearly distinguishes from sibling tools like listJiraIssues (issues vs projects) and readJiraProject (list vs single project).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 that it retrieves projects accessible to the authenticated user, implying this is the right tool when you need all projects the user can see. However, it does not explicitly mention alternatives or when not to use it, such as referencing readJiraProject for a single project.
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 does reveal that this is a read-only retrieval and scopes results to the authenticated user's teams. However, it does not mention pagination, ordering, or what fields are returned, which are relevant for agents relying solely on the 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, well-structured sentence that immediately states the action, target, and scope. There is no wasted text or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema), and the description adequately states its purpose and scope. It lacks detail about the returned team structure, but for a straightforward list operation this is acceptable and unlikely to mislead.
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 an empty input schema, so there is no parameter ambiguity to clarify. The description adds nothing about parameters, but none are needed; the baseline of 4 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 action ('Retrieves a list of teams'), the resource ('teams associated with the authenticated user'), and the source ('from Linear'). It is specific enough to distinguish from sibling tools that list projects, issues, or favorites.
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 phrase 'associated with the authenticated user' provides clear context about when to use this tool: to see teams available to the current user. It does not explicitly exclude alternatives or mention when not to use it, but the scope is strong enough for simple list 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. It states the primary behavior ('Opens the WayStation desktop application') but does not disclose prerequisites (e.g., app installed), potential side effects, or error behavior. This is adequate for a trivial action but lacks depth.
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 filler. It front-loads the key trigger and action, making it easy to parse and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, minimal annotations), the description covers all essential information: when to call and what it does. It is complete for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema has no properties. The description adds no parameter-specific meaning, but none is needed. Baseline 4 for 0-param tools is appropriate here.
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 trigger phrase ('when users says 'Open WayStation'') and the action ('Opens the WayStation desktop application'). This is a specific verb+resource pair, and the trigger condition removes any ambiguity about its intended use.
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?
It explicitly says when to call this action: when the user says 'Open WayStation'. It does not mention when-not-to-use or alternatives, but for a simple command-driven tool, the trigger phrase serves as sufficient usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states the tool is 'read-only', which is a critical safety trait, and that it 'returns the results', indicating output behavior. However, it does not mention constraints like query timeouts, result size limits, or how errors are handled, leaving some gaps.
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 14 words, efficiently conveying the tool's purpose, scope, and safety profile. It is front-loaded with the verb and resource, and every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers the core behavior: executing a read-only SQL query and returning results. It does not elaborate on result format or limitations, but given the low complexity, this is acceptable. The read-only qualifier adds important context beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'query' parameter minimally as 'The SQL query to execute.' The description adds semantic meaning by specifying that the query must be 'read-only', which is a crucial constraint not present in the schema. This enriches the parameter understanding beyond the 100% 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 states a specific verb ('Executes'), a specific resource ('SQL query against your Neon database'), and the scope ('read-only'), clearly distinguishing it from sibling tools like executePostgreSQLSqlQuery and executeSupabaseSqlQuery. It also mentions the return behavior, making the tool's 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 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 this tool: for read-only SQL queries against Neon. The 'read-only' qualifier serves as a usage guideline by excluding write queries. However, it does not explicitly name alternative tools or state when NOT to use it (e.g., 'for write operations use X'), but the context is clear enough from the sibling tool names.
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 burden of disclosure. It adds non-obvious details: it retrieves from the user's Drive and orders by last modified date. This provides meaningful context beyond the tool name, though it doesn't mention pagination or that it is read-only, which is implied by 'Retrieves'.
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 resource. Every word adds value, with no redundancy or filler.
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 tool with no parameters, no output schema, and no annotations, the description is sufficiently complete. It specifies the input source ('user's Drive') and behavior (ordering), covering the key context an agent would need. It could potentially note the scope of 'Google Docs' but that is reasonably inferred from the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (no parameters), so the description doesn't need to explain parameters. Schema description coverage is vacuously 100%, and the baseline for zero parameters is 4. The description adds no parameter info because there are none.
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 ('Retrieves'), resource ('Google Docs'), and scope ('from the user's Drive'), along with an ordering detail ('ordered by last modified date'). It clearly distinguishes itself from siblings like readGoogleDoc and listOfficeDocs.
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 tool's purpose is clear enough to imply when to use it: whenever a list of Google Docs is needed. No explicit exclusions or alternatives are mentioned, but for a simple list tool, this is acceptable and the context is unambiguous.
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. The verb 'displays' unambiguously indicates a read-only, side-effect-free behavior, which is transparent for an agent. It doesn't detail what information is shown, but for a welcome message that's not critical; the absence of mutation is clear.
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 concise sentences, front-loading the trigger condition and then stating the action. Every word earns its place; there is no redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema, no annotations—the description fully covers the necessary context. It tells the agent exactly when to invoke it and what it does, making it complete for an AI agent to select and call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information since none exist; the schema confirms this with an empty properties object.
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's purpose: 'displays welcome information about WayStation'. It uses a specific verb ('displays') and identifies the resource (WayStation), and it is distinct from sibling tools which focus on integrations like Miro, Jira, and Slack.
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 gives an explicit trigger condition: 'Call this action when users says 'Hello WayStation''. This is clear context for when to use it, and no alternatives are needed since it's a specialized greeting tool. It doesn't mention exclusions, but for a simple greeting action that's acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It accurately describes the read-only nature and scope of results (only bases the user has access to). It doesn't mention pagination or errors, but for a simple list tool this is adequate.
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 immediately communicates the tool's purpose with no unnecessary 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?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description fully covers what the tool does and its scope. There is no missing information that would impede correct invocation.
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 score is 4. The description adds no parameter information because none exists, and the schema already confirms 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 clearly states the tool's function: 'Returns a list of all Airtable bases the authenticated user has access to.' It specifies a specific verb, resource, and scope, and is easily distinguished from sibling tools like listAirtableTables and listAirtableRecords.
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 for when to use this tool—when you need to list accessible Airtable bases. It does not explicitly mention alternatives or exclusions, but the sibling tool names make usage contexts apparent.
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:

[![mcp-d1839 MCP server](https://glama.ai/mcp/servers/grantanderson603-bit/mcp-d1839/badges/card.svg)](https://glama.ai/mcp/servers/grantanderson603-bit/mcp-d1839)

Score Badge

Copy to your README.md:

[![mcp-d1839 MCP server](https://glama.ai/mcp/servers/grantanderson603-bit/mcp-d1839/badges/score.svg)](https://glama.ai/mcp/servers/grantanderson603-bit/mcp-d1839)

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/grantanderson603-bit/mcp-d1839'

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