WayStation MCP Server

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
Tools are largely distinguishable due to the service prefix in each name (e.g., listNotionPages vs. listMondayBoards). Some subtle overlap exists within a service, such as readAsanaProject returning tasks and listAsanaTasks also returning tasks, but descriptions clarify the differences. Overall, the platform-prefixed naming prevents major confusion.
Naming Consistency4/5
The vast majority of tools follow a consistent verb + Service + Noun pattern (e.g., listNotionPages, createMondayItem, updateAsanaTask). Minor exceptions like recentOfficeDocs (no verb) and helloWayStation/openWayStation (descriptive non-standard) are present but do not significantly disrupt the overall pattern.
Tool Count1/5
With 71 tools, the server has an extreme number of operations, well beyond the recommended upper bound of 25. While the breadth reflects the many integrated services, the sheer count makes tool selection overwhelming for an agent and suggests potential redundancy across similar operations for different platforms.
Completeness3/5
The tool surface provides solid coverage for core workflows across many services: listing, reading, creating, and updating for most integrations. However, notable gaps exist, such as missing delete operations (e.g., no Notion page delete, no Monday item delete, no Asana task delete) and limited actions for some services (e.g., no Slack channel creation, no Gmail search). This makes the surface functional but not fully complete.
Average 3.7/5 across 71 of 71 tools scored. Lowest: 2.9/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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description simply says 'Retrieves a list of issues,' which restates the purpose rather than disclosing behavioral traits. It does not mention whether the list includes all issues, only accessible ones, archived issues, or any default ordering or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the verb and resource, but it is so minimal that it adds little beyond the tool name, making it under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and the presence of a closely related sibling tool (listMyLinearIssues), the description is incomplete. It does not clarify the exact set of issues returned, leaving the agent without enough context to select the tool 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 fully describes the single 'limit' parameter with its default value, achieving 100% description coverage. The description adds no further 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.
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 issues from Linear, providing a specific verb and resource. However, it fails to differentiate from sibling tools like listMyLinearIssues, leaving ambiguity about scope (all issues vs. only the user's issues).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool compared to alternatives such as listMyLinearIssues or readLinearIssue. No exclusions or alternative suggestions are provided, 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.
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 mentions that tasks can be arbitrary JSON objects, which hints at the return format, but it fails to disclose pagination, potential large result sets, response structure, or any other behavioral traits. This is minimal information for a read tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no redundant filler. Every word adds value, and it is appropriately sized for a simple single-parameter 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?
For a read tool with no output schema and no annotations, the description should explain the return format or behavior. It only vaguely says tasks are arbitrary JSON objects, without details on pagination, response envelope, or how to handle multiple tasks. Given the sibling tool context, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (projectId has a clear description). The tool description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate. The parameter itself is straightforward and well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all tasks from a specified Asana project, using a specific verb ('Retrieves') and resource ('all tasks from the specified Asana project'). This distinguishes it from readAsanaTask (which retrieves a single task), but it does not explicitly differentiate from listAsanaTasks, another sibling that likely lists tasks.
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 implies usage when you need all tasks from a project, but provides no explicit guidance on when to use this tool versus alternatives like listAsanaTasks or readAsanaTask. No exclusions, prerequisites, or alternative pointers 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?
There are no annotations, so the description bears full responsibility for disclosing behavior. It misleadingly states that filtering by completion status is optional, but no such parameter exists, and workspace is required rather than optional. It also doesn't mention return values or side effects. This erroneous information undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no redundant phrasing. It could be slightly improved by removing the inaccurate filter list, but the length and structure are appropriate.
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 search tool with no output schema, the description should cover what results look like, any pagination or limits, and any behavioral nuances. It does none of that, and the filter inaccuracy adds confusion. Given the tool's complexity (3 params, no output schema), the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters thoroughly (100% coverage), so the description adds little value. Worse, it introduces a non-existent 'completion status' filter and refers to workspace as optional when it is required, which could confuse an AI agent. Therefore it doesn't meaningfully enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for tasks in Asana, which is a specific verb+resource. It also lists optional filters, but the mention of 'completion status' is inaccurate since no such parameter exists in the schema, and 'workspace' is actually required. This minor inaccuracy prevents a 5, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to find tasks by a search term, with optional filters. However, it provides no explicit guidance on when to choose this over listAsanaTasks or other task-related tools, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the action without mentioning side effects, required parent resources, default states, authorization needs, or what happens on success/failure. It adds no behavioral context 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 concise sentence that states the core action 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema or annotations, the description provides only a one-sentence overview. It lacks context about return values, prerequisites (e.g., teamId must exist), priority semantics, or typical usage flow. Schema parameter descriptions help but do not compensate for the absence of usage and outcome guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description's phrase 'specified details' adds no new parameter meaning; it merely references the parameters already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new issue in Linear', using a specific verb and resource. It distinguishes itself from siblings like createLinearComment and updateLinearIssue by indicating it creates a new issue.
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, e.g., when to prefer creating an issue over updating one, or that you should first call listLinearTeams to obtain a teamId. There is no mention of 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Retrieves a list of issues,' which implicitly indicates a read operation, but does not disclose pagination behavior, maxResults limits, authentication requirements, error handling, or any side effects. This is insufficient for a tool with no annotation 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 16-word sentence that front-loads the core action and resource. It contains no filler or redundant information, fitting the conciseness ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description is too sparse. It omits the return format (fields like key, summary, status), ordering, pagination behavior, and error semantics. For a list tool with this complexity, the description should provide more operational context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (jql and maxResults) with high coverage (100%). The description adds marginal context by mentioning 'from a Jira project or using a JQL query,' but this could confuse users because there is no project parameter in the schema. It does not significantly augment the schema's parameter information.
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 identifies the resource as 'a list of issues from a Jira project or using a JQL query.' This clearly distinguishes it from sibling tools like readJiraProject (which reads a single project) and createJiraIssue (which creates issues). The two modes (project or JQL) add clarity.
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 listJiraProjects or readJiraProject. It implies usage for retrieving issues but does not mention exclusions, preconditions, or trade-offs. It also fails to clarify that a 'project' filter is achieved through JQL rather than a dedicated parameter, which is a missed opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral transparency. It implies a read-only operation via 'Retrieves', but it does not disclose any potential side effects, authentication requirements, pagination, or data scope limitations. The phrase 'associated with the authenticated user' hints at auth context but is insufficient.
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 key action and resource. It is concise 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?
With no parameters, annotations, or output schema, the description is the sole source of context. It explains the basic purpose but lacks details about the return format (e.g., board IDs, names), pagination, or any limitations. Given the simplicity of a zero-parameter read tool, this is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the baseline for 0 params is 4. The description does not need to add parameter-level detail, but the phrase 'associated with the authenticated user' adds implicit context about how the tool uses authentication.
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 ('Retrieves') and the resource ('a list of boards') along with the context ('associated with the authenticated user from Monday'). However, it does not explicitly distinguish itself from the sibling tool 'readMondayBoard', which would be useful for clarity.
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. With many sibling tools (e.g., readMondayBoard, listNotionPages), the description lacks any mention of selection criteria, exclusions, or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are present, the description carries the full burden of behavioral disclosure. It only states 'updates' without explaining partial update semantics, error behavior, permissions, or return value. It doesn't even clarify whether only provided fields are changed.
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 conveys the action and target, making it highly 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?
Given the complexity of 6 parameters, no annotations, and no output schema, the description is too thin. It omits key context like partial updates, invalid issue key handling, and response details, leaving substantial gaps for the 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?
Schema description coverage is 100%, with each of the 6 parameters internally documented. The description adds no extra parameter meaning, but the schema already handles param semantics, so this is a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'existing issue in Jira', which distinguishes it from createJiraIssue (creating) and addJiraComment (commenting). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It doesn't state that it only works on existing issues (precluding creation) or mention any prerequisites. The description is purely action-based with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'with the specified changes' which hints at partial updates, but does not explain potential side effects, permissions required, or whether some fields are immutable. The behavior beyond the obvious update is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is front-loaded with the action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain what the function returns, how errors are surfaced, or how partial updates interact with missing fields, leaving a significant information gap for the 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics; it merely refers to 'specified changes' which is already implied by the optional fields in the schema. No value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'existing issue in Linear', making the tool's purpose unambiguous. It distinguishes itself from sibling tools by explicitly scoping to Linear issues, contrasting with update tools for other platforms like Monday or Asana.
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 scenarios such as creating new issues with createLinearIssue or reading before updating, leaving the agent without context for selecting this tool.
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 full behavioral disclosure. It merely states the tool creates a task but does not mention side effects (e.g., permanent record creation), required permissions, error conditions, or return values. This is a significant gap for a mutation tool with zero annotation coverage.
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 aptly sized sentence that front-loads the key verb and resource, then lists optional details without unnecessary wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, a nested custom_fields object, no output schema, and no annotations, the description needs to clarify required fields and expected results. It omits that projectId and name are required, misrepresents custom_fields as optional, and does not describe the response, making it insufficient for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description actively misleads by labeling custom_fields as optional when the schema requires it. This contradicts the schema and adds no beneficial meaning beyond the field names 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 'Creates a new task in the specified Asana project' with a specific verb and resource, distinguishing it from sibling tools like updateAsanaTask and createAsanaComment. It also lists optional details (description, due date, assignee, custom fields) that add granularity beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool's use case (creating a task) but offers no explicit 'when to use' vs alternatives, such as naming updateAsanaTask for updates. There are no exclusions or comparative guidance with sibling tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'creates,' implying a write operation, but fails to mention any side effects, auth requirements, reversibility, or response details. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no redundant words, making it efficient and front-loaded. However, it is minimal to the point of vagueness, which slightly detracts from its usefulness, so it earns a 4 rather than 5.
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 4 parameters (including a parentType enum), no annotations, and no output schema, the description is too sparse. It does not explain the page vs database parent distinction, the optional content parameter, or what success looks like. This makes it incomplete for an agent operating in a large tool ecosystem.
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?
All parameters are already described in the input schema (100% coverage), so the description does not need to explain them. The phrase 'with specified content' adds no new meaning beyond the schema. Baseline 3 is appropriate given 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 clearly states the action (creates), the resource (a new page in Notion), and the content aspect. This distinguishes it from sibling tools like listNotionPages, readNotionPage, and createNotionComment. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating Notion pages but provides no explicit when-to-use context or mention of alternatives. It does not state when not to use it or point to other tools for read/list operations, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Retrieves' indicates a read-only operation, but it does not disclose behaviors like pagination, response structure, or whether filters are optional. It adds some transparency but misses several behavioral details.
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 of 13 words that is front-loaded and free of fluff. Every word contributes to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with complete schema documentation, the description is adequate but leaves gaps: it does not state the default behavior when no filters are provided, whether results are paginated, or what the return format looks like. No output schema exists, so the description could have provided more 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 covers 100% of parameters with meaningful descriptions, so baseline is 3. The description mentions the three filter criteria (project, assignee, completion) which align with schema properties, but adds no extra semantic beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves'), the resource ('tasks from Asana'), and the filtering dimensions ('project, assignee, and completion status'). It distinguishes itself from single-task tools like readAsanaTask, though it does not explicitly differentiate from searchAsanaTasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs. alternatives. The description implies usage for filtered task lists, but it does not mention searchAsanaTasks or other siblings, nor does it provide 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 provided, the description carries the full burden of behavioral disclosure. It does disclose the sorting behavior (ordered by last modified date) and scope (from OneDrive, optionally within a folder). However, it omits details such as pagination, required permissions, or the structure of returned items, which are relevant for a list operation without an 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, concise sentence that immediately states the action and resource. It contains no redundant or irrelevant information, earning a perfect score for conciseness and structure.
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, but the absence of an output schema and the presence of closely related siblings (searchOfficeDocs, recentOfficeDocs) create gaps. The description covers the core purpose but does not explain what fields are returned or how this listing differs from related tools, making it adequate yet incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description covers the only parameter (folderId) with 100% coverage, including the behavior when not provided. The description adds no additional parameter semantics, 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.
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 Office documents and folders from OneDrive, with a specific ordering by last modified date. It does not explicitly distinguish itself from siblings like searchOfficeDocs or recentOfficeDocs, but the verb 'retrieves a list' and the resource are specific enough.
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 searchOfficeDocs or recentOfficeDocs. It does not mention any exclusions or specific scenarios, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It implies a read-only operation via 'Retrieves' and mentions the authenticated user, but does not disclose potential behaviors like pagination, empty results, or errors, nor state explicitly that it causes no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is front-loaded with the action and resource. It contains no redundant information or filler, making it concise and easily scannable.
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 tool with no output schema, the description adequately covers the main context: what is retrieved and from where. It could add details about the format of the returned list, but given the simplicity, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per baseline, a score of 4 is appropriate because parameter semantics are vacuous and the description need not add parameter details. The description effectively communicates the tool's purpose without needing parameter explanations.
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 ('Retrieves a list') and the resource ('teams and channels from the authenticated user's Microsoft Teams workspace'), distinguishing it from sibling tools like postTeamsMessage. However, it does not specify whether the result is a flat list or nested channels, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as listSlackChannels or postTeamsMessage. The description only states what it does without specifying use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'converted from PDF' which adds some context, but it does not state whether the operation is read-only, has side effects, or any limitations such as content truncation or format fidelity. The description lacks essential behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action. It contains no redundant information and earns its place with the specific detail about PDF conversion.
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 one parameter and no output schema, the description covers the basic purpose and return format ('as text'). However, it lacks context on when to use the tool, and the PDF conversion detail raises questions about input format and output fidelity without clarification. It is minimally complete but has clear 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 schema already provides a description for docId ('ID of the Office document to read') with 100% coverage. The tool description adds no new parameter-specific semantics beyond what the schema gives, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 content from a specific Office document as text, with a specific verb and resource. It distinguishes itself from sibling tools like listOfficeDocs and searchOfficeDocs by focusing on a specific document's content, and from readGoogleDoc by explicitly targeting Office documents.
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. It does not mention prerequisites (e.g., obtaining a docId from listOfficeDocs) or exclusions. The usage is only implied through the phrase 'specific Office document', which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the creation action without mentioning permissions, side effects, error conditions, or return behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no filler. It is appropriately sized 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 is a mutation with no annotations and no output schema, yet the description provides minimal context—only the basic creation action. It lacks information about prerequisites, effects, or return behavior. While the schema covers parameters, the overall description is insufficient for a complete agent decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with descriptions, including an example for the 'fields' object. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('creates a new record') and the resource ('record in the given table'), which distinguishes it from sibling tools like updateAirtableRecord and listAirtableRecords. The verb is specific and the scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'creates' implies when to use the tool (creating new records), but it provides no explicit guidance on alternatives or exclusions. Sibling tools like updateAirtableRecord are not mentioned, so the agent must infer from the name and the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool updates tasks, but does not mention permissions, reversibility, partial update semantics, side effects, or error behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, listing the key updateable aspects 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a relatively rich schema with nested objects and 7 parameters, the description does not explain crucial context such as partial update behavior, how to unassign, or the structure of custom_fields. It is under-specified for an update operation, leaving the agent to infer important usage semantics.
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 every parameter with descriptions. The description adds only a high-level list of updateable fields, providing marginal value beyond the schema. It does not clarify syntax or edge cases not already 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 updates an existing Asana task, listing the specific fields it can modify. This distinguishes it from sibling tools like createAsanaTask, readAsanaTask, and listAsanaTasks.
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 tasks, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The context from the name and siblings makes it somewhat clear, but the description itself does not articulate this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does and mentions the 'existing' issue precondition, but it does not disclose permissions required, side effects (e.g., whether a notification is sent), or any other behavioral traits beyond the obvious write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It immediately conveys the action and target, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter write tool, the description is minimally adequate, but it lacks usage guidance and behavioral context (e.g., return behavior or prerequisite permissions). Since there is no output schema, the description could have provided more context, but the simplicity of the operation prevents a lower score.
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% and both parameters include meaningful descriptions. The tool description adds no parameter-specific information, but the schema already documents the parameters effectively, 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 uses a specific verb ('Adds') and resource ('new comment to an existing Jira issue'), clearly distinguishing it from sibling tools like createJiraIssue or updateJiraIssue. It precisely states the tool's scope without ambiguity.
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 usage—when you need to comment on a Jira issue—but provides no explicit guidance on when to use it versus alternatives or any exclusions. There are no sibling Jira comment tools, but the absence of explicit context keeps this at baseline.
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 convey behavioral traits. It only states that a new issue is created, but omits side effects, authentication requirements, return values, or error behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the verb and resource, with no filler or redundant information. It is well-front-loaded and appropriately sized.
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 documents all parameters, but the description lacks any mention of return values or error handling. With no output schema, this gap is noticeable though not critical for basic selection and 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 schema covers all 6 parameters with descriptions (100% coverage), so the description's phrase 'with the provided details' adds no additional parameter-level meaning. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates), the object (a new issue), and the destination (specific Jira project). It distinguishes itself from sibling tools like updateJiraIssue and addJiraComment by focusing on creation.
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 use case via the verb 'creates' but does not explicitly state when to use this tool vs alternatives, nor does it mention any prerequisites or exclusions. No alternative tools are referenced.
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 does not disclose permissions, irreversibility, rate limits, or response behavior. The only added behavior context is the column_values format, which is parameter semantics rather than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose. No unnecessary words or repetition; each sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 4 parameters, all fully described in the schema. However, with no output schema and no annotations, the description omits expected response details and any prerequisites or side effects, leaving some contextual gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3. The description adds a note about the column_values format ('should follow the format { "column_id": "value" }'), but this overlaps with the schema's example, offering marginal extra 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 'Creates a new item in the specified Monday board and group' with a specific verb+resource. It distinguishes from siblings like updateMondayItem (updating) and createMondayUpdate (adding updates/comments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb 'creates' but no explicit guidance is given about when to use this tool versus alternatives like updateMondayItem. It does not mention exclusions or suitable contexts beyond the 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 carries the full burden. It mentions 'Creates' (implying a write) but does not disclose any side effects, authentication requirements, rate limits, or error behavior. It also doesn't clarify whether the call returns the created update or anything about the underlying API. 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?
A single sentence with no filler. It front-loads the verb and object, includes the optional parent_id context, and stops there. Perfectly concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 3 parameters and no output schema. The description clearly states what it does and the optional threading parameter, which is enough for a basic create operation. However, it omits any information about return values, error cases, or required permissions, which would be helpful for a complete understanding. It is minimally 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 schema already describes all three parameters with 100% coverage. The description adds minimal value beyond the schema, only restating that parent_id is for threaded replies (already in the schema description). Since schema coverage is high, a baseline of 3 is appropriate; the description does not go 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 action ('Creates'), the resource ('new update (comment)'), and the target ('specified Monday.com item'). It also mentions optional threading behavior, distinguishing it from createMondayItem/updateMondayItem. The parenthetical '(comment)' disambiguates Monday's domain-specific term 'update'.
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 add a comment/update to a Monday.com item, with optional threading. However, it does not explicitly state when not to use it or contrast with alternatives like updateMondayItem (which edits an existing item rather than adding a comment). There is no mention that this is for creating a new comment, not for general item creation.
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 must fully disclose behavior. It mentions the action and output but does not state whether the operation is read-only, whether it requires special permissions, or what specific schema objects are included (e.g., views, indexes, all schemas). This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately front-loaded with the verb and object, making it easy to scan.
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 zero-parameter tool, the definition is fairly complete, but it lacks details about the return structure beyond 'tables and columns', and there is no output schema to clarify. It may leave the agent uncertain about whether other database objects are included.
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 correctly does not address parameters. The baseline for zero-parameter tools is 4, and the description adds no confusion or unnecessary parameter detail.
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 a clear resource 'schema of the connected PostgreSQL database'. It distinguishes itself from sibling schema tools like fetchSupabaseSchema and fetchNeonSchema by specifying the generic PostgreSQL database, and from executePostgreSQLSqlQuery by focusing on schema rather than arbitrary SQL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as fetchSupabaseSchema or fetchNeonSchema, or whether to use executePostgreSQLSqlQuery instead. The description only states what it does, not when to prefer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Returns a list' without disclosing side effects, permissions, or error behavior. Although the operation appears read-only, the description does not explicitly state this or any constraints.
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, no filler, front-loaded with the action. It is appropriately 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 one-parameter list tool with no output schema, the description is adequate but leaves unspecified the return format (just 'all tables') and any pagination or size limits. With no annotations, more detail would help.
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 baseId description 'ID of the Airtable base to list tables from'. The description adds minimal value beyond the schema, merely reinforcing the base reference.
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 resource ('tables in the specified Airtable base'), clearly distinguishing from sibling tools like listAirtableBases and listAirtableRecords. It precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the tool lists tables from a base, but does not provide explicit when-to-use guidance or mention alternatives such as listAirtableBases for listing bases or listAirtableRecords for records. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('Retrieves') without revealing whether it is purely read-only, what data is returned (e.g., thread summaries vs. full content), pagination behavior, or default exclusions like spam/trash. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy or filler. Every word contributes to clearly stating the tool's function.
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 no output schema, the description explains the return type as 'list of email threads/conversations' but lacks details about thread content, pagination, or default filtering behavior. The input schema covers parameters well, but the overall description is adequate yet not fully complete for a tool with no structured return specification.
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 additional parameter semantics beyond the schema; all parameters are already well-documented with descriptions and defaults.
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 resource ('email threads/conversations from the user's Gmail account'), clearly distinguishing it from sibling tools like readGmailThread or sendGmailEmail. The scope and optional filtering are also present.
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 and filtering threads but provides no explicit guidance on when to prefer this tool over alternatives like readGmailThread or listGmailLabels. No exclusions or when-not situations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Retrieves a list', which implies a read operation, but it does not disclose pagination, sorting, filtering, authentication needs, or the structure of the returned data. This is a minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple with no parameters and no output schema. The description covers the basic purpose, but it omits details about the returned list's format or any potential limitations. Given the lack of annotations and output schema, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter-specific meaning because there is nothing to document.
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 sibling tools like readLinearProject (single project) and listLinearIssues (issues) by explicitly naming the resource as 'projects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it lists all projects, nor does it contrast with readLinearProject for retrieving a single project or listLinearIssues for issues. The agent must 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 for behavioral disclosure. It only says 'Retrieves the content,' which implies read-only but does not state whether the operation is safe, what happens on errors, whether it behaves differently for different formats, or any other behavioral traits. No side effects or constraints are disclosed.
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 adds value; it is not over-specified or verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema covers parameters, but there is no output schema, so the description should ideally clarify what 'content' means or what return value to expect. The description gives only a high-level overview and does not mention return structure or edge cases, leaving some gaps for a tool without annotations or 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?
The input schema already describes both parameters comprehensively (100% coverage), so the baseline is 3. The description adds a minor hint that the output format is controlled by the 'format' parameter ('in the specified format'), but it does not provide additional meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves the content') and the resource ('a Notion page'), and mentions the format parameter, distinguishing it from sibling tools like listNotionPages and queryNotionDatabase. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading a single page's content but does not explicitly state when to use this over alternatives, nor does it provide exclusions or mention of sibling tools. No guidance on when to choose this tool over listNotionPages or queryNotionDatabase is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states that the tool 'retrieves' data. It does not explain what 'recent' means, how results are ordered, any limits on the list size, or whether any authentication or permissions are required. This is minimal and leaves significant uncertainty.
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, compact sentence with no redundant words. It front-loads the action ('Retrieves') and resource, making it quick to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for basic invocation but leaves gaps: no definition of 'recently used,' no mention of result count or ordering, and no output schema to clarify the return format. Given the simplicity of the tool, this is a middle-ground score.
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 100% (empty schema). Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter information, but none 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 the specific verb 'Retrieves' and identifies a distinct resource: 'list of recently used Office documents by the user.' The term 'recently used' differentiates it from sibling tools like listOfficeDocs or searchOfficeDocs, making the 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 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. There is no context about typical use cases or exclusions, leaving the agent to infer when 'recent' is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose all behavioral traits. It only states the search purpose, but fails to mention whether it searches content/metadata, whether results are paginated, return format, or any limitations. Minimal transparency for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the key action and resource. Every word is necessary; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, yet the description lacks essential context such as what 'Office documents' includes, the type of match (content vs. filename), and what the return value looks like. Competes with many sibling tools but provides only minimal differentiation.
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 description's 'query string' aligns with the 'query' parameter, but it adds no new semantics beyond the schema definition. 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 verb ('Searches'), resource ('Office documents'), and scope ('matching a specific query string'). It distinguishes from sibling tools like 'listOfficeDocs' and 'recentOfficeDocs' by focusing on search functionality.
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 finding Office documents via a query, but does not explicitly state when to prefer it over alternatives like 'listOfficeDocs' or 'readOfficeDoc'. No exclusions or conditions 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 bears full responsibility for behavioral disclosure. It offers no information about what happens if the record does not exist, whether it performs a partial or full update, required permissions, or the return value. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded, with no redundant phrases. Every word contributes to conveying the core action.
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 update tool, the description and schema together provide the essential information to invoke the tool correctly. However, the absence of an output schema and annotations, plus the lack of any behavioral details (e.g., partial update semantics, error handling), leaves some gaps. It is minimally viable but not rich in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all parameters are well-documented with descriptions. The description adds no additional meaning beyond the schema; it merely restates 'specified fields' which the schema already explains with an example. Baseline 3 applies because the schema covers parameter 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 a specific verb ('Updates') and resource ('existing record in the given table'), clearly distinguishing it from sibling tools like createAirtableRecord (create vs update) and listAirtableRecords (list vs update). It precisely conveys 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 usage context is implied rather than explicit: 'Updates ... existing record' suggests use when modifying an existing record, but no alternatives or exclusions are mentioned. Sibling tools like createAirtableRecord are not referenced, so the agent must infer the appropriate choice.
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. The verb 'fetches' implies a read-only operation, but it does not explicitly state non-destructive behavior or any access/rate-limit considerations. It provides basic context but leaves room for assumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words and effectively communicates the tool's purpose.
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 no parameters, no output schema, and simple read-only behavior, the description is complete enough. It covers what the tool does and what it returns (tables and columns).
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 description coverage is 100% (trivially). Per baseline for 0 params, this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the schema of the connected Supabase database and shows tables and columns. It is specific to Supabase, but does not explicitly distinguish it from sibling tools like fetchPostgreSQLSchema or fetchNeonSchema.
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 alternative schema-fetching tools or query execution tools. No when/when-not criteria or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavioral traits. It only states the action ('Adds') and the content/position, but doesn't mention permissions, reversibility, return value, or error handling. For a mutation tool, this is insufficient, so score 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?
A single, well-structured sentence that front-loads the action and includes the essential details (content and position). No wasted words, so score 5.
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 creation tool with no output schema and full parameter coverage, the description covers the primary behavior. However, it omits return value or side effects, and with no annotations, it's slightly incomplete. Given the simplicity, it's reasonably complete but not fully, so score 4.
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?
All five parameters are described in the schema with 100% coverage. The description adds minimal extra meaning beyond the schema, merely restating 'content' and 'position'. 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 ('Adds') and clearly identifies the resource ('a new sticky note') and target ('a Miro board'). It distinguishes itself from sibling tools like listMiroBoards and getMiroBoard by clearly indicating a create operation on a note, so score 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 when creating a sticky note but provides no explicit guidance on when to use this tool over alternatives, nor prerequisites like needing a valid boardId. It doesn't state exclusions or mention other Miro operations, so it gets a 3 for implied 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 carries the full burden. It discloses that the tool is a read operation ('Retrieves') and that output is plain text, which is useful. However, it does not mention access requirements (e.g., doc must be shared) or error conditions, 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 core purpose. There is no redundant or extraneous information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description adequately explains the purpose and the output format, which is sufficient for most cases. However, it could mention the need for the doc to be accessible to the tool, which is a common pitfall. Overall, it is nearly complete for a straightforward read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter docId with a clear description. The tool description does not add any additional parameter-level detail beyond the word 'specific', which is already implied by the schema. Baseline of 3 is appropriate since the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieves' and the resource 'content of a specific Google Doc', with a specific output format 'as plain text'. This distinguishes it from sibling tools like listGoogleDocs (which lists docs) and readOfficeDoc (which reads a different service).
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, nor does it mention prerequisites like needing the document to be shared with the service account. It does not differentiate from other read tools for different services, so the agent is left to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only restates the core action and mentions optional reply capability, but does not disclose consequences like the email being immediately sent and irreversible, nor any permission or failure handling. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences, with the core purpose front-loaded. Every sentence adds relevant information, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description is too brief. It omits important operational details such as whether the email is sent immediately, that the action is irreversible, and what a successful send returns. These gaps could lead to misuse or confusion.
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 covers all 7 parameters with descriptions, so baseline is 3. The description adds value by explaining that threadId/inReplyTo enable replying to an existing thread, which is not fully captured by the parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an email via the user's Gmail account, using the specific verb 'Sends' and resource 'email'. It distinguishes itself from potential siblings like saveGmailDraft by emphasizing 'directly' sending rather than drafting.
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 sending emails, but does not explicitly state when to use this tool versus alternatives such as saveGmailDraft, which is a notable sibling for drafts. It does provide context for replies via threadId, but no exclusions or alternative 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 provided, the description carries the full burden of behavioral disclosure. It states the action (adds/removes labels) but does not disclose important traits such as reversibility, permission requirements, idempotency, or what happens on invalid input. As a mutation tool, this lack of safety or side-effect information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and immediately followed by useful context. Every word 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 tool is simple with well-documented parameters, but the description omits any mention of return values, prerequisites (e.g., label IDs must come from listGmailLabels), or behavior when both add and remove are specified. It is adequate for basic usage but not fully complete given the lack of an output schema and 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 schema covers 100% of the parameters with descriptions. The tool description adds no additional meaning beyond what the schema already provides—it simply restates the add/remove concept without explaining parameter relationships or edge cases. Baseline 3 is appropriate because 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 clearly states the tool's function with a specific verb and resource: 'Adds or removes labels from a Gmail message.' It also narrows the scope by mentioning drafts, sent emails, or any existing message, which distinguishes it from sibling tools like sendGmailEmail or listGmailThreads.
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 on when to use this tool: 'This can be used to label drafts, sent emails, or any existing message in the user's Gmail account.' It does not explicitly mention alternatives or exclusions, but the context is sufficient for a simple label-modification operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action (create) and the 'story' terminology, but fails to mention any side effects, return values, permissions, or idempotency. This is a minimal disclosure 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. It front-loads the action and resource, includes the helpful Asana-specific clarification '(story)', and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with complete parameter documentation, but the lack of annotations and output schema means the description should explain more about what the user can expect. It does not mention return values or any behavioral constraints, leaving some gaps, but it is adequate for a straightforward create-comment 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 covers 100% of parameters with clear descriptions for both taskId and text. The tool description adds no additional semantic insight beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (creates), the resource (a comment/story), and the target (specified Asana task). It distinguishes the tool from sibling comment tools by explicitly naming Asana, making its purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for adding comments to Asana tasks. It does not explicitly mention alternatives or exclusions, but the platform-specific wording implies when to use it, earning a 4 rather than 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 burden. It discloses that filtering and pagination are optional, which is useful, but it doesn't mention that the operation is read-only (though 'retrieves' implies it), nor does it specify default behavior, return format, or rate limits. It adds some context beyond the schema but not extensive.
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 11-word sentence, front-loaded with the action and resource. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no annotations, and no output schema. The description covers the core purpose and notes optional filtering/pagination, but it doesn't describe the response format or provide guidance on pagination workflow (e.g., using offset from previous response). The schema covers parameters, but the description is thin on behavioral/return details, so it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already described. The description's mention of 'optional filtering and pagination' loosely maps to filterByFormula, pageSize, offset, and sort but doesn't explain syntax or interaction. 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?
Description uses specific verb 'retrieves' and resource 'records from the specified table', clearly distinguishing it from sibling tools like createAirtableRecord and listAirtableTables. It also mentions optional filtering and pagination, adding operational detail.
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 for retrieving records but provides no explicit guidance on when to choose it over alternatives (e.g., create/update). It doesn't mention exclusions or alternatives, so an agent must infer usage from the purpose.
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. Beyond stating that it retrieves issues, it offers no additional context about pagination, ordering, status filters, or whether the operation is read-only. The description is a bare factual statement without extra behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action and resource. It contains no redundant information or fluff, earning full marks 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?
The tool is relatively simple with one optional parameter and no output schema, but the lack of annotations places more burden on the description. It does not clarify whether the list includes all issue statuses, how pagination works beyond 'limit', or what fields are returned. While the description is adequate for a basic list tool, it leaves some gaps for a fully self-contained explanation.
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 covers the only parameter 'limit' with a clear description and default value (100% coverage). The tool description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves a list of issues'), the resource ('issues'), and the scope ('assigned to the authenticated user'), which distinguishes it from the generic 'listLinearIssues' sibling. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 (when you need issues assigned to the current user) and inherently differentiates it from listLinearIssues by explicitly mentioning the 'authenticated user' filter. However, it does not explicitly state exclusions or name alternatives, so it falls 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 carries the full burden of behavioral disclosure. The verb 'Retrieves' implies a read-only operation, and 'databases the user has access to' scopes the result set. However, it does not disclose pagination behavior, rate limits, or whether the list includes database objects or just names—common traits for a list endpoint. The description is minimally adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Retrieves a list of databases') and immediately scopes it ('the user has access to in Notion'). Every word contributes value; there is no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 params, no output schema), the description is mostly sufficient. However, it lacks any mention of alternatives or use cases, and does not describe the return format (e.g., database names, IDs). For a list tool in a large sibling family, this creates ambiguity in tool selection and expectation setting.
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 fully defines invocation requirements. The description correctly implies no arguments are needed. With 0 parameters, the baseline is 4, and the description adds no conflicting or missing information.
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 identifies the resource as 'databases the user has access to in Notion', clearly distinguishing it from sibling tools like listNotionPages and queryNotionDatabase. The scope ('the user has access to') adds 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 this tool versus alternatives. The description doesn't mention that listNotionPages is for pages, queryNotionDatabase is for querying a specific database, or that this is the first step in discovering available databases. The agent must infer usage solely from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation with 'retrieves', but with no annotations, it carries the full burden. It does not disclose whether archived channels are included, whether only channels the user belongs to are returned, or any pagination/rate-limit behavior. The workspace scoping is helpful but incomplete.
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 front-loaded with the action ('Retrieves') and includes all necessary information. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description should explain what the returned list contains (e.g., channel names/IDs). It only says 'a list of channels', which is somewhat vague. For a simple tool, this is adequate but not fully 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?
There are zero parameters, so the description need not explain parameter details. It appropriately avoids describing non-existent parameters, and the baseline of 4 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 a list of public and private Slack channels for the authenticated user's workspace. This distinguishes it from siblings like readSlackChannel (single channel) and postSlackMessage (posting), and specifies the resource (channels) and action (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as readSlackChannel for a specific channel or listTeamsChannels for Microsoft Teams. There are no exclusions or explicit 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, the description carries the full burden of behavioral disclosure. It adds context about the output being 'readable' and 'stripped of unnecessary metadata', but it does not mention error handling, authentication requirements, attachment handling (despite an includeAttachments parameter), or any other behavioral traits. It is minimally transparent 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 immediately states the core action and value. No wasted words, and it is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description partially explains the return format ('readable message content') but omits details about attachments, error cases, or response structure. It is adequate for a simple read tool but not fully 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?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, not even mentioning the includeAttachments parameter. 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') with a clear resource ('complete email thread/conversation') and adds scope ('readable message content, stripped of unnecessary metadata'). This clearly distinguishes it from sibling tools like listGmailThreads (which lists threads) and 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 usage for reading a specific thread, but it does not explicitly state when to use this tool versus alternatives like listGmailThreads. There is no mention of exclusions or alternative tools, leaving the agent to infer the appropriate context from the name and sibling tool names.
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 disclosure. It clearly indicates a read operation (retrieves) and specifies what is returned (metadata and all issues), but it does not disclose potential response size, pagination behavior, or ordering. Given the simplicity of the tool, this is adequate but not extensive.
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 tool's purpose without any wasted words. It is perfectly concise and well-structured for its simple scope.
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 one parameter and no output schema, the description provides a high-level summary but lacks details on the response structure of the issues, possible pagination, or any limitations. An agent selecting this tool would benefit from more context about the exact shape of the returned data or potential performance implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters, with projectId described as 'The unique identifier of the Linear project.' The description adds no additional meaning beyond this, and with such high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves project metadata and all issues from a specified Linear project. The verb 'retrieves' plus the resource 'Linear project' is specific, and it distinguishes itself from siblings like readLinearIssue (single issue) and listLinearProjects (list projects) by describing the combined scope of metadata plus all 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 project metadata and all issues together. However, it does not explicitly state when to use this over alternatives such as listLinearIssues or readLinearIssue, nor does it mention any exclusions or conditions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It discloses that the search covers pages, databases, and content, which is useful context. However, it does not mention any limitations, authentication requirements, or result format details. The description provides basic transparency but lacks deeper behavioral insights.
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 efficiently communicates the core purpose. It is front-loaded with the main action and resource. There is no redundant or extraneous information, making it an model of 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?
Given the simple tool design with 3 parameters and no output schema, the description is minimally sufficient. It does not explain return values or pagination, but it does hint at the content types returned. However, for a search tool, users might benefit from knowing result limits or search scope details. Overall, 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 schema description coverage is 100%, with each parameter (query, sort, filter) having a clear description. The tool description does not add any additional parameter semantics beyond what the schema already provides. Per the rubric, a baseline of 3 is appropriate when the schema handles 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 clearly states the tool's function: searching across a Notion workspace for pages, databases, and content. It uses a specific verb ('searches') and resource ('Notion workspace'), and the scope is well-defined. This distinguishes it from sibling tools like listNotionPages and listNotionDatabases, which are listing operations.
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 user needs to search across Notion, but it does not explicitly mention when to use this tool versus alternatives. No exclusions or alternative tool references are provided. The guidance is implicit rather than explicit, which is adequate but not standout.
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 comment is created, without disclosing prerequisites (e.g., issue must exist), permissions, response details, or side effects. This is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the verb and target with no filler or redundant information. 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 two-parameter create operation with no output schema and no nested objects, the description provides the core action and context adequately. It lacks behavioral specifics, but the operation is straightforward enough that the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'body' and 'issueId' explicitly described (including markdown support for body). The tool description adds no additional parameter semantics, 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 ('Creates') and resource ('new comment on an existing issue in Linear'), making the action unambiguous. It also distinguishes itself from sibling comment tools for other platforms (e.g., createNotionComment, addJiraComment) by naming Linear as the target system.
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 'on an existing issue in Linear' clearly indicates the intended use case: commenting on an existing Linear issue. It does not explicitly mention when not to use it or list alternatives, but the context is clear enough for an agent to select this tool over comment tools for other platforms.
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 behavioral disclosure. It clearly states the action (adding a comment) and the content type (plain text), which implies a write operation. However, it does not mention permissions, error behavior, or whether the comment is returned.
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 immediately informative and free of waste.
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 two fully described parameters and a clear action, the description is adequately complete. However, since there is no output schema, it does not disclose the return value or side effects beyond the action itself, which is 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 schema covers 100% of parameters with descriptions ('Text content of the comment' and 'ID of the page to comment on'). The description adds only the 'plain text' qualifier, which slightly enriches the text parameter but does not substantially exceed the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adds') and a clear resource ('a plain text comment to a Notion page'), making it unambiguous. It distinguishes from sibling comment tools (e.g., addJiraComment, createLinearComment) by naming Notion as the target.
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 does not explicitly state when to choose this over alternatives, nor does it mention any prerequisites or exclusions. Sibling tools like createNotionPage are not referenced for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It indicates a read-only operation ('Retrieves') but does not mention pagination, result ordering, or whether favorites are returned as a combined array or separate structures. For a tool with no annotation support, this leaves significant 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, well-structured sentence with no redundant words. It is front-loaded and immediately states the core function.
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 simplicity of the tool (no parameters, no output schema), the description conveys what is returned (a list of favorite projects and issues) and the intended user scope. It could be slightly more explicit about the return format, but for a basic list retrieval, this is 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 an empty input schema, so the baseline is 4. The description adds no parameter-specific semantics because none exist, but it does clarify the scope (favorites for the authenticated user) through its text, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieves') and names the exact resource ('favorite projects and issues from Linear for the authenticated user'), clearly distinguishing it from sibling tools that list all projects or issues. It is unambiguous and action-oriented.
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 favorites are needed (as opposed to all issues or projects), but it does not explicitly state when to use this tool versus alternatives like listLinearProjects or listMyLinearIssues. There is no exclusionary guidance or named alternatives, so the context is clear but not deeply instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds context about the source (user's Drive) and ordering (last modified), but lacks details on return format, pagination, or explicit read-only status. The verb 'Retrieves' implies a safe read, but it is not stated.
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 action, and contains no redundant information. It is concise and well-structured.
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 parameterless list tool, the description covers the key aspects: what it lists, from where, and the ordering. However, it does not describe the returned data structure or pagination behavior, which would be useful given the absence of an output 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 tool has zero parameters, so there is nothing to document. The description appropriately says nothing about parameters, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of Google Docs from the user's Drive and orders them by last modified date. This distinguishes it from siblings like readGoogleDoc (single document) and listOfficeDocs (different app).
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 vs alternatives. While the name and description imply it is for Google Docs, there is no mention of when not to use it or which sibling to prefer (e.g., readGoogleDoc for content).
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 carries the full burden. It discloses that this is a read operation ('Retrieves') and restricts scope to pages the user has access to, but it does not disclose output format, pagination, sorting, or whether it includes archived pages or page content. This leaves some behavioral aspects unknown.
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 action 'Retrieves' followed by the resource. Every word contributes, with no 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?
With no output schema and no annotations, the description must explain what the list returns, but it only says 'a list of pages.' It does not clarify whether the response contains page IDs, titles, metadata, or full content, which is a notable gap for a tool with no structured output definition. Given the low complexity, some additional detail about return format would be needed for full 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 no parameters, and schema coverage is 100% (empty schema). The description adds no parameter-specific information, which is appropriate since none exist; the baseline for zero parameters 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 uses the specific verb 'Retrieves' with the resource 'a list of pages the user has access to in Notion,' which clearly states the tool's function. It distinguishes from sibling tools like listNotionDatabases (different resource) and searchNotion (search vs. list) by specifying it directly lists pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like searchNotion or readNotionPage. The intended use is implied by the phrasing 'pages the user has access to,' but no exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It accurately indicates a read operation via 'Retrieves', but it does not mention behavior such as error handling, required permissions, or return format details beyond 'detailed information'. 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, focused sentence of 12 words with no redundant content. It is front-loaded with the core action and target resource, 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?
The tool has low complexity (1 required parameter, no nested objects, no output schema). The description clearly states the operation and input, and the sibling context makes its role obvious. The only gap is that 'detailed information' is vague without an output schema, but for a simple read-by-ID tool, this is largely 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?
Schema coverage is 100% with taskId described as 'The unique identifier of the Asana task.' The description's phrase 'by its ID' adds no additional meaning beyond the schema definition. This meets the baseline 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 ('Retrieves') and resource ('detailed information about a specific Asana task'), clearly distinguishing it from sibling tools like listAsanaTasks, searchAsanaTasks, and createAsanaTask. The mention of 'by its ID' further clarifies the exact scope.
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 specific task ID is known, but it does not explicitly state when to use this tool over alternatives such as listAsanaTasks or searchAsanaTasks. There are no exclusions or alternative tool references, making the guidance somewhat 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. The verb 'Retrieves' clearly indicates a read-only operation with no side effects, which is sufficient for a simple retrieval. However, it does not disclose error behavior (e.g., invalid issue ID) or any potential limits on returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and resource. It efficiently lists key data points without unnecessary detail, earning its place with zero waste.
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 low complexity (one parameter, no output schema), the description gives a reasonable overview of what the tool returns by enumerating key fields. It lacks specifics on pagination or exact structure, but this is acceptable 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?
The schema provides a clear description for issueId with 100% coverage. The tool description adds minimal extra meaning beyond rephrasing 'from the specified Linear issue.' No additional format or example is given, so it meets the baseline but does not exceed 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 action (Retrieves), the resource (Linear issue), and the scope (specified issue). It lists the specific data fields (assignee, state, labels, comments, related data), which differentiates it from sibling tools like listLinearIssues or readLinearProject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need comprehensive details of a single Linear issue. However, it does not explicitly state when to use it over alternatives, such as listLinearIssues for lists or readLinearProject for project-level details.
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. It explicitly states 'read-only', which is a key behavioral trait and sufficient for the agent to understand there are no write side effects. However, it does not disclose other behaviors like query result formatting, limits, or error handling, so it is not exhaustive but still valuable.
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 one clear, front-loaded sentence of about 15 words. Every word is purposeful, stating the action, the read-only scope, the target database, and the output. There is 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?
The tool has low complexity (1 param, simple read-only query), and the description provides the essential purpose. However, there is no output schema, and the description does not detail the result format or specify when to use this vs. sibling SQL executors. It is adequate but has clear gaps in guidance and result semantics.
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: the single 'query' parameter is described as 'The SQL query to execute.' The tool description adds no additional meaning or syntax details beyond this, 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 uses a specific verb ('Executes') and identifies the target resource ('Neon database') with a clear scope ('read-only SQL query'). It distinguishes itself from sibling tools like executePostgreSQLSqlQuery and fetchNeonSchema by naming the database type and read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for read-only SQL queries against Neon, but it does not explicitly state when to use it over alternatives (e.g., executePostgreSQLSqlQuery for other Postgres databases, fetchNeonSchema for schema discovery) or provide any exclusions. Usage context is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. 'Retrieves and filters' clearly indicates a read-only operation, which is a key behavioral trait. However, it does not disclose other aspects like pagination behavior, authentication requirements, or how filters are processed. For a read tool, the core safety message is conveyed, but depth is 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?
The description is a single concise sentence with no fluff or redundancy. It front-loads the core action and resource, making it immediately scannable.
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 4 well-documented parameters and no output schema, so the description does not need to explain return values. However, it lacks explicit guidance on when to prefer this over sibling tools (e.g., searchNotion for global search, listNotionPages for listing pages). The description is adequate for a simple query tool 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?
Schema description coverage is 100% (all parameters have descriptions), so the baseline is 3. The description merely summarizes the tool's overall function and does not add extra meaning to individual parameters 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 specific verbs 'Retrieves and filters' with a clear resource ('items from a specified Notion database'), making its purpose unambiguous. It distinguishes itself from siblings like listNotionPages (lists pages) and readNotionPage (reads a single page) by focusing on database-level queries with filtering.
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 clear usage context: when you need to query a Notion database with filtering and sorting. However, it does not explicitly name alternatives or state when not to use this tool, even though siblings like searchNotion and listNotionDatabases exist. This provides context but lacks explicit 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 must convey the tool's behavior. It explains the core action (creating a draft that can be edited later) and the reply option, but lacks details on authentication, permissions, rate limits, or what the response contains. The behavior is adequately described for basic use but lacks deeper 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 two sentences long, front-loads the verb and resource, and avoids unnecessary elaboration. Every phrase adds value, and the optional reply behavior is stated succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is moderately complete. It covers the main purpose and the reply option, but omits the return format (e.g., draft ID), any prerequisites, and does not address possible side effects beyond saving a draft. It is adequate but leaves operational details unclear.
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%, and parameter descriptions in the schema are already detailed (e.g., threadId explains automatic Message-ID fetching). The tool description adds no additional parameter-level meaning beyond referring to the reply-to-thread capability, which is already reflected 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 verb ('Creates and saves') and resource ('a draft email in the user's Gmail account'), distinguishing it from the sibling tool sendGmailEmail by emphasizing the draft can be 'edited and sent later.' The optional reply-to-thread capability is also clearly mentioned.
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 appropriate use for saving drafts rather than sending immediately, and mentions the optional reply-to-thread context. However, it does not explicitly name sendGmailEmail as the alternative for immediate sending, nor does it state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states 'read-only', which is a critical non-mutation guarantee, and mentions that it returns results. However, it does not disclose error behavior, query limits, or supported SQL dialect, leaving some behavioral aspects unspecified.
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 immediately states the action and key constraint ('read-only'), making it maximally concise and well-structured.
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 with one simple string parameter and no output schema, the description provides the essential context: read-only behavior, target database (PostgreSQL), and that results are returned. It lacks details on query restrictions or result format, but given the tool's minimal complexity, the description covers the core usage needs adequately.
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 for the single parameter 'query', describing it as 'The SQL query to execute.' The description adds context by indicating the query is read-only and targets PostgreSQL, but it does not add syntax details, examples, or any semantics beyond what the schema already states. This matches the baseline 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 clearly states the tool's function: 'Executes a read-only SQL query against your PostgreSQL database and returns the results.' It uses a specific verb ('Executes') and resource ('your PostgreSQL database'), and distinguishes from sibling tools like executeSupabaseSqlQuery and executeNeonSqlQuery by explicitly naming PostgreSQL.
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 this tool: for read-only SQL queries against a PostgreSQL database. It provides clear context that differentiates it from database-specific siblings, though it does not explicitly name alternatives or state exclusion criteria. This aligns with 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying safety. The verb 'fetches' implies a read-only operation, and 'showing tables and columns' indicates the output. However, it does not explicitly state that the operation is non-destructive, does not require specific permissions, or describe any side effects, though these are unlikely for a schema fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Fetches the schema') and provides relevant specifics without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters, the description adequately conveys the tool's purpose and output. However, it does not describe the exact return format or mention any limitations (e.g., which schema is inspected), though this may not be critical given the tool's simplicity.
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 no parameters, so the description doesn't need to explain any. The input schema is empty, and the description's mention of 'tables and columns' provides context for what the schema output contains, but no parameter details 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 fetches the schema of the connected Neon database and explicitly mentions the output (tables and columns). This distinguishes it from sibling tools like fetchPostgreSQLSchema and fetchSupabaseSchema by specifying the Neon context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching schemas from a Neon database, but it does not provide explicit guidance on when to choose this over alternative schema-fetching tools (e.g., fetchPostgreSQLSchema) or mention exclusions. The usage context is clear but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is read-only ('retrieves') and that the response includes items, but it does not detail the return format, pagination, or any access requirements. This is acceptable for a simple read tool 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, well-structured sentence that front-loads the action and resource. Every word contributes value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation with no output schema, the description provides sufficient context by stating what is returned ('detailed information including items'). It could be more explicit about what 'detailed information' entails, but the low complexity reduces the need for further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters, so the baseline is 3. The description adds no additional meaning about boardId beyond what the schema already states, and the schema's description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieves' and the resource 'specific Miro board', while the inclusion of 'including its items' adds specificity. It distinguishes itself from sibling tools like listMiroBoards, which lists boards, and postMiroNote, which writes notes.
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 retrieving a single, specific board, which provides clear context for when to use it versus listing or creating. However, it does not explicitly name alternatives or state exclusions, 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, the description carries the burden of behavioral disclosure. It transparently states the scope ("all") and access requirement ("authenticated user has access to"). However, it omits details about return format, pagination, or empty-result behavior, leaving some aspects opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the action and resource, and every word contributes to clarity.
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, parameterless list tool, the description is adequate and explicitly states the return value and access scope. It could be enhanced by mentioning the data structure (e.g., base IDs and names), but the absence of an output schema makes the current description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4 per the evaluation rules. The description adds no parameter details because there are none to document.
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 a list" and clearly identifies the resource "all Airtable bases the authenticated user has access to." This distinguishes it from sibling tools like listAirtableTables and listAirtableRecords by specifying the base-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description's statement of what it returns, but no explicit guidance is provided about when to use this tool versus alternatives or any prerequisites beyond authentication. It doesn't name alternatives or exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read-only operation ('Retrieves') but does not disclose details like pagination, ordering, authentication needs, or error behavior. This is adequate for a simple list tool but leaves some behavioral aspects unstated.
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 13-word sentence that is direct and front-loaded with the core action and resource. Every word earns its place, and it avoids 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 list tool with one required parameter and no output schema, the description covers the essential context: what it retrieves and the workspace scope. It could mention pagination or return format, but given the low complexity, it is sufficiently complete for an agent to select and 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 schema already documents workspaceId fully with 100% coverage, and the description merely references 'the specified Asana workspace' without adding new meaning. It meets the baseline but does not enrich the parameter understanding.
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 a list of projects associated with the specified Asana workspace.' This uses a specific verb ('Retrieves') and resource ('list of projects'), and distinguishes it from sibling tools like listAsanaTasks and readAsanaProject by focusing on projects within a workspace.
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: it is used to list projects in an Asana workspace. However, it does not explicitly mention alternatives or exclusions, such as using readAsanaProject for a single project or that it does not return tasks. The context is clear but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope (all labels, system and custom) but does not mention any authorization requirements, rate limits, or return format details beyond 'list of labels.' For a read-only 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, front-loaded sentence that immediately states the action and resource. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description adequately conveys the function and scope. It could mention that label IDs are returned for use in other Gmail operations, but this is not essential. Overall, it is complete for the complexity level.
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 100% (empty). The description adds no parameter-specific information, but none is needed. According to the rubric, a baseline of 4 applies for zero-parameter tools.
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 identifies the resource as 'all labels in the user's Gmail account,' clearly distinguishing it from sibling Gmail tools that operate on threads, drafts, or messages. It also mentions the inclusion of both system and custom labels, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like listGmailThreads or applyGmailMessageLabels. However, it is implied by the name and description that this is the tool for label listing, though no exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a read (retrieves) and scoped to the user's access, but does not mention pagination, ordering, or return structure. This is adequate for a simple list tool 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?
Single sentence, directly states the function without any extraneous words. It is 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?
Given zero parameters and no output schema, the description covers the core purpose and scope. It is sufficient for an agent to understand what the tool does, though it could mention return format or pagination, which is not critical for an empty-schema list 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 semantics, but none are needed since there is no schema to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (retrieves), resource (list of projects), and scope (accessible to the authenticated user) from Jira. This distinguishes it from sibling tools like listJiraIssues and readJiraProject.
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 fetching Jira projects but does not explicitly mention alternatives or when not to use it. It provides clear context about user access scope, but lacks explicit exclusions or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read-only operation via 'Retrieves' and specifies the user association, which is useful. However, it does not disclose other behavioral traits like pagination, response format, or potential rate limits. For a simple list tool, the minimal info is adequate but not comprehensive.
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 front-loaded with the action verb and directly states the resource and scope. There is zero fluff or redundancy, making it highly concise and well-structured.
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 0-parameter tool with no output schema, the description provides the essential purpose and scope. It mentions the authenticated user context and Miro source, making it complete enough for a basic list operation. It could mention return value details, but these are largely inferable 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 has zero properties, and the description has no parameters to explain. Per the rubric, 0 params earns a baseline of 4. The description does not need to add parameter semantics 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 uses a specific verb ('Retrieves') and clearly identifies the resource ('list of boards') with a source ('from Miro') and scope ('associated with the authenticated user'). This distinguishes it from sibling tools like listMondayBoards and getMiroBoard.
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 list of the user's Miro boards is needed, but it does not explicitly mention when to use this tool versus alternatives (e.g., getMiroBoard for a single board). The context is clear but without exclusions or alternative guidance, it stops at an implied level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Opens the WayStation desktop application' without mentioning prerequisites, side effects, failure modes, or what happens if the app is already running. This is minimal information and leaves potential behavior unaddressed.
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 very concise, with just two short sentences. The first gives the usage trigger, the second states the core action. There is zero filler, and every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple zero-parameter tool with no output schema, the description is mostly complete for its purpose. It identifies the trigger and the action. However, it could be slightly more complete by noting e.g., that the app will be opened locally or that no output is returned, but the current level is adequate for the tool's simplicity.
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 100% (vacuously). Since there are no parameters to explain, the description adds no parameter-specific meaning, but it also doesn't need to. The baseline for 0-parameter tools is 4, and the description is consistent with that.
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 exactly what the tool does: 'Opens the WayStation desktop application.' It uses a specific verb and resource, and the trigger phrase ('when users says Open WayStation') distinguishes it clearly from sibling tools like 'helloWayStation' and the many integration 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 explicitly states when to call the tool: when the user says 'Open WayStation'. This provides clear usage context. However, it does not explicitly mention when not to use it or point to alternatives, which keeps it a notch below a perfect score.
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 clarifies that the message is sent within the authenticated user's workspace, which is useful context. However, it does not disclose side effects (e.g., message appears as the user), permission requirements, or what the tool returns after sending, 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 sentence of 14 words that clearly and directly states the tool's behavior. There is no redundant or extraneous information, and it is appropriately front-loaded with the action.
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 (2 required params, no output schema, no annotations), the description is nearly complete. It explains the action and the workspace context. It could mention return values or error handling, but for a straightforward send-message tool, this is sufficient 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 provides 100% description coverage for both parameters, including notes about the '#' prefix for channel and the message text. The description does not add significant semantic meaning beyond the schema, 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 uses the specific verb 'Sends' with a clear object: 'a text message to a specified Slack channel.' This unambiguously states the tool's function and differentiates it from sibling tools like listSlackChannels (reading channels) and postTeamsMessage (posting to Microsoft 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 provides clear context for when to use the tool: when you need to send a message to a Slack channel. It does not explicitly mention when not to use it or alternatives, but the scope is obvious from the wording, so it earns a 4 rather than 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 burden. It clearly states the primary behavior (sending a message) but does not disclose any additional behavioral traits such as potential side effects, permissions, or message formatting. This is adequate for a simple messaging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. Every word earns its place, with no unnecessary detail.
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 three fully documented parameters and no output schema, the description is sufficient. It covers the purpose and required parameters, though it could optionally mention that the message is plain text or provide guidance on getting team/channel IDs, but these are not essential.
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 each parameter already described in the schema. The tool description adds no additional parameter semantics beyond the phrase 'specified Microsoft Teams channel', so it meets the baseline but does not enhance understanding.
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) and the specific resource (text message to a Microsoft Teams channel). It is unambiguous and distinguishes itself from sibling tools like postSlackMessage by explicitly naming 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 implies the tool is used when you need to post a message to a Microsoft Teams channel. There are no exclusions or alternative recommendations, but the context is clear enough given the tool name and description.
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 the return content (detailed info, issue types with IDs) but does not mention authentication requirements, potential errors, or explicit read-only behavior. The verb 'Retrieves' implies a safe read, but that is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the action ('Retrieves') and resource ('Jira project'), and 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 read tool with one parameter and no output schema, the description adequately conveys the purpose and key output. However, 'detailed information' is somewhat vague and does not enumerate the fields returned, but given the simplicity, it 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 fully documents the single parameter (projectIdOrKey) with an example, so the schema description coverage is 100%. The tool description adds no additional parameter semantics 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 the specific verb 'Retrieves' and identifies the resource as 'a Jira project' with the added detail 'including all available issue types with their IDs.' This clearly distinguishes it from sibling tools like listJiraProjects and listJiraIssues by highlighting the unique return of issue 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 description implies when to use this tool: when you need detailed project information including issue types. However, it does not explicitly compare to alternatives like listJiraProjects or mention when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It states the read-only nature and thread inclusion, but it does not disclose details like message ordering, pagination behavior, or authentication requirements. It is adequate for a simple read operation but not richly 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, tightly worded sentence that front-loads the primary action and resource. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with all parameters documented in the schema, this description is mostly complete. It captures the core purpose and thread behavior, but since there is no output schema, a bit more detail on return format could be helpful; still, the tool is straightforward enough that the description suffices.
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 minimal semantic value beyond saying 'including thread replies,' which aligns with the includeThreads parameter but does not explain parameter usage 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 a specific verb ('Retrieves') and resource ('conversation history from a specified Slack channel'), clearly distinguishing it from sibling tools like listSlackChannels (lists channels) and postSlackMessage (writes messages). The mention of thread replies further clarifies the scope.
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: this tool is for reading conversation history from a Slack channel, including thread replies. However, it does not explicitly state when to use it instead of alternatives or mention any exclusions, though the sibling context makes the use case fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the update requires column_values in a specific format and implies partial updates by saying 'updated field(s)'. However, it does not mention permissions, reversibility, or what happens to unspecified columns. It adds some useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and each sentence adds value—the second clarifies the critical column_values format. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation with no output schema, the description covers the core usage and the format for column_values. It lacks details like return values or error behavior, but it's adequately complete for an agent to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with examples, so the description adds little. It reiterates that column_values is required and should use the specified format, but this is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: updating an existing item in a Monday board. The verb 'Updates' and object 'existing item' distinguish it from createMondayItem and createMondayUpdate.
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 'existing item' implies the user must have an item_id, which gives some context. However, it does not explicitly state when to use this tool over alternatives like createMondayItem, nor does it provide exclusions. Still, the context is clear enough for an agent to identify the appropriate 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, the description bears full responsibility for behavioral disclosure. The verb 'retrieves' implies a read-only operation, but it doesn't mention whether there are any side effects, pagination behavior, or rate limits. For a simple list operation this is adequate but minimal, similar to the TDQS 4.3 example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 12 words, front-loading the core action and resource. Every word adds value, 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?
The tool is very simple: no parameters and no output schema. The description explains the core function and scope adequately. It could optionally mention the return format (e.g., workspace IDs and names), but this is 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 tool has zero parameters, so the input schema already fully covers the parameter space. The description provides no parameter-specific details, but none are needed. This aligns with the baseline score of 4 for tools with no params.
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 ('a list of workspaces'), the source ('from Asana'), and the scope ('associated with the authenticated user'). This distinguishes it from sibling tools like listAsanaProjects or listAsanaTasks, which target different resources.
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: use this tool to get workspaces for the authenticated Asana user. It doesn't explicitly state when not to use it or name alternatives, but the resource type itself naturally separates it from other list tools. This meets the 'clear context, no exclusions' bar.
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 disclosing behavior. 'Retrieves' clearly indicates a read-only operation, and saying 'all items' plus 'arbitrary JSON objects' gives a sense of the return payload. It does not discuss error conditions or rate limits, but for a simple read operation 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?
Two concise sentences, no filler. The main action and the key detail about output format are front-loaded, making the description easy to scan.
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 has one simple parameter and no output schema. The description covers what the tool does and hints at return format ('arbitrary JSON objects'). It does not explicitly state that the result is a list, but 'all items' implies a collection. Overall, sufficient 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?
Schema description coverage is 100%, with boardId described as 'The unique identifier of the Monday board.' The tool description adds no new information about the parameter but is not required to, given the schema already provides sufficient semantics. 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 the specific verb 'Retrieves' and clearly identifies the resource as 'all items from the specified Monday board'. This distinguishes it from sibling tool listMondayBoards, which lists boards, not items. The added note that items are arbitrary JSON objects further clarifies scope.
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 'specified Monday board' implies the need for a boardId and indicates this tool is for reading items from a known board. It does not explicitly compare against alternatives like listMondayBoards or createMondayItem, but the context is clear enough for an agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds the scoping detail 'associated with the authenticated user,' but does not disclose behaviors like pagination, sorting, or potential empty results. For a simple read-only retrieval, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb 'Retrieves' and resource 'teams,' with no unnecessary words. It is optimally concise and structured.
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 list tool with no output schema, the description sufficiently conveys the operation's purpose and scope. The return of a list of teams is self-evident, and the description is complete for its simplicity.
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, and schema description coverage is trivially 100%. The description adds context about the authenticated user scope, which is useful. Baseline 4 is appropriate for zero-parameter tools.
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 'Retrieves a list of teams associated with the authenticated user from Linear,' using a specific verb and resource. It distinguishes itself from sibling tools like listLinearProjects and listLinearIssues by focusing on 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 provides clear context by indicating the auth scope ('associated with the authenticated user'), which tells the agent when this tool is applicable. It does not explicitly list alternatives, but no other sibling tool lists teams, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the transparency burden. It discloses the critical read-only behavior, preventing accidental mutations, and states that results are returned. It does not mention permissions, limits, or error behavior, but for a simple query tool the core safety trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no redundant words. Every word ('read-only', 'Supabase', 'returns results') adds value.
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-only query tool, the description provides adequate context: target database, read-only behavior, and return value. It doesn't detail output structure, but no output schema is provided and the behavior is straightforward. It could have mentioned differences from other SQL execution tools, but the core completeness is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the query parameter simply as 'The SQL query to execute.' The description adds essential restriction that it must be a read-only SQL query and that it targets Supabase, giving the parameter meaningful constraints beyond the schema. With 100% schema coverage, baseline is 3; the added read-only semantics justify a 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 executes a read-only SQL query against Supabase and returns results. It distinguishes from sibling tools like fetchSupabaseSchema (schema retrieval) and executePostgreSQLSqlQuery (different database) by specifying the target database and read-only nature.
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 that this is for read-only queries on Supabase, implying it should not be used for write operations or for other database types. However, it does not explicitly name alternatives like executeNeonSqlQuery or executePostgreSQLSqlQuery, so it lacks the strongest 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?
No annotations are present, but the description carries the safety burden by using 'Retrieves' to indicate a read-only operation and by noting the authenticated-user and all-workspace scope. It does not mention pagination or empty-result behavior, which is a minor gap for a simple list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly worded sentence gets straight to the point: the action, the resource, and the scope. No filler, front-loaded with the verb and object.
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 parameterless retrieval tool with no output schema, the description adequately explains what is returned (a list of favorite projects/tasks), the scope (all workspaces), and the auth context. It does not detail item structure, but that is acceptable given its simplicity.
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 has nothing to add beyond the schema. With 100% coverage and no params, baseline 4 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 a list') and resource ('favorite projects and tasks ... from Asana'), with a clear scope ('all workspaces' and 'authenticated user'). This clearly differentiates it from sibling tools like listAsanaProjects and listAsanaTasks, which cover non-favorite items.
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 wording implies when to use this tool: when the user wants aggregated favorites across all Asana workspaces. It does not explicitly state exclusions or alternatives, but the scope statement provides clear context for choosing this over project- or task-specific list tools.
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. It clearly states the behavior (displays welcome information) and implies no side effects. It doesn't specify exact content of the welcome message but that's acceptable for such a simple action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the trigger condition and outcome. No fluff 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 trivial no-parameter, no-output tool, the description is fully complete: it gives the trigger, the action, and the purpose. Nothing else is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameters to explain, and the description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: 'displays welcome information about WayStation to the user'. The trigger phrase 'when users says Hello WayStation' differentiates it from siblings like 'openWayStation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states exactly when to invoke: 'Call this action when users says Hello WayStation'. No alternatives are needed since this is a unique greeting/welcome action.
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-0b583 MCP server](https://glama.ai/mcp/servers/grantanderson603-bit/mcp-0b583/badges/card.svg)](https://glama.ai/mcp/servers/grantanderson603-bit/mcp-0b583)

Score Badge

Copy to your README.md:

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

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-0b583'

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