Autotask Search

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Some tools have overlapping purposes, particularly get_ticket_details, get_tickets_details, and get_tickets_notes, which all retrieve ticket information and notes. Names like 'get_tickets_details' and 'get_tickets_notes' could easily be confused, though descriptions help clarify the distinctions. The other retrieval tools (by company, contact, queue) are clearly distinct.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern with 'search' and 'get' prefixes. Minor inconsistencies exist: get_ticket_details is singular while get_tickets_details is plural, and 'get_tickets_by_queue' uses 'by' while 'get_tickets_company' and 'get_tickets_contact' do not. Overall, the pattern is predictable and readable.
Tool Count5/5
With 11 tools, the server is well-scoped for a search-oriented read-only API. Each tool serves a distinct retrieval purpose, and the count is within the ideal range of 3-15 tools.
Completeness4/5
The tool set provides a comprehensive read-only surface for ticket searching and retrieval, covering search by text, company, contact, queue, and related tickets, plus batch detail and notes retrieval. Minor gaps exist, such as no direct company/contact detail retrieval beyond search, but the core workflows are covered.
Average 4.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states this is a search operation, which implies read-only behavior, but it does not explicitly disclose side effects, pagination behavior, or default filters like active_only. The schema contains these details, but the description adds limited behavioral context beyond the obvious search semantics. This is adequate but not rich, scoring 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: 'Search for contacts (account contacts) in Autotask.' is followed by 'This tool searches the Autotask contacts database,' which restates the same idea. The information is front-loaded, but every sentence does not earn its place due to this repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and full parameter descriptions, the description adequately covers the tool's purpose and main use cases. It does not explain return values (not needed due to output schema) and does not mention pagination, but the schema covers that. It is complete enough for a search tool, with minor gaps around filtering defaults and relationship to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some contextual value by mentioning 'contact IDs for filtering ticket searches' and 'contacts associated with a specific company,' which map to query and company_id, but it does not add meaningful parameter-level semantics beyond what the schema already provides. 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 opens with 'Search for contacts (account contacts) in Autotask,' which is a specific verb+resource pairing. It distinguishes from siblings by focusing on contacts and mentions concrete use cases like 'looking up contact IDs for filtering ticket searches' and 'exploring contacts associated with a specific company,' clearly differentiating it from search_tickets and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contexts for when to use the tool: finding contact information, looking up contact IDs for ticket filtering, and exploring contacts by company. It does not explicitly exclude alternatives or name sibling tools, but the use cases imply when it is appropriate. This is clear context without explicit exclusions, matching a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the scope of data returned ('complete details', 'all human-created notes') and positions it as providing more context than search results. However, with no annotations provided, the description carries the full burden for behavioral transparency; it does not explicitly state read-only nature, permissions, or any side effects, which would be expected for a get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the purpose stated in the first sentence. There is some redundancy between 'complete details' and 'full information' and the repetition of 'including all notes', but overall it is well-structured and free of unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter) and the presence of an output schema, the description covers the essential use case and contrasts with search results. It could be more complete by explicitly noting that the tool is read-only or mentioning potential limitations such as ticket not found, but for a simple get operation it is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single parameter task_id, with a clear description ('The numeric task ID (from search results)'). The tool description does not add additional parameter-level meaning beyond what the schema already provides, so per the rubric the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get complete details for a specific ticket including all notes.' It distinguishes from siblings like search_tickets (which returns search results) and get_tickets_notes (which likely returns only notes) by emphasizing both complete details and all human-created notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use this tool when you need full information about a specific ticket.' It also compares to search results ('This provides more context than search results alone'), but it does not explicitly name alternative sibling tools or state when not to use it, leaving a slight gap in exclusionary 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?
With no annotations, the description carries the full burden. It discloses a key behavioral default (only open/active tickets unless include_completed=True) which adds value. However, it does not mention pagination defaults, per_page limits, ordering, or interactions between date filters and completed status, leaving several behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core purpose, clarify the domain concept, and state the default behavior. There is no redundant information, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema and output schema, the description provides sufficient context for tool selection and basic invocation (queue concept and default status filter). It lacks some higher-level guidance like pagination interactions and comparison with search_tickets, but the overall information is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions, so baseline is 3. The description adds minimal semantic context by clarifying that queue maps to TicketCategory and highlighting include_completed, but these are also inferable from the schema. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Get all tickets in a specific queue' with a specific verb and resource, and notes it retrieves from TicketCategory in Autotask. This distinguishes it from sibling tools like search_tickets or get_ticket_details by focusing on queue-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to retrieve tickets from a specific queue, with optional filtering, and explains the default behavior of excluding completed tickets. It doesn't explicitly mention alternatives or when-not-to-use, but the purpose is sufficiently constrained to guide selection 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, the description carries the full burden. It transparently describes the multi-step behavior: vector embeddings, AI re-ranking, and returning relevance scores. This goes beyond the schema and gives useful insight into how results are produced. It does not disclose potential limitations like only page 1 supported, but that is already in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a numbered process list, and a use-case list. It is informative but slightly verbose, with some redundancy in the use cases (e.g., 'Discovering patterns' and 'Finding similar issues' overlap).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, method, and use cases, and the output schema exists to detail return values. It lacks explicit mentions of error handling or empty results, but for a read-only semantic search tool with good schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100%, with each parameter having a clear description (e.g., page has default and pagination note). The description adds little specific parameter semantics beyond mapping 'given ticket' to task_id, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find tickets semantically related to a given ticket using vector similarity and AI re-ranking.' This includes a specific verb, resource, and method, and distinguishes it from siblings like search_tickets and get_ticket_details by emphasizing semantic relatedness.
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 'This is useful for' section provides clear contexts for using the tool, such as 'Finding similar issues or tickets' and 'Discovering patterns across related tickets.' However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It adds valuable context: results are in reverse chronological order, have no search ranking or filtering, and are formally assigned. It does not cover permissions, errors, or pagination details, but the provided traits are useful.
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 three sentences long and front-loads the core purpose. There is minor redundancy between the first and second sentences ('Get' and 'retrieves tickets') but overall it is tight and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema, the description adequately covers purpose, usage context, and return ordering. It lacks explicit mention of pagination behavior, but the schema documents page and per_page parameters, so the gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description reinforces that multiple contact IDs can be used but does not add substantial meaning beyond the schema, such as formatting or constraints for page/per_page.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('tickets assigned to one or more contacts'), clearly indicating the tool's scope. This distinguishes it from sibling tools like get_tickets_company and get_tickets_by_queue, which target different filters.
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 'Use this after finding contacts with search_contacts', giving clear contextual guidance on when to invoke the tool. It does not mention exclusions or directly compare to alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety. It uses 'Get' and 'retrieves', indicating a read-only operation. It adds context about the role of queues and the API naming. However, it does not explicitly state that no side effects occur or discuss any dependencies like authentication, but these are implied by the nature of the 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 compact and front-loaded, with each sentence contributing: definition, purpose, and terminology note. No redundant filler. It is slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema exists. The description sufficiently explains what is returned (list of queues) and the terminology. It could mention that inactive queues are excluded by default, but that is covered by the schema parameter description. Overall, adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter include_inactive is fully described in the schema with default and behavior. The description's discussion of queue semantics provides background but doesn't add new parameter-specific meaning. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get ticket queues (categories) from Autotask.' It further clarifies the purpose by explaining that queues are used to categorize and route tickets and that the tool retrieves them 'for reference when filtering or categorizing tickets.' This clearly distinguishes it from sibling tools like get_tickets_by_queue, which retrieves tickets assigned to a queue.
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 states that the tool retrieves queues 'for reference when filtering or categorizing tickets,' implying its use case. It also clarifies the API terminology difference (TicketCategories vs Queues), which helps avoid confusion. However, it does not explicitly exclude alternatives like get_tickets_by_queue for when tickets themselves are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that results are sorted newest-first and that no search ranking/filtering is applied, which adds behavioral context beyond the schema. It doesn't mention permission requirements or side effects, but the read-only nature is implied and the disclosed traits are useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short paragraphs, front-loaded with the primary action. Each sentence adds value: purpose, usage context, and result behavior. 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?
The description is sufficient for a simple list tool: it explains what it does, when to use it, and result ordering. An output schema exists for return structure. It doesn't cover edge cases or error handling, but those are not critical here. Slightly more detail about pagination behavior could make it a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, so the baseline is 3. The description adds no parameter-specific details beyond the schema; it only refers to 'companies' generically, which aligns with company_ids but doesn't enhance semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object phrase 'Get all tickets assigned to one or more companies' and clarifies it retrieves formally assigned tickets in Autotask. It distinguishes from siblings by noting it's the follow-up to search_companies and that no search ranking/filtering is applied.
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?
Gives explicit usage context: 'Use this after finding companies with search_companies.' This clearly indicates when to use the tool, but it doesn't explicitly name alternative tools or state when not to use it. The context is clear, yet exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds some useful context by noting the single-request nature and that it includes 'all notes and time entries.' However, it does not discuss limitations, error behavior, or whether the operation is read-only, which is a notable gap for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, front-loaded with the main purpose in the first sentence, and every sentence earns its place by adding batch context or usage guidance. No redundant or excessive wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, batch behavior, and content (notes/time entries) adequately for a simple read operation. Since an output schema exists and the parameter schema is complete, the description does not need to explain return values or parameter details. Minor gaps like lack of explicit read-only indication are offset by the clear 'Get' phrasing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter task_ids with a clear description including max 50). The description adds no additional detail about the parameter itself, only reiterating that it handles multiple tickets. Baseline 3 is appropriate since the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get complete details for multiple tickets including all notes and time entries.' It uses a specific verb ('Get') with a resource ('complete details for multiple tickets') and explicitly differentiates from the sibling tool get_ticket_details by emphasizing the batch capability and efficiency ('More efficient than calling get_ticket_details multiple times').
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: 'when you need details for several tickets.' It also names the alternative approach (calling get_ticket_details multiple times) and implies this tool is more efficient, providing clear usage guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. The verb 'searches' and 'searches the database' clearly indicate a read-only operation. Mention of 'various matching strategies' discloses a behavioral trait. No contradictions or hidden side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema, an output schema, and simple read-only nature, the description provides enough context for an agent to select and invoke the tool correctly. It could be more explicit about competing siblings, but that is not necessary for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter description coverage, including defaults and allowed values for match_type. The description adds no significant parameter detail beyond the schema, but it does mention 'matching strategies' which aligns with match_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search for companies (accounts) in Autotask', which clearly specifies the resource and action. This differentiates it from sibling tools like search_tickets and search_contacts by limiting the scope to companies/accounts.
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 states specific use cases: 'finding company information, looking up account IDs for filtering other searches, or exploring the customer base.' This gives clear context for when to use it, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the underlying search methods (BM25, semantic, fuzzy, reranking), sentiment analysis, and Redis caching behavior. This gives the agent insight into performance and functionality beyond what a simple 'search' would imply, though it omits details like rate limits or authentication.
Agents need to know what a tool does to the world before calling it. Descriptions 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 well-structured, with a clear one-sentence summary followed by a scannable bullet list of search features. It front-loads the core purpose and adds only relevant technical details, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 8 parameters and no annotations or output schema, the description provides sufficient context about the tool's behavior, including pagination, caching, and the multi-method search approach. Since an output schema exists, no explanation of return values is needed. The description is complete for a read-only search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with detailed descriptions for every field, including defaults, formats, and valid ranges. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate. The description's mention of 'partial company names' is already covered in the query parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Autotask tickets using advanced methods, distinguishing it from sibling tools like search_companies and search_contacts. The verb 'search' is explicit and the resource is specific, with additional scope (sentiment filtering, pagination) making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for flexible searches with typos, vague descriptions, and partial names. It implies use over simpler search tools due to its advanced capabilities, but does not explicitly name alternatives or state exclusions. This is clear context without formal '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?
With no annotations, the description carries the burden. It adds useful context (e.g., 'human-created notes,' bulk efficiency), but it does not disclose potential error handling, behavior when both parameters are provided (though it says 'or both'), permission requirements, or how invalid IDs are handled. The output schema covers return shape, so no credit needed there, but behavioral depth is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, starts with the core purpose, and contains no redundant information. Every sentence earns its place: purpose, specifics, and efficiency comparison. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two optional params, no annotations) and the presence of an output schema, the description covers the essential context: what it does, when to use it, and how to invoke it. It lacks edge-case details (e.g., empty parameter lists, mixed validity), but for a bulk retrieval tool this is acceptable. It is nearly complete, earning a 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions and examples for task_ids and task_numbers, with 100% coverage. The description adds relational meaning by stating these are alternative or combinable inputs ('either... or both'), which is not explicitly in the schema. This goes beyond baseline, so a 4 is warranted.
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: 'Get notes for multiple tickets in bulk.' It specifies the resource (tickets' notes) and the verb (get), and distinguishes itself from siblings like get_ticket_details by focusing on notes-only and bulk retrieval. The mention of 'human-created notes' adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is more efficient than calling get_ticket_details multiple times when you only need the notes,' providing an alternative and a clear when-to-use condition. It also explains how to supply input: 'You can provide either task IDs, ticket numbers, or both,' offering practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![mcp-autotask-search MCP server](https://glama.ai/mcp/servers/JM-Addington/mcp-autotask-search/badges/card.svg)](https://glama.ai/mcp/servers/JM-Addington/mcp-autotask-search)

Score Badge

Copy to your README.md:

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

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/JM-Addington/mcp-autotask-search'

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