Autotask MCP Server

Server Quality Checklist

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

Latest release: v2.18.0
Disambiguation4/5
Most tools have distinct purposes (create vs. search vs. get vs. update), but there is some overlap between 'get' and 'search' tools (e.g., get_quote vs. search_quotes) and among delete tools for different entities. The descriptions clarify usage, though the sheer number could cause confusion.
Naming Consistency5/5
All tools follow a consistent 'autotask_verb_noun' pattern (e.g., autotask_create_ticket, autotask_search_companies, autotask_get_quote). Verbs are standard CRUD terms plus search/list/get/execute/router. No mixing of conventions.
Tool Count3/5
90 tools is very high for a single server. While Autotask is a large domain covering many entities, this count feels excessive and likely includes many variants (e.g., three service call delete tools). It would benefit from consolidation or categorization.
Completeness4/5
The tool surface covers most major Autotask entities (companies, contacts, tickets, projects, quotes, expenses, service calls) with create, read, update, delete and search. Minor gaps: no delete for companies, contacts, or projects; no update for contacts. Overall well-rounded for the domain.
Average 3.5/5 across 90 of 90 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Create' implying a write operation, but does not disclose any side effects, authorization requirements, or constraints beyond the input schema. Missing 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence), but arguably too brief for a tool with 7 parameters and no annotations. It could add value without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is insufficient. It does not explain return values, required permissions, or relationship with other quote-related tools. 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 coverage is 100%, so the schema already documents all parameters. The description adds no parameter-specific meaning beyond the schema, which is acceptable per guidelines, but remains a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new quote' is clear and uses a specific verb+resource, but it does not distinguish from sibling tools like 'autotask_create_quote_item'. The name and description together make the purpose reasonably clear.
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 'autotask_create_quote_item' or 'autotask_update_quote'. The description lacks context on prerequisites or typical use cases.
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 does not mention whether this is a read-only operation, rate limits, or pagination behavior (pageSize parameter hints at pagination but not explicitly). The description is too minimal to compensate for missing annotations.
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. It uses front-loaded structure with the key verb and resource. However, it could be more informative without sacrificing conciseness (e.g., mentioning pagination or sorting).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with no required fields, no output schema, and no annotations, the description should provide more context about return format, result set behavior, and interaction with other tools. The minimal description is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. No parameters have enums or nested objects, so the schema is straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Search for opportunities with optional filters,' which identifies the verb/resource. However, it lacks specificity about the scope or behavior (e.g., pagination, result set size) and does not differentiate from sibling search tools like autotask_search_projects or autotask_search_tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other search tools (e.g., autotask_search_companies). There is no mention of prerequisites, performance considerations, or specific use cases. The description implies that all filters are optional, but does not explain when each filter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as pagination behavior, default sorting, or whether the search is case-sensitive. The agent is left to infer from schema defaults like pageSize.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and directly states the tool's purpose. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters and no output schema, the description should clarify search behavior, result ordering, or how multiple filters combine. It lacks these details, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no extra semantics beyond 'optional filters', which is already implied by the schema having no required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for quotes with optional filters', which is a clear purpose. However, it does not distinguish this tool from its sibling 'autotask_get_quote' which retrieves a single quote, but the description lacks that differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives like 'autotask_get_quote' for a specific quote or 'autotask_search_quote_items'. It only says 'with optional filters', but no context on typical use cases.
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 fully carries the burden of disclosing behavior. It only says 'optional filters' but does not explain that no filters return all active services, or how pagination works or if results are limited. The description lacks transparency on default behavior and edge cases.
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 concise at 5 words and front-loaded with 'Search for services'. However, it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description should provide more context about return structure (list of service objects), default active filter, and pagination behavior. It is insufficient for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description 'Search for services with optional filters' mirrors the schema's parameter descriptions (e.g., 'Search term for service name', 'Filter by active status') without adding new meaning. It does not clarify that 'isActive' defaults to true or the order of results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for services with optional filters', which clearly identifies the verb (search) and resource (services). However, it does not differentiate this tool from sibling search tools like autotask_search_service_bundles, autotask_search_service_calls, etc., leading to potential confusion.
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. There is no mention of prerequisites, context, or when not to use it, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as required permissions, whether the description supports HTML or plain text, or what happens on duplicate titles. Lacks details beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but lacks additional context. It could be expanded slightly to include usage guidance or behavioral details without being overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It does not specify what the response contains (e.g., the created note ID) or potential required fields (e.g., actionType is optional but not explained).
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%, but the description adds no extra meaning beyond the parameter names. The schema already describes each parameter, so description adds marginal value.
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 'Create a new note for a company,' which is a specific verb+resource pair. It distinguishes from sibling tools like autotask_get_company_note and autotask_search_company_notes 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 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 like creating a ticket note or project note. No when-not or prerequisites 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 provided, so description must carry behavioral information. It does not disclose whether the tool creates a project and automatically triggers workflows, emits notifications, or requires specific permissions. The description is too brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short (one sentence), but it is complete in conveying the basic purpose. However, it lacks any structural elements like bullet points or examples that could improve usability.
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 9 parameters, no output schema, and no annotations, the description is incomplete. It does not clarify required vs optional parameters beyond what the schema already states, or explain return values or validation rules.
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 meaning beyond the schema fields; it simply repeats the schema's parameter descriptions without enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create a new project') and the system ('Autotask'). It clearly distinguishes from sibling create tools like 'autotask_create_ticket' and 'autotask_create_task', but does not differentiate within the project suite (e.g., 'autotask_create_project_note').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as 'autotask_update_project' for existing projects or 'autotask_create_phase' for sub-projects. No prerequisites or context 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 provided, so description carries full burden. It states 'Create' implying mutation, but gives no details on permissions, side effects (e.g., triggering notifications), or return behavior. Lacks 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks any structure or additional context. It does the minimum but could be expanded slightly without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return value. It does not. Plus, many optional parameters (9 total) with no guidance on defaults or relations (e.g., startDateTime vs endDateTime dependencies).
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 baseline is 3. Description adds no additional parameter meaning beyond what schema already provides (e.g., no tips on formatting or constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Create a new task in Autotask', using a clear verb-resource combination. It distinguishes from sibling tools like autotask_create_ticket or autotask_create_project by specifying 'task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., autotask_create_ticket or autotask_create_phase). No mention of prerequisites or 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?
The description does not disclose any behavioral traits such as side effects, required permissions, or what happens on success/error. No annotations are provided, so the description carries full burden, but it only states the basic action. It does not mention if the company is immediately available or if there are constraints like uniqueness checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the key action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters including an ID and boolean, and no output schema, the description is insufficiently complete. It does not explain return values (e.g., the ID of the new company) or any behavioral nuances. With no annotations, the description should provide 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 has 9 parameters with 100% description coverage, so the schema already documents each parameter well. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'company in Autotask', which is specific. However, it does not differentiate from the sibling 'autotask_update_company' or other create tools, though the distinction is implied by the name. A slight improvement could mention that it creates a new company rather than updating an existing one.
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. For example, it does not mention that companyName and companyType are required, nor when to use the update tool instead. The agent must infer usage from 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 full burden for behavioral disclosure. It mentions creation but does not specify if the operation is idempotent, what happens on duplicate emails, or required permissions. The lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose without fluff. It could be slightly more detailed, but it is not 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?
Without an output schema or annotations, the description provides minimal context. The 100% schema coverage offsets some need, but important aspects like return values, error handling, or side effects are missing. A minimally adequate score is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning; baseline score is 3. The description does not elaborate on parameter formats, constraints, or relationships beyond what the schema already provides.
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 creates a new contact in Autotask, combining a specific verb ('create') and resource ('contact'). It distinguishes from siblings like autotask_search_contacts or autotask_create_company, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For instance, whether to use this or autotask_search_contacts first is not mentioned, nor are prerequisites like ensuring the company ID exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It does not mention that creation may fail if the project doesn't exist, whether the operation is idempotent, or what side effects occur. It lacks details about authorization requirements or impact on other entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. It contains no unnecessary words and is front-loaded with the action and resource. However, it could be slightly more informative without sacrificing conciseness.
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 6 parameters (2 required), no output schema, and no annotations, the description is incomplete. It does not explain what is returned upon success, possible errors, or restrictions. For a creation tool, more context is needed.
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 meaning beyond the schema's parameter descriptions ('Project ID for the phase', etc.), which already explain each parameter adequately.
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 creates a new phase in an Autotask project. It specifies the verb ('Create') and the resource ('phase in an Autotask project'). However, it does not explicitly differentiate from sibling tools like `autotask_create_task` or `autotask_create_project`, but the resource is distinct 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?
No guidance is provided on when to use this tool vs. alternatives, such as when to create a phase vs. a task or project. There are no hints about prerequisites (e.g., project must exist) or context. The description is purely declarative.
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 provided, so description carries full burden. It does not disclose behavioral traits like whether creation is immediate, if it validates project existence, or if it overrides defaults. The description only states basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and to the point. No wasted words, but could benefit from being slightly more descriptive without adding length.
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 6 parameters (2 required) and no output schema, description is insufficient. It does not explain return behavior or side effects. Complete enough for basic use but lacks depth for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description provides no additional meaning beyond schema; the schema already describes each parameter well. No added semantics.
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 'Create a new note for a project', which specifies the verb (create), resource (note), and scope (for a project). It distinguishes itself from siblings like autotask_create_company_note or autotask_create_ticket_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as when to create a note vs a ticket note. No mention of prerequisites or 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 provided, so description bears full burden. It states the action but does not disclose if any side effects occur (e.g., overwriting existing links), permissions needed, or whether it's reversible.
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?
Short and to the point, with two sentences. Could be slightly more informative without excessive length.
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 lack of output schema and annotations, description should provide more context about expected behavior, errors, or outcomes. It is sufficient for a simple linking operation but lacks completeness for error handling or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not add much. It adds minimal context 'for scheduling purposes' but does not explain the relationship between the IDs beyond what the schema provides.
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 'Link a ticket to a service call' and explains the purpose 'for scheduling purposes'. It distinguishes from sibling tools like 'autotask_create_service_call' and 'autotask_create_ticket', which create separate entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While siblings exist for creating service calls or tickets, the description does not mention prerequisites (e.g., service call must already exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It does not disclose behavioral traits such as whether the action is destructive, whether it requires specific permissions, or what happens to related data (e.g., recalculating quote totals). The description only states the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and concise. It gets straight to the point without extraneous information. However, it could be slightly improved by adding a brief usage note without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters and no output schema, the description is adequate but not complete. It lacks context about prerequisites (e.g., the quote must exist) and consequences (e.g., the item is permanently removed). The verb 'delete' implies destruction, but more behavioral clarity would raise completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so the baseline is 3. The description does not add extra meaning beyond the schema, such as clarifying that quoteId must be a valid quote number or that quoteItemId must reference an existing item. No enhancement needed.
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 'Delete' and the resource 'quote item (line item) from a quote', which is specific and unambiguous. It distinguishes this tool from siblings such as 'create_quote_item' and 'update_quote_item'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. For example, it does not mention that the quote must not be in a locked or finalized state, or that deletion is irreversible. The usage context is implied but not detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It does not mention read vs. write behavior, authentication requirements, or what happens if the ID is invalid. The tool likely reads data, but this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no padding. Efficient but lacks some context as noted.
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 simple struct, description could state what is returned (e.g., 'Returns full service bundle details'). It is minimally complete but lacks expected details.
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 already has 100% coverage with description for the parameter, so description adds no extra meaning beyond 'ID to retrieve'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a specific service bundle by ID, using the verb 'Get' and a specific resource. It distinguishes from sibling search tools like autotask_search_service_bundles which list bundles vs. retrieving one by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like autotask_search_service_bundles, or any prerequisites. The agent must infer from the ID parameter that this is for retrieving a known bundle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states the basic action without disclosing read-only behavior, potential side effects, authentication requirements, or rate limits. The tool name suggests it is a read operation, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words, though it could be slightly more informative without sacrificing brevity.
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 (2 parameters, no output schema, no annotations), the description is minimally adequate. However, it does not mention the return format, pagination behavior, or what constitutes a phase, which could help the agent. No output schema exists, but the tool is simple enough that this gap is not critical.
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% (both parameters are described in the schema). The description does not add additional meaning beyond the schema; the projectID is straightforward and pageSize has default/max values in the schema. With full 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list phases') and the resource ('for a project in Autotask'). It specifies the required input (projectID) but does not differentiate from sibling tools like autotask_create_phase or autotask_search_projects. However, the distinct purpose is sufficiently clear.
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 autotask_create_phase or other list/search tools. The description does not mention context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavior beyond the verb 'search' – e.g., pagination behavior, sorting, or whether it returns full notes or summaries. The pageSize parameter hints at pagination but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. However, could be slightly more descriptive without bloating.
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 2 parameters, no output schema, and no annotations, the description is too minimal. It does not explain the return format, ordering, or the difference from other note-related tools (get, create).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to parameters beyond what's in the schema (ticketId is required, pageSize has defaults).
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 is clear: 'Search for notes on a specific ticket' – it specifies the action (search) and the resource (notes on a ticket). It distinguishes from siblings like autotask_get_ticket_note (which retrieves a single note) and autotask_create_ticket_note (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives like autotask_get_ticket_note or other search tools. No mention of context (e.g., ticket must exist) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It says 'update' implying mutation but does not disclose idempotency, partial update behavior (only specified fields are updated), auth requirements, or what happens if id is invalid. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that conveys the essential purpose. It is concise and front-loaded, but could be slightly expanded to include key behavioral details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too brief. It does not explain return values (e.g., whether it returns the updated company or just success), error handling, or which fields are required beyond id. The tool has 8 parameters with 100% schema coverage, but completeness is low due to missing behavioral and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra parameter info. Baseline 3 is appropriate. The tool updates company fields, but the description does not clarify how overlapping fields behave (e.g., if companyName is omitted, does it remain unchanged?).
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 'Update an existing company in Autotask', which identifies the verb (update), resource (company), and system (Autotask). It distinguishes from sibling tools like autotask_create_company, but could be more specific about which fields are updatable.
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 like autotask_update_company_site_configuration or create_company. There is no mention of prerequisites (e.g., company must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of disclosing behavioral traits. It mentions updating text, completion status, and position, but does not state whether changes are reversible, if there are side effects (e.g., updating audit logs), or required permissions. The tool likely modifies data, but no safety info 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the supported operations. It is front-loaded and avoids unnecessary words. However, it could be slightly improved by adding a conditional or example, but it's concise overall.
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 lack of annotations and output schema, the description provides a basic but sufficient overview for a simple update operation. However, it doesn't cover edge cases or what happens if itemId does not exist. The tool has 5 parameters but only 2 are required; the description could clarify when optional parameters are applicable.
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?
Since schema description coverage is 100%, the baseline is 3. The description reiterates what each parameter does but adds minimal extra meaning. For example, it mentions 'edit text' corresponds to itemName, but doesn't clarify constraints like character limits or formatting. Position update is mentioned but no details on indexing.
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 that the tool updates a checklist item on a ticket, and specifies three possible operations: edit text, mark complete/incomplete, or change position. This differentiates it from sibling tools like autotask_create_ticket_checklist_item and autotask_delete_ticket_checklist_item, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For instance, it doesn't mention that to create or delete checklist items, one should use sibling tools with those actions. The description implies usage for updating existing items only but offers no context about prerequisites or conditions.
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 provided, so description carries full burden. It only says 'Create a new expense report', which implies creation but lacks details on side effects, permissions needed, or whether the tool creates associated records. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Could be slightly improved by front-loading the resource type, but it's concise.
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 and no annotations, the description is minimally adequate. It states what the tool does but lacks behavioral context. With 4 parameters and no nested objects, the complexity is low, so a 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3. The description does not repeat parameter details but the schema already explains each parameter (name, description, submitterId, weekEndingDate). No additional semantics in description needed.
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's action (create) and resource (expense report). While it doesn't differentiate from siblings like 'autotask_create_ticket' or 'autotask_create_expense_item', the resource name is distinct, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'autotask_search_expense_reports' or 'autotask_get_expense_report'. There is no mention of prerequisites, post-conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description must convey behavioral traits. It states the deletion action but fails to mention irreversible consequences, authorization requirements, or side effects like cascading deletes.
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?
Extremely short and front-loaded. Every word serves a purpose. However, it could be slightly expanded for clarity without losing conciseness.
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 is a delete operation with no output schema and no annotations, more context is needed: e.g., return value, confirmation behavior, or impact on related entities.
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 covers 100% of the parameter, so baseline is 3. The description adds nothing beyond the schema's parameter description, which already states its purpose.
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 (delete) and the resource (service call) and identifies the parameter (by ID). It distinguishes well from sibling delete tools which have different resources (quote_item, ticket_charge, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, does not mention prerequisites (e.g., service call must exist) or contrast with update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description implies a read-only operation (search). It does not disclose behavior like pagination, rate limits, or data scope beyond filters. Since annotations are missing, the description partially fulfills transparency by labeling it as 'search', but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It conveys the core purpose but no additional context, making it minimal.
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 output schema and 3 parameters, the description should explain return behavior (e.g., list of expense reports, empty array if none) and pagination. It does not, leaving the agent uncertain about the response format.
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 already has 100% coverage with good descriptions (e.g., enum values for status, limits for pageSize). The description adds little beyond the schema, so baseline 3 applies. However, the description implicitly supports optional filtering, which aligns with the schema, so a 4 is reasonable given full schema coverage.
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 expense reports and mentions it has optional filters, which distinguishes it from creation tools and other search tools. However, it does not differentiate from the sibling 'autotask_get_expense_report' or other search tools, so a 5 is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'autotask_get_expense_report' (which likely retrieves a single report) or when to avoid it. The description only says 'optional filters' without specifying when filters are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description should disclose behavioral traits. It mentions pagination defaults but does not clarify if the search is fuzzy/exact, filters are optional, or whether results are sorted. No destructive/read behavior indicated.
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 concise with two sentences. It front-loads the purpose and adds pagination details efficiently.
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 (6 optional params, no output schema, no annotations), the description lacks completeness. It does not explain what results look like, error handling, or behavior with empty search terms.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter, so the description adds little beyond the schema. It mentions pagination defaults (page, pageSize), which are already described in 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 tool searches for projects in Autotask. It distinguishes from sibling search tools by naming the entity 'projects', but does not explicitly contrast with other search tools.
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 basic usage information (paginated, 25 results per page) but does not guide on when to use this tool versus other search tools or when to use filters. No is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. The description only states 'Create a new ticket in Autotask', which implies a write operation but does not disclose any behavioral traits like required permissions (e.g., authentication), side effects (e.g., triggers notifications), rate limits, or response behavior. However, the schema provides some constraints (e.g., assignedResourceID requires assignedResourceRoleID) which partially compensates. The description is adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one short sentence). It is front-loaded and to the point. While brevity is good, the sentence is so short that it sacrifices detail. However, given the extensive schema, the description wisely leaves details to the schema, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 21 parameters, many complex (picklists, required relationships). No output schema exists, so the description should hint at what the tool returns (e.g., ticket ID). The description lacks this. However, the rich schema with cross-references to other tools (e.g., autotask_get_field_info) provides good context for selecting valid parameter values. The description itself is incomplete, but the schema compensates somewhat.
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 baseline is 3. The description adds minimal meaning beyond what the schema provides, but the schema itself is well-documented with examples and references to auxiliary tools (e.g., 'Use autotask_list_queues to discover valid IDs'). The description does not add new semantic understanding beyond the parameter descriptions already present.
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 ('Create'), the resource ('a new ticket'), and the system ('Autotask'). It distinguishes this from sibling tools like autotask_create_ticket_note, autotask_create_ticket_attachment, etc., which create related but different resources. However, it does not explicitly contrast with these siblings, and the title is null, so it relies solely on the description.
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 (e.g., when to use autotask_update_ticket instead, or prerequisites like companyID must exist). The input schema includes some helpful hints (e.g., use autotask_list_queues, autotask_get_field_info), but these are not part of the description itself. The description is too brief to offer 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?
No annotations are provided, so the description must cover behavioral aspects. It does not disclose any side effects, required permissions, or whether the note creation triggers notifications. The verb 'create' implies writing, but no further context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that efficiently conveys the core purpose. It could benefit from a bit more detail, but it is not 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?
Given 5 parameters, no output schema, and no annotations, the description provides a minimal but adequate purpose. However, it omits details about return values, potential errors, and prerequisites (e.g., ticket must exist), which would help complete the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond field names and types. However, the description lists important optional parameters like noteType and publish, but does not explain their impact (e.g., visibility, type categorization). 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 'Create a new note for a ticket' clearly states the action (create) and the resource (ticket note), distinguishing it from other create tools like autotask_create_ticket or autotask_create_ticket_attachment. However, it could be more specific by mentioning the required and optional parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like autotask_search_ticket_notes or autotask_get_ticket_note. The context of needing a ticketId and description implies usage for adding a note to an existing ticket, but no exclusion 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a destructive action, but no annotations provided. No details on error behavior, permissions needed, or side effects (e.g., does it cascade?). Basic disclosure of deletion, but not thorough.
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?
Single sentence is concise and front-loaded with the action. No extraneous 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?
Tool is simple (2 params), but missing behavioral details like error handling or idempotency. For a simple delete, this is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with descriptions, so description adds no extra meaning. Baseline 3 is appropriate given 100% schema coverage.
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 (delete) and the resource (checklist item from a ticket). It is distinct from sibling tools like autotask_create_ticket_checklist_item and autotask_update_ticket_checklist_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as updating or creating checklist items. No mention of prerequisites like requiring an existing checklist item or ticket.
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 states the tool retrieves a quote, implying it is a read-only operation. However, it does not disclose any behavioral traits such as possible errors (e.g., if ID not found), rate limits, or required permissions.
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 that front-loads the core action. No unnecessary words. However, it could include a slightly more detailed context without violating 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 tool's simplicity (one required parameter, no output schema, no nested objects), the description is adequate to understand its purpose. However, it lacks details about error handling or return format which might be helpful for an AI 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%, and the parameter is straightforward (quote ID). The description adds no additional meaning beyond 'the quote ID to retrieve'. Since coverage is high, a 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 it gets a specific quote by ID. It uses a specific verb ('get') and resource ('quote'), and the input schema confirms the ID parameter. Among siblings, there are distinct create, delete, update, search, list, and other get tools, so the purpose is clear and distinguishable.
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. The input schema is minimal and the description doesn't mention any context or alternative tools (e.g., when to use autotask_search_quotes instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. While 'Get' suggests read-only behavior, the description does not confirm idempotency, specify authentication requirements, or mention any side effects. The lack of details on what happens if the ID does not exist (e.g., error vs. empty) is a gap.
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 very concise (one sentence, 6 words), which is efficient. It directly states the purpose without unnecessary words. However, it could slightly expand for completeness without losing 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 tool is simple (1 param, get operation), the description is adequate but minimal. It could mention that there is no output schema, so the agent might need to infer the return structure from search results. Compared to sibling tools like autotask_get_quote, no additional context is needed, but basic behavioral info is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (quoteItemId) already described. The description adds minimal extra meaning beyond the schema, simply restating 'by ID'. Baseline 3 is appropriate since the schema already documents the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a specific quote item by ID, which is a specific verb ('Get') and resource ('quote item'). However, it could be more precise by noting that it retrieves a single item, distinguishing it from search_quote_items which returns multiple.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single quote item by ID, which is clear. However, no guidance is given on when to use this tool versus alternatives like autotask_search_quote_items, and no context on prerequisites (e.g., the quote must exist) is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses default page size (25) and pagination behavior. However, lacks info on whether search is case-sensitive, supports wildcards, or any rate limits.
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?
Description is brief (two sentences) and front-loaded with main purpose. Could be slightly more efficient by combining ideas, but no extra 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?
Given simple tool with full schema coverage and no output schema, description provides core pagination detail but misses behavioral context like default behavior when optional filters are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. Description doesn't add meaning beyond schema; for instance, 'pageSize' max 200 is in schema but not reiterated.
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 companies in Autotask and returns results paginated. It distinguishes from sibling search functions by focusing on 'companies' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like autotask_search_contacts or autotask_search_tickets. Doesn't specify that it only searches by name and active status, or mention any limitations.
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 does not mention behavioral traits beyond the schema and annotations. Since no annotations are provided, the description should compensate but fails to clarify if the search is read-only, case-sensitive, or returns paginated results. It only mentions 'optional filters'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the purpose. It could be improved by adding brief usage context, but it is not 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?
Given no output schema and simple parameters, the description is adequate but does not explain return format, pagination behavior, or default filters. For a simple search tool, it meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions (100% coverage). The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 invoices with optional filters. However, it does not differentiate from sibling tools like autotask_search_billing_items or autotask_search_contacts, which also search for entities. It is specific to invoices.
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 lacks guidance on when to use this tool versus alternatives, such as autotask_get_invoice_details for a single invoice or other search tools. It does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions it returns 25 results per page and pagination behavior. No annotations provided, so description partially covers behavioral aspects but does not mention rate limits, authentication, or potential errors. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clear and to the point. Front-loads the main purpose. Could be slightly more structured but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, description adequately covers pagination but lacks details on what is returned (e.g., just names or full profiles). Could be improved with return info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, so description adds little beyond repetition of defaults and page parameter. Baseline 3 is appropriate since description does not add significant semantics beyond 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?
States it searches for resources (users) in Autotask. Verb 'search' and resource 'resources' are specific. However, does not explicitly differentiate from sibling search tools like autotask_search_contacts, though the resource type is implied.
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?
Provides default page size and pagination info, but no guidance on when to use vs alternatives like autotask_search_contacts or autotask_search_companies. No when-not-to-use or preference for resource search.
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 implies this is a read-only operation (search/read), which is accurate. However, it does not disclose pagination behavior beyond the pageSize parameter, or whether results are sorted or filtered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it could benefit from a brief note on scope (only for a specific ticket) to improve clarity.
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 100% schema coverage and the simplicity of the tool (2 params, no output schema), the description is adequate but not complete. It does not mention that 'search' likely returns a list of attachments, nor does it provide any usage example or note about field searching.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what the schema provides. It does not explain the relationship between ticketId and the search (i.e., it returns attachments belonging to that ticket). The pageSize parameter is described in the schema, and the description adds no extra context.
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 attachments on a specific ticket, distinguishing it from sibling tools like 'autotask_get_ticket_attachment' which retrieves a single attachment by ID. However, it does not explicitly mention that the search is scoped to a single ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'autotask_get_ticket_attachment' (for known attachment IDs) or listing all attachments. Does not explain search semantics, such as whether it performs text search or just returns all attachments.
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 were provided, so the description carries the burden. It states 'Only fields provided will be changed,' which implies a partial update behavior. However, it does not disclose whether this operation has any side effects, requires specific permissions, or is reversible. Lacks details on error handling or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences. It is front-loaded with the core action. Every word is useful, but it could expand slightly on usage context without losing 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 complexity (8 parameters, no output schema), the description provides basic functional clarity but lacks completeness. It does not explain what happens on success (e.g., returns updated charge object?), nor does it address constraints like which fields are required or related to ticket context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. However, the tool description adds no extra explanation beyond the schema. For example, it does not clarify which fields are commonly updated together or any dependencies between parameters. 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 states the tool updates existing ticket charges and specifies that only provided fields change. It clearly identifies the target resource (ticket charge) and the action (update). However, it does not explicitly distinguish it from siblings like autotask_update_ticket, which might update different aspects of a ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, compared to autotask_create_ticket_charge or autotask_search_ticket_charges, there is no mention of when to update vs create or search. The description only states what it does, not when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must cover behavioral aspects. Description implies creation (mutation) but does not discuss side effects like return value, required permissions, or whether the item is appended by default. It's minimally 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?
Single sentence, no fluff, gets straight to the point. Perfectly concise.
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 and four parameters, the description is adequate but minimal. It doesn't explain that the checklist item is added to the existing ticket checklist, or how position works. Completeness is average.
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 has a description in the schema. The description adds no extra meaning beyond 'add a new checklist item'. 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?
Description clearly states the verb 'add' and the resource 'checklist item' and its parent 'ticket'. The purpose is easily understood and distinct from siblings, as sibling names show different actions like 'delete_ticket_checklist_item' and 'search_ticket_checklist_items'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that you need an existing ticket or that position is optional. No comparison with update or delete checklist items.
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 provided. Description only states the action, no behavioral details (e.g., if it's irreversible, permission requirements, side effects). For a delete operation, this 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?
One clear sentence, no fluff. Front-loaded with action and object.
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?
Simple tool with one parameter and no output schema. Description adequately explains what it does, but lacks behavioral details for a deletion operation (e.g., reversibility, confirmation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage on parameter description, so the description adds no new info. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Remove), the object (ticket association from a service call), and the method (by service call ticket record ID). Not a tautology, though 'delete' in name is slightly redundant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use. Implies it's for removing a specific association, but doesn't distinguish from deleting the service call itself or other related tools (e.g., autotask_delete_service_call, autotask_delete_service_call_ticket_resource).
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 provided, so description carries full burden. It correctly implies a read operation (since it's 'get'), but fails to disclose any side effects, error conditions, or required permissions. However, for a simple retrieval tool, a score of 3 is fair.
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 wasted words. Information is front-loaded and precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is minimally complete. However, it lacks any details about return format or possible error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with a clear description for opportunityId. The description adds no further meaning beyond 'Get a specific opportunity by ID', which is adequate but not helpful 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?
Description clearly states the action (get), resource (opportunity), and retrieval method (by ID). While specific, it does not differentiate from siblings like autotask_get_quote, but the sibling set includes many CRUD tools which are naturally distinct by entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., autotask_search_opportunities). The description provides no context about prerequisites or when it's appropriate to use.
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 a moderate burden. It discloses the search operation but does not mention pagination behavior, sorting, or what happens if no notes are found. The input schema partially compensates by defining pageSize, but the description could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the tool's purpose without any unnecessary words. It is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description is adequate but not complete. It lacks information about return format, filtering options if any, and additional context like whether it returns only active notes. For a search tool with a sibling for individual retrieval, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the input schema (100% coverage), so the description adds no additional meaning beyond the schema. The baseline score is 3, which is appropriate given that the schema already explains the required companyId and optional pageSize with constraints.
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 'Search for notes on a specific company' clearly states the action (search) and the resource (notes on a company). It distinguishes from sibling tools like autotask_create_company_note and autotask_get_company_note, making it clear what this tool does differently.
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 autotask_get_company_note for retrieving a single note. The description does not mention any constraints or prerequisites beyond the input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It does not disclose pagination behavior (though pageSize is in schema), whether results are returned in any order, or if there are any constraints on the searchTerm. The description is minimal on behavioral aspects.
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. It is front-loaded with main purpose and common filter. Could be slightly more informative without being lengthy.
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 3 parameters, 100% schema coverage, and no output schema, the description is adequate but lacks detail on return format or behavior beyond filtering. It's complete enough for basic use but not for advanced scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions filtering by quote ID, which adds context beyond the schema description for that parameter. However, schema coverage is 100% so the bar is higher; the description does not add much extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Search for quote items, typically filtered by quote ID', which clearly indicates the tool searches for quote items with a common filter by quote ID. It differentiates from sibling tools that are create or get operations for specific entities.
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 primary use case (filter by quote ID) but does not explicitly state when to use this tool over other search tools like autotask_search_quotes or autotask_search_products. No alternatives or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read/search operation, which is appropriate. However, it doesn't mention any side effects (none expected), auth requirements, or pagination behavior beyond what the schema implies (pageSize parameter). This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (6 words), which could be seen as concise, but it provides only the bare minimum. It lacks any elaboration on what the search returns or how the parameters interact. It is not front-loaded with additional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and only 3 optional parameters, the description is adequate to understand the basic purpose. However, it doesn't clarify if results are paged, the return format, or how to combine filters. For a search tool, more context on expected behavior would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds no parameter-specific meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource assignments on service call tickets, specifying it's about technician assignments. This distinguishes it from sibling tools like autotask_search_service_calls (which searches service calls overall) and autotask_search_resources (which searches resources directly).
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 searching when you need to find which technicians are assigned to service call tickets, but it doesn't explicitly guide when to use it vs alternatives like autotask_search_service_call_tickets (which searches tickets linked to service calls). No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a mutable operation (updating), but does not disclose any side effects, such as whether updates are persisted immediately, or if there are restrictions on changing certain fields after the quote is finalized. No annotations are provided, so the description carries the full burden, which it only partially addresses.
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 only 7 words, efficiently conveying the core purpose without superfluous details. It is front-loaded with the verb 'Update' and the resource.
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 complexity (8 parameters, no output schema, no annotations), the description is too minimal. It does not mention return values, error scenarios, or any constraints on updates. However, the schema itself is well-described, so the description's lack of depth is somewhat mitigated.
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 all 8 parameters with descriptions, so schema description coverage is 100%. The description adds minimal value beyond the schema by listing 'quantity, price, etc.', but does not elaborate on usage or constraints. 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 it updates quote items, listing example fields like quantity and price. However, it does not distinguish from the sibling tool 'autotask_create_quote_item', which is for creating, nor from 'autotask_search_quote_items' which is for reading. The verb 'update' and resource 'quote item' are specific, but the lack of scope differentiation prevents a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like creating a new item or deleting an item. No context is given about prerequisites, such as requiring the quote to be in a certain state, or when it's appropriate to update vs recreate.
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 should disclose behavioral traits. It describes the purpose but does not mention side effects, required permissions, or cancellation behavior. It adds some value beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded. It conveys purpose in one sentence plus additional context. 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?
Given no output schema, description does not explain return value (likely the created call's ID). It covers creation purpose adequately but misses return info.
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 baseline is 3. The description does not add additional meaning beyond what is already in 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 tool creates a new service call and explains what service calls are used for. It distinguishes from siblings like autotask_create_ticket and autotask_update_service_call.
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 scheduling work on tickets but does not explicitly state when to use this versus other creation tools. No guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It states the operation is a deletion, which implies irreversibility, but does not disclose if there are side effects (e.g., cascading deletes) or authorization requirements. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and no unnecessary words. It is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two required numeric parameters, no output schema), the description provides the essential purpose and inputs. However, it lacks optional details like error handling, response format, or permission hints, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which already specify 'The parent ticket ID' and 'The charge ID to delete'.
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 ('Delete a ticket charge by ID') and specifies the required identifiers ('parent ticket ID and charge ID'). It distinguishes itself from sibling tools like autotask_create_ticket_charge (create) and autotask_update_ticket_charge (update) by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that both ticketId and chargeId are needed, matching the 'required' schema. However, it does not provide guidance on when to use this tool versus alternatives (e.g., searching for charges first) or any prerequisites like permissions.
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 indicates it retrieves detailed information, but no annotations are provided. It does not disclose behavior like potential errors, authorization needs, or data freshness. However, the description does not contradict any annotations (none present).
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?
Single sentence, concise and front-loaded with key action. Could be slightly more structured but 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?
Tool is simple with one parameter and no output schema, so description is minimally adequate. However, no explanation of what 'detailed information' includes or example usage.
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 one parameter, which already has description 'The billing item ID to retrieve'. The description adds no further meaning beyond the schema, leading to baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a resource 'billing item' identified by ID, clearly stating the purpose. However, it lacks differentiation from the sibling tool autotask_search_billing_items, which likely retrieves multiple items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs autotask_search_billing_items, but the description implies it's for a single item by ID. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'nested line items' and that it fetches a single record, which helps. However, it does not state whether this is a read-only operation, any authentication needs, or rate limits. The description is neutral but adds value beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main purpose, followed by a usage hint. It is concise and efficient, though the second part could be integrated more cleanly.
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 this is a simple retrieval tool with one parameter and no output schema, the description provides adequate context (nested line items, finance workflows). It could mention that invoice ID is required or clarify if any error handling occurs, but it's sufficient for a straightforward 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% with one parameter (invoiceId) described as 'The invoice ID to fetch'. The description adds no additional semantic meaning to the parameter beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single Autotask invoice with nested line items, using a specific verb ('Get') and resource ('Autotask invoice'). It distinguishes itself from sibling tools like autotask_search_invoices which would search for multiple invoices, but does not explicitly name that sibling.
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 mentions 'finance workflows' as a use case, giving some context, but does not provide explicit guidance on when not to use this tool or when to use alternatives like autotask_search_invoices for listing invoices.
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 provided, but description implies a simple read operation. No details on authentication, rate limits, or error handling, which is acceptable for a straightforward get.
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?
One short sentence, efficient and front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple one-param tool with no output schema, the description is adequate but could mention returned fields or link to documentation.
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 covers parameter with description. Description adds no extra semantics beyond what schema provides, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a specific product by ID' with a specific verb and resource. Distinguishes from sibling 'get' tools by focusing on product retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides basic usage context (get by ID) but no explicit when-to-use or alternatives. For more complex queries, search_products exists, but not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a retrieval operation, but does not disclose any limitations (e.g., required permissions, performance, or specific fields returned). Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: one sentence of six words that directly states the purpose. Could be marginally improved by adding context about usage, but no unnecessary words present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description is functional but not comprehensive. It lacks detail about the structure of the returned service object or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a 'description' for the only parameter 'serviceId'. The description does not add additional meaning beyond the schema itself, so 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?
Description clearly states the tool retrieves a specific service by ID, matching the verb 'get' and resource 'service'. While it distinguishes from sibling 'autotask_search_services' which presumably returns multiple results, it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a specific service ID and need full details, but it does not explicitly state when not to use it or mention alternatives like autotask_search_services for broader queries.
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 provided, so the description must cover behavioral aspects. It discloses default page size and pagination behavior, but lacks info on whether the search is case-sensitive, partial match, etc.
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?
Two sentences, front-loaded with purpose, then key behavior. Efficient with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description gives enough basics for a simple search tool. Could mention result structure or search tuning, but adequate for 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?
Schema coverage is 100%, so all parameters already documented. Description adds no extra meaning beyond mentioning '25 results per page' and 'use page parameter', which aligns with schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for contacts in Autotask, specifying the resource and action. It does not explicitly distinguish from sibling search tools like autotask_search_companies, but naming and context imply differentiation.
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?
It mentions pagination defaults but provides no guidance on when to use this tool over other search tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions filtering but does not disclose pagination behavior (pageSize defaults are documented in the schema), response structure, or any side effects. However, since the schema covers pageSize fully, the description adds no meaningful behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 8 words, which is concise and front-loaded. It contains no unnecessary words, but could benefit from slightly more detail without being 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 has 4 optional parameters and no output schema. The description is minimal but sufficient given that all parameters are documented in the schema. However, it lacks explanation of return behavior or result format, making it slightly incomplete for a search 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% (all 4 parameters have descriptions). The description says 'optional filters' which adds no new meaning beyond what the schema provides. Therefore baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool searches for contracts with optional filters. The verb 'Search' and resource 'contracts' convey the purpose, and it distinguishes itself from sibling create/get/update tools for contracts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for searching contracts, but provides no guidance on when to use this versus other search tools (e.g., autotask_search_quotes, autotask_search_invoices). It doesn't specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It correctly implies a read operation (search), but does not disclose any behavioral traits like pagination behavior beyond the pageSize parameter, rate limits, or whether results are sorted.
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 very concise at one sentence, front-loading the action and common filters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate but minimally covers what the tool returns or any edge cases. It lacks details on pagination beyond pageSize, sorting, or that all parameters are optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal value beyond listing filter types. It does not explain the semantics of combining filters or the relationship between startAfter/startBefore.
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 service calls and lists three common filters (company, status, date range). It distinguishes itself from siblings like autotask_get_service_call (which likely retrieves a single call) and create/update/delete variants, but does not explicitly differentiate from other search tools.
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 searching service calls but provides no guidance on when to use this tool versus other search tools (e.g., search_tickets). It does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must compensate. It mentions default page size (25) and pagination behavior, which is useful. However, it doesn't disclose read-only nature or any side effects. Since the tool is a search, it's likely safe, but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with key purpose. Two sentences, no fluff. Could be slightly improved by adding a sentence about when to use or additional context, but it's 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?
Given no output schema and 6 parameters, description adequately covers core behavior and pagination. However, it lacks guidance on search behavior (exact match, wildcards?) and return format. For a search tool, more detail on result structure 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?
Input schema has 100% description coverage, so description adds no new parameter meaning. The description only notes pagination defaults which are already in schema. Baseline 3 is appropriate as schema does the job.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for tasks in Autotask and mentions pagination details. It effectively communicates the core function, though it could be more specific about filtering capabilities beyond defaults.
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 basic context (search tasks) but does not differentiate from sibling search tools (e.g., autotask_search_projects, autotask_search_tickets) or specify when to use this tool over others. No alternative tools or when-not-to-use guidance 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 provided, so description must disclose behavior. It indicates a read operation (get) but doesn't mention if it returns the full report or just summary, or any quirks. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with verb and object.
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 input and no output schema, the description is sufficient but could mention what fields are returned or if any error cases exist. Completeness is adequate for a straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and description in schema explains 'reportId' as 'The expense report ID to retrieve'. Description adds no extra beyond that, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a specific expense report by ID. The verb 'get' and resource 'expense report' are specific. However, it does not differentiate from sibling search tools like 'autotask_search_expense_reports', which could also retrieve a report by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: use this tool when you have a specific expense report ID. No guidance on when not to use it (e.g., if you need to search by criteria, use the search tool instead).
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 disclose behavior. It correctly indicates a read operation but doesn't state that it returns only one note, or what happens if IDs are invalid. The description is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose without any unnecessary words. All required information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with two clearly documented required parameters and no output schema, the description is adequate but minimal. It could benefit from noting the return format or that the IDs must exist, but overall 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?
Schema coverage is 100%, so the schema already documents both parameters. The description restates 'projectId' and 'noteId' but adds no new meaning. 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 specific project note by project and note IDs. It distinguishes itself from siblings like autotask_create_project_note (create) and autotask_search_project_notes (search). However, it could be more specific about the source (e.g., 'from Autotask').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a single known note, but it doesn't explicitly mention when to use it over search_project_notes (which could be used to find note IDs). No alternatives or exclusions 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 description carries full burden. It mentions optional filters but does not disclose pagination behavior beyond the pageSize parameter (default 25, max 100) already documented in schema. No mention of rate limits or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, using only 7 words. It is front-loaded with action and resource. However, being too concise may omit useful context like result format or typical use cases.
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 3 optional parameters and no output schema, the description is somewhat complete but lacks information on how results are returned (e.g., list format, pagination with pageSize). For a search tool, describing the return structure would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds minimal value by stating 'optional filters'. The schema already describes each parameter well. However, the description does not explain searchTerm behavior (e.g., is it exact match or fuzzy?).
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 products with optional filters, using the specific verb 'search' and resource 'products'. It distinguishes from sibling 'get_product' which retrieves a single product. However, it could be more explicit about what 'products' means in this 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 usage when needing to find products, but no guidance on when not to use or alternative tools. Among siblings, 'autotask_get_product' exists for retrieving a single product, but the description does not mention this distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates mutation via 'Create' but does not disclose side effects, required permissions, or whether the tool is idempotent. With 100% schema coverage, the description adds little beyond stating the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, clearly stating the action and target. However, it could be slightly improved by front-loading key constraints or linking to related tools.
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 10 parameters (5 required) and no output schema, the description is minimal. It does not explain what is returned, nor does it provide guidance on picklist IDs or date formatting. The 100% schema coverage partially compensates, but more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so each parameter has a description. The tool description does not add additional meaning beyond what the schema already provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'expense item on an existing expense report'. It distinguishes from sibling tools such as autotask_create_expense_report, which creates a new report rather than an item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after an expense report exists, but does not explicitly mention prerequisites or when to use alternatives like autotask_create_expense_report or autotask_search_expense_reports for finding the report ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation, but does not disclose potential errors, rate limits, or data format. Adequate for a simple retrieval.
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 immediately conveys the purpose. No 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?
Given the simple nature of the tool (2 parameters, no output schema), the description is complete enough for an agent to invoke it correctly. Leaves no ambiguity about required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal value beyond the schema, but is sufficient for the agent to know what the parameters mean.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a specific ticket note') and specifies the required identifiers (ticket ID and note ID). It differentiates from sibling tools like 'autotask_create_ticket_note' and other search/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a single note when both ticketId and noteId are known, but does not explicitly state when to use alternatives like 'autotask_search_ticket_notes' for searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states that approval levels describe tiered approval workflows, hinting at read-only behavior. However, it does not disclose pagination defaults or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clear and to the point. The first sentence states the purpose, the second adds context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides basic context but lacks details about return structure, pagination behavior, or authentication requirements. 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 coverage is 100% and all parameters have descriptions. The description adds no additional meaning beyond what the schema provides. Per guidelines, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for billing item approval levels' with a clear verb and resource. It further explains that these describe multi-level approval records for Autotask time entries, distinguishing it from other search tools like autotask_search_time_entries or autotask_search_billing_items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives, but the description implies it is for searching approval levels, which is a distinct concept from other search tools. However, no exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states 'search' which implies a read operation, but does not disclose pagination behavior, rate limiting, or whether the search supports full-text or keyword filtering. The schema provides pageSize and max results, but the description is silent on 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?
The description is extremely concise with one sentence. No wasted words; it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple search with two parameters (both well-documented in schema), no output schema, and clear sibling tools, the description is mostly complete. It could mention that results may be paginated or indicate the type of notes (e.g., project notes only), but overall it 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 baseline is 3. The description does not add any additional meaning beyond what the schema provides for the parameters. It does not explain how pageSize affects results or what format projectId should follow.
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 notes on a specific project. It distinguishes itself from siblings like 'autotask_get_project_note' (which retrieves a single note) and 'autotask_search_company_notes' (which searches company-wide). However, it does not explicitly note that it is scoped to a single project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you need to find notes for a project, but it does not provide explicit when-to-use or when-not-to-use guidance. It also does not mention alternatives like 'autotask_get_project_note' for retrieving a specific note or 'autotask_search_company_notes' for cross-project search.
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 provided, so description alone sets expectations. It states 'optional filters' but does not describe default behavior when no filters are given (likely returns many results), pagination, or any side effects. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No unnecessary words, 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?
Given the low complexity (3 optional params, no output schema), the description is mostly complete. It could mention that results are filtered or that it's a search tool distinct from get tools, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so parameters are already documented. The description adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for service bundles with optional filters. It has a specific verb 'Search', resource 'service bundles', and mentions filters, but does not differentiate from sibling search tools like 'autotask_search_services' or 'autotask_search_products'.
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 searching service bundles with filters, but provides no guidance on when to use this vs alternatives (e.g., 'autotask_get_service_bundle' for a single bundle). No when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must bear the burden. The phrase 'Only fields provided will be changed' reveals partial update behavior, which is good. However, it does not mention potential side effects, required permissions, or whether updates are irreversible. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, with no wasted words. It is front-loaded with essential purpose and behavior.
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 complexity (9 parameters, 1 required, no output schema), the description is fairly complete: it identifies the operation, resource, and partial update behavior. However, it could mention return value (e.g., updated ticket object) or error conditions, but since no output schema exists, the description doesn't need to explain return values per rules. Overall, it provides sufficient context for an update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra param info beyond the schema's descriptions. It does not compensate with additional context for any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('existing ticket in Autotask'). It distinguishes from sibling tools by being the only 'update_ticket' among many create/search tools, but does not explicitly differentiate from e.g., update_ticket_checklist_item or other update tools.
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 provide when-to-use or when-not-to-use guidance. It notes that only provided fields are changed, which implies partial updates, but lacks alternatives or context. The schema hints at using other tools for status/priority IDs, but description itself doesn't.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full responsibility. The description discloses that this is a destructive action (delete), which is clear from 'Remove'. However, it does not mention any confirmation, cascading effects, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the action and the parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple delete with one parameter, the description is adequate but could mention the return value (e.g., success indicator) or that it only works for existing resources. The schema provides no output schema, so description could clarify what happens on success/failure.
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 already describes the parameter with 100% coverage, and the description adds meaning by specifying it is for 'resource record ID', giving context beyond just the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'resource assignment from a service call ticket', uniquely identifying what this tool does. It distinguishes from siblings like 'autotask_delete_service_call' which deletes a whole service call, and 'autotask_search_service_call_ticket_resources' which is a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention prerequisites or relationships to other tools, such as needing to first search for the resource assignment using 'autotask_search_service_call_ticket_resources'.
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 disclosing behavior. It states it executes a tool but does not detail side effects (e.g., whether this is a read or write operation, idempotency, error handling). With no annotations, a 3 is reasonable given the 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 sentence that conveys the core purpose and a key usage hint. No extraneous words; every part earns its place. It is front-loaded with the main 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 (executor pattern) and the high schema coverage, the description is sufficient. It does not cover return values, but no output schema is provided. The context of sibling tools and the discovery prerequisite add enough completeness for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, and the description does not add extra semantics beyond naming the parameters. The description succinctly indicates the purpose of toolName (the tool to execute) and arguments (arguments to pass), which aligns with the schema. Since coverage is high, a 4 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 that the tool executes any Autotask tool by name, which is a specific verb+resource combination. It also provides a prerequisite (discovering tools via autotask_list_category_tools), helping distinguish it from the many sibling tools that perform specific CRUD 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 mentions using it after discovering tools via autotask_list_category_tools, which implies a use case, but does not explicitly state when not to use it or provide alternative tools. It is adequate but lacks depth.
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 provided, so description should disclose behavior. It accurately describes retrieval (read) but lacks details like permissions or potential errors.
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 unnecessary words. Perfectly concise for a simple retrieval tool.
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 and no annotations, description is adequate for a simple read operation but could mention response format or usage notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for both parameters, providing clear meaning. Description does not add beyond what schema already conveys.
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 explicitly states it retrieves a specific company note by required IDs, distinguishing it from sibling tools like autotask_search_company_notes or autotask_create_company_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance, but the specific retrieval nature is clear from description and sibling context (search vs. get).
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 provided, so description must carry behavioral burden. It indicates a read-only operation without explicit destructive hint. Description does not mention any side effects or return format, which is acceptable for a simple retrieval.
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 concise sentence that clearly states the purpose, with no extraneous 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?
Given the tool's simplicity (single parameter, no output schema), the description is sufficiently complete. It covers the core functionality. Missing details like return format are acceptable as they are standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes parameter 'serviceCallId' with type and required status. Description adds that it retrieves by ID, reinforcing but not adding beyond schema. With 100% schema coverage, baseline is 3; however, description aligns with parameter meaning, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves a specific service call by ID. The verb 'Get' and resource 'service call' are specific. However, it does not distinguish from sibling search tools like autotask_search_service_calls which might return multiple results.
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?
It is implied that this tool should be used when you know a specific service call ID, as opposed to searching. However, no explicit when-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It correctly indicates a read operation ('Get'), so the agent knows it's non-destructive. However, it does not disclose what happens if the charge ID is invalid (e.g., error handling) or if it returns null vs throws, leaving minor ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is appropriately sized for a simple retrieval tool, and every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 required parameter with full schema coverage, no output schema, and is a simple retrieval operation, the description is largely complete. It explains what the tool does and what input it needs. The lack of output description is acceptable without an output schema, as the return value is implied to be a ticket charge object.
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 100% coverage with a single 'chargeId' parameter described as 'The ticket charge ID to retrieve'. The description adds no extra meaning beyond the schema, but since schema coverage is high, the baseline is 3. I rate it 4 because the parameter is simple and the combination of schema and description is sufficient.
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 'Get a specific ticket charge by ID' uses a clear verb ('Get') and resource ('ticket charge'), and uniquely identifies the charge by ID. It distinguishes itself from siblings like autotask_search_ticket_charges and autotask_create_ticket_charge, though it doesn't explicitly differentiate.
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 need a single charge by ID, but it doesn't explicitly state when not to use it (e.g., for listing charges, use autotask_search_ticket_charges) or mention prerequisites like requiring an existing ticket charge. The sibling list suggests alternative tools for creation and search, but the description itself provides no 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?
The description mentions a default page size of 25 results, which adds useful behavioral context. However, with no annotations provided, it does not disclose other traits like rate limits or query performance. The description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the purpose. The first sentence defines the tool and the second provides a detail about results per page. No extraneous text.
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 12 parameters (all with schema descriptions) and no output schema, the description is reasonably complete. It explains what billing items are and gives default pagination, which is sufficient for a search tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description. The description adds no additional parameter semantics beyond the schema. 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 searches for billing items in Autotask, explicitly defining billing items as 'approved and posted billable items from the Approve and Post workflow', which distinguishes it from other search tools like search_invoices or search_tickets.
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 basic context for when to use the tool (searching billing items) but does not mention when not to use it or suggest alternatives among siblings. As a search tool, it's implied to be used when filtering by various IDs, but there's no explicit 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?
The description and input schema together indicate a search/read operation. No annotations are provided, so the description carries full burden. It does not mention destructive behavior or side effects, but search operations are safely assumed read-only. The description is sufficient 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?
Extremely concise at 9 words. Every word carries meaning, no redundancy. Perfect for a simple search operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema is complete (5 params, all described) and no output schema, the description is sufficient for a basic search. However, it lacks details on pagination behavior, sorting, or expected return format, which could be added without bloating.
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 baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 configuration items in Autotask with optional filters, making the purpose straightforward. However, it does not differentiate this from sibling tools like autotask_search_products or autotask_search_services, which are similar search tools. So it loses one point.
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 provide explicit guidance on when to use this tool vs alternatives. It mentions 'optional filters' but no context on typical use cases or when not to use it. However, the 'configuration items' scope is implied, and the input schema allows filtering, so it's minimally adequate.
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 mentions pagination defaults (25 results per page) which is helpful, but fails to disclose that this is a read-only operation, any rate limits, or that results might be empty. The word 'Search' implies reading, but no explicit guarantee.
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 concise with three sentences, covering default page size, filter options, and a practical example. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and no output schema is needed, the description adequately covers pagination and a key use case. It is complete for a search tool with no required parameters.
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 good descriptions for all parameters. The description adds some context about filters but does not significantly extend beyond 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 searches for time entries in Autotask, with specific verb 'Search' and resource 'time entries'. It distinguishes from siblings that create, get, delete, or update, and lists common filter 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 mentions a common use case: finding unapproved entries using approvalStatus='unapproved'. However, it does not explicitly exclude other scenarios or mention when not to use this tool versus other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must carry the burden. It indicates a read operation (get field definitions), which is correct. However, it doesn't mention potential pagination, rate limiting, or whether it returns all fields or only non-empty ones.
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 main purpose, followed by usage guidance. No superfluous 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?
The tool has simple input (2 params, 1 required) and no output schema, but description explains the return concept (field definitions with picklist values) well. Minor gap: doesn't mention the return format or whether it's a list/object, but sufficient for a simple info lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented in the schema. Description adds context about entityType examples and fieldName being optional, but doesn't add depth beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves field definitions and picklist values for an Autotask entity type. This purpose is distinct from siblings, most of which are create/search/get operations on specific records.
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?
Description explicitly mentions usefulness for discovering valid picklist values, implying when to use (before creating/updating entities). It doesn't contrast with alternatives, but the sibling list has many other get/search tools, so the guidance is adequate.
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 full burden. It states the tool retrieves an attachment, but does not disclose whether it's read-only, if there are permission requirements, or side effects. The default behavior of 'includeData' is noted, but overall behavioral context 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 sentence that fully conveys the tool's purpose. Every word is necessary and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, schema covers all, and no output schema. The description is complete enough for a simple retrieval tool. Minor improvement could mention that data is returned as attachment metadata plus optional base64 data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds no additional meaning beyond the schema, 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 it retrieves a specific ticket attachment by ticket ID and attachment ID. The verb 'Get' and resource 'ticket attachment' are precise. Distinguishes itself from sibling tools like 'autotask_create_ticket_attachment' and 'autotask_search_ticket_attachments'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single attachment given ticket and attachment IDs, but no guidance on when to use this vs. searching for attachments or creating them. No exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears the full burden. It mentions pagination behavior (default 25 per page, use page parameter) but does not disclose whether the operation is read-only, any rate limits, or if there are implicit filters (e.g., default shows all open tickets? Status parameter says 'omit for all open tickets' but is not described here). The transparency is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, no wasted words. Each sentence adds distinct value: purpose, pagination detail, and pointer to an alternative. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters (all optional) and no output schema, the description covers the essential behavioral aspects (pagination defaults) and points to get_ticket_details for deeper detail. It does not explain the output structure, but without an output schema, that's acceptable. It provides enough context for basic usage.
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 baseline is 3. The description adds minimal parameter semantics beyond the schema (e.g., 'use page parameter for more results' re-emphasizes pagination). It does not explain the relationship between parameters or typical use cases, but schema already provides clear descriptions for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search for tickets in Autotask', clearly indicating the verb and resource. However, it does not explicitly distinguish this tool from sibling search tools like autotask_search_time_entries or autotask_search_ticket_notes, though the resource 'tickets' is distinct enough given the server's many search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: 'Returns 25 results per page by default. Use page parameter for more results.' It also directs users to 'Use get_ticket_details for full data on a specific ticket', indicating when to use an alternative tool. It lacks explicit when-not-to-use guidance for other search tools but still offers valuable direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It states 'Assign a resource (technician)' which implies a mutating action, but doesn't describe side effects (e.g., whether existing assignments are replaced, if any constraints apply).
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, complete sentence that conveys the core action efficiently. No filler words, and the key terms (Assign, resource, service call ticket) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple assignment tool with two required parameters and one optional, the description covers the high-level action. However, given the lack of annotations and output schema, it would benefit from clarifying behavioral details like whether the resource is appended or replaced, and if roleID is mandatory in some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The tool description adds no extra meaning beyond the schema, which is acceptable given high coverage. The description lists the parameters implicitly via the 'resource (technician)' and 'service call ticket', but does not elaborate on 'roleID' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-subject pair ('Assign a resource...') and clearly identifies the object ('service call ticket'). It distinguishes from siblings like 'autotask_create_service_call_ticket' (creating the association ticket) and 'autotask_search_service_call_ticket_resources' (searching), by focusing on assignment.
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 assigning a technician to a ticket but does not mention when to use this over alternatives like 'autotask_create_service_call_ticket' or 'autotask_update_service_call'. No explicit guidance on prerequisites such as requiring an existing ticket or resource.
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 description alone must convey behavior. It discloses that this tool is for creating billable charges but does not mention side effects, required permissions, or whether it modifies existing entities. The description is adequate 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?
Two sentences, concise and front-loaded. First sentence states the action and resource, second sentence explains usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 12 parameters with full schema coverage. The description provides a high-level purpose but does not explain optionality like productID or status behavior. No output schema exists, so description could hint at return value but doesn't. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for parameters, but the description does not add additional meaning beyond schema descriptions. However, it briefly categorizes charge types as material/cost/expense, which helps. Baseline is 3 due to high coverage, but the description adds slight context.
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 it creates charges on tickets for billing non-labor costs like parts and travel. It specifies the resource (ticket charge) and action (create), distinguishing it from sibling tools like autotask_create_ticket (creates tickets) and autotask_delete_ticket_charge (deletes charges).
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 mentions charges are for non-labor costs, implying when to use, but does not explicitly state when not to use or compare with alternatives like time entries (autotask_create_time_entry). However, the context of billing parts/travel provides some implicit 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 must carry the burden. It describes the ability to tie to tickets/tasks/projects and the concept of Regular Time, but does not disclose side effects like whether this triggers notifications, dependencies on existing records, or any constraints like maximum hours or overlapping entries.
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 concise at two sentences, front-loading the core purpose and then adding the key nuance. No redundant or unnecessary phrases.
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 complexity (12 parameters, no output schema, no annotations), the description provides adequate high-level context about the two use cases (tied vs Regular Time). It could be improved by noting that the response likely returns the created time entry ID, but the lack of output schema reduces the penalty.
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 high-level context about the distinction between ticket/task/project and Regular Time, but does not add new detail for individual parameters 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 action (Create a time entry) and the resource (time entry in Autotask). It distinguishes between entries tied to tickets/tasks/projects vs Regular Time, which sets it apart from sibling creation tools like autotask_create_ticket or autotask_create_task.
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 explains when to use this tool (to log time) and provides guidance on using it for regular time with category examples. However, it does not explicitly state when not to use it or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The description indicates a read operation (listing categories), which is safe. However, it doesn't disclose details like rate limits, pagination, or the format of the returned list. For a simple list tool, this is acceptable but could be slightly more 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 two short sentences, front-loaded with action and purpose. Every word is necessary and adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and simple 'list' functionality, the description is complete enough for an agent to understand usage. It could optionally mention the format or example output, but not strictly required. The presence of sibling tools like 'autotask_list_queue' and 'autotask_list_category_tools' provides context, and the description helps differentiate.
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 no parameters, and schema description coverage is 100%. The description adds value by explaining the purpose of the tool's output (discovery of categories). Since there are no params to document, the description effectively covers the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available tool categories and helps discover operation types. The verb 'list' and resource 'tool categories' are specific and meaningful. However, it doesn't differentiate from the sibling tool 'autotask_list_category_tools', which might be related but distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Use this to discover what types of Autotask operations are available before loading specific tools.' This clearly indicates the tool is for initial discovery. However, it doesn't explicitly state when not to use it or mention alternatives, though the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it creates an opportunity, implying a write operation, but does not mention side effects, permissions, or if the tool modifies other records. The description is minimal but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence that conveys the tool's purpose without extraneous words. No redundancy or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, 7 required) and no output schema, the description is adequate but could benefit from mentioning return value (e.g., the created opportunity ID). The schema is comprehensive, making the description sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds value by hinting that useQuoteTotals calculates totals from quotes and explaining probability default. However, the description does not detail parameter relationships or usage 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 tool creates a new sales opportunity in Autotask, using a specific verb and resource. It distinguishes itself from sibling tools like autotask_create_company or autotask_create_ticket by focusing on opportunities.
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, such as when to use autotask_update_opportunity or autotask_search_opportunities. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It correctly indicates it lists tools with full schemas, implying a read-only operation. However, it does not disclose potential side effects or limitations (e.g., whether results are cached, performance impacts). With no annotations, this 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?
Two sentences, front-loaded with action and result. Every sentence adds value: first states what it does, second provides usage context. No 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?
Given the simple single-parameter input schema and the meta-purpose of listing tools, the description is nearly complete. It clearly states the input source and output content (full schemas). Could be more explicit about output format but adequate for the 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%, so the schema already documents the category parameter. The description reiterates the parameter's purpose ('Category name from autotask_list_categories') without adding new meaning beyond the schema. Thus 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?
Clear verb-object pair: 'List tools in a specific category with full schemas.' It specifies what it does (list tools) and the resource (category), and distinguishes itself from sibling tools like autotask_list_categories.
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?
Explicitly states 'Use after autotask_list_categories to see available tools and their parameters.' This guidance on when to use it is helpful, but does not mention when not to use it or alternative tools beyond dependencies.
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 this is a read-only listing operation and does not modify anything. It adds the sub-resource constraint beyond the schema but does not disclose details like pagination, results limit, or output format (e.g., only completion status fields).
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 two sentences long, front-loaded with the primary purpose, and efficiently conveys the key constraint about the ticket ID dependency. It is concise and well-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?
Given the tool has only one parameter with full schema coverage and no output schema, the description sufficiently covers the purpose and key constraint. For a simple listing operation, the description is complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, already documenting the ticketId parameter. The description adds context that the ticketId is required and provides the relationship (sub-resource), but does not add new semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all checklist items on a ticket with their completion status. It specifically identifies the resource (checklist items) and the action (list), and distinguishes from sibling tools like autotask_create_ticket_checklist_item and autotask_delete_ticket_checklist_item.
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 that checklist items are a sub-resource of a ticket and cannot be queried without a ticket ID, which clarifies the prerequisite. However, it does not provide guidance on when to use this tool versus other search tools for tickets or checklist items, though the uniqueness of the operation makes it less necessary.
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 full burden. It discloses default values for discounts and isOptional, and the mutual exclusivity of item references. However, it doesn't mention side effects (e.g., whether it recalculates quote totals) or permissions needed, 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 extremely concise, using only three sentences to cover purpose, key rule, required fields, and defaults. It front-loads the core action and critical constraint, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no output schema), the description provides sufficient guidance for a create operation. It omits return value details (which might be expected from a create tool) and potential error conditions, but the constraints and defaults are well-covered. The schema's rich descriptions partially compensate for the lack of 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 input schema has 100% description coverage for all 15 parameters. The description adds value by summarizing the key rules (set exactly one item reference, required fields, defaults) and explaining the quoteItemType auto-determination, which goes beyond the schema's individual 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 verb 'Create' and the resource 'line item on a quote', distinguishing it from siblings like autotask_create_quote (creates the quote itself) and autotask_update_quote_item (updates an existing item). The tool is uniquely for adding items to quotes.
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 specifies to set exactly one item reference (serviceID, productID, or serviceBundleID) and lists required fields (quoteId, quantity) and defaults. It does not explicitly mention when not to use this tool versus alternatives like autotask_update_quote_item, but the context of creation vs. update is implied.
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?
The description mentions the fullDetails parameter controls response size, which adds behavioral context. No annotations are provided, so it carries the full burden; it does well but could note that it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. It front-loads the purpose and includes actionable guidance.
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 no output schema and simple parameters, the description sufficiently covers what the tool does. It doesn't explain return values, but that might be 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, but the description adds context about fullDetails optimizing data. This adds value beyond the schema, though not extensively.
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 it retrieves detailed information for a specific ticket by ID, distinguishing it from sibling tools like search_tickets for listing groups or create_ticket for 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?
It says 'Use this for full ticket data when needed,' implying it's for specific lookups rather than search, but doesn't explicitly state when not to use it or mention alternatives like search_tickets.
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 provided, so description carries burden. It states it lists statuses, implying read-only operation. Without annotations, this is minimal but adequate for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no params, the description is complete for its purpose. It could mention that statuses are returned as a list of values, but overall 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?
Input schema has no parameters, and schema description coverage is 100%. The description adds purpose but no parameter details are needed. Baseline is 4 since no params exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all available ticket statuses in Autotask. It mentions usage for filtering or creating tickets, which is specific and distinct from sibling tools like autotask_list_queues or autotask_list_ticket_priorities.
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?
Description recommends using this tool to find status values for filtering or creating tickets, which gives clear context. However, it does not explicitly mention when not to use it or alternatives, but the sibling list shows many search/filter tools that might accept status values, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a search operation, which implies no side effects. However, no annotations are provided, so the description carries the full burden. It does not mention pagination behavior for pageSize (default, max), or whether both filters can be used together. Schema already covers parameter 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?
The description is concise, consisting of two sentences that clearly state the tool's purpose and usage. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a search tool with a simple input schema and no output schema. It explains the use case and the two primary filters. However, adding a note about pagination or default pageSize would improve completeness. Given the low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter's meaning is already clear from the schema. The description adds context by explaining the overall purpose, which helps agents understand how to use the filters in combination. However, the description does not add new parameter-specific details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for ticket associations on service calls, and provides two specific use cases: finding tickets linked to a service call or finding service calls containing a specific ticket. This distinguishes it from sibling tools that search for tickets alone (autotask_search_tickets) or service calls alone (autotask_search_service_calls).
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 mentions when to use this tool ('use this to find which tickets are linked to a service call, or which service calls contain a specific ticket'), providing clear context. However, it does not explicitly state when not to use it or mention alternatives like autotask_search_tickets for plain ticket searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates this is a non-destructive test operation. However, it does not disclose what a successful test returns or what happens on failure.
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-loading the essential purpose. No unnecessary words; every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple test connection tool with no parameters and no output schema, the description is complete. It provides enough context for an agent to understand the tool's purpose and use it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add meaning beyond what the schema provides. The description is sufficient for a parameterless tool.
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 'Test' and the resource 'connection to Autotask API'. It distinguishes this tool from the many create/search/update siblings by indicating it is a connectivity check.
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 should be used to test connectivity, but does not explicitly state when to use it (e.g., initial setup, troubleshooting) or when not to use it. No alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions partial update behavior and hints at Autotask constraints via input schema notes (e.g., assignedResourceRoleID required when assignedResourceID provided). However, it does not disclose return value, error handling, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First defines purpose, second adds key usage guidance. 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?
Given schema has 12 parameters with full coverage, no output schema, and no annotations, the description effectively covers the basic behavior. It is complete enough for a straightforward update tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds value by clarifying that only provided fields are updated and by giving a concrete use case (status=5). Parameter descriptions also include cross-parameter dependencies (e.g., assignedResourceRoleID required alongside assignedResourceID).
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 clearly states 'Update an existing project in Autotask' with the specific verb 'update' and resource 'project'. It distinguishes from sibling tools like autotask_create_project, autotask_search_projects, etc., by its domain (update vs create/search) and resource (project vs ticket, company, etc.).
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?
Description explains partial update behavior ('Only the fields you provide will be updated') and gives a common use case ('set status=5 to mark a project Complete'). It does not explicitly exclude any alternatives, but provides sufficient context for when to use.
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 provided, so description must carry full burden. Description implies a read-only operation (listing) but does not explicitly state side effects or authorization requirements. It is truthful and adequate 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?
Two sentences, concise and front-loaded. First sentence states primary function, second provides use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no input parameters and no output schema, so description need only explain what it does and how results are used. It does that succinctly. A 5 would require explicit mention that output is a list of queues with IDs and names, but the use case is clear enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so schema_description_coverage is 100%. The description adds value by explaining the purpose of the returned data (queue IDs for filtering), which is not obvious from schema alone. No parameter documentation 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?
Description clearly states the tool lists all available ticket queues in Autotask. It specifies the purpose is to find queue IDs for filtering tickets, which is a specific use case that distinguishes it from siblings like 'autotask_search_tickets' or 'autotask_list_ticket_statuses'.
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 to use this tool to find queue IDs for filtering tickets by queue. It does not mention when not to use it or name specific alternatives, but the context is clear given the sibling set includes search tools and other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It implies mutation (update) and closure behavior via the 'complete' field. However, it does not disclose side effects, permissions needed, or other traits, resulting in moderate clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the main purpose and usage. Every sentence provides direct value without 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 an update tool with full schema coverage and no output schema, the description adequately covers what to update and how to close. Given the parameter count (6) and no nested objects, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The description adds context for the 'complete' parameter by explaining its use to close the call, and for status by mentioning picklist ID. This goes beyond the schema descriptions slightly.
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 explicitly states 'Update an existing service call' with specific fields (status, times, description) making the verb and resource clear. It distinguishes from sibling tools like autotask_create_service_call and autotask_delete_service_call by focusing on updates.
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 guidance on when to use (for changes to status, times, description) and how to close a call (set complete: true or update status). Lacks explicit exclusion of alternatives but effectively implies this is the update tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only, listing behavior, and with no annotations provided, it carries the full burden. It states it lists 'all available ticket priorities', which is sufficient. However, it doesn't mention if the list is static or dynamic, but that is minor given the simplicity.
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 every word is necessary. 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?
Given the tool has no parameters, no output schema, and is a simple listing operation, the description is complete enough. It explains what it returns and how to use it. Could include that it returns a list of IDs and names, but not necessary for functionality.
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 0 parameters and schema coverage is 100%, so there is no need for parameter description. Baseline 3 is appropriate as the description adds no additional param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available ticket priorities in Autotask and explicitly mentions its use case: finding priority values for filtering or creating tickets. It uses a specific verb and resource, making it distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'Use this to find priority values for filtering or creating tickets.' This provides clear context without needing exclusions, as there are no alternative tools for listing priorities among siblings.
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?
Without annotations, the description must disclose behavior. It accurately describes the router's function: it suggests a tool and pre-fills parameters based on the user's intent. However, it does not specify limitations, such as whether it only suggests tools from the current server or how it handles ambiguous intents. A minor gap, but generally transparent.
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 concise at two sentences, with the key purpose and usage guideline front-loaded. It could be slightly more structured by separating the usage condition, but overall it is efficient and informative.
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 (one parameter, no output schema), the description covers the essential information: what it does and when to use it. However, it could mention that the tool returns a suggestion (tool name and parameters) rather than executing the action, which would be helpful for an agent. Still, it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'intent'. The description adds meaning by providing natural language examples ('find tickets for Acme Corp', 'log 2 hours on ticket 12345'), which clarifies what kind of input is expected. This adds value beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Intelligent tool router - describe what you want to do and get the right tool suggestion with pre-filled parameters.' This distinguishes it from siblings, which are all direct action tools for specific Autotask operations. The verb 'router' and resource 'tools' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when unsure which tool to call,' providing clear guidance on when to use this alternative to sibling tools. It effectively acts as a meta-tool for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that unfiltered queries are expensive and capped at 10 results, and implies that filtered queries may return more results. This is good transparency, though it does not mention pagination or whether results are ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the key action and follow up with important usage constraints. Every sentence adds distinct value without redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional parameters, no output schema, no nested objects), the description completely addresses the agent's need to select and invoke it correctly. It covers purpose, usage guidance, and behavioral constraints, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, meaning each parameter already has a description. The description adds value by explaining the context of the parameters (why ticketId is recommended) and inferring behavior (capped results). This goes beyond mere schema documentation, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to search for charges on a ticket, defining 'charges' as materials, costs, or expenses. It effectively distinguishes itself from sibling tools like 'autotask_get_ticket_charge' (which retrieves a single charge) and 'autotask_create_ticket_charge' (which creates a charge), making it easy for an agent to select the correct tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong guidance by recommending the use of ticketId and warning against unfiltered queries due to expense and result cap. However, it does not explicitly mention when not to use this tool (e.g., when needing specific charges vs. searching) or alternative tools, leaving some room for improvement.
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 fully conveys that this is a read-only operation (Get). It explains the nature of site configurations (tenant-defined fields) and implies that the tool returns field information. No annotations to contradict, so no contradiction flag.
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?
Three sentences are concise and front-loaded: first sentence states the action, second explains what site configurations are, third provides usage guidance. No 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?
Given the tool has one simple parameter and no output schema, the description is complete enough for an agent to understand the tool's purpose, when to use it, and what it returns (field discovery). It lacks details about the output structure, but that may be acceptable without 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 input schema has one required parameter with 100% description coverage (companyId described as 'The company ID whose site configuration records should be returned'). The description adds context that this is for a company and ties to discovering fields for subsequent updates, but the schema itself is clear.
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 explicitly states it retrieves site configuration records for a company in Autotask, clarifying that these contain tenant-defined fields for per-company configuration data. It also distinguishes its purpose from the sibling tool autotask_update_company_site_configuration by suggesting this tool be called first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool: 'Call this first to discover which fields are available before calling autotask_update_company_site_configuration.' This provides explicit guidance on ordering and alternatives, helping the agent decide to use this tool before the update tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the set of available fields is tenant-defined, which is a key behavioral trait. It also implies the tool is a mutation (update), which is clear. However, it does not mention whether the operation is idempotent, reversible, or what happens on partial failures, slightly reducing 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 three sentences, each serving a distinct purpose: (1) states the action, (2) provides critical prerequisite, (3) specifies the parameters. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity with nested object parameter and no output schema, the description covers the essential aspects: what the tool does, prerequisites, parameter usage, and tenant-specific nature. It is complete enough for an agent to use correctly without additional context.
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 already provides descriptions for both parameters (id and updates), achieving 100% coverage. The description adds value by explaining that updates object keys are tenant-specific and must be discovered via another tool, which goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update fields on a company site configuration record', using a specific verb (update) and resource (company site configuration). It distinguishes from sibling tools by referencing a specific discovery tool (autotask_get_company_site_configuration) and clarifying it uses a site configuration record ID, not a company ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells callers to first call autotask_get_company_site_configuration to discover available fields and current values. It also clarifies to pass site configuration record id (not company id) and an updates object, providing clear prerequisites and usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 explains that data must be base64-encoded due to JSON-RPC, mentions the 3 MB Autotask hard limit, and states that the tool validates size before calling the API and returns clear errors. This is excellent 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 three sentences long, each adding distinct value: purpose, encoding rationale with size limit, and example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not cover return values, but it does explain validation behavior. The tool is simple (upload attachment) and the description covers the key points: what, how (encoding), constraints (size), and gives an example. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description still adds value by clarifying the base64 encoding requirement for the `data` parameter and referencing the 3 MB limit. It also includes a practical example that maps parameter names to values, demonstrating how to call the 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 starts with a specific verb+resource pair: 'Upload a file attachment to an existing ticket.' This clearly distinguishes it from sibling tools, most of which are creates/deletes/updates for other entities or gets/searches. The tool name includes 'create_ticket_attachment,' and the description reinforces that exact action.
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: to attach files to tickets. It does not explicitly state when not to use it or mention alternative tools (e.g., there is no other attachment creation tool among siblings), but it gives strong usage context including the encoding requirement and size limit.
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:

[![autotask-mcp1 MCP server](https://glama.ai/mcp/servers/haxos-anon/autotask-mcp1/badges/card.svg)](https://glama.ai/mcp/servers/haxos-anon/autotask-mcp1)

Score Badge

Copy to your README.md:

[![autotask-mcp1 MCP server](https://glama.ai/mcp/servers/haxos-anon/autotask-mcp1/badges/score.svg)](https://glama.ai/mcp/servers/haxos-anon/autotask-mcp1)

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/haxos-anon/autotask-mcp1'

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