MCP Request Tracker CrunchTools

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools target distinct actions (e.g., get_ticket, create_ticket, add_time_worked), but some overlap exists: open_ticket vs. take_ticket and set_ticket_status vs. resolve_ticket perform similar or combined operations. Descriptions are clear enough to guide selection, but an agent could occasionally mis-pick between these related tools.
Naming Consistency4/5
The set generally follows a verb_noun pattern (e.g., get_ticket, create_ticket, set_ticket_status, reply_to_ticket), with all names ending in '_tool'. Minor deviations like 'get_my_open_tickets' and 'get_new_tickets' break the strict noun structure, but the convention is readable and predictable overall.
Tool Count4/5
17 tools is on the higher end of the expected range for a robust ticketing domain, slightly exceeding the typical 3-15 sweet spot. However, each serves a plausible operational need (e.g., dedicated time/comment/history actions), so the count feels justifiable rather than bloated.
Completeness4/5
The surface covers the core ticket lifecycle (create, read, search, update, resolve, comment, time tracking) and adds useful extras like history and a weekly checklist shortcut. Missing capabilities such as attachment handling or queue creation are minor gaps not central to common agent workflows.
Average 3.4/5 across 17 of 17 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on March 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('take ownership and open') but doesn't reveal side effects, prerequisites, whether the ticket must first be unowned, or what happens if the action fails. This is dangerously vague for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, which is concise but inappropriately undersized for a tool that performs two actions. It lacks necessary detail about side effects or usage, making it under-specified rather than efficiently brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) and a two-parameter schema, but the description provides no indication of return behavior, error cases, or the exact meaning of 'open it' (e.g., status change). Given that annotations are absent, this is incomplete 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%, and each parameter (ticket_id, username) is described in the input schema. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Take ownership of a ticket and open it.' This specifies the verb (take/open) and resource (ticket), and the combined action distinguishes it from siblings like set_ticket_owner_tool and open_ticket_tool. However, it doesn't explicitly contrast with those alternatives, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like set_ticket_owner_tool or open_ticket_tool. The description offers no context, preconditions, or exclusions, leaving the agent to infer usage from the name only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details are given, such as side effects, permissions required, reversibility, or what happens to the ticket after the status change. The description is too minimal to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and directly stated in a single sentence, with no unnecessary words or complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks context about usage scenarios, side effects, or relationships with other tools. It is not complete enough for users to fully understand when and how to use it.
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 does not add extra meaning beyond the schema's parameter descriptions, which already cover ticket_id and status. Since the schema provides clear parameter info, the baseline is acceptable.
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 of setting a ticket's status, which is distinct from other ticket operations. It is specific enough to identify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of related tools like 'update_ticket' or 'resolve_ticket'. The description does not mention alternative scenarios 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, the description carries the full burden. It does not disclose side effects (e.g., ticket creation modifies system state), permissions required, or any consequences of creation. The description is minimal and does not address these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, lacking any extraneous information. It satisfies the requirement of being appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is extremely minimal and does not explain return values, error handling, or how this tool fits into the broader ticket lifecycle. Given the absence of any additional context, it is incomplete for a tool with multiple parameters and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema, but they are brief and mostly restate the parameter names. Some add clarity (e.g., 'text' as 'Initial ticket content/description', 'owner' as 'Username to assign as owner'), but they do not provide deep semantics like valid values or relationships. The baseline 3 applies due to full coverage, but descriptions are not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a new ticket') and resource, which is distinct from siblings like update or set. However, it could be more specific about the required parameters or the purpose of creation, but it is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., update_ticket, set_ticket_status). It lacks context on prerequisites, such as needing an existing ticket or when creation 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 of behavioral disclosure. While it does signal mutation of ticket state and an optional side-action (adding a comment), it does not disclose whether the comment is attached even when empty, whether the operation is idempotent, whether specific permissions are needed, or whether the ticket is hard-closed versus marked resolved. For a mutation tool with zero annotations, this single clause 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 an efficient, front-loaded single sentence with no wasted words — five words establish the core action and six more qualify the optional comment behavior. Every word earns its place. It is just short of a 5 because the terse phrasing 'Resolve/close' could have been disambiguated for clarity without much added length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no annotations and no output schema details described, so the description alone must communicate effects. Although complexity is low (only 2 simple parameters), the description fails to mention consequences such as what state the ticket ends in after resolution, whether comments are required to be non-empty, or what happens on success. With zero annotations, more behavioral context is needed for a write 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%, as both ticket_id ('The ticket ID number') and comment ('Optional comment to add before resolving') are documented in the schema, setting a baseline of 3. The description's phrase 'optionally adding a comment' reinforces the comment parameter's optionality and default empty string but adds no new syntactic or semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-plus-resource construction ('Resolve/close a ticket') that clearly conveys the action on the resource. The resolve/close scope distinguishes it from siblings like set_ticket_status_tool, set_ticket_owner_tool, and update_ticket_tool, though the slash 'Resolve/close' introduces slight ambiguity about whether these are distinct 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?
No guidance is given on when to use this tool versus its siblings. Given the crowded sibling set that includes set_ticket_status_tool, update_ticket_tool, and take_ticket_tool, there is no explicit statement about when resolving/closing is preferred over setting a status or performing a general update, nor any exclusions or prerequisites. The use case is only implied by the tool's name and the bare description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the action without mentioning that it's read-only, what the response contains, or any access requirements. The fact that it's a 'get' operation implies non-destructive but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded with the core action and resource, making it efficient and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema, the description is minimally sufficient but lacks clarification on the nature of the history (e.g., status changes, comments, etc.) and any usage context. It is adequate for a simple read operation but leaves room for ambiguity about what exactly 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?
The schema covers 100% of the parameter descriptions (ticket_id is already described as 'The ticket ID number'). The description adds no additional context about the parameter, so it 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 retrieves the ticket's history/changelog, which is a specific resource and operation. It implicitly distinguishes from siblings like get_ticket_tool by the mention of 'history/changelog', though it doesn't explicitly contrast with 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 gives no guidance on when to use this tool versus alternatives like get_ticket_tool or search_tickets_tool. There is no mention of scenarios or exclusions, leaving usage to be inferred solely from the name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must bear the full burden of behavioral disclosure. It does not mention whether this overwrites existing time, requires specific permissions, or how it interacts with other time-related fields. The word 'set' implies overwriting, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's purpose. It contains no unnecessary words or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two clearly documented parameters and an existing output schema, so the description does not need to explain return values. However, the lack of context about overwrite semantics versus add_time_worked_tool leaves some ambiguity for an agent deciding between tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (ticket_id and minutes), with minutes described as 'Total time worked in minutes'. The description reinforces this for minutes but adds no new semantic information beyond what the schema already states.
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 function: setting the total time worked on a ticket. The verb 'Set' and resource 'total time worked' are specific. However, it does not distinguish itself from the sibling tool 'add_time_worked_tool', which suggests 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as add_time_worked_tool. There is no mention of prerequisites, context, or when this tool is preferred. The description is purely functional with no 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 the full burden of behavioral disclosure. It only says 'Get details' and does not mention read-only behavior, error conditions, authentication requirements, or what specifically constitutes '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 a single, front-loaded sentence with no filler or redundant information. It is appropriately concise for a simple getter tool.
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 fully documented parameter and an output schema present, so the minimal description is mostly sufficient. However, it lacks any contextual guidance about when to use it relative to sibling tools or what happens for invalid ticket IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the ticket_id parameter is described as 'The ticket ID number.' The description adds no additional parameter context, but it does not need to since the schema fully documents the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the target ('a specific ticket'), and the required ticket_id parameter reinforces the specificity. It is distinguishable from sibling list/search tools, though 'details' is somewhat broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_tickets_tool, get_ticket_history_tool, or get_my_open_tickets_tool. The intended use is implied by the ticket_id parameter but never explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the useful clarification 'take/assign ticket,' which hints at the common workflow. However, it does not disclose side effects (e.g., overwriting existing owner), permissions, or failure scenarios, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the action and intent. Every word earns its place without any 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?
The tool is deceptively simple, but the presence of sibling tools like `take_ticket_tool` creates ambiguity that the description fails to address. It does not explain when to use this tool over `take_ticket_tool` or how it relates to ownership changes, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both `ticket_id` and `owner`. The description does not add extra meaning beyond the schema, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'set' and resource 'owner of a ticket,' and clarifies with 'take/assign ticket,' making the action clear. However, it does not distinguish from the sibling tool `take_ticket_tool`, so it does not 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 `take_ticket_tool` or `set_ticket_status_tool`. It only states the action without any context, exclusions, or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations and the description is minimal. It indicates the search mechanism, but does not disclose return behavior, pagination, output format, or any constraints or side effects, so the agent's behavioral expectations are largely implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repeated information. It compactly states the tool's core 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?
The description, combined with a detailed schema and output schema, is sufficient for basic invocation. However, the lack of usage guidance and any behavioral caveats makes it only minimally complete for an agent evaluating all alternatives and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the parameters, including meaningful examples for the query string and order_by behavior. The description adds no parameter-specific meaning beyond what is already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a ticket search operation using RT query syntax. It distinguishes broadly from single-ticket or status-focused sibling tools, though it does not explicitly contrast with get_my_open_tickets or get_new_tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would use this when a ticket lookup requires arbitrary RT query syntax. However, the description gives no explicit guidance about when to prefer this over alternative ticket lookup 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 must disclose side effects. It states 'Update' implying mutation, but does not mention whether partial updates are supported (though 'All fields are optional' hints at it), permissions required, or error behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and scope. No filler or redundancy. It efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but sufficient for the basic operation. However, given the presence of many sibling tools, it lacks any guidance on when to use this versus others. The output schema exists, so return format is covered. The behavior of optional fields (e.g., not updating omitted fields) is implicitly clear but not explicitly stated. Overall, it is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes each parameter (queue, subject, priority) with descriptions comparable to the tool description. The only added value is stating 'All fields are optional', which reinforces the schema's 'required: [ticket_id]'. Since schema coverage is 100%, baseline of 3 is appropriate; no additional semantic depth is provided beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update ticket fields' and explicitly lists the fields: subject, priority, queue. This distinguishes it from sibling tools like set_ticket_status or resolve_ticket, which target specific operations. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 does not mention that it is only for these three fields and that other updates (e.g., status, owner) should go to other tools. The presence of siblings like set_ticket_owner_tool and set_ticket_status_tool makes this distinction important, but the description omits it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Add time to the time worked on a ticket' conveys a mutation, but it omits any details about error conditions, whether years are allowed/required, whether the operation is destructive, or how the existing value is affected (e.g. no existing time means).
Agents need to know what a tool does to the world before 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 short and direct sentence with no redundant or invented detail. Every word contributes to understanding the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema present, the description is sufficient enough for an agent to understand the purpose. The main gap is the absence of usage guidance versus the set-time sibling, but the schema already handles input 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 each parameter ('ticket_id', 'minutes') already clearly documented. The description adds no extra parameter semantics beyond what the input schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('time worked on a ticket'), clearly conveying the operation. It also distinguishes itself from the sibling 'set_time_worked_tool' because adding is not the same as setting/replacing the value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. A sibling tool, 'set_time_worked_tool', exists and could easily be confused for this operation, but the description does not clarify when to use 'add' versus 'set'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden—it does clearly state the tool's behavior (returns new/unassigned tickets, honoring an optional queue filter) and the scoping clarification ('unassigned') adds value. However, it does not explicitly declare read-only/side-effect-free behavior, ordering, pagination, or error behavior beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with zero wasted words. Every element ('new', 'unassigned', 'optionally filtered by queue') contributes meaning not apparent from the tool name alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this simplicity (1 optional parameter, no required params, no nested objects, and an output schema present so return values are documented elsewhere), the description covers the tool's purpose sufficiently. It falls just short of a 5 by not explicitly addressing edge expectations (e.g., behavior with an empty queue name or how results are ordered), but these are minor gaps given the low 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% (the single 'queue' parameter is documented as 'Optional queue name to filter by'). Since the rubric assigns a baseline of 3 when coverage exceeds 80%, and the description adds no additional parameter nuances (e.g., exact-match semantics, format), the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get'), resource ('tickets'), and precise scope ('new (unassigned)'). The parenthetical defining 'new' as 'unassigned' provides meaningful disambiguation from siblings like get_my_open_tickets_tool and search_tickets_tool, which could otherwise overlap. This matches the 'specific verb+resource+scope, distinguishes from siblings' bar.
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 core use case (retrieve all new/unassigned tickets, with an optional queue filter) is implied clearly by the wording, so an agent can reasonably infer when to invoke it. However, there are no explicit when/when-not statements, exclusions, or named alternatives such as search_tickets_tool or get_my_open_tickets_tool, which would elevate the guidance beyond implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the privacy behavior (not visible to requestor) but omits other behavioral details such as permissions, side effects, or reversibility. This is adequate but minimal 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, concise sentence that communicates the essential purpose and key differentiator without any wasted words. It is front-loaded and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, full schema coverage, and an output schema, the description is nearly complete. The only notable gap is the lack of explicit linkage to sibling tools like reply_to_ticket_tool, but the privacy qualifier provides sufficient context for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (comment and ticket_id) documented in the input schema. The description adds no additional parameter meaning, 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 identifies the action ('Add'), the resource ('ticket'), and the key characteristic ('private comment/note', 'not visible to requestor'), which distinguishes it from sibling tools like reply_to_ticket_tool. This is a specific, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for private/internal notes, effectively distinguishing it from public reply tools. However, it does not explicitly name alternatives or state when-not-to-use, so it lacks full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation (get) with no side effects, but it does not explicitly state that it is non-destructive or read-only. Given the operation type, it is reasonable to assume no side effects, but the lack of explicit statement or annotations leaves some room for interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly conveys the tool's purpose without unnecessary fluff. It is well-structured and to the point.
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 gives sufficient context about what the tool does (retrieve open tickets for a specified user). It does not mention return format, but the output schema is indicated as present, so that is not required. A slight ambiguity remains about whether 'a user' refers to the current user or any user, but the parameter 'owner' clarifies that it is user-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a clear description for the 'owner' parameter ('Username to search for'), so the tool description does not need to add further meaning. The description of the tool itself does not provide additional context about the parameter beyond what the schema already includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving all open tickets assigned to a user. It specifies the verb (get), resource (tickets), and filters (open, assigned), which distinguishes it from other ticket-related siblings like search_tickets_tool or get_ticket_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives. While the name 'my_open_tickets' implies it is for the current user's open tickets, the description says 'assigned to a user' generically, leaving some ambiguity about whether it is meant for the current user or any user. No guidance on when to prefer it over search_tickets_tool is given.
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 clearly states the state change (from new to open) and the optional ownership assignment, which are the core effects. It does not detail error handling, permissions, or prerequisites beyond the implied 'new' status, but for a simple state-transition tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and immediately clarifies the state transition and optional side effect. There is no filler or redundant information; every phrase contributes to understanding the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, one required) and the presence of an output schema, the description provides adequate context. It states the exact status change and optional ownership. It lacks explicit commentary on edge cases (e.g., if the ticket is already open) and does not differentiate from overlapping sibling tools, but overall it is sufficiently complete for a straightforward mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are well-described: ticket_id as the ID number and owner as an optional username. The description's phrase 'optionally taking ownership' adds semantic context to the owner parameter but does not go beyond what the schema already states. Since the schema covers parameter meaning fully, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Open a ticket (change status from new to open), optionally taking ownership.' It specifies the resource (ticket), the specific state transition (from new to open), and an optional secondary action (taking ownership). This distinguishes it from generic status tools like set_ticket_status_tool by narrowing the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you want to open a ticket and optionally take ownership. However, it does not explicitly address when to use this over the overlapping sibling tools such as set_ticket_status_tool or take_ticket_tool, nor does it provide exclusions or alternative guidance. It offers clear context but no explicit alternatives.
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 transparency burden. It usefully discloses that the correspondence is visible to the requestor, which is a key behavioral trait. However, it does not mention side effects such as notifications, permission requirements, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaningful information, including the critical visibility qualifier.
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?
This is a simple two-parameter mutation tool with an output schema present. The description is sufficient for understanding the core action and its customer-facing nature. It could be more complete with explicit usage alternatives, but given the low complexity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters ticket_id and message are already described in the schema. The description adds no additional parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reply to a ticket (correspondence visible to requestor)' uses a specific verb and resource, clearly indicating the action. The parenthetical distinguishes it from sibling tools like add_ticket_comment_tool by noting that the reply is visible to the requester.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for sending correspondence to the requestor through the parenthetical. However, it does not explicitly state when to avoid it or directly name an alternative like add_ticket_comment_tool for internal notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of transparency. It enumerates all six behavioral steps, including 'adds time worked (if specified)' and 'resolves the ticket,' which are critical side effects. It does not reveal error handling, permission requirements, or idempotency, but the core behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a one-sentence summary, followed by a six-item numbered list that precisely outlines the workflow. Every sentence earns its place; there is no fluff or redundant repetition. The structure is highly scannable and front-loaded.
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 that this is a multi-step workflow tool, the description provides a complete and explicit sequence of actions. The output schema exists, so return values are covered elsewhere. The description fully explains the tool's operational scope and side effects, making it self-sufficient for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description exceeds this by mapping parameters to workflow steps: 'owner' is used to take ownership, 'checklist_results' go into correspondence, and 'time_minutes' becomes time worked. This adds workflow context beyond simple field definitions, enhancing the agent's understanding of how each parameter is consumed.
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: 'Complete a weekly checklist ticket with results.' It lists six specific steps, making the tool's purpose unambiguous. It distinguishes itself from sibling tools by framing itself as a 'workflow shortcut' that combines ownership, correspondence, time entry, commenting, and resolution into one operation, which no single sibling tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'workflow shortcut' implies this tool is used as an alternative to calling multiple sibling tools (e.g., take_ticket_tool, resolve_ticket_tool) in sequence. The description clarifies the targeted use case: completing weekly checklist tickets. However, it does not explicitly state when NOT to use it or mention alternative tools, so I deduct one point.
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-request-tracker MCP server](https://glama.ai/mcp/servers/crunchtools/mcp-request-tracker/badges/card.svg)](https://glama.ai/mcp/servers/crunchtools/mcp-request-tracker)

Score Badge

Copy to your README.md:

[![mcp-request-tracker MCP server](https://glama.ai/mcp/servers/crunchtools/mcp-request-tracker/badges/score.svg)](https://glama.ai/mcp/servers/crunchtools/mcp-request-tracker)

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/crunchtools/mcp-request-tracker'

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