PetPals KittyClaw MCP Server

by Danissimode

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a specific resource and action, with clear names that leave little room for confusion. Even related tools like board.summary and columns.list are distinct because one provides aggregated counts and the other lists detailed items. No two tools appear to duplicate functionality.
Naming Consistency3/5
The kitty namespace follows a resource.action dot pattern, but uses plural for list and singular for get (e.g., projects.list vs project.get). The petpals namespace uses underscore verb_phrase (e.g., create_task_contract), and audit uses just a noun. This mixing of conventions across namespaces makes the overall naming less predictable.
Tool Count2/5
With 28 tools, the set exceeds the 25+ threshold for 'too many.' Though the scope is broad, many ticket update operations could be consolidated into a generic update tool, and the workflow tools add significant volume. The high count makes selection more difficult for agents.
Completeness3/5
The core ticket lifecycle is well covered: create, get, list, update description/status/priority/labels/assignment, add comments, and create subtasks. The petpals workflow also spans contract creation to verification. However, there are notable gaps such as no project creation/update, no ticket deletion or title updates, and no management of columns/members/labels beyond reading.
Average 3.3/5 across 28 of 28 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Tools from this server were used 2 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one side effect (updates the ticket description) but omits crucial behavioral details such as whether the description is overwritten or appended, whether permissions are required, whether the action is reversible, and what happens on validation failure. For a mutating tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, clearly front-loading the core action. It is appropriately concise for its length, though it could be slightly more informative without becoming verbose. It earns a 4 for efficiency but not a 5 because it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 8 required, no output schema, no annotations), the description is severely incomplete. It does not explain what a task contract is, how the parameters come together, what the returned result looks like, or any side effects beyond updating the description. This is far from adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only ticketId and projectSlug have descriptions), and the description does not compensate by explaining any of the other 8 parameters. The term 'task contract' is vague and doesn't clarify how goal, scopeAllowed, primaryAgent, reviewer, acceptanceCriteria, or requiredValidation relate to the contract being created. The description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (task contract), and also notes the side effect of updating the ticket description. This distinguishes it from other tools like kitty.ticket.update_description because it also performs a creation step. However, it doesn't explain what a 'task contract' is, which is a minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The implied usage is 'when you need to create a task contract and put it in the ticket description,' but there's no mention of alternative tools or conditions that would make this tool inappropriate.
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 annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not explain whether the priority is overwritten, if the operation is idempotent, or any authentication requirements. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence with no wasted words. While it is under-specified, it is appropriately sized for a simple setter and front-loads the core action.
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 simple but lacks output schema and behavioral context. The description does not explain return values, side effects, or any business logic. Given the absence of annotations, this minimal description leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions (ticketId and projectSlug), but the priority parameter has no description and no enums. The tool description does not add any meaning to the priority parameter, leaving its accepted values ambiguous.
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 (set) and the resource/field (ticket's priority). It is specific and distinguishes itself from sibling tools like assign_member or add_label by indicating the exact operation being performed.
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. There is no mention of prerequisites, typical use cases, or when not to use it. The description simply states what it does without contextualizing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only the listing behavior and not return format, ordering, filtering, or error behavior. The read-only nature is implied by 'List' 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, front-loaded sentence with no filler. Every word contributes to meaning, and it is appropriately concise for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what a successful response contains and what 'columns' means in this context. It does not. For a one-parameter simple tool, the description is minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with projectSlug described as 'Project slug'. The description aligns the parameter to 'for a project' but adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('columns') scoped to a project. It distinguishes from sibling list tools by the resource type, though it doesn't name alternatives. Overall purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use, prerequisites, or alternatives. The description only states what the tool does, leaving the agent to infer usage from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List comments', which implies a read operation, but it does not describe the return format, pagination, ordering, or whether the comments include metadata like authors or timestamps. The agent is left without critical information about what to expect from the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is efficiently front-loaded with the core action and resource. However, it could be slightly enriched without sacrificing conciseness, so it does not earn the top score reserved for descriptions that pack in both brevity and additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations or output schema, the description is inadequate for an agent to fully understand the tool's behavior. It fails to specify return values, ordering, or any filtering/scope limitations, making it incomplete for a production context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with clear descriptions for both parameters (ticketId and projectSlug). The description itself adds no additional meaning beyond what the schema already states, 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 ('List') and resource ('comments') with the context 'for a ticket', which is specific enough to distinguish it from sibling tools like add_comment and other list tools. However, it does not explicitly differentiate itself from other potential comment-related tools or mention any scoping nuances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to use a specific ticket-level comment list versus other list tools. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'create,' implying a mutation, but offers no details about required permissions, side effects, idempotency, or what happens on success or failure. This is a significant gap for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded and easy to scan, though it lacks detail. It earns high marks for conciseness even if it sacrifices completeness.
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 7 parameters and no output schema, so the description should provide more context about the creation process, parameter roles, and return values. It doesn't explain side effects, relationship to sibling tools, or required inputs beyond 'in a project.' This is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only projectSlug is documented). The description adds no parameter details beyond implying the ticket belongs to a project. Seven parameters, including title, status, assignee, and priority, are left entirely unexplained, and the description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create'), a resource ('a new ticket'), and a context ('in a project'), which distinguishes it from sibling tools like updates and comments. It is unambiguous and immediately conveys the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as kitty.ticket.create_subtask or kitty.ticket.update_description. It simply states the action without exclusions, prerequisites, or contextual cues for appropriate use.
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 does not mention side effects, whether commands are appended or replaced, permissions required, or any other behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is appropriately sized and front-loaded, with every word contributing to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutable operation with three required parameters and no output schema, the description is too sparse. It lacks context about return values, behavior, and when to use it, making it incomplete for an agent to fully understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides some context for the 'commands' parameter by calling them 'validation commands,' but it does not explain the parameters in detail. Schema coverage is 67%, and the description does not fully compensate for the missing description of the 'commands' 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 (attach) and the resource (validation commands) to a ticket description, making the core purpose understandable. It is specific enough to distinguish from sibling tools like attach_acceptance_criteria, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or conditions. The description merely states the action, leaving the agent to infer appropriate usage from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals the mechanism ('by adding a comment template') but doesn't disclose side effects (e.g., it likely creates a visible comment), required permissions, reversibility, or any impact on the ticket. This is minimal disclosure for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the main verb and object ('Request a structured agent completion report'). Every word contributes meaning, and there is no redundancy. This is an efficiently sized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's placement in a petpals workflow with siblings like review_completion_report, reject_completion, and mark_verified, the description lacks workflow context. It doesn't explain the report lifecycle, when to request, or what happens after the request. With no output schema, the description is the only source for expected behavior, and it is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already provides basic descriptions for ticketId ('Ticket ID') and projectSlug ('Project slug'), and the tool description adds no extra parameter semantics. No additional guidance on formatting or relationships is given, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request a structured agent completion report' with a specific mechanism ('by adding a comment template'). This distinguishes it from siblings like review_completion_report, which reviews instead of requests. However, it doesn't explicitly differentiate itself from related report tools, so it stops short of 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, prerequisites, or conditions. It offers no insight into the workflow (e.g., when a report should be requested) or circumstances where this tool is appropriate. Siblings like review_completion_report imply a later step, but the description doesn't clarify the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'List labels' with no additional behavioral context such as read-only nature, response format, or side effects. It does not contradict annotations but provides negligible transparency beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and zero wasted words. Every word contributes to meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter, this is minimally sufficient. However, without an output schema, it does not describe the return format or any behavior like ordering or filtering, leaving some gaps for an agent relying solely on this description. 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 schema has 100% coverage for the parameter description ('Project slug'), so the baseline is 3. The description does not add any extra meaning about the parameter 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 'List' and resource 'labels', scoped to 'a project' which matches the projectSlug parameter. It clearly distinguishes from siblings like kitty.tickets.list by the resource type, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or related tools, leaving the agent without context for when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only states the action without explaining whether labels must pre-exist, whether existing labels are appended or replaced, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema, the description must carry the full information load. It is too sparse, lacking behavioral details, parameter semantics for the 'label' field, and usage context. This makes it minimally viable but insufficient for informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 67% of parameters (ticketId and projectSlug), but the central 'label' parameter lacks description. The description does not clarify the expected label format (e.g., slug vs display name) or how to determine valid labels, so it fails to compensate for the missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('label') with a target ('ticket'), clearly distinguishing it from sibling operations like add_comment or set_priority. It unambiguously states the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites like listing available labels first (e.g., via kitty.labels.list) or scenarios where labels should be added.
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 whether the review has side effects, requires permissions, or only returns a result. 'Return a verdict' is ambiguous about what the verdict contains or if the tool modifies any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasteful words. It is front-loaded with the verb. However, it could include more structured context about the verdict output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description needs to explain what 'verdict' means as a return value, but it doesn't. The tool's role in the completion workflow is unclear, especially regarding 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?
Schema description coverage is 100%, so parameters are already documented. The description adds no additional meaning to the parameters.
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 action ('Review') and target ('completion report for a ticket'), and indicates the output ('return a verdict'). This distinguishes it from sibling tools like 'request_agent_completion_report' and 'reject_completion' by focusing on the evaluation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, workflow position, or whether this should be called before reject_completion or mark_verified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'Get a specific project' without disclosing whether the operation is read-only, what the response format looks like, or how errors are handled. This adds no information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with clear structure. It is front-loaded with the action and resource, avoiding any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is too sparse to fully specify the tool's behavior. It does not mention what the returned project entity contains, any error conditions, or how to differentiate a successful retrieval from a missing project.
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 includes a single property 'projectSlug' with description 'Project slug', providing 100% parameter coverage. The tool description does not elaborate on this parameter or any parameter-specific behavior, so it adds no value beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific project' clearly identifies the action (get) and resource (project), and the qualifier 'specific' distinguishes it from the sibling tool kitty.projects.list which lists all projects. This makes the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as kitty.projects.list. There is no mention of the required projectSlug parameter or any prerequisites, leaving the agent to infer usage from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the basic action with no mention of side effects, authorization requirements, return values, or consequences. For a mutation tool like add_comment, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the primary action without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete for full understanding. It does not explain return behavior, error conditions, or how this comment addition interacts with existing ticket state. The minimal description is barely viable for an agent to invoke correctly without additional assumptions.
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 67% (ticketId and projectSlug have descriptions, but body does not). The description does not add any parameter-level details beyond the schema, leaving the 'body' parameter's semantics implicit. Baseline 3 applies because coverage is high, but the description offers no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to a ticket' is a specific verb+resource statement that clearly distinguishes this tool from siblings like kitty.comments.list (which lists comments) and kitty.ticket.create (which creates a ticket). It accurately and concisely identifies 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?
The description provides no guidance on when to use this tool versus alternatives or any exclusions or prerequisites. The agent must infer usage solely from the tool's name and schema, with no explicit contextual cues or contrasting sibling tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the basic action. It does not disclose whether status values are validated, if permissions are required, whether the operation is reversible, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded, and free of fluff. It is a single clear sentence that immediately conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't mention valid status sources, constraints, or return behavior, forcing the agent to rely on external tools or trial and error.
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 67%, so the schema documents most parameters. The description adds marginal meaning by implying 'status' is the new status, but it does not specify allowed values or format, leaving the agent uncertain about valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move a ticket to a new status' uses a specific verb and resource, clearly identifying the action and distinguishing it from sibling tools like set_priority or assign_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The distinction from sibling tools is only implicit through the verb and parameter names.
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, but it says nothing about side effects, permissions, idempotency, or whether the update overwrites the existing description. For a mutation tool, this is a significant gap, similar to the mid-tier update example in the calibration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that states the core functionality without any wasted words. It is appropriately sized for a simple update operation and is fully 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?
Given the lack of annotations and output schema, the description is too thin to be contextually complete. It omits any information about return values, behavior on failure, or why an agent might choose this tool over others. While the name and schema provide basic context, an agent would be unsure about the full effects and prerequisites of invoking this 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 already describes 2 of 3 parameters (projectSlug and ticketId) with clear names and descriptions, and the third parameter (description) is self-explanatory with a maxLength constraint. The tool description adds no parameter-level information, but the schema coverage is sufficient (67%) and the missing description is obvious, so it does not require compensation.
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 'Update a ticket's description' uses a specific verb ('update') and resource ('ticket's description'), clearly distinguishing it from sibling tools like add_comment, set_priority, or move_status. It directly matches the tool name and leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or situations where another tool (e.g., add_comment or create_subtask) would be more appropriate. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of explaining side effects. It merely says 'attach' without clarifying whether criteria are appended, replaced, validated, or the need for specific permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is insufficient. It does not explain the impact on the existing ticket description, potential failure modes, or what the agent should expect in response. The agent would face uncertainty when invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so the projectSlug and ticketId parameters are already described. The criteria parameter lacks a schema description, but its purpose is clear from the tool name and description. The description does not add meaningful detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Attach acceptance criteria') and the target ('to a ticket description'), using a specific verb and resource. It effectively distinguishes itself from sibling tools like attach_validation_commands, which attach a different type of content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or related tools, leaving the usage context entirely to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing behavioral details such as whether the operation is read-only, what criteria define 'blocked', pagination behavior, or response format. The word 'List' implies a read operation, but no further context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary information. It is front-loaded with the key action ('List blocked tickets') and scoped by 'for a project'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lacks important context such as what constitutes a 'blocked' ticket, whether the response includes full ticket details or just IDs, and any filtering or ordering behavior. It is minimally adequate but leaves room for ambiguity.
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 coverage is 100%, with projectSlug fully described in the schema as 'Project slug'. The tool description does not add meaning beyond the schema, but the schema is itself sufficient for parameter understanding, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('blocked tickets') scoped to a project. This distinguishes it from sibling tools like kitty.tickets.list (which lists all tickets) and kitty.ticket.get (which gets a single ticket).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for filtering to blocked tickets only, nor does it reference other list tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List members for a project' and does not mention return format, pagination, ordering, error behavior, or permissions. For a read operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'List members for a project', with no wasted words. It is front-loaded with the action and resource, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description plus the parameter schema is minimally viable. However, with no output schema, the description does not describe what the returned members list contains, which leaves a small but notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter 'projectSlug' has a schema description 'Project slug'. The tool description adds no extra meaning beyond that. Baseline of 3 applies because the schema covers the parameter.
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 'List members for a project' clearly identifies the action (list), the resource (members), and the scope (project). It is distinct from sibling tools like kitty.tickets.list or kitty.comments.list, which address different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or context. It only states what it does, without clarifying scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the tool's purpose without adding details about side effects, prerequisites (e.g., whether the parent ticket must exist in the same project), permissions, or return value. The phrase 'under a parent ticket' adds minimal behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, front-loading the action and object. It is as concise as possible while conveying the essential purpose, aligning with the expectation that every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (a create operation with 4 parameters), but the description lacks sufficient context for correct invocation: no mention of required fields, parameter semantics, or return behavior. Sibling tools and missing annotations increase the need for a richer description, which is absent. The description is too sparse to fully guide an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only projectSlug has a description), and the tool description does not mention any parameters. The description's reference to 'parent ticket' indirectly clarifies parentId, but it does not compensate for the lack of parameter documentation in the schema. Titles, descriptions, and constraints for title, parentId, and description are otherwise undocumented.
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 ('Create') and resource ('subtask under a parent ticket'), clearly distinguishing it from sibling tools like kitty.ticket.create (which creates a top-level ticket) and other ticket operations. The parent-child relationship is explicitly stated, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming 'subtask' and 'parent ticket', but it does not explicitly state when to prefer this tool over alternatives such as kitty.ticket.create. No exclusions or alternative tool mentions are provided, though the name and sibling set make the differentiation reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only says 'Get a single ticket by ID,' which implies a read operation but does not disclose any behavioral traits such as permissions, response format, or behavior on missing ticket IDs. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is immediately actionable. It is efficiently front-loaded with the verb and resource, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with all parameters fully schematized, but there is no output schema and the description does not mention the return value or any edge cases. For a basic get operation, this is adequate but leaves gaps for the agent regarding expected response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (projectSlug and ticketId), resulting in 100% schema description coverage. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get'), a distinct resource ('a single ticket'), and the means of identification ('by ID'). This distinguishes it from sibling tools like kitty.tickets.list, which retrieves multiple tickets, and other mutating ticket 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 provided on when to use this tool versus alternatives. It does not mention that this is for retrieving a specific ticket by ID, nor does it advise using kitty.tickets.list for multiple tickets. The context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether it overwrites an existing assignee), permissions, or error conditions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized for a straightforward assignment action and is easily scannable.
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, so the description needs to provide more context about behavior and effects. It does not explain what happens on assignment, whether it's idempotent, or any prerequisites. This is incomplete for an agent to invoke confidently.
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 67% of parameters with descriptions (ticketId and projectSlug), but assignee lacks a description. The description's use of 'member' gives some semantic context that assignee refers to a person, but it doesn't clarify format or constraints beyond the schema. This is adequate but not comprehensive.
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 'Assign a member to a ticket' uses a specific verb ('assign') and clearly identifies the resource (a member) and target (a ticket). This distinguishes it from sibling tools like add_comment or update_description, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided, but the purpose is clear enough that an agent can infer it should be used when a member needs to be assigned to a ticket. The usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions adding a comment but does not clarify whether the ticket status is changed, what side effects occur (e.g., notifications), or any permission requirements. The phrase 'mark... ready for human review' is ambiguous regarding state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the primary action and includes no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool that likely performs a workflow state change. It does not explain what 'ready for human review' means in terms of potential status transitions, how it differs from simply adding a comment with kitty.ticket.add_comment, or what the expected outcome is. With no output schema or annotations, the burden on the description is high, and it is not met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers projectSlug and ticketId but lacks a description for the optional 'note' parameter. The description's mention of 'adding a comment' implies that note contains the comment content, adding meaningful semantics beyond the schema. However, it does not specify note formatting or optionality.
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 ('Mark') with a clear resource ('ticket') and outcome ('ready for human review'), plus the mechanism ('by adding a comment'). This clearly distinguishes it from siblings like petpals.mark_verified and petpals.reject_completion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The sibling list includes similar actions (mark_verified, reject_completion, add_comment), but the description does not differentiate when this should be chosen over those.
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 disclose behavioral details. It only states the basic function and does not mention search scope (e.g., whether comments are included), pagination, ordering, or return structure. This minimal disclosure leaves significant behavioral unknowns for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. No redundant wording or filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 required params, no output schema). The description explains the core purpose but omits details like return format, whether the search includes comments or ticket fields, and any limitations. Given no output schema, the description could be more helpful, but it is minimally viable for a straightforward lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: projectSlug is already described in the schema. The description adds meaning to 'handle' by indicating it refers to a 'user handle', which is not described in the schema. It partially compensates for the missing schema description but does not provide full parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('tickets where a user handle is mentioned'). It is distinct from sibling tools like kitty.tickets.list (which lists all tickets) and kitty.ticket.get (which fetches a single ticket), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to find tickets that mention a specific user handle. However, it does not explicitly contrast with alternatives or state when not to use it. The context is clear but not formally differentiated from other list/filter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially carries the burden. It discloses what the summary includes (columns, counts), which is useful behavioral information. However, it does not explicitly state whether the operation is read-only, mention permissions, or address potential side effects. The verb 'Get' implies safety, but the disclosure 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, well-structured sentence that lists the key return elements. Each word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and lack of output schema, the description adequately conveys what data will be returned. It lists the main components, making it complete enough for an agent to know what to expect, though it does not detail the exact structure or formatting.
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 only parameter, projectSlug, is described in the schema with 'Project slug', achieving 100% schema coverage. The tool description adds no additional meaning beyond this, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('board summary') and enumerates the exact contents (columns, member count, label count, open ticket count). This distinguishes it from sibling tools that list individual entities like columns.list or members.list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description implies a high-level overview, but it does not explicitly compare with sibling list tools or suggest a decision process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the core action (listing tickets) and the existence of optional filters, but does not disclose return format, pagination behavior, default sorting, or whether all statuses are included. This is adequate for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the action and resource, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is underspecified. It does not explain what the returned list contains, how to combine filters, the meaning of limit, or how this tool relates to other ticket tools. The agent lacks sufficient detail to correctly and confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only projectSlug is described). The description merely says 'optional filters' without enumerating or explaining the specific parameters (label, limit, status, assignee, parentId). It does not compensate sufficiently for the low schema coverage, leaving the agent to rely on parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'tickets' scoped to 'a project', making its function distinct from sibling tools like kitty.ticket.get (single ticket) and kitty.ticket.create. The optional filters hint further clarifies its 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 phrase 'for a project' provides clear context for when to use this tool, but it does not explicitly mention alternatives or exclusions such as using kitty.ticket.get for a single ticket. This is a minor gap compared to a fully explicit guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It discloses the core behaviors (rejecting the completion and adding a comment), but does not mention side effects like status changes, required permissions, or reversibility. Some behavioral context is missing.
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 directly states the action and purpose without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-param mutation tool, the description covers the main purpose, but it lacks workflow context such as prerequisites (e.g., when a completion can be rejected) and expected outcomes. No output schema exists, so return behavior remains unspecified.
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 67% (projectSlug and ticketId already have descriptions). The description adds meaning for 'reasons' by linking it to the comment, but does not explain format or constraints beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reject' with a clear resource 'ticket completion' and an outcome 'add a comment with reasons'. It distinguishes this tool from sibling actions like mark_verified or request_agent_completion_report.
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 purpose implies when to use the tool (when rejecting a ticket completion), but it does not explicitly state alternatives, prerequisites, or when not to use it. Clear use case but no exclusions or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'read' conveys a non-destructive read operation, which is useful. However, it does not disclose other behavioral traits such as output format, ordering, or any permissions required, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action, resource, and parameter, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, this description is complete enough to understand its purpose and usage. It does not explain the nature of the audit log entries, but that is not essential for invoking the tool correctly. The description is simple and adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It directly explains the only parameter ('lines') as 'N lines', giving meaning to 'lines' beyond the raw schema. The default/min/max constraints are left to the schema, but the core semantics are covered.
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 ('read') and resource ('audit log'), and clearly indicates the parameter N. It is distinct from all sibling tools, which are focused on project/ticket management, so there is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Read the last N lines from the audit log') but does not explicitly state when to use it or mention alternatives. For a simple read tool this is reasonably clear, but there is no guidance on conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It discloses a key non-obvious trait (does not move to Done) and describes the mechanism (adding a review comment). However, it does not mention permissions, reversibility, or how the ticket state is otherwise affected, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the primary action and includes a crucial exclusion. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three parameters and no output schema, the description covers the core purpose and a key behavioral nuance. It could elaborate on what 'verified' implies in the workflow or the format of the review comment, but the essential context for invoking the tool is present.
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 two of three parameters with descriptions (ticketId, projectSlug), leaving 'note' undocumented. The description adds no parameter-level meaning, so it does not compensate for the missing note semantics. With moderate schema coverage (67%), a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Mark a ticket as verified' and specifies the mechanism 'by adding a review comment.' It also distinguishes from related tools by explicitly noting 'Does NOT move to Done,' which separates it from status-change tools like move_status or mark_ready_for_human_review.
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 a clear behavioral exclusion ('Does NOT move to Done'), implying when to use this tool (when verification is needed without status advancement). However, it does not explicitly name alternative tools or state prerequisites, though sibling names like reject_completion and mark_ready_for_human_review provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that only projects visible to the agent are returned, which is a meaningful behavioral trait. However, it omits other potential behaviors like pagination, ordering, or inclusion of archived projects, so it is only partially 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, front-loaded sentence with no wasted words. It conveys exactly what the tool does without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool, the description is adequate. It specifies the scope (projects, visible to the agent) and the action (list all). Since there is no output schema, it could provide more detail about return format, but the simplicity of the tool and sibling context make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed given the parameterless schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all projects visible to the agent, using a specific verb ('list') and resource ('projects'), and distinguishes it from sibling 'kitty.project.get' which presumably fetches a single project. The scope 'visible to the agent' adds useful precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: whenever the complete set of accessible projects is needed. However, it does not explicitly contrast with alternatives like kitty.project.get for single-project lookups, so it lacks an explicit when-not.
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:

[![BeaverBoardKanban-mcp MCP server](https://glama.ai/mcp/servers/Danissimode/BeaverBoardKanban-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Danissimode/BeaverBoardKanban-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Danissimode/BeaverBoardKanban-mcp'

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