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
The tools are well-differentiated by resource and action, with clear naming like 'create_company' vs. 'search_companies' preventing confusion. However, some overlap exists in note-handling tools (e.g., 'autotask_create_company_note' and 'autotask_search_company_notes') which could cause minor misselection if an agent isn't careful about the specific operation needed.
Naming Consistency5/5
All tools follow a consistent 'autotask_verb_noun' pattern with snake_case, such as 'autotask_create_ticket' and 'autotask_search_time_entries'. This predictability makes it easy for agents to understand and navigate the toolset without confusion from mixed conventions.
Tool Count2/5
With 90 tools, the count is excessive for a single server, making it overwhelming and difficult for agents to manage. While Autotask is a complex platform, this many tools suggests poor scoping, likely leading to inefficiency and confusion in tool selection.
Completeness5/5
The toolset provides comprehensive CRUD and lifecycle coverage across all major Autotask domains (e.g., tickets, projects, companies, time entries), including advanced operations like attachments, charges, and service calls. No obvious gaps exist, ensuring agents can handle full workflows without dead ends.
Average 3.2/5 across 74 of 90 tools scored.
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 is passing
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 the full burden of behavioral disclosure. While 'Search' implies a read-only operation, the description doesn't clarify authentication needs, rate limits, pagination behavior (beyond the pageSize parameter), error handling, or the format of returned results. For a search tool with zero annotation coverage, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action ('Search for opportunities') and includes key qualifiers ('with optional filters'). There's zero waste, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation with four parameters, no annotations, and no output schema, the description is incomplete. It fails to address critical aspects like result format, pagination details beyond pageSize, error scenarios, or how it integrates with sibling tools. For a tool in a rich ecosystem with many alternatives, this minimal description leaves too many open questions for effective agent use.
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, with clear documentation for all four parameters (companyId, searchTerm, status, pageSize). The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain opportunity-specific filtering nuances or default behaviors). Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 'Search for opportunities with optional filters' clearly states the verb ('Search') and resource ('opportunities'), making the basic purpose understandable. However, it doesn't distinguish this tool from other search tools in the sibling list (like autotask_search_companies, autotask_search_tickets, etc.), nor does it specify what kind of opportunities these are (sales, project, etc.). This makes it vague compared to what could be achieved.
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. With many sibling search tools available (e.g., autotask_search_companies, autotask_search_tickets), there's no indication of when opportunities are the appropriate resource to search, what prerequisites might exist, or how this differs from other search operations. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'search' which implies read-only behavior, but doesn't disclose pagination details (implied by pageSize parameter), rate limits, authentication needs, or what the return format looks like. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple search tool and front-loads the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a search operation that likely returns structured results, the description is incomplete. It doesn't explain what the search returns (e.g., note content, metadata, pagination), error conditions, or behavioral constraints. For a tool with 2 parameters and search functionality, 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%, with clear documentation for both parameters (projectId and pageSize). The description adds no additional parameter semantics beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 'Search for notes on a specific project' clearly states the action (search) and resource (notes), but it's vague about scope and doesn't distinguish from sibling tools like 'autotask_search_company_notes' or 'autotask_search_ticket_notes'. It specifies 'on a specific project' which helps, but lacks detail on what type of notes or search criteria beyond project ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'autotask_get_project_note' (which likely retrieves a single note) or other search tools. The description implies usage for notes within a project context, but doesn't specify prerequisites, exclusions, or comparative scenarios with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create' which implies a write/mutation operation, but fails to mention permissions required, whether creation is idempotent, what happens on duplicate names, or what the response contains. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, what values are returned, error conditions, or system behavior. The agent lacks sufficient context to use this tool effectively despite the good schema coverage.
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 9 parameters with clear descriptions. The tool description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation but not exceeding it.
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 ('new company in Autotask'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like autotask_create_contact or autotask_update_company, which would require explicit comparison to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like autotask_update_company or autotask_search_companies. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with insufficient context for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description lacks critical details such as required permissions, whether the note is editable or permanent, any rate limits, or what the response looks like (since there's no output schema). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and appropriately sized for its simple function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a creation tool. It does not address behavioral aspects like permissions, side effects, or response format, which are crucial for an agent to use the tool effectively in a real-world context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters (companyId, title, description, actionType) and their purposes. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage, 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.
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 a new note') and the target resource ('for a company'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'autotask_create_project_note' or 'autotask_create_ticket_note', which perform similar note-creation actions for different 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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple note-creation tools in the sibling list (e.g., for projects, tickets), but the description does not mention any context, prerequisites, or exclusions for choosing this company-specific note tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't mention important behavioral aspects like required permissions, whether the operation is idempotent, what happens on duplicate contacts, or what the response contains. For a creation tool with zero annotation coverage, this represents significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before 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, efficient sentence with zero wasted words. It's appropriately sized for a simple creation operation and front-loads the essential information. Every word earns its place in communicating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permissions, idempotency, or error conditions, nor does it explain what the tool returns. The 100% schema coverage helps with parameters, but the overall context for using this mutation tool remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 6 parameters clearly documented in the schema. The description adds no additional parameter information beyond what's already in the structured schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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 ('new contact in Autotask'), making the purpose unambiguous. However, it doesn't differentiate this tool from other 'create' siblings like autotask_create_company or autotask_create_ticket, which would require mentioning what specifically distinguishes contact creation from other entity creations.
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. With many sibling tools including autotask_search_contacts, there's no indication of when to create versus search, or prerequisites like needing a valid companyID. The description simply states what it does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation, implying it's a write/mutation tool, but doesn't address critical aspects like required permissions, whether the operation is idempotent, what happens on failure, or what the response looks like. For a mutation tool with 10 parameters and no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states exactly what the tool does without any unnecessary words. It's perfectly front-loaded with the core functionality and wastes no space on redundant information. Every word earns its place in this concise formulation.
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 this is a mutation tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, what validation occurs, error conditions, or system behavior. The agent would need to guess about important operational aspects despite the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters well-documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('expense item on an existing expense report'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'autotask_create_expense_report' by specifying it adds items to existing reports rather than creating new reports. However, it doesn't explicitly contrast with other item-creation tools like 'autotask_create_quote_item' or 'autotask_create_ticket_charge'.
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 minimal guidance, only implying usage when you need to add an expense item to an existing report. It doesn't specify when to use this versus creating a new expense report, nor does it mention prerequisites like needing a valid expenseReportId. No explicit alternatives or exclusions are provided, leaving the agent with little contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'create' implying a write operation, but doesn't mention critical details like required permissions, whether the creation is immediate or pending approval, or what happens on success/failure. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and front-loads the core action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after creation, error conditions, or behavioral constraints. Given the complexity of creating financial records, more context about the operation's impact and requirements 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?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create') and resource ('expense report'), making the purpose immediately understandable. It distinguishes from sibling tools like 'autotask_create_expense_item' by specifying the report level rather than individual items, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'autotask_search_expense_reports' or 'autotask_get_expense_report'. The description lacks context about prerequisites, such as whether an expense report requires existing expense items or specific user permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write operation, but fails to mention critical details like required permissions, whether the operation is idempotent, error handling, or what the response looks like (since there's no output schema). This is inadequate for a mutation tool with 15 parameters.
Agents need to know what a tool does to the world before 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 zero wasted words. It is front-loaded and efficiently communicates the core purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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), lack of annotations, and no output schema, the description is insufficient. It does not address behavioral aspects like side effects, error conditions, or return values, leaving significant gaps for the agent to infer. For a creation tool in a business context, more guidance 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?
The schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3. It does not compensate with extra context like default behaviors or interdependencies between 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 action ('Create') and resource ('new sales opportunity in Autotask'), making the purpose immediately understandable. However, it does not differentiate this tool from its sibling 'autotask_create_company' or other create tools, which would require specifying what makes an opportunity distinct from other 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing existing company or contact IDs, or when to choose this over other create tools like 'autotask_create_contact'. This leaves the agent without context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't mention required permissions, whether this operation is reversible, potential side effects, or what happens on success/failure. For a creation tool with zero annotation coverage, this represents a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly communicates the core purpose without any wasted words. It's appropriately sized for a straightforward creation tool and gets directly to the point.
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 creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address what the tool returns upon success, what error conditions might occur, or any prerequisites beyond the required parameters. Given the complexity of creating a project phase in a professional services automation system, more contextual information 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 description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions (e.g., it doesn't clarify relationships between parameters like startDate and dueDate). The baseline score of 3 reflects adequate but not enhanced parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new phase') and resource ('in an Autotask project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling creation tools like 'autotask_create_project' or 'autotask_create_task', which would require mentioning it's specifically for project phases rather than other Autotask 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for creating different Autotask entities (e.g., autotask_create_project, autotask_create_task), there's no indication that this is specifically for adding phases to existing projects rather than creating projects themselves or other related entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't address critical aspects like required permissions, whether the operation is idempotent, rate limits, error handling, or what happens on success (e.g., returns a project ID). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place by conveying the essential action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, 4 required) and lack of annotations or output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., a project ID), error conditions, or behavioral constraints. For a creation tool with significant input requirements, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented in the input schema (e.g., 'Project status (1=New, 2=In Progress, 5=Complete)'). The description adds no additional parameter information beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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') and resource ('new project in Autotask'), making the purpose immediately understandable. It distinguishes from sibling tools like 'autotask_update_project' by specifying creation rather than modification, though it doesn't explicitly contrast with other creation tools like 'autotask_create_company' or 'autotask_create_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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing company ID), when not to use it (e.g., for updating projects), or refer to sibling tools like 'autotask_search_projects' for finding existing projects. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create' which implies a write/mutation operation, but doesn't mention permissions required, whether the operation is idempotent, what happens on failure, or what the response looks like (since no output schema exists). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like error conditions, authentication requirements, or return values. While the schema covers parameters well, the overall context for safe and effective use is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's in the schema (like explaining noteType values or publish visibility options). This meets the baseline expectation when schema coverage is complete.
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 a new note') and target resource ('for a project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'autotask_create_company_note' or 'autotask_create_ticket_note', which follow the same pattern for different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing project), nor does it contrast with related tools such as 'autotask_get_project_note' or 'autotask_search_project_notes' for reading notes. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new quote' implies a write/mutation operation, but the description doesn't mention required permissions, whether the operation is idempotent, what happens on failure, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation (e.g., returns a quote ID), error conditions, or how it fits into broader workflows with sibling tools like 'autotask_create_quote_item'. The combination of missing behavioral context and no output information creates significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters clearly documented in the schema itself (e.g., 'companyId' as required, date formats specified). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage without adding extra 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 the action ('Create') and resource ('a new quote'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'autotask_create_quote_item' or 'autotask_get_quote', which would require mentioning it's for creating the main quote entity rather than quote items or retrieving quotes.
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. With many sibling tools (e.g., 'autotask_create_quote_item' for quote line items, 'autotask_get_quote' for retrieval, 'autotask_search_quotes' for finding existing quotes), there's no indication of prerequisites, typical workflows, or when this creation tool is appropriate versus other quote-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address critical behavioral aspects: required permissions, whether this is an idempotent operation, what happens on failure, rate limits, or what the response contains (since there's no output schema). The additional context about service call purpose is helpful but 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 appropriately concise with two sentences. The first sentence directly states the tool's purpose, and the second provides helpful context about service calls. There's no wasted text, though it could be slightly more structured by front-loading more critical information about behavioral aspects.
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 this is a mutation tool (create operation) with no annotations and no output schema, the description is incomplete. It doesn't address what happens after creation (return values, success/failure responses), authentication requirements, error conditions, or how this tool relates to the broader Autotask workflow. The context about service call purpose is helpful but insufficient for proper agent 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 the schema already documents all 7 parameters thoroughly with descriptions and format examples. The description adds no parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 a new service call') and resource ('in Autotask'), with additional context about what service calls are used for ('schedule and plan work on tickets'). However, it doesn't explicitly differentiate this tool from other 'create' siblings like autotask_create_ticket or autotask_create_task, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions service calls are 'used to schedule and plan work on tickets,' but doesn't specify when to create a service call versus directly working on a ticket or using other scheduling tools. There's no mention of prerequisites, dependencies, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a write operation ('Link'), but doesn't specify permissions required, whether the link is reversible, error conditions, or response format. This leaves significant gaps for a mutation tool, making it inadequate for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero wasted words. It front-loads the core action ('Link a ticket to a service call') and adds clarifying context efficiently. Every sentence earns its place, making it highly readable and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, error handling), usage context, and expected results. For a tool that modifies data, this leaves the agent under-informed about critical operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the input schema. The description adds no additional meaning beyond the schema's 'serviceCallID' and 'ticketID' descriptions. According to the rules, this results in a baseline score of 3, as the schema handles the parameter semantics effectively.
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 purpose: 'Link a ticket to a service call' with the specific action 'associates the ticket with the service call for scheduling purposes.' It distinguishes from sibling tools like autotask_create_service_call (which creates a service call) and autotask_delete_service_call_ticket (which deletes such a link), but doesn't explicitly contrast with all siblings, keeping it at 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing ticket and service call), exclusions, or compare with tools like autotask_search_service_call_tickets. The context 'for scheduling purposes' is vague and doesn't offer practical usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Assign a resource' which implies a write/mutation operation, but fails to disclose critical traits such as required permissions, whether the assignment is reversible, potential side effects (e.g., notifications), or error conditions (e.g., if the resource is already assigned). This leaves significant gaps for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundant information. It is front-loaded and wastes no words, making it easy for an agent to parse quickly. Every part of the sentence earns its place by clarifying the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, side effects), usage context, and what the tool returns upon success or failure. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially given the tool's potential impact on system state.
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 clear descriptions for all three parameters in the input schema. The description adds no additional semantic context beyond what the schema already provides (e.g., it doesn't explain what a 'roleID' entails or provide examples). Given the high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting without extra value from the description.
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 ('Assign') and target ('a resource (technician) to a service call ticket'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'autotask_create_service_call_ticket' or 'autotask_delete_service_call_ticket_resource' by focusing on assignment rather than creation or deletion. However, it doesn't explicitly differentiate from other assignment-related tools in the list, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'autotask_update_service_call' or 'autotask_search_service_call_ticket_resources', nor does it mention prerequisites like needing an existing ticket or resource. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't mention authentication requirements, permission levels, whether the creation is idempotent, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns a task ID), error conditions, or how this tool relates to other task management tools in the sibling list (like autotask_search_tasks). The 100% schema coverage helps with parameters but doesn't compensate for the lack of behavioral and contextual 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?
Schema description coverage is 100%, with all 9 parameters well-documented in the schema itself (including descriptions, types, required fields, and default values). The description adds no parameter information beyond what's in the schema, so it meets the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new task in Autotask'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its many sibling 'create' tools (e.g., autotask_create_company, autotask_create_contact) beyond specifying it's for tasks rather than other Autotask 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for creating different Autotask entities (tasks, companies, contacts, etc.), there's no indication of when a task is appropriate versus other record types, nor any prerequisites or contextual constraints mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new ticket' which implies a write/mutation operation, but it does not disclose any behavioral traits such as required permissions, whether the operation is idempotent, rate limits, error handling, or what the response contains (since there is no output schema). This leaves significant gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action ('Create a new ticket') and specifies the system ('in Autotask'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (21 parameters, no annotations, no output schema), the description is insufficient. It does not explain the return value, error conditions, or behavioral nuances like dependencies between parameters (e.g., assignedResourceID requiring assignedResourceRoleID). The agent must rely heavily on the input schema and external knowledge, which is inadequate for a mutation tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all 21 parameters are documented in the input schema with clear descriptions. The tool description adds no additional parameter information beyond what the schema provides, so it meets the baseline for high schema coverage without compensating 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 the verb ('Create') and resource ('new ticket in Autotask'), making the purpose unambiguous. However, it does not differentiate this tool from other 'create' tools in the sibling list (e.g., autotask_create_company, autotask_create_contact), which would require specifying what makes ticket creation distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., required companyID), when not to use it, or how it relates to sibling tools like autotask_update_ticket or autotask_search_tickets. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create' which implies a write operation, but does not address permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this lack of behavioral context is a significant gap, though it doesn't contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a write operation with 5 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavioral traits, usage context, and output expectations, leaving critical gaps for an agent to invoke the tool correctly in a real-world scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., noteType and publish include enum-like descriptions). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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 the verb ('Create') and resource ('new note for a ticket'), making the purpose evident. It distinguishes itself from sibling tools like 'autotask_create_ticket' or 'autotask_create_ticket_attachment' by specifying notes, but does not explicitly differentiate from 'autotask_create_company_note' or 'autotask_create_project_note' beyond the resource type, which is implied but not stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing ticket), exclusions, or sibling tools like 'autotask_get_ticket_note' or 'autotask_search_ticket_notes' for retrieval, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a quote item, implying a destructive mutation, but fails to mention critical aspects like whether the deletion is permanent, requires specific permissions, affects related data, or has side effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, front-loading the key action and resource. It efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (implied by 'Delete'), lack of annotations, and absence of an output schema, the description is incomplete. It doesn't address behavioral risks, return values, or error conditions, leaving the agent under-informed for a mutation operation in a complex system like Autotask.
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, clearly documenting both parameters ('quoteId' and 'quoteItemId') with their types and roles. The description adds no additional semantic details beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating further.
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 resource ('a quote item (line item) from a quote'), making the purpose specific and understandable. It distinguishes itself from siblings like 'autotask_update_quote_item' by focusing on deletion rather than modification, though it doesn't explicitly contrast with other deletion tools like 'autotask_delete_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to delete a quote item instead of updating it or using other deletion tools. It lacks context on prerequisites, permissions, or typical workflows, leaving the agent without usage direction.
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 states the tool deletes, implying a destructive mutation, but doesn't disclose critical behavioral traits like whether deletion is permanent, requires specific permissions, has side effects (e.g., cascading deletions), or returns confirmation. For a destructive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral context (e.g., permanence, permissions), output format, or error handling. The high schema coverage helps with parameters, but overall context is inadequate for safe and effective use.
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 the parameter 'serviceCallId' fully documented in the schema. The description adds no additional parameter semantics beyond implying the ID is used for deletion. Baseline 3 is appropriate when the schema does the heavy lifting, though no extra value is added.
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 resource ('a service call by ID'), making the purpose specific and unambiguous. However, it doesn't explicitly differentiate from sibling delete tools like 'autotask_delete_service_call_ticket' or 'autotask_delete_quote_item', which would require mentioning it deletes service calls specifically rather than other 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid service call ID), consequences of deletion, or when to choose this over other delete tools in the sibling list. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Delete' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, required permissions, rate limits, error conditions, or what happens to associated data. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized and front-loaded with the essential action. Every word earns its place with zero waste.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects (permanence, permissions), doesn't explain what happens after deletion, and provides no usage context. The 100% schema coverage helps with parameters, but overall context is inadequate for safe tool 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 description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides (ticketId and itemId). According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in description.
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 resource ('a checklist item from a ticket'), providing specific verb+resource. It distinguishes from sibling tools like 'autotask_create_ticket_checklist_item' by specifying deletion rather than creation. However, it doesn't explicitly differentiate from other deletion tools like 'autotask_delete_ticket_charge' beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing existing ticket and checklist item), when deletion is appropriate, or what happens after deletion. Sibling tools include many search and get operations that might be needed first, but this isn't indicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core action ('Get detailed information') without unnecessary words. It efficiently communicates the tool's purpose in a structured manner, with zero waste or redundancy, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what 'detailed information' includes, the response format, error handling, or authentication needs. For a read operation with no structured output documentation, this leaves the agent with insufficient context 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?
The schema description coverage is 100%, with the parameter 'billingItemId' fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'by ID', which is already implied. Since the schema handles parameter documentation effectively, the baseline score of 3 is appropriate, as the description doesn't provide additional semantic 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's purpose with a specific verb ('Get detailed information') and resource ('specific billing item by ID'). It distinguishes from sibling tools like 'autotask_search_billing_items' by focusing on retrieval of a single item rather than search operations. However, it doesn't explicitly contrast with other 'get_' tools (e.g., 'autotask_get_quote_item'), leaving minor ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid billing item ID), compare it to 'autotask_search_billing_items' for broader queries, or indicate scenarios where this tool is preferred (e.g., for known IDs). Usage is implied through the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic operation ('Get...by ID') without mentioning whether this is a read-only operation, what permissions are required, what happens if the ID doesn't exist, rate limits, or response format. For a retrieval tool with zero annotation coverage, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at 6 words: 'Get a specific expense report by ID'. It's front-loaded with the core purpose and contains no unnecessary words or sentences. Every word earns its place in conveying the essential 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 that this is a retrieval tool with no annotations, no output schema, and 100% schema coverage for its single parameter, the description is incomplete. It doesn't explain what information the expense report contains, how to interpret the result, error handling, or how this differs from search operations. The agent would need to guess about the return format and behavioral characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with one parameter ('reportId') fully documented in the schema. The description doesn't add any parameter information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 purpose: 'Get a specific expense report by ID'. It specifies the verb ('Get') and resource ('expense report'), but doesn't differentiate it from sibling tools like 'autotask_get_ticket_details' or 'autotask_get_quote', which follow the same 'get X by ID' pattern. The purpose is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'autotask_search_expense_reports' for listing multiple reports or other 'get_' tools for different resources. There's no context about prerequisites, error conditions, or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication requirements, error handling (e.g., what happens if IDs are invalid), rate limits, or the format of the returned note. This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's front-loaded with the core action and resources, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., note content, metadata), error conditions, or behavioral constraints. For a retrieval tool with no structured output information, this leaves the agent without crucial context for proper 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 description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain the relationship between projectId and noteId or provide examples). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific project note'), specifying it requires both project ID and note ID. However, it doesn't explicitly differentiate from sibling tools like 'autotask_get_company_note' or 'autotask_get_ticket_note' which retrieve different types of notes, though the 'project' prefix in the tool name provides some implicit distinction.
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 doesn't mention when to use this versus 'autotask_search_project_notes' (which likely retrieves multiple notes) or other note retrieval tools, nor does it specify prerequisites like needing existing project and note IDs.
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. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns full or partial data, or handles errors. For a tool with no annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration. Every word earns its place in this minimal but complete statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't describe what data is returned (quote fields, status, pricing), error conditions (invalid ID, permissions), or how this differs from search operations. Given the lack of structured metadata, the description should provide more operational 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%, with the single parameter 'quoteId' clearly documented in the schema. The description adds no additional parameter context beyond implying ID-based retrieval. Since the schema already fully describes the parameter, the baseline score of 3 is appropriate—the description doesn't add value but doesn't need to compensate for gaps.
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') and resource ('a specific quote by ID'), making the purpose immediately understandable. It distinguishes this as a retrieval operation rather than creation or search. However, it doesn't explicitly differentiate from sibling tools like 'autotask_get_quote_item' or 'autotask_search_quotes', which would require more specific language about scope.
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. With sibling tools like 'autotask_search_quotes' (for finding multiple quotes) and 'autotask_get_quote_item' (for quote line items), the agent has no indication whether this is for single-record lookup by known ID versus broader queries. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), which implies it's non-destructive, but doesn't mention potential errors (e.g., invalid ID), authentication needs, rate limits, or the return format. This leaves significant gaps for an agent to understand how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the core action ('Get a specific quote item') and efficiently specifies the key constraint ('by ID'), making it easy to parse and understand immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'quote item' entails in this context, what data is returned, or how errors are handled. Given the complexity implied by sibling tools (e.g., create, update, delete operations), more context is needed for an agent to use this 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%, with the single parameter 'quoteItemId' fully documented in the schema. The description adds no additional meaning beyond implying the ID is used for retrieval, which is already clear from the schema. This meets the baseline score of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific quote item by ID'), making the purpose unambiguous. It doesn't explicitly differentiate from sibling tools like 'autotask_get_quote' or 'autotask_search_quote_items', but the specificity of 'by ID' versus broader retrieval methods 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?
No guidance is provided on when to use this tool versus alternatives like 'autotask_get_quote' (for the parent quote) or 'autotask_search_quote_items' (for multiple items). The description assumes the user already knows they need a specific item by ID, offering no context on prerequisites or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, what happens if the service ID doesn't exist (error behavior), rate limits, or what format the returned service data takes. For a retrieval tool with zero annotation coverage, 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?
The description is extremely concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place by specifying the action and key constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the Autotask ecosystem with many sibling tools, no annotations, and no output schema, the description is incomplete. It doesn't help an agent understand how this tool fits within the broader toolset, what authentication is required, error conditions, or return format - all critical for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions retrieving by ID, which aligns with the single 'serviceId' parameter. With 100% schema description coverage (the schema already documents 'The service ID to retrieve'), the description adds minimal value beyond what's in the structured schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific service'), making the purpose understandable. However, it doesn't differentiate from sibling tools like autotask_search_services or autotask_get_service_bundle, which could cause confusion about when to use this specific retrieval tool versus search alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools including autotask_search_services and autotask_get_service_bundle, there's no indication whether this is for exact ID-based retrieval versus broader searches, or when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify aspects like authentication requirements, error handling (e.g., what happens if the ID is invalid), rate limits, or the format of returned data. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., read-only nature, error conditions), usage context compared to siblings, and what the return value contains. While concise, it doesn't provide enough information for an agent to confidently invoke the tool in a real-world scenario.
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, with the single parameter 'serviceBundleId' clearly documented as 'The service bundle ID to retrieve'. The description adds no additional parameter details beyond what the schema provides, such as ID format or examples. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific service bundle by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'autotask_search_service_bundles' or 'autotask_get_service', which would require mentioning this is for retrieving a single entity by identifier rather than searching or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'autotask_search_service_bundles' for broader queries or 'autotask_get_service' for individual services, nor does it specify prerequisites such as needing a valid ID. This leaves the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a service call but doesn't mention whether this is a read-only operation, what permissions are required, how errors are handled (e.g., invalid ID), or the format of returned data. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the essential information ('Get a specific service call') efficiently, making it easy to parse and understand immediately.
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 incomplete. It doesn't explain what data is returned, potential side effects, error handling, or how it fits within the broader context of sibling tools. For a retrieval tool with no structured output documentation, more detail is needed to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'serviceCallId' clearly documented as 'The service call ID to retrieve.' The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high coverage, resulting in the baseline score.
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') and resource ('a specific service call by ID'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'autotask_search_service_calls' or 'autotask_get_ticket_details', which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'autotask_search_service_calls' for multiple records or other 'get_' tools for different entities. It lacks any context about prerequisites, error conditions, 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves an attachment but lacks details on permissions, rate limits, error handling, or response format. For a read operation with zero annotation coverage, this is insufficient to guide the agent effectively.
Agents need to know what a tool does to the world before 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and parameters, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, response structure, or error cases. For a tool with 3 parameters and no structured output information, more context is needed to ensure reliable use by 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 schema fully documents all three parameters. The description mentions 'ticket ID and attachment ID' but doesn't add meaning beyond what the schema provides for 'ticketId' and 'attachmentId', nor does it explain 'includeData'. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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') and target ('a specific ticket attachment') with identifiers ('by ticket ID and attachment ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'autotask_search_ticket_attachments' or 'autotask_create_ticket_attachment', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'autotask_search_ticket_attachments' for listing attachments or 'autotask_get_ticket_details' for broader ticket information, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a retrieval operation ('Get'), implying read-only behavior, but doesn't specify authentication requirements, rate limits, error handling, or what the return format looks like. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content.
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 retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what data is returned, error scenarios, or how it fits into the broader context of ticket management alongside sibling tools, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'chargeId' fully documented in the schema. The description adds no additional parameter details beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific ticket charge by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'autotask_search_ticket_charges' or 'autotask_get_ticket_details', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, error conditions, or how it differs from search tools in the sibling list, leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation (implying read-only), but doesn't mention pagination behavior, rate limits, authentication requirements, error conditions, or what the return format looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential 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 no annotations, no output schema, and the description provides minimal behavioral context, this is incomplete. For a list operation that likely returns structured data, the description should at minimum hint at the return format or pagination behavior to help the agent understand what to expect.
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 fully documents both parameters (projectID and pageSize). The description adds no additional parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is high.
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') and resource ('phases for a project in Autotask'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar list/search tools in the sibling set (like autotask_search_projects or autotask_list_categories), which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when-not-to-use scenarios, or comparison to sibling tools like autotask_search_projects or other list/search operations. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a search operation but doesn't describe whether it's read-only, paginated (though schema hints at this), rate-limited, or has authentication requirements. The mention of 'multi-level approval records' adds some context, but key behavioral traits like response format or error handling are missing.
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 efficiently structured in two sentences: the first states the core purpose, the second adds context about approval workflows. There's no wasted language, though it could be slightly more front-loaded with key usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It explains what's being searched but lacks information about return values, pagination behavior (beyond schema hints), or typical use cases. The absence of annotations means the description should do more to compensate, but it doesn't.
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 fully documents all 7 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'timeEntryId' and 'approvalLevel'). The baseline score of 3 reflects adequate coverage through the schema alone.
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 purpose: 'Search for billing item approval levels' with the specific resource identified. It distinguishes from siblings by focusing on approval levels rather than other billing items or entities, though it doesn't explicitly contrast with 'autotask_search_billing_items' which might search different aspects of 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'enabling visibility into tiered approval workflows' but doesn't specify use cases, prerequisites, or differentiate from other search tools in the sibling list (e.g., 'autotask_search_billing_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 are provided, so the description carries full burden. It mentions 'Search' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, how results are returned (e.g., pagination, sorting), or potential rate limits. The description is minimal and lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (e.g., note content, metadata), how results are structured, or any limitations. For a search tool with no structured output documentation, 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%, with clear documentation for both parameters (companyId and pageSize). The description adds no additional meaning beyond the schema, such as explaining what 'notes' entail or search criteria. Baseline 3 is appropriate since the schema adequately covers parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for notes') and target resource ('on a specific company'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'autotask_search_project_notes' or 'autotask_search_ticket_notes' that search notes on different entities, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid company ID), exclusions, or comparisons to similar tools like 'autotask_get_company_note' (which might retrieve a single note) or other search tools in the sibling list.
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 states this is a search operation but doesn't disclose behavioral traits like whether it's read-only, pagination behavior (beyond the pageSize parameter), rate limits, authentication requirements, or what happens with no results. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before 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, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a search operation with 5 parameters, the description is incomplete. It doesn't explain what configuration items are, what the search returns, or behavioral aspects like pagination or error handling. For a tool in a complex ecosystem with many siblings, more context is needed to guide effective use.
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 5 parameters thoroughly. The description adds no additional meaning beyond mentioning 'optional filters' generically. This meets the baseline of 3 where the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for') and resource ('configuration items in Autotask'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other search tools in the sibling list (like autotask_search_companies, autotask_search_tickets, etc.), missing specific differentiation about what makes configuration item search unique.
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 mentions 'optional filters' but provides no guidance on when to use this tool versus alternatives. With many sibling search tools available, there's no indication of specific use cases, prerequisites, or comparisons to other search functions (e.g., when to search configuration items vs. companies).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions pagination defaults (25 results per page) and the page parameter, which is useful. However, it omits critical details such as search scope (e.g., partial vs. exact matches), error handling, authentication requirements, rate limits, or whether it's a read-only operation. For a search tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose. Both sentences are relevant: the first states the tool's function, and the second provides pagination details. There is no wasted text, though it could be slightly more structured (e.g., separating purpose from behavioral notes).
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 incomplete. It covers basic pagination but misses key contextual elements like search behavior (e.g., fuzzy matching), result format, error conditions, or integration with sibling tools. For a search tool with 5 parameters and no structured output, more guidance is needed to ensure proper agent 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 the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond implying pagination usage. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance understanding of the 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 tool's purpose: 'Search for contacts in Autotask.' It specifies the verb ('Search') and resource ('contacts in Autotask'), making the function unambiguous. However, it does not differentiate from sibling search tools like autotask_search_companies or autotask_search_tickets, which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions pagination details but does not specify use cases, prerequisites, or exclusions. With many sibling tools available, this lack of context leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it's a search operation. It lacks details on behavioral traits like pagination (implied by pageSize but not explained), rate limits, authentication needs, or response format, which are critical for a search tool with 4 parameters.
Agents need to know what a tool does to the world before 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like result format, error handling, or usage context, leaving significant gaps 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%, so the schema fully documents each parameter. The description adds no extra meaning beyond mentioning 'optional filters,' which is already implied by the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('contracts in Autotask'), making the purpose evident. It distinguishes from siblings by specifying contracts rather than other entities like companies or tickets, though it doesn't explicitly contrast with similar search tools (e.g., autotask_search_companies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions 'optional filters' but doesn't specify scenarios, prerequisites, or exclusions, leaving the agent without context for selection among many sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for searching, implying a read-only operation, but doesn't mention pagination behavior, rate limits, authentication requirements, or what the response looks like (e.g., list format). This leaves significant gaps for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to understand at a glance.
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 incomplete. It doesn't explain the return format, pagination, or error handling, which are critical for a search tool. While the schema covers parameters well, the overall context for proper tool invocation is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for each parameter (submitterId, status with enum mapping, pageSize with defaults and limits). The description adds no additional parameter semantics beyond 'optional filters,' which is already implied by the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search for expense reports with optional filters,' which specifies the verb (search) and resource (expense reports). It distinguishes itself from sibling tools like autotask_create_expense_report and autotask_get_expense_report by focusing on search functionality, though it doesn't explicitly mention these alternatives in 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, such as autotask_get_expense_report for retrieving a specific report or autotask_search_time_entries for other search operations. It mentions 'optional filters' but doesn't specify scenarios or prerequisites for 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 are provided, so the description carries full burden. It states it's a search operation but doesn't disclose behavioral traits like pagination (implied by pageSize but not explained), rate limits, authentication needs, or what happens on no results. For a search tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return format, error handling, or behavioral context, making it inadequate for the agent to fully understand how to use this 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 schema fully documents all 4 parameters. The description adds no additional parameter semantics beyond mentioning 'optional filters', which is already implied by the schema. This meets the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('invoices in Autotask'), making the purpose specific and understandable. However, it doesn't distinguish this tool from its many sibling search tools (e.g., autotask_search_companies, autotask_search_tickets) beyond mentioning invoices, which is adequate but not optimal for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'optional filters' but doesn't specify contexts, prerequisites, or exclusions. Given the numerous sibling tools, this lack of differentiation leaves the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'optional filters' which hints at flexibility, but doesn't describe what the tool returns (product list? details?), whether results are paginated (implied by pageSize parameter but not stated), authentication requirements, rate limits, or any side effects. For a search tool with zero annotation coverage, 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?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a search tool and gets straight to the point.
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 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a 'product' in this context, what fields are searchable beyond name, what the return format looks like, or any limitations. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond mentioning 'optional filters' generally. This meets the baseline of 3 when the schema does the heavy lifting, but doesn't provide extra context about how parameters interact or typical usage patterns.
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 ('Search') and resource ('products'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other search tools in the sibling list (like autotask_search_companies, autotask_search_services, etc.), which all follow the same 'search for X with optional filters' pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this search is appropriate versus other product-related tools (like autotask_get_product), or any contextual limitations. The phrase 'with optional filters' is descriptive but doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it's a search operation. It doesn't disclose behavioral traits like pagination (implied by pageSize but not explained), rate limits, authentication needs, or what happens with multiple filters. This leaves significant gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the core functionality without unnecessary elaboration.
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 3 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain return format, error handling, or how multiple filters interact. Given the complexity and lack of structured support, more context is needed for effective use.
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 fully documents all parameters. The description adds no additional meaning beyond implying quoteId is a common filter, which is already covered in the schema's 'recommended' note. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('quote items'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'autotask_get_quote_item' or 'autotask_search_quotes', which could cause confusion about scope.
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 minimal guidance with 'typically filtered by quote ID', but lacks explicit when-to-use rules, alternatives, or exclusions. No mention of when to use this versus other search or get tools for quote-related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a search tool with optional filters, implying read-only behavior, but doesn't disclose critical details like pagination handling (beyond the 'pageSize' parameter in schema), rate limits, authentication requirements, or what the return format looks like (especially since there's no output schema). The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Search for quotes with optional filters'. It's front-loaded with the core purpose and wastes no words, making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search operation with 5 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return structure, pagination behavior beyond 'pageSize', error conditions, or how search results are ordered. For a search tool with multiple filters, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 5 parameters well-documented in the input schema (e.g., 'companyId' for filtering by company ID). The description adds no additional parameter semantics beyond stating 'optional filters', which is already implied by the schema. This meets the baseline of 3 for high schema coverage without extra value from the description.
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 purpose as 'Search for quotes with optional filters', which specifies the verb (search) and resource (quotes). It distinguishes from other quote-related tools like 'autotask_get_quote' (which likely retrieves a single quote) by emphasizing search functionality, though it doesn't explicitly differentiate from other search tools like 'autotask_search_companies' beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'autotask_get_quote' for single quotes or other search tools for different resources, nor does it specify prerequisites or exclusions. Usage is implied only by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions pagination behavior (25 results per page default, use page parameter for more), which is useful, but lacks critical details like whether this is a read-only operation, authentication requirements, rate limits, or error handling. For a search tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core purpose. It could be slightly improved by integrating the pagination detail more seamlessly, but it's efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a search tool with behavioral nuances, the description is incomplete. It covers pagination but misses key context like return format, error conditions, or how results are ordered, leaving significant gaps 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%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline 3 for high 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 verb ('Search') and resource ('resources (users) in Autotask'), making the purpose explicit. However, it doesn't differentiate from sibling search tools like autotask_search_companies or autotask_search_contacts, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description mentions pagination but doesn't explain when to use this specific resource search over other search tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a search operation but doesn't describe key behaviors: whether it's read-only (implied but not explicit), pagination details beyond the 'pageSize' parameter, rate limits, authentication requirements, error conditions, or the format/structure of results. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before 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, efficient sentence that front-loads the core purpose ('Search for service bundles') and adds a brief qualifier ('with optional filters'). There is zero waste or redundancy, making it easy to parse quickly while conveying the essential 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 complexity of a search operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what a 'service bundle' is in this context, the expected return format (e.g., list of objects, paginated results), error handling, or any behavioral nuances. For a tool that likely returns structured data, the lack of output schema means the description should compensate more, which it fails to do.
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 ('searchTerm', 'isActive', 'pageSize') with clear descriptions and constraints. The description adds no additional semantic context beyond mentioning 'optional filters', which is redundant with the schema's optional parameters. This meets the baseline of 3 where the schema does the heavy lifting, but the description doesn't enhance understanding of parameter usage or interactions.
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 ('Search') and resource ('service bundles'), making the purpose immediately understandable. It distinguishes from sibling tools like 'autotask_get_service_bundle' (singular retrieval) by specifying search functionality with filters. However, it doesn't explicitly differentiate from other search tools like 'autotask_search_services' or 'autotask_search_products' beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'autotask_get_service_bundle' (for specific retrieval) or other search tools, nor does it specify any prerequisites, context requirements, or typical use cases. The phrase 'with optional filters' hints at flexibility but offers no decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a search operation but doesn't describe what kind of search (exact match, partial, etc.), whether it's paginated, what authentication is required, rate limits, or what the return format looks like. 'Search' implies read-only, but this isn't explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a search tool with good schema documentation.
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 3 parameters and no annotations or output schema, the description is insufficient. It doesn't explain the search behavior (filtering logic), result format, pagination, or how parameters interact. With no output schema, the description should ideally indicate what information is returned.
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 with clear descriptions. The description doesn't add any additional parameter context beyond what's in the schema, such as explaining relationships between parameters or providing examples of valid values.
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 ('Search for') and target ('resource assignments on service call tickets'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling search tools like 'autotask_search_resources' or 'autotask_search_service_call_tickets', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling search tools available (like autotask_search_resources, autotask_search_service_call_tickets), there's no indication of what makes this specific search distinct or when it's the appropriate choice.
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 'optional filters' but doesn't disclose behavioral traits like pagination behavior (implied by pageSize but not explained), rate limits, authentication requirements, error handling, or what 'search' entails (e.g., partial matches, case sensitivity). For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before 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, efficient sentence with zero wasted words. It's front-loaded with the core action ('Search for services') and includes essential qualifiers ('with optional filters'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a search operation with potential complexity (filtering, pagination), the description is incomplete. It lacks details on return format, error conditions, or behavioral context needed for an AI agent to use it effectively beyond basic parameter passing.
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 fully documents all three parameters (searchTerm, isActive, pageSize). The description adds no additional parameter semantics beyond implying filtering capability, which is already covered by the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('services') with scope ('with optional filters'), making the purpose immediately understandable. However, it doesn't differentiate from sibling search tools like 'autotask_search_companies' or 'autotask_search_products' beyond the resource type, missing explicit sibling distinction.
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. With many sibling search tools available (e.g., autotask_search_companies, autotask_search_products), there's no indication of context, prerequisites, or exclusions for selecting this specific service search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'Search' which implies a read-only operation, but doesn't specify whether it's paginated, returns metadata vs. file content, requires authentication, has rate limits, or what happens with invalid ticket IDs. This leaves significant gaps for a tool with potential complexity.
Agents need to know what a tool does to the world before 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 zero wasted words. It's front-loaded with the core purpose and appropriately sized for what it communicates, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the search returns (attachment metadata, files, or both), how results are structured, pagination behavior, or error handling. Given the context of sibling tools that include various search operations, more completeness 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 schema already fully documents both parameters (ticketId and pageSize with defaults/limits). The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage but not providing extra 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 the verb ('Search') and resource ('attachments on a specific ticket'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'autotask_get_ticket_attachment' (singular vs. plural search) or 'autotask_search_tickets' (tickets vs. attachments), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a valid ticket ID), comparison to 'autotask_get_ticket_attachment' for single attachments, or when searching attachments is appropriate versus other search tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Search' implies a read operation, the description doesn't specify whether this is paginated, what format results return, authentication requirements, rate limits, or any other behavioral traits. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple search tool and front-loads the essential information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (note content, metadata, format), whether results are filtered/sorted, or any behavioral context. The 100% schema coverage helps with inputs, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema (ticketId and pageSize with defaults/limits). This meets the baseline 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search for notes') and target resource ('on a specific ticket'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'autotask_search_ticket_attachments' or 'autotask_get_ticket_note', which would require explicit differentiation to earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of when this search tool should be used instead of 'autotask_get_ticket_note' (which appears to retrieve a single note) or other related search tools, nor any context about prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but fails to mention critical details such as required permissions, whether changes are reversible, rate limits, or what the response looks like (especially since there's no output schema). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to stating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., side effects, error handling), usage context, and output expectations, leaving the agent under-informed for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 8 parameters well-documented in the input schema. The description adds no additional parameter information beyond implying an 'id' is needed for updating, which is already covered by the schema. This meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing company in Autotask'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'autotask_update_company_site_configuration' or 'autotask_update_project', which would require specifying what distinguishes updating a company from other update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing company ID), exclusions (e.g., what cannot be updated), or comparisons to siblings like 'autotask_create_company' or 'autotask_search_companies', leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundancy or unnecessary elaboration. It's appropriately sized for a straightforward update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It lacks critical context such as error handling, response format, side effects, or dependencies on other tools. The agent would struggle to use this effectively without additional behavioral 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?
Schema description coverage is 100%, so the schema already documents all 8 parameters with clear descriptions. The description adds minimal value by listing examples ('quantity, price, etc.') but doesn't provide additional context like units, constraints, or interactions between parameters. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing quote item'), with examples of what can be updated ('quantity, price, etc.'). It distinguishes from sibling tools like 'autotask_create_quote_item' and 'autotask_delete_quote_item' by specifying it's for updating existing items, though it doesn't explicitly differentiate from other update tools like 'autotask_update_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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a quote item ID), when not to use it (e.g., for creating new items), or refer to sibling tools like 'autotask_get_quote_item' for retrieving items first. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Only fields provided will be changed,' which is useful partial-update behavior, but lacks critical information: whether this is a destructive mutation, what permissions are required, if there are rate limits, what happens on success/failure, or the response format. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the core action and a key behavioral trait ('Only fields provided will be changed'). There's no wasted verbiage, and it's front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It lacks behavioral context (e.g., side effects, error handling), usage guidance relative to siblings, and any information about return values. The partial-update hint is helpful but insufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds no additional parameter semantics beyond implying partial updates apply to all fields. This meets the baseline of 3 where the schema does the heavy lifting, but the description doesn't enhance understanding of parameter interactions 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?
The description clearly states the verb ('Update') and resource ('existing ticket charge'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'autotask_update_ticket' or 'autotask_create_ticket_charge', which would require mentioning it's specifically for modifying charges rather than tickets or creating new charges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing charge ID), compare to 'autotask_create_ticket_charge' for new charges, or indicate when partial updates are appropriate versus full replacements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions what can be updated (text, completion status, position) but doesn't cover important aspects like required permissions, whether updates are reversible, error handling, or what happens when only some fields are provided. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's front-loaded with the main action and clearly lists the three update operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral constraints. While the schema covers parameters well, the overall context for using this tool remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by listing the types of updates possible (edit text, mark complete/incomplete, change position), which loosely maps to parameters but doesn't provide additional syntax or format details 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 verb ('update') and resource ('checklist item on a ticket'), making the purpose immediately understandable. It distinguishes from sibling tools like 'autotask_create_ticket_checklist_item' by focusing on updates rather than creation, though it doesn't explicitly mention this distinction.
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 'autotask_update_ticket' or other update tools. It doesn't mention prerequisites, dependencies, or contextual constraints for updating 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?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether this is a mutating operation (implied by 'Add'), what permissions are required, potential side effects (e.g., affecting ticket status), rate limits, or error conditions. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond the simple action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it immediately understandable without unnecessary elaboration. Every word earns its place by directly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a creation operation with 4 parameters), no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidance, and output details. The schema covers parameters well, but overall completeness is limited to the basic action without supporting information for effective use.
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 fully documents all 4 parameters (ticketId, itemName, position, isCompleted). The description adds no parameter-specific information beyond what's in the schema, such as format examples or constraints. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('checklist item to a ticket'), making the purpose immediately understandable. It distinguishes this tool from sibling tools like 'autotask_create_ticket' or 'autotask_update_ticket_checklist_item' by specifying it's for adding checklist items rather than creating tickets or updating existing checklist items. However, it doesn't explicitly mention it's for creating new items versus other checklist operations, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing ticket), exclusions (e.g., not for updating items), or refer to sibling tools like 'autotask_update_ticket_checklist_item' for modifications or 'autotask_delete_ticket_checklist_item' for removal. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation ('Get'), but doesn't disclose behavioral traits like error handling (e.g., what happens if IDs are invalid), authentication requirements, rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 required parameters, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it lacks details on behavioral aspects and return values. For a simple retrieval tool, this is passable but leaves room for improvement in transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond stating that parameters are needed to retrieve the note, which is already implied by the schema. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('a specific company note'), specifying it requires company ID and note ID. It distinguishes from sibling tools like 'autotask_search_company_notes' by focusing on retrieval of a single note rather than searching multiple notes. However, it doesn't explicitly contrast with other get tools (e.g., 'autotask_get_project_note'), so it's not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'autotask_search_company_notes' for single-note retrieval or clarify prerequisites like needing valid IDs. Without such context, the agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying it's likely read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens on errors (e.g., invalid ID). For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, error handling, or output format, which would be helpful for an agent to use it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions retrieving by 'ID', which aligns with the single parameter 'opportunityId' in the schema. Since schema description coverage is 100%, the schema already documents this parameter fully. The description adds minimal value beyond what's in the schema, meeting the baseline for high 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 verb ('Get') and resource ('a specific opportunity by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'autotask_search_opportunities' or 'autotask_get_quote', which are similar retrieval operations for different entities or search patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'autotask_search_opportunities' for broader searches or prerequisites such as needing a specific opportunity ID. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states a read operation ('Get'), which implies non-destructive behavior, but doesn't disclose authentication needs, rate limits, error handling, or response format. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—front-loaded and appropriately sized for a simple retrieval tool. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 100% schema coverage but no annotations or output schema, the description is minimally adequate. It clarifies the purpose but lacks behavioral details and usage context, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'productId' fully documented in the schema. The description adds no additional meaning beyond implying the ID is used for retrieval, matching the baseline for high 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 verb ('Get') and resource ('product'), specifying it retrieves a specific product by ID. It distinguishes from sibling search tools (e.g., autotask_search_products) by focusing on retrieval of a single item, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like autotask_search_products or other get_* tools. The description implies usage when you have a specific product ID, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get' implies a read operation, but doesn't mention whether it's safe (non-destructive), requires authentication, has rate limits, or what the return format looks like. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with zero waste. Every word contributes directly to understanding the tool's function, making it appropriately sized for a simple retrieval 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 tool's low complexity (2 required parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks behavioral details and usage context. Without annotations or output schema, more guidance on what the tool returns or how it behaves 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?
The schema description coverage is 100%, with both parameters clearly documented in the input schema. The description adds no additional meaning beyond what the schema provides, such as format details or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a specific ticket note', specifying it requires both ticket ID and note ID. It distinguishes from sibling tools like 'autotask_search_ticket_notes' (which likely searches multiple notes) by focusing on retrieval of a single note, though it doesn't explicitly name that sibling for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'autotask_search_ticket_notes' for searching notes or 'autotask_get_ticket_details' for broader ticket information. It lacks context on prerequisites or typical use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses pagination behavior (25 results per page default, use page parameter for more), which is useful. However, it doesn't mention authentication requirements, rate limits, error conditions, or what the return format looks like (only that it 'returns 25 results per page'). For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states the core purpose, second adds crucial behavioral detail about pagination. Every word earns its place, and information is front-loaded appropriately.
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 search tool with 6 parameters and no output schema, the description is adequate but has clear gaps. It covers the basic purpose and pagination behavior, but doesn't explain search scope, result format, or how to interpret results. With no annotations and no output schema, more context about what 'search' actually means and what gets returned 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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema - it mentions the page parameter and default page size, but doesn't explain search semantics, filtering logic, or how parameters interact. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('tasks in Autotask'), making the purpose evident. It distinguishes from siblings by focusing on tasks rather than other entities like companies or tickets, but doesn't explicitly differentiate from other search tools (e.g., 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?
The description provides no guidance on when to use this tool versus alternatives. It mentions pagination but doesn't specify when to use search vs. get operations, or how it differs from other search tools in the sibling list. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool tests the connection but doesn't describe what 'testing' entails—whether it validates credentials, checks network reachability, verifies API endpoints, or returns specific status information. For a connectivity tool with zero annotation coverage, this is a significant gap in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence: 'Test the connection to Autotask API'. It is front-loaded with the core action, has zero wasted words, and efficiently communicates the essential purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is minimal but insufficient. It lacks details on what the test involves, what output to expect (e.g., success/failure status, error messages), or behavioral traits. For a connectivity tool with no annotations, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't mention parameters, which is correct for this case. A baseline of 4 is applied since no parameter information is needed, and the description doesn't incorrectly reference any.
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 purpose: 'Test the connection to Autotask API'. It uses a specific verb ('Test') and identifies the target resource ('Autotask API'), making the action unambiguous. However, it doesn't explicitly differentiate from sibling tools, which are all data operations rather than connectivity tests, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication setup), typical use cases (e.g., troubleshooting connectivity issues), or relationships to other tools (e.g., whether it should be run before other operations). This leaves the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs a deletion ('Remove'), implying a destructive mutation, but fails to disclose critical traits such as whether the action is reversible, what permissions are required, if it affects related data, or what happens on success/failure. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Remove a ticket association from a service call') without any wasted words. It is appropriately sized for a tool with one parameter and clear purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a deletion operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits (e.g., irreversibility, side effects), usage context, and expected outcomes. For a mutation tool, this leaves the agent with incomplete information to invoke it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'serviceCallTicketId' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param info in the 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 specific action ('Remove a ticket association from a service call') and the resource ('by the service call ticket record ID'), distinguishing it from sibling tools like autotask_delete_service_call (which deletes the entire service call) or autotask_delete_service_call_ticket_resource (which removes a resource association). It uses precise terminology that matches the tool's name and schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as autotask_delete_service_call or autotask_delete_ticket_charge, nor does it mention prerequisites like needing an existing service call ticket record ID. It lacks explicit when/when-not instructions or references to sibling tools, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that deletion requires specific IDs, but lacks details on permissions, reversibility, side effects (e.g., impact on billing), or response behavior. For a destructive operation, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and has zero wasted words. Every sentence directly contributes to understanding the tool's purpose and requirements.
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 destructive delete operation with no annotations and no output schema, the description is insufficient. It misses critical details like confirmation prompts, error handling, or what happens post-deletion, leaving gaps for safe agent 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 description coverage is 100%, with clear parameter descriptions in the schema. The description adds minimal value by reiterating that both IDs are required, but doesn't provide additional context like format examples or validation rules beyond what the schema already documents.
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 resource ('ticket charge by ID'), making the purpose unambiguous. It distinguishes from sibling tools like 'autotask_create_ticket_charge' and 'autotask_update_ticket_charge' by specifying deletion, though it doesn't explicitly contrast with other delete operations (e.g., 'autotask_delete_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 by stating 'Requires both the parent ticket ID and charge ID,' which suggests prerequisites but doesn't explicitly guide when to use this tool versus alternatives like updating or searching for charges. No explicit when-not-to-use or sibling alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'detailed information' and 'full ticket data,' but doesn't cover critical aspects like whether this is a read-only operation (implied by 'Get'), error handling, rate limits, or authentication requirements. For a tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences: one stating the purpose and another providing usage guidance. It's front-loaded with the core function and avoids unnecessary details. However, the second sentence could be slightly more specific to enhance clarity without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and hints at usage, but lacks details on behavioral traits, error cases, or output format. Without annotations or output schema, more context would be beneficial for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('ticketID' and 'fullDetails') thoroughly. The description adds minimal value by implying 'full ticket data' relates to the 'fullDetails' parameter, but doesn't provide additional context beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 purpose: 'Get detailed information for a specific ticket by ID.' It specifies the verb ('Get'), resource ('ticket'), and identifier ('by ID'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'autotask_search_tickets' or 'autotask_get_ticket_attachment', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance with 'Use this for full ticket data when needed,' which implies this tool is for detailed retrieval rather than searching or listing. However, it doesn't explicitly state when to use alternatives (e.g., 'autotask_search_tickets' for filtering multiple tickets) or mention prerequisites like authentication, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that results are paginated (25 per page default), which is useful behavioral context. However, it doesn't mention other important traits like whether this is a read-only operation (implied by 'search'), authentication requirements, rate limits, error handling, or what the return format looks like (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that each add value: the first defines the tool's purpose and domain context, the second provides important behavioral information about pagination. No wasted words, though it could be slightly more structured by separating purpose from constraints.
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 search tool with 12 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate basic context (what's being searched and pagination behavior). However, it lacks information about return format, error conditions, and when to use versus sibling tools, leaving some gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 fully documents all 12 parameters. The description adds no parameter-specific information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 billing items in Autotask and explains what billing items represent (approved and posted billable items from the 'Approve and Post' workflow). It specifies the verb 'search' and resource 'billing items' but doesn't explicitly differentiate from sibling tools like autotask_search_invoices or autotask_search_ticket_charges, which might have overlapping domains.
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. With many sibling search tools (e.g., autotask_search_invoices, autotask_search_ticket_charges), there's no indication of when billing item search is appropriate versus other search types, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Only fields provided will be changed,' which is useful partial information about partial updates. However, it lacks critical details like whether this is a destructive operation, what permissions are required, error handling, or what the response looks like (no output schema exists).
Agents need to know what a tool does to the world before 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, efficient sentence that directly states the tool's function and a key behavioral constraint ('Only fields provided will be changed'). It's front-loaded with the core purpose and wastes no 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 complexity of a 9-parameter update tool with no annotations and no output schema, the description is insufficient. It lacks information about behavioral traits (e.g., side effects, authentication needs), response format, and usage context relative to siblings. The partial update hint helps but doesn't compensate for 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?
Schema description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no parameter-specific information beyond what's in the schema, but doesn't need to compensate for gaps. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing ticket in Autotask'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'autotask_create_ticket' by specifying it's for existing tickets, though it doesn't explicitly differentiate from other update tools like 'autotask_update_project' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying existing tickets, but provides no explicit guidance on when to use this versus alternatives (e.g., when to update vs. create a new ticket, or when to use other update tools). The sibling list includes many other update tools, but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a destructive operation ('Remove'), but doesn't specify whether this requires special permissions, if the deletion is permanent/reversible, what happens to related data, or any rate limits. For a deletion tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and includes all essential elements: verb, target, and mechanism. Every word earns its place in conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter deletion tool with no output schema and no annotations, the description adequately covers the basic purpose but lacks important context. It doesn't explain what happens after deletion (success/failure responses), potential side effects, or error conditions. The description is minimally viable but leaves gaps that could hinder effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'serviceCallTicketResourceId' fully documented in the schema. The description adds minimal value beyond the schema by mentioning 'resource record ID' but doesn't provide additional context about format, validation, or where to obtain this ID. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Remove a resource assignment'), target resource ('from a service call ticket'), and mechanism ('by the resource record ID'). It distinguishes itself from sibling tools like 'autotask_create_service_call_ticket_resource' and 'autotask_delete_service_call_ticket' by specifying it removes resource assignments rather than creating them or deleting entire 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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. While it's clear this is for removing resource assignments, it doesn't specify scenarios where this is appropriate versus other deletion tools or mention any dependencies like needing an existing assignment to delete.
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 adds useful context about default pagination (25 results per page) and the use of the page parameter, which helps understand operational traits. However, it lacks details on permissions, rate limits, error handling, or what the return format looks like, leaving gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly convey key information: the tool's purpose and pagination behavior. Every sentence earns its place without redundancy, making it front-loaded and efficient for quick understanding.
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 complexity (a search function with 6 parameters), no annotations, and no output schema, the description is incomplete. It covers basic purpose and pagination but misses critical details like return format, error conditions, or authentication needs. However, the high schema coverage mitigates some gaps, making it minimally adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema fully documents all 6 parameters. The description does not add any meaning beyond the schema, such as explaining how searchTerm works (e.g., partial matches) or providing examples for numeric filters like status. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 ('Search') and resource ('projects in Autotask'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling search tools like 'autotask_search_companies' or 'autotask_search_tickets', which would require mentioning unique aspects such as project-specific filters or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as other search tools in the sibling list or non-search tools like 'autotask_get_project_note'. It mentions pagination but lacks context on prerequisites, typical use cases, or comparisons to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions filtering capabilities but doesn't describe whether this is a read-only operation, what authentication is required, whether there are rate limits, what the return format looks like, or if results are paginated. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately communicates the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. It's appropriately sized for a search tool with well-documented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search with 5 optional parameters), 100% schema coverage, but no annotations and no output schema, the description is minimally adequate. It covers what the tool does but lacks behavioral context about safety, authentication, rate limits, and return format that would 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?
The schema description coverage is 100%, so the schema already fully documents all 5 parameters. The description mentions filtering by 'company, status, or date range' which maps to parameters companyId, status, startAfter, and startBefore, but doesn't add meaningful semantic context beyond what the schema provides. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('service calls in Autotask'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'autotask_search_tickets' or 'autotask_search_service_call_tickets', but the resource specificity ('service calls') provides inherent 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?
The description implies usage context by listing filterable attributes ('Filter by company, status, or date range'), suggesting when this tool would be appropriate. However, it doesn't provide explicit guidance on when to use this versus other search tools (like 'autotask_search_service_call_tickets') or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'full schemas' as output but doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, or what 'full schemas' entails. The description is minimal and lacks essential operational 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 two sentences with zero waste—each sentence serves a clear purpose (stating the tool's function and providing usage guidance). It's appropriately sized and front-loaded with the core functionality.
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 (1 parameter, no nested objects) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should provide more behavioral context (e.g., read-only nature, output format). The description is complete enough for basic use but lacks depth.
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 the single parameter 'category' well-documented in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List tools') and resource ('in a specific category with full schemas'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'autotask_list_categories' or 'autotask_execute_tool' beyond mentioning the former as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Use after autotask_list_categories to see available tools and their parameters'), establishing a workflow dependency. It doesn't explicitly state when not to use it or name alternatives, but the guidance is sufficient for proper sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful context: the default pagination behavior (25 results per page) and the ability to use the 'page' parameter for more results. However, it lacks details on error handling, rate limits, authentication needs, or what the return format looks like (since there's no output schema). This leaves gaps for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: it starts with the core purpose, followed by key behavioral details in two sentences. Every sentence earns its place by providing essential information without waste, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context: no annotations, no output schema, and 4 parameters with 100% schema coverage, the description is moderately complete. It covers the basic purpose and pagination behavior but lacks details on return values (since no output schema), error conditions, or how it fits into the broader Autotask ecosystem. For a search tool, this is adequate but has clear gaps in behavioral 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 schema description coverage is 100%, meaning all parameters are well-documented in the input schema. The description does not add any parameter-specific details beyond what the schema provides (e.g., it mentions the 'page' parameter but doesn't explain it further than the schema's description). Since the schema handles the heavy lifting, the baseline score of 3 is appropriate, as the description adds no extra semantic value for 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 tool's purpose: 'Search for companies in Autotask.' It specifies the verb ('Search') and resource ('companies in Autotask'), making it easy to understand what the tool does. However, it does not explicitly differentiate from sibling tools like 'autotask_search_contacts' or 'autotask_search_projects,' which are similar search operations for different resources, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning pagination ('Returns 25 results per page by default. Use page parameter for more results.'), which implies when to use the 'page' parameter. However, it does not offer explicit guidance on when to use this tool versus alternatives (e.g., other search tools in the sibling list) or any prerequisites. The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It states this is a creation tool but doesn't mention required permissions, whether it's idempotent, what happens on failure, or what the response contains (no output schema). The description adds some context about billing purposes but misses key operational traits for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the core purpose, and the second provides usage context. Every word earns its place, and the most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter mutation tool with no annotations and no output schema, the description is incomplete. It explains the 'what' and 'why' but misses critical operational context: required permissions, error handling, response format, and system constraints. The schema covers parameters well, but behavioral transparency is inadequate for safe 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 description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds minimal value beyond the schema by mentioning charge types and billing purposes, but doesn't provide additional syntax, format, or constraint details for any parameters. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a charge') and resource ('on a ticket'), with examples of charge types ('material, cost, or expense') and use cases ('bill clients for parts, travel, or other non-labor costs'). It distinguishes from siblings like autotask_create_ticket (creates tickets) and autotask_create_time_entry (creates labor charges).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Used to bill clients for parts, travel, or other non-labor costs'), which implicitly distinguishes it from labor-related tools like autotask_create_time_entry. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation but doesn't mention whether it's read-only, safe, or has any rate limits or authentication requirements. For a tool with zero annotation coverage, this represents a significant gap in 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 consists of two clear, focused sentences with zero wasted words. The first sentence states the purpose, and the second provides usage guidance. This is an excellent example of efficient communication that earns every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema), the description is adequate but has gaps. It explains what the tool does and when to use it, but doesn't address behavioral aspects like safety, permissions, or return format. For a discovery tool in a complex system like Autotask, more context about what 'categories' means 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?
The tool has zero parameters with 100% schema description coverage, so the baseline would be 3. The description adds value by explaining the purpose of this parameterless tool ('to discover what types of Autotask operations are available'), which provides useful semantic context beyond the empty 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's purpose with a specific verb ('List') and resource ('available tool categories'), making it immediately understandable. However, it doesn't explicitly differentiate from its closest sibling 'autotask_list_category_tools', which appears to list tools within categories rather than categories themselves.
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 usage context ('to discover what types of Autotask operations are available before loading specific tools'), which helps the agent understand when this tool is appropriate. While it doesn't explicitly state when NOT to use it or name specific alternatives, the guidance is sufficient for this discovery-oriented tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it correctly indicates this is a mutation tool ('Update'), it lacks critical information such as required permissions, whether updates are reversible, error handling for invalid IDs, or what the response contains. The mention of 'complete: true' adds some context but doesn't compensate for the overall gap in 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 and well-structured with two sentences: the first states the core purpose, and the second provides specific usage guidance. Every word earns its place, with no redundancy or 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 that this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permissions, side effects, or response format, leaving significant gaps for an agent to understand how to use the tool safely and 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 schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'status, times, or description' and the 'complete' parameter, but doesn't provide additional semantics beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Update an existing service call') and identifies the resource ('service call'), distinguishing it from sibling tools like autotask_create_service_call and autotask_delete_service_call. It provides concrete examples of what can be changed ('status, times, or description'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Update an existing service call') and provides specific guidance for a common use case ('To complete/close a service call, set complete: true or update the status'). However, it does not mention when not to use it or explicitly compare it to alternatives like autotask_get_service_call for reading or autotask_delete_service_call for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves definitions and picklist values, which is useful behavioral context. However, it doesn't mention whether this is a read-only operation, potential rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences that directly state the purpose and usage without waste. Every sentence earns its place by providing essential information efficiently.
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 adequate but not complete. It covers the basic purpose and usage but lacks details on behavioral traits like read-only nature or error scenarios. Without annotations or output schema, the description should do more to compensate, but it meets a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (entityType and fieldName) with descriptions and examples. The description adds minimal value beyond the schema by implying the tool is for 'discovering valid values,' which relates to parameter usage but doesn't provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get field definitions for an Autotask entity type, including picklist values.' It specifies the verb ('Get') and resource ('field definitions'), and distinguishes it from sibling tools by focusing on metadata rather than data operations. However, it doesn't explicitly differentiate from similar tools like autotask_list_categories or autotask_list_ticket_statuses, which also provide metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Useful for discovering valid values for any picklist field.' This indicates when to use the tool—for field definition lookup, especially for picklists. It implicitly suggests using this before operations that require valid field values, but it doesn't explicitly state when not to use it or name alternatives 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?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a search/read operation (implied by 'search'), returns paginated results (25 per page default), and provides filtering logic. It doesn't mention rate limits, authentication needs, or what happens with no filters, but covers essential operational 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 appropriately sized and front-loaded: three concise sentences that each earn their place by stating purpose, pagination behavior, filterable fields, and a specific usage example. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 10 parameters, 100% schema coverage, and no output schema, the description is adequate but has gaps. It explains what the tool does and basic behavior, but doesn't cover response format, error handling, or what happens when no results are found. Given the complexity, it meets minimum viable standards.
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 fully documents all 10 parameters. The description adds minimal value beyond the schema by listing filterable fields and giving an approvalStatus example, but doesn't provide additional syntax, format, or interaction details. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for time entries in Autotask with specific filtering capabilities. It distinguishes itself from sibling tools by focusing on time entries rather than companies, tickets, projects, etc., though it doesn't explicitly differentiate from other search tools that might exist.
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 implied usage by listing filterable fields (resource, ticket, project, etc.) and giving a specific example for approvalStatus='unapproved'. However, it doesn't explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool executes other tools, it doesn't describe what happens during execution (e.g., whether it's read-only or destructive, error handling, authentication requirements, or rate limits). For a meta-execution tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence states the core purpose, and the second provides essential usage guidance. Every word earns its place, and the information is front-loaded appropriately.
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 this is a meta-execution tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., the result of the executed tool), error conditions, or behavioral traits like whether it's safe or destructive. For a tool that executes other tools, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (toolName and arguments). The description doesn't add any additional semantic meaning beyond what's in the schema, such as format examples for arguments or constraints on toolName. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'any Autotask tool by name', making the purpose specific. It also distinguishes this tool from its siblings by indicating it's a meta-tool that runs other discovered tools, unlike the many specific CRUD operations in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use after discovering tools via autotask_list_category_tools.' This provides clear context and prerequisites, telling the agent exactly when this tool should be invoked relative to the discovery process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a creation operation (implying mutation) and mentions defaults for discounts and optional status, which helps understand behavior. However, it lacks details on permissions needed, error conditions, whether the operation is idempotent, or what the response looks like (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by essential constraints and defaults in a single, efficient sentence. Every part earns its place with no redundant information, making it easy to parse quickly.
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 (15 parameters, mutation tool) and lack of annotations or output schema, the description is adequate but has gaps. It covers the core action and key constraints, but doesn't address behavioral aspects like error handling, permissions, or response format, which would be helpful for a creation tool with many 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 description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description adds value by clarifying the mutual exclusivity rule for item references (serviceID, productID, serviceBundleID) and listing required parameters, but doesn't provide additional syntax or format details beyond what the schema offers. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'line item on a quote', distinguishing it from siblings like autotask_create_quote (creates the quote itself) or autotask_update_quote_item (modifies existing items). It specifies the exact action with precision.
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 about setting exactly one item reference (serviceID, productID, or serviceBundleID) and lists required parameters (quoteId, quantity). However, it doesn't explicitly state when to use this tool versus alternatives like autotask_update_quote_item or autotask_delete_quote_item, nor does it mention prerequisites like quote existence.
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 indicates this is a read operation ('Get') and mentions nested line items, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or response format 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?
Two sentences with zero waste: the first defines the tool's function and scope, the second provides usage context. Every word contributes value, and it's appropriately 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 read tool with 100% schema coverage but no annotations and no output schema, the description adequately covers purpose and usage. However, it lacks details about return format, error handling, or system behavior that would be helpful given the absence of structured metadata.
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 single parameter 'invoiceId'. The description doesn't add any parameter-specific information beyond what the schema provides, maintaining the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a single Autotask invoice'), specifies the scope ('with its nested line items'), and distinguishes from siblings by focusing on detailed invoice content rather than search operations like 'autotask_search_invoices'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for usage ('finance workflows that need to see exactly what an invoice contains'), which implicitly suggests when to use it versus search tools. However, it doesn't explicitly name alternatives or state 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List all available ticket priorities' implies a read-only operation, it doesn't explicitly state this is a safe, non-destructive query. It also doesn't mention potential limitations like rate limits, authentication requirements, or what format the priorities are returned in.
Agents need to know what a tool does to the world before 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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides practical usage guidance. There's zero wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with no output schema, the description is adequate but could be more complete. It explains what the tool does and when to use it, but doesn't describe the return format or any behavioral constraints. Given the simplicity of the tool, this is minimally viable but leaves some questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% (empty schema). The description appropriately doesn't discuss parameters since none exist. A baseline of 4 is appropriate for zero-parameter tools where the schema fully documents the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all available ticket priorities in Autotask', making the purpose specific and unambiguous. It distinguishes this tool from its many siblings by focusing on ticket priorities rather than other entities like companies, tickets, or projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'to find priority values for filtering or creating tickets.' This gives practical guidance on its purpose. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly identifies this as a search/query operation (implied read-only), but doesn't mention pagination behavior beyond the pageSize parameter, rate limits, authentication requirements, or what the return format looks like. The description adds basic context but lacks important operational 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 perfectly concise with two sentences that each earn their place. The first states the core purpose, the second provides usage guidance. No wasted words, well-structured, and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description provides adequate basic context. However, it doesn't explain what the search returns (association objects? ticket IDs? service call IDs?), pagination behavior beyond the pageSize parameter, or error conditions. The description is complete enough for basic usage but lacks depth for optimal agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any additional parameter semantics beyond what's in the schema - it mentions filtering by service call or ticket but doesn't provide syntax examples, format requirements, or usage patterns beyond what the parameter descriptions already state.
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 with specific verbs ('search for ticket associations on service calls') and resources ('tickets', 'service calls'). It distinguishes itself from sibling tools by focusing specifically on the association between tickets and service calls, unlike broader search tools like autotask_search_tickets or 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 provides clear usage context with 'Use this to find which tickets are linked to a service call, or which service calls contain a specific ticket.' This gives explicit guidance on when to use the tool. However, it doesn't mention when NOT to use it or name specific alternatives among the many sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a read operation ('List') and specifies the dependency on ticket ID. However, it doesn't mention pagination behavior, rate limits, authentication requirements, or what happens with invalid ticket IDs.
Agents need to know what a tool does to the world before 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 perfectly concise with two sentences that each serve a clear purpose: the first states what the tool does, and the second provides important usage constraints. There's no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and no output schema, the description covers the basics adequately. However, without annotations or output schema, it could benefit from more information about return format, error conditions, or what 'completion status' entails specifically.
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 fully documents the single required parameter. The description adds minimal value beyond the schema by reinforcing that checklist items 'cannot be queried without a ticket ID,' but doesn't provide additional context about parameter format, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all checklist items'), the resource ('on a ticket'), and includes completion status information. It distinguishes this tool from sibling tools like 'autotask_search_tickets' by focusing specifically on checklist items as a sub-resource of tickets.
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 about when to use this tool ('cannot be queried without a ticket ID'), establishing it as dependent on having a specific ticket. However, it doesn't explicitly mention when NOT to use it or name alternative tools for related operations.
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 full burden and adds valuable behavioral context: it discloses the 3 MB file size limit, validation before API call, and clear error handling. It also notes the base64 encoding requirement for JSON-RPC, though it doesn't cover other aspects like permissions or response format, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by essential technical details (encoding, size limit, validation) and a clear example. Every sentence adds value without waste, making it efficient and well-structured for quick understanding.
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 (mutation with file upload) and no annotations or output schema, the description does well by covering key behaviors like size limits and encoding. However, it lacks details on permissions, error types beyond size, or what the response contains, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal extra meaning by mentioning the 'data' field requires base64 encoding and the 3 MB limit, but this is largely redundant with schema details. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Upload a file attachment') and target resource ('to an existing ticket'), distinguishing it from sibling tools like 'autotask_create_ticket' (creates tickets) or 'autotask_create_ticket_note' (adds notes). It precisely identifies the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'to an existing ticket,' suggesting it should be used after ticket creation, but does not explicitly state when to use this tool versus alternatives (e.g., 'autotask_create_ticket_note' for text notes) or mention prerequisites like ticket existence. Guidance is present but not comprehensive.
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 explains the two creation modes (parented vs Regular Time) and mentions category requirements, which is helpful. However, it doesn't disclose important behavioral aspects like authentication requirements, rate limits, error conditions, or what happens on successful creation. For a creation tool with 12 parameters and no annotations, this leaves significant 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 perfectly concise - two sentences that efficiently cover both usage scenarios. The first sentence establishes the main purpose and alternatives, the second provides specific guidance for Regular Time. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, creation operation) and lack of both annotations and output schema, the description is somewhat incomplete. While it covers the two main usage patterns well, it doesn't address what happens after creation, error handling, or system constraints. For a creation tool with this many parameters and no structured safety/behavior annotations, 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 description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds some value by explaining the Regular Time use case and category requirement, but doesn't provide additional parameter semantics beyond what's already in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a time entry in Autotask') and distinguishes between two usage scenarios: tied to a ticket/task/project OR as 'Regular Time' with specific categories. This differentiates it from sibling tools like autotask_create_ticket or autotask_create_task by focusing specifically on time tracking.
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 provides explicit guidance on when to use each option: 'Can be tied to a ticket, task, or project, OR created as "Regular Time" (no parent) for meetings, admin work, etc.' It clearly defines the alternative use cases and specifies that Regular Time requires a category, giving clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('List') and hints at its output being reference data for other operations. However, it lacks details on behavioral traits like rate limits, authentication needs, or response format, which are important for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and efficient. The first sentence states the purpose, and the second provides usage context, with no wasted words. Every sentence earns its place by adding 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's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what the tool does and why to use it, but lacks details on output format, error handling, or system constraints, which could be helpful for an AI agent despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter information, but this is appropriate given the lack of parameters. A baseline of 4 is assigned as it meets expectations for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all available ticket statuses in Autotask'), making the purpose specific and unambiguous. It distinguishes itself from sibling tools by focusing on ticket statuses rather than other entities like companies, contacts, or tickets themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'to find status values for filtering or creating tickets.' This gives practical guidance on its purpose. However, it does not explicitly mention when not to use it or name specific alternatives among siblings, though the context implies it's for reference rather than mutation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains the partial update behavior ('Only the fields you provide will be updated'), which is crucial for a mutation tool. It also provides a practical example of status codes. However, it doesn't mention authentication requirements, error handling, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that each serve a clear purpose: the first states the tool's function and key behavioral trait, the second provides a practical usage example. There is zero wasted language.
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 mutation tool with 12 parameters, no annotations, and no output schema, the description provides adequate but minimal context. It covers the core purpose and partial update behavior but lacks information about authentication, error responses, or what the tool returns. The high schema coverage helps compensate for some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds minimal parameter-specific information beyond the schema, mainly reinforcing the status parameter usage with the 'status=5' example. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('existing project in Autotask'), and distinguishes it from sibling tools like 'autotask_create_project' by specifying it's for updating existing projects rather than creating new ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Update an existing project') and includes a common use case example ('set status=5 to mark a project Complete'). However, it doesn't explicitly mention when NOT to use it or provide alternatives for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('Get') and mentions the purpose of discovering fields, but doesn't specify whether it returns single or multiple records, pagination behavior, error conditions, or authentication requirements. It adds some context but leaves behavioral details incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each serve a distinct purpose: the first explains what the tool does, and the second provides crucial usage guidance. Every word earns its place with zero wasted 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?
For a read operation with one parameter and no output schema, the description provides good context about what site configurations are and when to use the tool. However, it doesn't describe the return format or what happens when no configuration exists. Given the lack of annotations and output schema, it could be more complete about behavioral expectations.
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 (companyId) fully documented in the schema. The description doesn't add any additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the 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 specific action ('Get'), resource ('site configuration record(s) for a company in Autotask'), and purpose ('contain tenant-defined fields used to track per-company configuration data'). It distinguishes from sibling tools by explicitly mentioning autotask_update_company_site_configuration as a related but different operation.
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 provides explicit guidance on when to use this tool: 'Call this first to discover which fields are available before calling autotask_update_company_site_configuration.' This clearly establishes a workflow sequence and distinguishes it from the update operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool provides 'pre-filled parameters' which adds useful behavioral context beyond basic routing. However, it doesn't disclose important details like whether this is a read-only operation, what format the suggestions come in, or any limitations/errors that might occur.
Agents need to know what a tool does to the world before 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 just two sentences that efficiently communicate purpose and usage guidelines. Every word earns its place, and the information is front-loaded with no wasted 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?
For a single-parameter tool with no annotations and no output schema, the description does a good job explaining what the tool does and when to use it. However, it lacks details about what the output looks like (tool suggestions format) and any behavioral constraints, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'intent' well-documented in the schema. The description adds minimal value by mentioning 'describe what you want to do' which aligns with but doesn't significantly expand upon the schema's description. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as an 'Intelligent tool router' that suggests the right tool with pre-filled parameters based on a natural language description. It uses specific verbs ('describe', 'get') and distinguishes itself from all sibling tools which are specific CRUD operations, making its unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this when unsure which tool to call.' This provides clear guidance on its intended context versus the many specific sibling tools listed, effectively distinguishing it as a discovery/helper tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('List') but doesn't disclose behavioral aspects like pagination, rate limits, authentication requirements, or what format the list returns. The description adds some value by explaining the purpose of the returned data, but lacks operational 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 perfectly concise with two sentences that each earn their place. The first states what the tool does, and the second explains when to use it. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no annotations and no output schema, the description provides adequate purpose and usage guidance but lacks information about the return format (e.g., structure of queue objects, pagination). Given the complexity is low (simple list operation), it's minimally complete but could benefit from output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all available ticket queues') and resource ('in Autotask'), distinguishing it from sibling tools that primarily create, get, search, update, or delete various Autotask entities. It provides a concrete purpose beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this to find queue IDs for filtering tickets by queue'), providing clear context and purpose. It differentiates this list operation from search/filtering operations on tickets, which is helpful given the many sibling tools for searching tickets and other entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively reveals key behavioral traits: the operation is a search (implying read-only), unfiltered queries are 'expensive' (performance impact) and 'capped at 10 results' (limitation). However, it doesn't mention authentication requirements, error handling, or pagination beyond pageSize.
Agents need to know what a tool does to the world before 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 perfectly concise and front-loaded: the first sentence states the core purpose, the second explains what charges are, and the third provides critical usage guidance. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 2 parameters, 100% schema coverage, and no output schema, the description is quite complete. It explains the resource being searched, provides important behavioral constraints, and gives parameter guidance. The main gap is the lack of output format description, which would be helpful since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds marginal value by emphasizing that ticketId is 'strongly recommended' and explaining why (unfiltered queries are expensive/capped), but doesn't provide additional semantic context beyond what's in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for charges') and resource ('on a specific ticket'), with additional clarification that 'Charges represent materials, costs, or expenses billed against a ticket.' It distinguishes itself from sibling tools like 'autotask_get_ticket_charge' (singular) and 'autotask_create_ticket_charge' (creation) by focusing on searching multiple charges.
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 provides explicit guidance on when to use this tool: 'Providing ticketId is strongly recommended — unfiltered queries are expensive and capped at 10 results.' This clearly advises against unfiltered searches and explains the consequences, helping the agent choose appropriate parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the default pagination (25 results per page), how to get more results (use page parameter), and the scope of returned data (contrasted with get_ticket_details). However, it doesn't mention potential rate limits, authentication needs, or error handling, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: three sentences that each serve a distinct purpose (stating the tool's function, explaining pagination defaults, and guiding to an alternative tool). There is no wasted text, and information is front-loaded effectively.
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 (10 parameters, no output schema, no annotations), the description is reasonably complete. It covers the tool's purpose, pagination behavior, and when to use alternatives. However, it lacks details on output format, error conditions, or performance considerations, which would be helpful for a search tool with many 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?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, such as explaining relationships between parameters or providing examples beyond the default pagination mention. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Search for tickets') and resource ('in Autotask'), distinguishing it from sibling tools like 'autotask_get_ticket_details' for full data retrieval. It precisely defines what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: it specifies when to use this tool (for searching tickets) versus alternatives (use 'get_ticket_details for full data on a specific ticket'). It also mentions pagination behavior, helping the agent understand context and limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It effectively discloses key behavioral traits: it's a mutation tool (implied by 'Update'), requires prerequisite data discovery, and handles tenant-specific fields. However, it lacks details on permissions, error handling, or response format, which would be helpful for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by essential usage guidance. Every sentence earns its place by providing critical information without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by covering purpose, prerequisites, and parameter nuances. However, it could improve by mentioning potential side effects, authentication needs, or expected response structure to fully prepare an agent for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the purpose of the 'id' parameter (site configuration record ID from a specific sibling tool) and clarifying that 'updates' contains tenant-specific fields, which enhances understanding beyond the schema's technical definitions.
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 ('Update fields') on a specific resource ('company site configuration record'), distinguishing it from sibling tools like autotask_update_company or autotask_update_project. It specifies the exact scope of what is being updated, avoiding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: after first calling autotask_get_company_site_configuration to discover available fields and current values. It also provides a clear exclusion by noting that the id parameter should be the site configuration record id, not the company id, guiding proper usage.
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-mcp MCP server](https://glama.ai/mcp/servers/TICnine/autotask-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TICnine/autotask-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TICnine/autotask-mcp'

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