kaiten-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation2/5
With 246 tools, several near-duplicates blur boundaries: list_cards vs list_all_cards, get_space_activity vs get_all_space_activity, and chart_control vs chart_cycle_time vs chart_lead_time. While many resource areas are distinct, the sheer volume plus overlapping bulk/all variants makes reliable tool selection difficult.
Naming Consistency4/5
The vast majority follow a consistent kaiten_verb_noun pattern (list, get, create, update, delete, add, remove). Minor deviations like kaiten_chart_cfd and kaiten_batch_add_sd_org_users break the pattern slightly, but overall naming is predictable.
Tool Count1/5
246 tools is an extreme mismatch for an MCP server; even a full platform API is better grouped into multiple focused servers. The count alone makes the toolset impractical for an agent to navigate and select from efficiently.
Completeness4/5
The surface is very comprehensive, covering CRUD-style operations for spaces, boards, cards, documents, checklists, custom properties, Service Desk, SLA policies, webhooks, and more. Minor gaps exist, such as missing single-get endpoints for some resources and a few operations documented as likely returning 405.
Average 3.4/5 across 246 of 246 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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.
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

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 on its own. It only reveals that the operation is an update, but gives no information about side effects, required permissions, what happens to existing settings, or whether the update is partial or full.
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 only one short sentence and contains no waste, but it is under-specification rather than effective conciseness. It restates the tool name and does not earn its place by adding useful detail or structure.
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 an update operation with a nested object parameter, no annotations, and no output schema, this description is incomplete. It does not explain what settings can be changed, what is required, or what the consequences of invocation are.
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. However, the schema merely calls the parameter 'Service Desk configuration object,' which is nearly a restatement of the property name, and the description adds no further meaning about allowed fields or structure of the nested object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update Service Desk settings' merely expands the tool name with spaces and a synonym ('sd' → 'Service Desk'). It does not specify which settings are affected or how this differs from sibling tools like kaiten_get_sd_settings or kaiten_update_sd_service.
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 about when to use this tool versus alternatives. Sibling tools include related functions such as kaiten_get_sd_settings and kaiten_update_sd_service, but the description offers no context, exclusions, or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'Update' only signals mutation; it does not explain partial versus full replacement, sharing side effects, permission requirements, or what response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and readable with no redundant wording. However, it is merely a restatement of the tool name, so the single sentence does not add useful content and is under-specified rather than effectively concise.
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 an update operation with no annotations, no output schema, and a nested filter object, a one-sentence description is insufficient. The schema covers parameter names, but the description lacks update semantics, prerequisites, side effects, and any guidance about what happens when fields are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The tool description adds no additional meaning about how filter_id, name, filter, and shared relate to each other or to the update operation, keeping this at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is essentially a natural-language restatement of the tool name (kaiten_update_saved_filter), adding no detail beyond 'update' and 'saved filter'. It does not mention which fields can be changed or that an existing filter is targeted, so it fails to be more informative than the name itself.
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 about when to use this tool versus kaiten_create_saved_filter, kaiten_get_saved_filter, or kaiten_delete_saved_filter. It also does not mention that the filter must already exist or that filter_id is required to identify the target.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create a new Kaiten project.' It does not mention permissions, side effects, required authorization, uniqueness constraints, or what happens after creation. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is so sparse that it essentially restates the tool name. It is concise structurally but does not add enough content to be genuinely useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has complex nested parameters, no output schema, and no annotations, yet the description only names the resource. It does not explain the required title parameter, expected return value, permission requirements, or any behavioral outcomes, leaving an agent under-informed for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters including nested settings and property pairs. The description adds no parameter-level meaning beyond what the schema provides, which matches 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 states a clear action ('Create') and a specific resource ('Kaiten project'), so an agent can immediately identify what the tool does. It is more informative than a bare tautology, but it does not explicitly differentiate from sibling tools like update_project or get_project.
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 about when to use this tool versus alternatives such as kaiten_update_project or kaiten_get_project. No conditions, prerequisites, or exclusions are provided; the only usage cue is implicit in the tool name and the word 'Create'.
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 only promises an unqualified list and says nothing about pagination defaults, ordering, scoping, filtering, or return shape. The limit/offset parameters imply pagination, but the description does not confirm how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It contains no front-loaded detail beyond the tool's own name and provides no additional information to help an agent select or invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description should explain what the listed calendars are and what the response contains. It does neither, leaving the tool's scope, return format, and semantics ambiguous. The optional pagination params are the only concrete context available.
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 fully documents both parameters as 'Max results' and 'Pagination offset', so schema coverage is 100%. The description adds no parameter-level detail, which lands at the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation ('List') and the resource ('calendars'), so an agent knows this is a read-only enumeration. However, it adds almost no nuance beyond the tool name, and with the sibling kaiten_get_calendar it does not clarify whether this returns all accessible calendars, user calendars, or calendars in a specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives. It does not mention kaiten_get_calendar for retrieving a single calendar, nor does it state any conditions that would favor list over get. An agent must infer usage purely from naming conventions.
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?
With no annotations, the description is the only source of behavioral disclosure, and it provides none beyond the action already implied by the tool name. It does not mention partial vs full update, side effects, permissions, or constraints like the one-per-company formula progress property documented in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with no filler. However, it is under-specified to the point of being only slightly more informative than a restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 12-parameter mutation tool with nested objects, no output schema, and no annotations, yet the description offers no usage context, no field semantics, no mutation behavior, and no alternative routing. The definition is far from complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 parameters. The description itself adds no parameter context, but the high coverage means the schema carries the semantic load, which warrants the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and concrete resource ('custom property'), and the update action distinguishes it from sibling create/get/delete operations. It does not add scope or expected effect, but an agent can infer the basic 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?
There is no guidance on when to update a custom property, what prerequisites exist, or how this differs from create_custom_property/delete_custom_property. The only hint is the verb 'update,' which is not enough to choose between overlapping operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral disclosure burden, but it only states 'Get', implying a read operation. It does not disclose whether report mode triggers a heavier/compute operation, what the API returns, whether date filters are required, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise, front-loaded sentence contains no wasted words and is easy for an agent to scan. Its brevity is appropriate for a simple retrieval tool, though it sacrifices informative depth.
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 no output schema and no annotations, yet the description provides no context about the returned statistics, the meaning of report mode, default date behavior, or how service_id influences results. For a statistics tool, this is insufficient context for reliable 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?
All four parameters have their own descriptions in the schema (100% coverage), so the schema already explains report, date_from, date_to, and service_id. The description adds no additional parameter semantics, but the high schema coverage meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete target ('Service Desk statistics') and a read verb, but leaves the scope and nature of the statistics undefined. It does not distinguish this from the closely related sibling kaiten_get_sd_sla_stats or the kaiten_chart_* statistics tools.
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 about when to choose this tool instead of alternatives. The description does not mention SLA-specific statistics, date-range filtering use cases, or when the report parameter should be enabled versus the other statistics/report tools.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Update a select value' and provides no information about side effects (e.g., whether changing value text affects cards using it, whether setting condition to 'inactive' disables it), permissions, or reversibility. The description is not misleading, but it discloses essentially nothing beyond the generic 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 sentence with no filler. It front-loads the purpose ('Update a select value') and adds a minimal qualifier ('for a custom property'). Every word contributes, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain the relationship between property_id and value_id, the effect of the condition enum, or what the response might look like. An agent would need to infer too much about how to invoke this correctly and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter meaning beyond what the schema already provides, but it also doesn't need to since each parameter has a description. No additional semantic context, such as which fields are commonly updated together, is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and a clear resource ('select value for a custom property'), which distinguishes it from custom property operations and other select-value actions like create/delete. It does not explicitly differentiate itself from sibling tools such as kaiten_create_select_value, but the verb 'update' plus the resource is unambiguous enough for basic purpose identification.
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 like kaiten_create_select_value, kaiten_delete_select_value, or kaiten_update_custom_property. There is no mention of prerequisites, such as needing an existing select value, nor any exclusions. The agent gets no help deciding between update and create/delete.
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 'Create a saved filter' and does not mention side effects, permissions, ownership, default sharing behavior, required relationships, or what happens on duplicate names. The description adds no behavioral value beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with no filler. However, it is concise to the point of under-specification, providing no usage context, caveats, or guidance about the nested filter object. It is not overly verbose, but it does not make the most of its 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?
For a create operation with a nested 'filter' object and no output schema, the description is insufficiently complete. An agent cannot tell what constitutes valid filter criteria, whether 'shared' has a default, what the response will be, or how this creation interacts with existing filters. The surrounding sibling tools show similar create/update/delete patterns, but the description offers no distinguishing or completing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even though the description itself adds no parameter-level detail. The schema documents 'name', 'filter', and 'shared' but the 'filter' parameter is only described as 'Filter criteria object', which is vague. The description does not compensate for that ambiguity, but it also does not need to fully re-explain well-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource: 'Create a saved filter.' It accurately identifies the action and resource type, and the operation distinguishes it from sibling tools like kaiten_update_saved_filter and kaiten_delete_saved_filter. However, it provides no additional context about what a saved filter represents or how it differs in scope from related saved-filter tools.
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 about when to use this tool versus alternatives. The description simply states the action with no mention of creating new named filters versus retrieving, listing, updating, or deleting existing ones. An agent is left to infer usage solely 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 carries the full burden of behavioral disclosure, and 'Delete a user timer' only conveys that the operation is destructive. It reveals nothing about reversibility, side effects on related data, permission requirements, error behavior for non-existent timers, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is maximally concise and front-loaded with the action. However, it borders on under-specification rather than deliberate conciseness, since several behavioral dimensions are entirely unaddressed. It earns its place but there is simply too little of it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete: it doesn't state what happens on success or failure, whether deletion is reversible, or whether timer_id can be obtained from kaiten_list_user_timers / kaiten_get_user_timer. A simple tool lowers the bar slightly, but a delete operation still needs more than a bare verb+object phrase.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds nothing beyond the schema ('timer_id' / 'Timer ID', which is itself largely tautological), and it doesn't hint at how to discover a valid timer_id (e.g., via kaiten_list_user_timers). The high coverage keeps this at baseline rather than lower.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('user timer'), clearly distinguishing it from the create/get/update/list user timer siblings. However, it doesn't explain what a 'user timer' is, which matters given the presence of the seemingly adjacent kaiten_delete_time_log, and it relies entirely on the verb for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as kaiten_delete_time_log, kaiten_delete_sprint, or other delete_* tools. There are no prerequisites, no context about timer state, and no mention of how this differs from the ~40 other delete operations in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-style list operation but does not describe pagination behavior, filtering semantics, response shape, or any side effects. The description adds little beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it essentially restates the tool name in sentence form. It is concise to the point of under-specification rather than being economically informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is too sparse. It does not clarify what a card type is, what fields the response will contain, or how query/limit/offset affect the result, leaving the agent without enough context to call the tool 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 input schema provides descriptions for all three parameters: 'Max results', 'Search filter', and 'Pagination offset', giving 100% schema coverage. The description itself adds no parameter-level meaning, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('Kaiten card types'), making the basic purpose clear. It is distinguishable from siblings like kaiten_get_card_type and kaiten_create_card_type by the plural-list framing. However, it provides no scope details and is minimal.
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 such as kaiten_get_card_type or other list tools. No conditions, exclusions, or context are provided, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It conveys that the action is a mutation, but says nothing about partial-update semantics, whether omitted fields are preserved, permission requirements, idempotency, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it is under-specified rather than usefully concise. It largely restates the tool name and offers no structural guidance for the agent.
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 omits key context: whether the update is partial or full, how type_id is used, what the response looks like, and when this tool should be selected. The schema covers the parameters but not enough surrounding context 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 has a short meaningful description, so the schema already documents the inputs. The tool description itself adds no parameter-level information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and a specific resource ('Kaiten card type'), so the agent can identify this as a write operation on card-type entities. It is clear and distinct from create/delete/get siblings by verb, though it does not explicitly differentiate itself in the text.
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 like kaiten_create_card_type or kaiten_delete_card_type. It also does not mention prerequisites such as obtaining a valid type_id via kaiten_list_card_types or kaiten_get_card_type.
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 action 'update'. It does not mention side effects, required permissions, reversibility, or consequences of updating a column. For a mutation tool, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded with the action. However, it is too sparse to be considered well-structured; it omits valuable details that could fit in a few more words. It is not verbose, but it under-specifies, so it earns a middle score.
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 (8 parameters, mutation, no output schema, no annotations), the description is incomplete. It does not explain what happens on success, any constraints on fields, or behavioral expectations. An agent needs more context to call this tool correctly, especially regarding which optional fields are mutually exclusive or dependent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters, each with a description, so the schema already explains what each field means. The tool description adds no additional semantic context beyond the verb 'update'. Since schema coverage is high, the baseline is 3; the description doesn't enhance parameter understanding but also doesn't need to.
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 'Update a column on a Kaiten board' clearly states the verb (update), resource (column), and domain (Kaiten board). It is specific enough to distinguish from unrelated tools, but it does not differentiate from sibling column tools like kaiten_update_subcolumn or kaiten_update_board. Still, the core 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 is provided on when to use this tool versus alternatives such as kaiten_create_column, kaiten_delete_column, or kaiten_update_subcolumn. There is no mention of prerequisites, conditions, or exclusions, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Update' signals mutation, but the description does not state whether the update is partial or a full replacement, whether renames propagate to affected documents, what the response contains, or whether any side effects occur. This matches the gap seen in similar minimal mutation-tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is short and front-loaded, but it borders on under-specification since it essentially restates the tool name. It is concise without being empty, though it could have used the available space to add behavioral or usage detail.
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 (2 params, no nested objects) and the schema is complete, but with no annotations and no output schema, the description leaves gaps: no return-value expectations, no usage context, and no behavioral details like partial-update semantics. For a mutation tool this is a meaningful incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both parameters are self-documenting ('New group title', 'Document group UID'). The description adds no parameter-level meaning, but per the baseline rule the schema carries the load, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('Kaiten document group'), clearly distinguishing it from the CRUD siblings (create/get/delete/list_document_group) by operation type. However, it adds nothing beyond what the name already conveys and does not differentiate it from the many other update_* tools in the sibling list, such as kaiten_update_document.
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 whether a document group must exist first, no prerequisite about fetching the group via kaiten_get_document_group, and no contrast with kaiten_update_document or kaiten_create_document_group.
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 reveals the basic mutation but does not mention idempotency, duplicate-member behavior, permission requirements, or error/response semantics.
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, front-loaded sentence with no wasted words. It is concise, though slightly under-specified in terms of 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?
For a write operation with no annotations and no output schema, the description omits important operational context such as what happens when adding an existing member, permission needs, and failure behavior. The schema covers parameters, but the overall contextual picture is thin.
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 card_id and user_id clearly documented. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline 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 states a clear verb ('Add') and resource ('a member' to 'a card'), and is distinct from sibling tools like kaiten_list_card_members and kaiten_remove_card_member by action. It does not elaborate on what a card member is, but the core operation 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 is given on when to use this tool versus alternatives such as kaiten_add_card_subscriber or kaiten_remove_card_member. There is also no mention of prerequisites like card permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It only states the action ('Add') and gives no information about permissions, side effects, idempotency, failure behavior, or response format.
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, front-loaded sentence with no filler or repetition. It is concise and readable, though some of its brevity comes at the cost of omitting useful behavioral context.
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 two-parameter mutation with full schema coverage, the core operation is clear. However, with no annotations and no output schema, the description leaves return behavior and edge cases undocumented, and it does not position the tool relative to its close siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both card_id and parent_card_id clearly. The description adds no parameter-specific detail beyond what the schema provides, so the baseline 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 is specific: 'Add a parent card to a given card' clearly identifies the verb and resource. It is distinguishable in direction from the sibling kaiten_add_card_child, though it does not explicitly name that alternative.
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 kaiten_add_card_child, kaiten_remove_card_parent, or kaiten_list_card_parents. No alternatives, exclusions, or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only repeats the obvious mutating action. It does not mention permissions, idempotency, whether the card must already exist, what happens to existing project-card relationships, or the nature of the mutation beyond 'add'.
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 filler or redundant wording. It is not poorly structured, though it is minimal to the point of omitting useful 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?
For a mutating tool with no annotations, no output schema, and many closely related sibling tools, the description is too thin. It omits the key distinction from card-creation tools, does not explain the operation's effect on project membership, and provides no safety or prerequisite context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both parameters clearly ('Card ID to add' and 'Project ID'). The description adds no additional semantic value for the parameters, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('add') and resource ('card to a Kaiten project'), making the core operation understandable. However, it does not explicitly clarify that this adds an existing card to a project versus creating a new card, which would help distinguish it from siblings like kaiten_create_card.
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 kaiten_create_card, kaiten_move_card, or kaiten_remove_project_card. There are no stated preconditions, exclusions, or context that would help an agent choose this tool correctly.
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 only states that a user is added, which implies a mutation, but it does not disclose idempotency, duplicate handling, permission overwrite behavior, auth requirements, or impact on existing memberships.
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, tight sentence with no filler. Every word contributes to communicating the core action, and it is appropriately sized for a straightforward add 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?
Given no output schema and no annotations, the description should supply more context about the expected response, error cases, or relationship to sibling tools. It currently provides only the bare action, leaving an agent without enough information to anticipate the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents user_id, organization_id, and permissions. The description adds no further meaning, such as what the permission bitmask values represent or whether the operation is additive or replacing.
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 specific action ('Add a user') and resource ('a Service Desk organization'), which distinguishes it from group/space user tools. However, it does not explicitly contrast with closely related siblings like kaiten_batch_add_sd_org_users or kaiten_update_sd_org_user, leaving slight ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over alternatives such as kaiten_add_group_user, kaiten_add_space_user, or kaiten_batch_add_sd_org_users. There are no prerequisites, exclusions, or context clues beyond the tool's name and basic 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?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the operation and does not mention permissions, duplicate handling, default role behavior, or side effects beyond adding a user.
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 filler and the core operation is front-loaded. It is concise, though it omits high-value context that could have been included without bloating the text.
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 mutating tool with no annotations, no output schema, and an optional role_id, the description is too thin. It does not explain what happens when role_id is omitted, whether duplicate membership is an error, or what response the agent should expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies. The description adds no extra meaning beyond the schema; role_id, user_id, and space_id are already labeled, though the relationship between adding a user and assigning a role is only implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: adding a user to a Kaiten space. This clearly distinguishes it from related tools like kaiten_add_group_user, though it does not explicitly contrast itself with any sibling.
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 such as kaiten_add_group_user or kaiten_update_space_user. It also does not mention prerequisites, exclusions, or when the optional role_id should be supplied.
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 only says 'create' and fails to mention whether the secret is returned only once, whether elevated permissions are required, or what the response contains. For a mutation with security implications, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It is appropriately terse for a one-parameter operation, though it sacrifices useful behavioral context.
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 one-parameter create tool, the description covers the basic call shape. The lack of an output schema and the absence of any note about the one-time API key secret leave moderate gaps, but the tool is not complex enough to demand much more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, name, is already described in the schema. The description adds no parameter-level detail, but none is necessary because the schema handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action and resource clearly: create an API key. It is effectively a restatement of the tool name, but it clearly differs from sibling list/delete API key tools. It is clear, though it adds little beyond what the name already conveys.
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 about when to use this tool versus listing or deleting API keys. There are no exclusions, prerequisites, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. 'Create a new automation' implies a mutating operation but does not disclose permissions, idempotency, validation behavior, side effects, or the fact that trigger/actions may be ignored when source_automation_id is set. This is a notable transparency gap for a creation 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 one short, front-loaded sentence with no filler or redundant phrasing. It immediately states the tool's purpose and earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested trigger/actions/conditions objects, the absence of annotations, and no output schema, the description is too thin to fully equip an agent. The schema details parameters well, but the description does not explain return expectations, prerequisites, or the relationship to kaiten_copy_automation, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and individual parameter descriptions are rich, including enums for trigger and action types. The description itself adds no parameter-level meaning, so the baseline of 3 applies. It neither helps nor hinders 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 and resource: 'Create a new automation in a Kaiten space.' It clearly identifies the action and target resource, differentiating it from update/delete/list automation tools. However, it does not explicitly distinguish itself from the sibling kaiten_copy_automation, especially since the schema's source_automation_id allows cloning.
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. With siblings like kaiten_copy_automation, kaiten_update_automation, and kaiten_list_automations, an agent receives no exclusions or selection criteria. The only implied usage is 'when you need to create an automation,' which is minimal.
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 indicates the mutation (creating a column) but does not mention side effects, permissions, reversibility, or what happens on conflict. It only restates the type enum, which is already in the schema, adding no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the core action. The type mapping sentence is redundant with the schema, but it is still concise and does not add bulk. It is appropriately sized, though the redundancy slightly prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters and no output schema, and the description only explains one parameter's values. The schema offers minimal descriptions for the other parameters, so an agent may not fully understand optional fields like col_count or wip_limit_type. The description is adequate for basic invocation but leaves room for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no new semantic meaning beyond the schema; 'Type: 1=queue, 2=in_progress, 3=done' exactly duplicates the schema's type description. It does not compensate for optional parameters like col_count or wip_limit.
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 specific action 'Create a column' on a Kaiten board, with a verb and resource that distinguish it from update/delete/list operations. It does not explicitly name sibling tools like kaiten_create_subcolumn or kaiten_update_column, so it lacks sibling differentiation but is still 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 given about when to use this tool versus alternatives. It does not mention prerequisites, such as needing a board_id, or when to choose create over update. The description only states what the tool does, not the context in which it should be used.
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 only says the group is created. It does not mention permissions, side effects, reversibility, or what happens when parent_entity_uid or sort_order are omitted, despite the schema hinting at auto-generation.
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, accurate sentence with no filler and the key action is front-loaded. It is efficient, though the economy comes at the cost of behavioral and usage detail.
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 mutating tool with no annotations and no output schema, the description is thin: it omits when to use it, what a document group's place in the hierarchy is, and what the response will be. The schema explains parameters but not the operation's context or 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?
Schema description coverage is 100%, so title, sort_order, and parent_entity_uid are already documented. The description adds no parameter-level nuance beyond the schema, which is acceptable under the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a new Kaiten document group.' This clearly identifies the operation and distinguishes it from create_document or create_company_group siblings, though it does not explicitly explain what a document group is or when it should be preferred over related group tools.
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, no prerequisites, and no mention of whether a parent group or space is required. The description only restates the operation and leaves usage context entirely to inference.
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 states the action 'Create' without describing side effects, return value, permission requirements, or behavior on duplicate titles or invalid board IDs. This is minimal for a mutation tool with no annotation safety hints.
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 filler. It is front-loaded with the core action and resource. It could be slightly richer, but as a concise statement it is appropriately tight.
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 a 7-parameter mutation tool with no annotations and no output schema, the description is too sparse to be fully contextual. It does not explain when to create a lane versus update one, what the response will be, or any constraints. The schema covers parameters, but the description leaves important operational context unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters already have individual descriptions in the input schema. The tool description adds no additional parameter semantics beyond the schema, which meets the baseline but does not enrich understanding of relationships or optional behavior.
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 and resource: 'Create a lane (swimlane) on a Kaiten board.' It clearly identifies what the tool does and clarifies the domain meaning of 'lane.' However, it does not explicitly distinguish itself from related siblings like kaiten_update_lane or kaiten_delete_lane.
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 kaiten_list_lanes, kaiten_update_lane, or kaiten_delete_lane. There is no mention of prerequisites, when creation is appropriate, or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the create action; it does not disclose whether the rule takes effect immediately, what happens if sla_id is invalid, whether existing rules are affected, or any permission requirements. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero wasted words. It delivers the core verb-resource-object relationship immediately. It is near the lower bound of acceptable length but earns conciseness points for efficiency, even though some of that brevity comes at the cost of missing guidance.
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 7-parameter create operation with a nested object, no output schema, and no annotations, this one-sentence description is incomplete. It doesn't explain what an SLA rule is, how the measurement fields (start_column_uid, finish_column_uid, estimated_time) interrelate, what the notification_settings object requires, or what the response will contain. The agent is left to guess at both semantics and success criteria.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters, including notification_settings as 'Notification configuration for the rule.' The tool description adds no parameter-level meaning beyond the schema, so the baseline 3 applies. However, the nested object's internal structure remains underspecified in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('create') and resource ('a rule within an SLA policy'), giving the parent context that distinguishes it from card-level SLA operations like kaiten_attach_card_sla and from kaiten_update_sla_rule/kaiten_delete_sla_rule via the verb. It stops short of a 5 because it doesn't explicitly name those siblings or the distinguishing conditions.
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. Nothing disambiguates it from kaiten_create_sd_sla, kaiten_attach_card_sla, or kaiten_recalculate_sla, and no prerequisites or preconditions (e.g., needing an existing SLA policy) are mentioned. The only contextual hint is the phrase 'within an SLA policy,' which is implicit rather than instructive.
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 for behavioral disclosure. It only says a new space is created, but does not mention permissions, side effects, whether creation can fail due to duplicates, or what the API returns.
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 one short, front-loaded sentence with no filler or repetition. Every word contributes to explaining the 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?
For a creation tool with no annotations and no output schema, this description is thin. It does not explain expected return values, access defaults, nesting behavior, or any constraints, leaving important operational context unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents every parameter. The description adds no parameter-level meaning, but per the baseline for full schema coverage, this 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 states a specific verb ('Create') and resource ('Kaiten space'), which clearly identifies the operation. It distinguishes itself from update/get/delete/list space siblings by verb, though it does not add any scoping or differentiation beyond the call itself.
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 about when to use this tool versus alternatives like create_board or create_project. The description only states what the tool does, with no mention of prerequisites, when-not-to-use, or related alternatives.
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, so the description carries the full behavioral disclosure burden. It only restates that a sprint is created and does not mention permissions, side effects, conflict behavior, or what the tool returns. It does not contradict any annotations, but it adds little transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is concise and scannable, though it achieves this by being very minimal rather than by adding helpful 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?
The tool has no annotations, no output schema, and a description that only states the core operation. While the schema fully documents parameters, the description lacks return-value context, board prerequisite context, and any operational guidance, making it incomplete for an agent facing this large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters already have semantic descriptions in the input schema. The tool description adds no parameter-level meaning beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: 'Create a new Kaiten sprint.' It is not vague and is easily distinguished from update/delete sprint tools by the verb 'Create,' though it does not explicitly call out sibling 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, no prerequisites (such as an existing board), and no context about required vs optional fields. An agent must rely entirely on the schema to infer invocation 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, but it only says 'Log time spent' – no mention of side effects, whether repeated calls create duplicate entries, permission requirements, or what response to expect. This is minimal behavioral disclosure for a write 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?
A single, front-loaded sentence with no wasted words. It is concise, though so brief that it leaves usage context to the schema and the tool name.
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 5-parameter create operation with no annotations or output schema, the description plus full schema coverage is minimally viable, but it lacks any operational context such as return value, duplicate behavior, permission needs, or how it differs from user timers. An agent can call it correctly but without broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (card_id, time_spent, comment, role_id, for_date) already have meaningful descriptions including defaults and constraints. The description adds no parameter-level detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Log') and resource ('time spent on a card'). It is concise and distinguishable from list/update/delete time-log siblings by the create intent, though it doesn't explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of related siblings such as kaiten_create_user_timer, kaiten_list_card_time_logs, kaiten_update_time_log, or kaiten_delete_time_log. The context for selection is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core destructive action ('Delete'), but does not reveal important traits such as irreversibility, cascading effects on cards, permission requirements, or whether the operation can fail silently. This is a significant gap for a destructive 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, front-loaded sentence with no filler. It communicates the action and target resource efficiently, and nothing extraneous is included. For a simple two-parameter delete operation, this is appropriately sized.
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?
Although the parameter schema is complete, the description lacks crucial context for a destructive operation: what happens to cards in the column, whether the deletion is permanent, and any permissions or preconditions. With no annotations and no output schema, the description alone does not fully equip an agent to safely invoke 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?
Schema documentation coverage is 100%: both board_id and column_id are described in the schema. The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies. It does not explain relationships between the parameters or any constraints like ownership or visibility.
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 and resource: 'Delete a column from a Kaiten board.' It is specific enough to distinguish from many sibling delete tools like delete_board or delete_workflow, but it does not explicitly differentiate from the closely related kaiten_delete_subcolumn or mention any exclusion criteria.
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 consequences that might affect the decision to delete a column. There is no mention of whether the column must be empty, whether deletion is reversible, or when users should prefer listing/updating instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that deletion occurs, without mentioning irreversibility, required permissions, side effects, or consequences. A destructive tool needs at least an explicit warning that the action cannot be undone.
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, direct sentence with no filler or repetition. It is appropriately concise for a tool with one parameter, though the brevity contributes to the lack of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is incomplete. It does not clarify whether the deletion is permanent, what happens to associated data, or what indicates success or failure. An agent would need more context to safely invoke 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?
Schema description coverage is 100%, with document_uid described as 'Document UID.' The tool description adds no additional parameter meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Delete a Kaiten document.' This distinguishes the operation from sibling document tools like kaiten_get_document and kaiten_update_document. However, it adds little beyond the tool name itself, so it is clear but not richly specified.
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, no prerequisites, and no mention of conditions under which deletion should be performed. The description offers no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says a lane is deleted. It does not disclose whether cards in the lane are deleted, moved, or archived, whether the action is reversible, or what permissions are required — a significant gap for a destructive 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 front-loaded sentence with no wasted words; the verb and object appear immediately. It is appropriately sized for what it states, though it could have included additional behavioral context without becoming bloated.
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 low-complexity with two fully documented required parameters and no output schema, but it is destructive and has zero annotation coverage. The description fails to address the cascade effects of deleting a lane, such as the fate of contained cards, reversibility, and permission requirements, leaving an agent unable to fully anticipate the operation's 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?
Schema description coverage is 100%, as both lane_id and board_id are documented in the input schema, so the description is not required to add parameter-level detail. It adds no meaning beyond the schema, but the baseline 3 applies given the 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 states a specific verb ('Delete') and resource ('lane') within 'Kaiten board', making the operation unambiguous. It is distinguishable from sibling tools like kaiten_list_lanes, kaiten_create_lane, and kaiten_update_lane via the resource name and verb. However, it does not explicitly call out alternatives, so it falls short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus updating, archiving, or listing lanes, and no prerequisites or conditions (e.g., whether the lane must be empty or what happens to its cards). The only usage signal is implied by the verb and resource themselves, which is effectively restating the 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 carries the full burden of behavioral disclosure, but 'Delete a saved filter' only restates the obvious destructive action. It does not disclose whether deletion is permanent, reversible, or requires specific permissions, nor does it mention side effects or return behavior.
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 unnecessary words and the key information front-loaded. However, it is so minimal that it borders on under-specification, lacking any supplementary context that would improve its structure.
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 tool with one parameter fully covered by the schema and no output schema, the description is adequate for basic invocation. The main gap is the lack of any note about permanence, permissions, or consequences, which would be especially relevant for a destructive operation with no annotations.
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 only parameter, filter_id, is already documented as 'Filter ID' 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 'Delete a saved filter' clearly states the action (delete) and the resource (saved filter), making it easy for an agent to understand the tool's purpose. It distinguishes from siblings by identifying the specific resource type, though it does not explicitly contrast with related tools like 'update_saved_filter' or 'get_saved_filter'.
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. It does not mention prerequisites, conditions for deletion, or any relationship to sibling tools such as 'list_saved_filters' or 'update_saved_filter'.
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, so the description itself must communicate what happens when the tool is called. It only restates the delete action and gives no information about irreversibility, permissions, cascading effects, or whether attached records are affected. This is a meaningful gap for a destructive 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, front-loaded sentence with no filler. For a one-parameter delete tool, this is appropriately concise, though it could have used the available space to mention behavioral consequences.
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 tool with one parameter and no output schema, the description is minimally sufficient for an agent to identify the action and find the required ID. It is not complete for a destructive action because it omits side effects, reversibility, and permission requirements, but the low complexity keeps the gap from being severe.
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 fully documents the single required parameter, sla_id, as a UUID string with 100% description coverage. The tool description adds no additional parameter-specific meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and a concrete resource ('Service Desk SLA policy'), so the action is unmistakable. It also expands the abbreviated tool name into a more readable object. It does not explicitly differentiate from kaiten_delete_sla_rule, but the resource naming is enough to distinguish it from most deletion siblings.
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 rather than related deletion tools, nor are any prerequisites, consequences, or alternatives mentioned. An agent is left to infer that this deletes an SD SLA policy and has no help deciding between it and kaiten_delete_sla_rule or other delete 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 bears the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not disclose what happens when the blocker or card does not exist, whether any authentication/access requirements apply, or what the response contains. For a tool with zero annotation coverage, this is minimal disclosure.
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 7-word sentence that front-loads the action and the resource. It is efficient and has no wasted words, though it is so terse that it borders on under-specification rather than deliberate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with fully documented parameters, the description covers the core operation. However, with no output schema and no annotations, the description is the sole source of context and does not hint at the return value or error behavior, leaving the description adequate but minimal.
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 card_id and blocker_id already described in the input schema. The description adds nothing beyond the schema, so the baseline of 3 applies; it neither enriches nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('blocker on a card'), and the qualifier 'specific' which contrasts with the CRUD sibling kaiten_list_card_blockers. It is clear what the tool does, though it does not explicitly name or differentiate from sibling 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?
There is no guidance on when to use this tool versus alternatives such as kaiten_list_card_blockers, kaiten_create_card_blocker, or kaiten_update_card_blocker. No prerequisites (e.g., the card must exist, blocker_id must be obtained from a list call) or exclusions are stated; usage is only weakly implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Get,' implying a read operation, but doesn't disclose return format, pagination, potential errors, or whether it aggregates across all cards. There is no mention of what 'measurements' includes or any side effects. The behavior is under-specified for an agent.
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 waste. It is concise and directly states the action. However, it is not front-loaded with any additional context beyond the basic purpose, and it could have included more value in the same space, so it's not a perfect 5.
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 straightforward with one parameter, and the schema covers that, but there is no output schema and the description doesn't explain what SLA rule measurements are, what the response looks like, or edge cases (e.g., empty spaces). An agent has insufficient context to confidently invoke and interpret the result.
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 space_id parameter is already documented. The description adds no extra meaning beyond affirming the context ('space'), which aligns with the parameter. Since the schema handles the semantic load, a baseline of 3 is appropriate; no additional value is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (get) and resource (SLA rule measurements for all cards in a space). It distinguishes from per-card operations by specifying 'all cards in a space.' However, the term 'SLA rule measurements' is somewhat opaque, and it doesn't clarify the difference from other SLA-related siblings beyond the 'space' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling kaiten_get_card_sla_measurements suggests a per-card counterpart, but the description doesn't mention it or any other condition for choosing this tool over others. No when/not or alternative routing.
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 behavioral burden. It only restates the operation and says nothing about response format, pagination, ordering, permissions, or side effects. 'List' implies a read operation, but no further behavioral detail is disclosed.
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 front-loaded sentence with no filler or repetition. This is appropriately minimal for a one-parameter tool, although the brevity comes at the cost of missing behavioral and usage context.
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 one-parameter read tool with a fully documented schema, this is nearly sufficient to invoke correctly. However, with no annotations and no output schema, an agent gets no information about return shape, auth requirements, or how this differs from the single-blocker getter, leaving selection and expectation-setting incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single card_id parameter is already described as 'ID of the card whose blockers to list.' The description adds no meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all blockers on a card'), clearly identifying the operation. It does not explicitly distinguish from kaiten_get_card_blocker, but the word 'all' conveys that this is the list variant.
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 kaiten_get_card_blocker or kaiten_create_card_blocker. There are no exclusions, prerequisites, or context clues beyond the tool name and basic verb.
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. 'List' implies a non-destructive read, but the description does not mention response shape, pagination, ordering, filtering effects, or any permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler and the key action and object are front-loaded. It is efficient, though the brevity contributes to under-specification in other dimensions.
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 one-line description leaves important context undocumented: what the returned time logs look like, how the optional filters behave, and how this tool relates to user timers. An agent can identify the required card_id but not fully understand the tool's complete behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with card_id, for_date, and personal all documented in the input schema. The description itself adds no additional parameter meaning, so the schema carries the load; the baseline 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 the resource ('time logs for a card'), matching the tool name and making the card scope unambiguous. It does not explicitly differentiate from related siblings like list_user_timers or the time-log CRUD tools, so it falls 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?
There is no guidance on when to use this tool versus alternatives such as kaiten_list_user_timers, kaiten_get_card_activity, or kaiten_create_time_log. The agent must infer its role purely from the 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?
There are no annotations, so the description carries the full behavioral disclosure burden. The verb 'List' signals a read-only operation, but the description provides no detail on pagination behavior, default limits, response format, or query semantics. This is minimal transparency for a tool whose behavior is otherwise undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no wasted words. 'In Kaiten' is mildly redundant given the tool namespace, but overall it is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too sparse. An agent cannot infer the return shape, default pagination size, whether query filters group names, or whether all company groups are returned by default. The optional parameters are documented in the schema, but broader behavioral context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with limit, query, and offset each having a brief description. The tool description adds no parameter-level meaning, but the schema already provides sufficient information. Baseline 3 is appropriate because the structured schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List company groups.' It clearly identifies what the tool does and distinguishes it from sibling tools like kaiten_list_group_users and kaiten_list_document_groups by naming the company-groups resource. However, it does not elaborate on scope, filtering, or what exactly is returned, so it stops short of the strongest possible clarity.
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. It does not mention that list_group_users is for users within a group, nor any conditions or exclusions for using this listing tool. An agent must infer usage entirely 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List saved filters' and does not mention pagination behavior, response format, or the read-only nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant wording. Every word contributes meaning, making it an appropriately concise definition 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?
There is no output schema and no annotation context, yet the description only provides a bare phrase. Pagination is inferable from the limit/offset parameters, but the description does not explain return contents, pagination behavior, or when listing saved filters is the right choice.
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 describes both parameters fully ('Max results', 'Pagination offset'), so the description does not need to add parameter detail. The description itself adds no parameter semantics, but the 100% schema coverage supports a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List saved filters.' The plural resource and 'list' verb distinguish it from get/update/delete saved-filter siblings, though it does not explicitly clarify scope or what a saved filter represents.
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 kaiten_get_saved_filter for a single filter or the mutation siblings. Usage is only implied by the verb 'list', with no explicit context, exclusions, or alternatives.
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, but it only states that the tool lists organizations. It does not disclose pagination behavior, default/includeUsers behavior, response structure, or any access prerequisites.
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, front-loaded sentence with no wasted words. It is efficient, though extremely minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description offers only the bare listing intent. Missing details include response format, pagination defaults, and the effect of includeUsers, so an agent would need to open the schema and still lack behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds no additional parameter meaning, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Service Desk organizations'), making the tool's core function clear. It is distinguishable from sibling tools like kaiten_get_sd_organization (singular fetch) and create/update/delete variants, though it doesn't mention any scoping details.
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 choose this tool over alternatives such as kaiten_get_sd_organization or kaiten_list_sd_users. The usage is only implied by the word 'List,' leaving the agent to infer the appropriate 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 of behavioral disclosure, and it discloses almost nothing. It does not state whether this is a read-only operation, how pagination behaves, response shape, or any rate-limit/scope constraints. Only the limit/offset parameter names hint at pagination; the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with zero filler, and the core purpose is front-loaded. It is appropriately sized for a simple list operation, though it borders on under-specification rather than deliberate conciseness. Every word earns its place, so the structure is sound.
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 and no output schema, the description is the only context, yet it explains nothing about return values, pagination defaults, or what constitutes a Service Desk request. Given a large sibling family including get/create/update/delete/list variants, the definition is insufficient for an agent to select and invoke it with confidence. The schema-complete parameters are the only thing preventing a lower score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (limit, query, offset) already documented in the input schema. The description adds no meaning beyond the schema, which is acceptable because the schema does the heavy lifting. Baseline 3 applies since the description neither helps nor hurts parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('Service Desk requests'), making the primary action unambiguous. The resource is distinct from the many sibling tools such as kaiten_list_sd_services, kaiten_get_sd_request, and kaiten_create_sd_request, so an agent can tell it apart at a glance. It does not explicitly contrast itself with those siblings, which is the only thing keeping it from 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 offers no guidance on when to use this tool versus alternatives like kaiten_get_sd_request (fetch one request) or kaiten_list_sd_services (list services rather than requests). There are no exclusions, prerequisites, or contextual signals stated. An agent must infer selection purely from the tool 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?
No annotations exist, so the description carries the full burden. It only names the action and resource, without disclosing pagination behavior, default values for include_archived, ordering, or what fields are returned. For a simple list operation this is low-risk but still opaque.
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 zero filler and the key action front-loaded. It is appropriately terse, though it could add useful behavioral context without becoming bloated.
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 straightforward list call with fully documented parameters, the description provides the minimal necessary action and resource. However, there is no output schema or mention of what a Service Desk service entry contains, and no guidance on filtering semantics beyond parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters (limit, query, offset, include_archived). The description adds no extra meaning about query syntax, supported filters, or parameter interactions, but the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List Service Desk services.' It differentiates at a glance from singular get/create/update/delete SD service siblings, though it does not explicitly distinguish itself from other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like kaiten_get_sd_service or kaiten_list_sd_requests. The context implies browsing, but there are no explicit when/when-not instructions or named alternatives.
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 states 'List Service Desk users' and does not reveal default behavior of the boolean flags (e.g., are paid users excluded by default?), pagination behavior, or result set semantics. A read operation with ambiguous filtering defaults is inadequately disclosed.
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, front-loaded sentence with zero filler. It is efficiently sized for what it states, though the brevity comes at the cost of missing useful context for a 5-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five optional parameters, no annotations, no output schema, and a large sibling set that includes kaiten_list_users, the description is too minimal. It does not clarify the difference between SD users and regular users, explain the purpose of the include_* flags, or set expectations about the return shape.
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 input schema already documents all five parameters with brief but adequate descriptions ('Max results', 'Search filter', etc.). The tool description adds no parameter meaning beyond the schema, which matches the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'List Service Desk users.' This clearly identifies what the tool does and the 'sd' in the tool name reinforces the resource scoping. However, it does not explicitly differentiate itself from the closely named sibling kaiten_list_users, leaving the agent to infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like kaiten_list_users, kaiten_update_sd_user, or kaiten_list_sd_organizations. The parameters suggest filtering workflows (query, include_paid_users, include_all_sd_users) but the description offers no context on when those would be needed.
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 bears full responsibility for behavioral disclosure, but it only states a read-only listing action. It does not disclose pagination behavior, whether v2_select_search should be used, or the response shape.
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?
A single, front-loaded sentence with no filler; every word contributes to the core meaning. It could be expanded with usage context without becoming bloated, but as written it is appropriately concise.
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 7-parameter tool with no output schema and no annotations, the description lacks operational context such as pagination defaults, conditions defaults, and when v2_select_search should be enabled. The required property_id and filtering options are discoverable only from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters are documented in structured form. The free-text description adds no additional parameter semantics beyond tying the listing to a custom property, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('List') and a constrained resource ('select values for a custom property'), which clearly separates it from create/get/update/delete select-value siblings. It does not explicitly contrast with kaiten_get_select_value, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence advises when to choose this over kaiten_get_select_value or how to use filtering, pagination, or v2_select_search. The agent must infer usage from the verb and sibling names, with no explicit alternatives 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 of behavioral disclosure, but it only restates the action and resource. It does not explicitly state that this is a read-only operation, describe pagination defaults, ordering, or what fields the returned sprints contain. The statement adds almost no behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the primary action is front-loaded. It is structurally clean and efficient, though the terseness means it provides little informational value beyond the tool name.
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 definition is incomplete for a tool with 3 optional parameters, no output schema, and no annotations. It does not specify the scope of sprints returned, pagination behavior, or how the active filter interacts with the listing. Given the large sibling context, this lacks the contextual detail an agent needs to call it 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?
Schema description coverage is 100%, with limit, active, and offset each documented in the input schema. The description adds no parameter semantics, but the baseline of 3 applies because the schema already provides sufficient detail for the agent to understand the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource, 'List Kaiten sprints,' which clearly distinguishes it from sprint mutations (create/update/delete) and from kaiten_get_sprint. However, it omits scope details such as whether this lists sprints across all spaces or for a specific project/board, so it does not fully differentiate itself from other list_ tools beyond the resource name.
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 description does not mention kaiten_get_sprint for retrieving a single sprint, nor does it suggest any prerequisites or context where listing sprints is appropriate. In a sibling set of over 200 tools, the agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the removal action and does not mention side effects, idempotency, error behavior, permissions, or whether the parent card object itself is deleted or merely unlinked.
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 front-loaded sentence with no filler. It states the action and target resource efficiently, earning its place while staying appropriately short.
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 mutating operation with no annotations and no output schema, the description is thin. It does not indicate what a successful response looks like, what errors to expect, or whether the operation requires preconditions such as the parent link already existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly described as the child card and the parent to remove. The description adds no meaningful semantic information beyond what the schema already provides, 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 uses a specific verb ('Remove') and a clear resource ('parent card from a given card'), which conveys the operation. It is distinguishable from related siblings like kaiten_remove_card_child or kaiten_add_card_parent, though it does not explicitly name those 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 given about when this tool should be used instead of related tools, such as kaiten_remove_card_child or kaiten_list_card_parents. The agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'remove' and does not specify whether the card is permanently deleted, just unlinked from the project, whether the operation is reversible, or what permissions are required. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. It front-loads the action and object clearly and is appropriately sized for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the parameters are fully documented, the description is too thin for a mutation tool with no annotations and no output schema. It does not clarify the practical effects of removal, how this differs from deleting a card, or what happens after the operation, so an agent lacks important context for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, documenting both card_id and project_id clearly. The description adds no additional semantics beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove a card from a Kaiten project') with a clear verb and resource. However, it does not distinguish this from kaiten_delete_card or kaiten_archive_card, so an agent could confuse removing a card from a project with deleting or archiving the card itself.
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 such as kaiten_delete_card, kaiten_remove_card_child, or kaiten_archive_card. There is also no mention of prerequisites or context needed before removing a card from a project.
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. 'Update a Kaiten board' only signals mutation; it does not explain whether the update is partial or full, what side effects occur, whether permissions are required, or what happens to unspecified fields. For a mutation tool with nine parameters, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It efficiently states the core purpose, though it could arguably add more context while remaining concise. The structure is clean and 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?
Given the tool's nine parameters, lack of annotations, and absence of an output schema, the one-sentence description is insufficient for an agent to confidently invoke the tool. It does not explain update semantics, required identification of the board, optional-field behavior, or what the response contains. The schema helps, but overall context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all nine parameters, including field names and meaning, so the description need not repeat that information. The tool description itself adds no parameter-level detail, but the schema already carries the load, aligning with 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 clearly identifies the action ('Update') and the resource ('a Kaiten board'), which distinguishes it from sibling tools like kaiten_create_board, kaiten_get_board, and kaiten_delete_board. However, it gives no indication of what aspects of the board can be updated, so it stops short of a fully informative definition.
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, no mention of prerequisites, and no exclusions. The description simply states the operation without contextual selection criteria, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states only that a blocker is updated, without explaining whether the update is partial, what fields are actually affected, whether permissions are required, or what side effects occur.
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, front-loaded sentence with no wasted words. It is appropriately sized for a simple CRUD update, though it is definitely on the terse side.
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?
With only three simple parameters, full schema coverage, and no output schema, the description plus schema provide enough to make a basic call. Missing are usage guidance and behavioral details such as partial-update semantics or permission requirements, which matter for a mutation with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for card_id, blocker_id, and reason. The description adds no 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 uses a specific verb ('Update') and names the resource ('a blocker on a card'), so the operation is clear. It doesn't add scope or explicitly contrast with sibling blocker CRUD tools, but the sentence plus tool name is enough to distinguish update from create/get/delete/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 given about when to use this tool versus kaiten_create_card_blocker, kaiten_get_card_blocker, or kaiten_delete_card_blocker. The only cue is the word 'update' in the tool name; the description itself provides no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is an update but does not explain whether it is a partial or full update, what fields are affected beyond name, whether changes are reversible, what permissions are required, or what the response looks like. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words and the core action is front-loaded. It is appropriately concise for a tool with a single parameter, though it achieves brevity at the cost of behavioral context captured in other dimensions.
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 incomplete. It does not mention what 'company information' can be updated, whether the update is partial, what the response contains, or any constraints. The simple schema partially compensates, but the tool still needs more context for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter 'name' is already documented as 'Company name'. The description adds no extra parameter semantics beyond the schema, but the schema itself is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('current company information'), so an agent can infer the purpose. It is distinct from sibling tools like kaiten_get_company or kaiten_update_company_group, though it does not explicitly differentiate itself or list what 'information' entails.
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 such as kaiten_get_company, kaiten_update_company_group, or other update tools. The description only implies a general update context and provides no exclusions, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it only restates that an update occurs. It does not state whether the update is partial, whether omitting name is meaningful, what permissions are required, or what response is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the core action is placed up front. It is efficient, though it is too thin to provide behavioral or usage context.
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 two-parameter CRUD tool with complete schema coverage, the description plus schema is minimally sufficient to identify the target and the field to change. However, with no annotations or output schema and no statement of update semantics, an agent cannot anticipate side effects, return values, or whether other company-group fields exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains 'New group name' and 'Group UID'; the description adds no parameter-level meaning. Baseline 3 is appropriate, but the description could have clarified that only the name property is updatable and that group_uid identifies the target.
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 clear imperative verb ('Update') with a specific resource ('company group') and a domain qualifier. It distinguishes the operation from create/get/delete siblings for the same resource, though it does not enumerate which fields are affected or how this update differs from related updates beyond the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus kaiten_create_company_group, kaiten_delete_company_group, or the other update_* tools. An agent must infer from the name alone that this is the mutation counterpart for company groups; no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and it only restates the action. It does not say whether the update is partial or full replacement, what happens if card_id or link_id do not match an existing link, or any permissions needed. The name and description both indicate mutation, so there is no contradiction, but no added transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero wasted words — 'Update' leads immediately and every word earns its place. It is appropriately brief, though so sparse that substantive details (which fields are updatable, which IDs identify the target) are entirely deferred to the schema.
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 covers only the purpose and nothing else. It omits update semantics (can url and description be changed independently or only together?), routing relative to sibling external-link tools, and any error or return behavior, forcing the agent to infer everything from the parameter schema and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (url, card_id, link_id, description) already carry schema-level descriptions, setting the baseline at 3. The tool description adds only the contextual fact that the link lives on a Kaiten card, which lightly ties card_id to the link's owner but adds no format or syntax 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 uses a specific verb ('Update') plus a specific resource ('external link on a Kaiten card'), making the core action unmistakable. It implicitly differentiates from siblings like kaiten_create_external_link, kaiten_delete_external_link, and kaiten_list_external_links through the verb itself, though it never names them or their scope explicitly.
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 creating, deleting, or listing external links. It also omits prerequisites such as obtaining the link_id from kaiten_list_external_links or confirming that card_id identifies the card that owns the link.
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 burden of behavioral disclosure, but it only says 'Update.' It does not explain whether updates are partial or full, what side effects occur, how condition=2 archives a lane, or whether the operation 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler and front-loads the core operation. It is concise, though it is so abbreviated that it contributes little beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters, no annotations, and no output schema, a one-sentence description is insufficient. It lacks update semantics, return behavior, and context around options like wip_limit, condition, and default_card_type_id, leaving important operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with every parameter named and documented. The description itself adds no parameter-level meaning, so the schema does the heavy lifting and the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update a lane on a Kaiten board.' It is distinct from siblings like kaiten_create_lane, kaiten_delete_lane, and kaiten_list_lanes by its verb and target resource. However, it does not mention what lane attributes can be updated or name any sibling alternatives, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and it does not state prerequisites such as an existing lane_id or when not to use it. It leaves the agent to infer usage entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update,' which conveys mutation, but does not reveal whether the update is partial or full replacement, whether permissions are required, what side effects occur, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and clearly structured, though slightly terse; this is better viewed as a completeness issue rather than a structure problem.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, nested objects, no annotations, and no output schema, one sentence is insufficient. The detailed schema mitigates the parameter gap, but behavioral context such as update semantics, prerequisites, and expected outcomes is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has descriptive meaning and the baseline of 3 applies. The tool description adds no parameter-level details, but it does not need to because the schema handles this adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update'), a clear resource ('a Kaiten project'), and is distinct from siblings like kaiten_create_project, kaiten_get_project, and kaiten_delete_project. It lacks detail on what fields can be changed, but the core 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?
There is no guidance on when to use this tool versus kaiten_create_project, kaiten_get_project, or other update tools. It does not mention prerequisites, intended scenarios, or exclusions, so the agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the desccription carries the full burden of behavioral disclosure. It only says 'Update' and does not explain whether fields are overwritten, whether partial updates are supported, what permissions are needed, or what the response looks like.
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 wasted words. It is front-loaded and easy to parse, though it could add more semantic value without becoming bloated.
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 low-complexity tool with three parameters and full schema coverage, the description plus schema is minimally sufficient to make a call. However, it lacks details about update behavior, return values, and any side effects, which would make it fully 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 all parameters are already documented with types and constraints. The description does not add any parameter meaning beyond the schema, which matches 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 an update action on a Service Desk organization, which is a specific verb+resource and matches the tool name with the 'SD' abbreviation expanded. It distinguishes the resource from sibling tools like update_sd_service and update_sd_org_user, though it adds no detail about what can be updated.
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 about when to use this tool versus alternatives such as create_sd_organization, delete_sd_organization, update_sd_org_user, or update_sd_settings. There are no preconditions, exclusions, or context about when an update 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. It only says 'Update a user's permissions' and does not mention effects, reversibility, required authorization, or what happens when the optional permissions parameter is omitted. The mutation nature is implicit but not elaborated.
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 redundant wording. It is appropriately front-loaded with the action and object, though it is quite minimal and does not include any routing or cautionary 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 there are no annotations and no output schema, the description is thin for a mutation tool. It identifies the resource but omits practical context such as permission value semantics, whether permissions is required for a meaningful update, and how this relates to SD organization membership tools. An agent would likely need external knowledge to invoke it 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?
Schema description coverage is 100%, so the schema already documents all three parameters (user_id, permissions, organization_id). The description adds some context by framing the operation as updating permissions in a Service Desk organization, but it does not meaningfully expand on the meaning of the permission bitmask or the optionality of the permissions parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Update') on a specific resource ('a user's permissions in a Service Desk organization'), so an agent can understand what the tool does. It does not explicitly distinguish itself from sibling tools like kaiten_add_sd_org_user or kaiten_update_sd_user, but the 'permissions in a Service Desk organization' phrasing provides reasonable specificity.
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 about when to use this tool versus related tools such as kaiten_add_sd_org_user, kaiten_remove_sd_org_user, or kaiten_update_sd_user. The wording implies it is for modifying permissions rather than membership, but it provides no explicit when-to-use or alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the policy is updated; it does not explain whether updates are partial or full, what side effects deactivating a policy has, whether should_delete_sla_from_cards permanently removes SLA data, what permissions are required, or what the response looks like.
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, front-loaded sentence with no filler words. It is appropriately concise for a purpose statement, though it is terse and does not carry much operational detail.
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 mutating tool with no annotations and no output schema, the description is too thin. It does not explain when to use it, what happens during deactivation, how notification_settings behaves, or what result the caller should expect, leaving an agent without enough context to reason about the update's full 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 the baseline is 3 even though the description itself adds no parameter-level meaning. The schema already documents each parameter, including the role of should_delete_sla_from_cards, though the nested notification_settings object is not expanded in either the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update') and a clear resource ('a Service Desk SLA policy'), making the tool's basic purpose obvious. It is distinguishable from siblings like create/delete/get SD SLA and update_sla_rule by naming the exact resource, though it does not explicitly call out those distinctions.
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 such as kaiten_update_sla_rule, kaiten_update_sd_service, or kaiten_create_sd_sla. No conditions, prerequisites, or exclusions are provided; the only hint is the verb 'update' in the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Update', which implies mutation, but does not explain whether this is a partial update, whether the previous values are overwritten, what permissions are required, or what happens on success or failure.
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 filler or redundancy. It is front-loaded with the action and resource, though it may be slightly too terse to carry the behavioral burden needed for a mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter update operation with a fully documented schema, the minimal description is borderline adequate. However, the lack of annotation coverage and absence of any usage or behavioral context leaves the agent without important information about how the update behaves.
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 individual parameters are already documented with types and descriptions. The description adds no additional semantic detail beyond naming the resource, which is acceptable given the schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and a clear resource ('a Service Desk template answer'), which distinguishes it from sibling tools like list_sd_template_answers, get_sd_template_answer, create_sd_template_answer, and delete_sd_template_answer. However, it offers no further detail about what aspects of the template answer are affected beyond what the schema already lists.
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, such as create or delete operations on the same resource. The description only states the action without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the mutating verb 'Update' without explaining whether the operation is a partial patch or full replacement, what permissions are required, or what side effects occur.
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 focused sentence with no filler and is front-loaded with the action. It is concise, though slightly terse and does not use its brevity to add distinguishing detail.
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 mutating tool with no annotations, no output schema, and many closely related update tools, a one-line description is insufficient for reliable selection and invocation. It omits when to use it, what qualifies as a Service Desk user, and any behavioral caveats, though the flat parameter list and full schema coverage keep the gap moderate.
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 user_id, lng, and full_name are already documented. The description adds no additional parameter-level meaning, which is acceptable given that the schema fully covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and a specific resource ('Service Desk user profile'), making the basic action clear. However, it does not differentiate this tool from closely related siblings such as kaiten_update_sd_org_user or kaiten_update_space_user.
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 kaiten_update_sd_org_user, kaiten_update_space_user, or kaiten_set_sd_user_temp_password. No context, prerequisites, or exclusions are provided, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It only says 'Update' without explaining whether it is a partial or full replacement, whether it is idempotent, what side effects occur, or what permissions are required. 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 a single efficient sentence with no redundant wording or filler. It is front-loaded and easy to parse, though it is so brief that it lacks some useful 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 that this is a mutation tool with 8 parameters, no annotations, and no output schema, the one-line description is insufficient. It does not explain update semantics, required versus optional field behavior, or the relationship between sla_id and rule_id beyond the schema. An agent would be guessing about common usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters. The description adds no additional parameter-level meaning, but it does not need to since the schema handles this adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Update') and resource ('a rule within an SLA policy'), so an agent can tell this modifies an existing SLA rule rather than creating or deleting one. It does not explicitly differentiate from siblings like kaiten_create_sla_rule or kaiten_delete_sla_rule, but the operation is clear enough from the wording.
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 does it mention prerequisites like the SLA policy already existing or permissions needed. Usage is only implied by the word 'Update' and the tool name, 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 supplied, the description carries the full burden of behavioral disclosure, but 'Update a Kaiten space' only indicates mutation. It does not describe partial-update semantics, required permission, side effects, or the response, which is especially important for a write operation with no annotation hints.
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 redundant wording or clutter. It is highly concise, though it is so terse that it adds little beyond restating the tool name.
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 CRUD update with fully documented parameters, the minimal description plus input schema is workable, but no output schema or annotations exist and the description does not explain update semantics or return behavior. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all seven parameters are documented in the input schema, so the baseline is 3. The description adds no parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update') and a specific resource ('a Kaiten space'), so the agent can identify the operation. It does not, however, add any distinguishing detail beyond the tool name, such as which space attributes are affected.
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 for when to choose this tool over the many sibling tools, such as kaiten_create_space, kaiten_get_space, or kaiten_delete_space. The usage context is left entirely to inference from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'update', which implies mutation, but gives no information about side effects, return values, permissions, reversibility, or behavior when role_id is omitted. For a mutation tool, this is a substantial 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise and easy to parse. It is somewhat too terse for the behavioral and usage context a mutation tool needs, but as a concise statement it is 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 and no output schema, the description must provide more operational context. It does not clarify whether role_id is effectively required to change a role, what happens if it is omitted, or how this differs from adding/removing a user from a space. An agent could invoke it incorrectly by omitting role_id while still expecting a role update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter individually described ('New role ID', 'User ID to update', 'Space ID'). The tool description adds no additional semantic meaning beyond the schema. The notable ambiguity around role_id being optional despite the operation being 'update a user's role' is not resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update a user's role in a Kaiten space.' This makes the operation clear and differentiates it from siblings like add_space_user and remove_space_user by the role-update intent. However, it does not explicitly name or contrast those siblings, so it falls just short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus kaiten_add_space_user, kaiten_remove_space_user, or kaiten_list_space_users. No prerequisites are given, such as the user already needing to be a member or the role_id being required for an actual role change. The agent must infer usage solely from the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It only states the generic 'update' action and does not describe important mutation semantics such as whether stages and transitions replace the entire workflow, whether partial updates are supported, what validation occurs, or any side effects. This is under-disclosed 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 or repetition. It is appropriately sized for the simple operation and the fully documented schema.
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 leaves out critical context such as required identification of the workflow, update semantics, and expected result. The schema covers parameters, but the missing behavioral and usage context makes the description incomplete for reliable 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 each parameter (name, stages, transitions, workflow_id) already documented in the schema. The description adds no additional parameter meaning, so the baseline 3 applies; the schema handles the parameter-semantics burden.
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 'Update a company workflow' uses a clear verb and resource, stating exactly what action the tool performs on the targeted entity. It does not explicitly differentiate from sibling update tools, but the workflow resource name distinguishes it from update_board, update_card, and similar 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 about when to use this tool versus kaiten_create_workflow, kaiten_get_workflow, kaiten_delete_workflow, or list_workflows. The description gives no context on situations where updating is appropriate or where alternatives should be selected.
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 'Create a new Service Desk service,' which conveys mutation but not side effects, whether the creation is immediate or asynchronous, what happens if defaults conflict (e.g., is_default), 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy, which is appropriately front-loaded for the core purpose. However, it is so minimal that it borders on under-specification, keeping it just below a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex creation tool with 16 parameters, nested objects, enums, no output schema, and no annotations. A single sentence with no guidance on return values, constraints between parameters, or operational behavior is severely incomplete for an agent to call it correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already documents every parameter's meaning. The description adds no additional parameter-level context beyond what is structured, which matches the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('a new Service Desk service'), and the word 'new' signals creation rather than update or retrieval. This directly distinguishes it from sibling tools like kaiten_update_sd_service, kaiten_delete_sd_service, and kaiten_get_sd_service.
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, no prerequisites, and no context such as required board ownership or uniqueness constraints. An agent must infer that 'create' means it is for new services rather than existing ones, with no explicit routing 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 indicates that the action is additive ('Add') but does not mention side effects, idempotency, whether existing vote properties are replaced, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It front-loads the primary action and object, making it easy to scan.
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 only two required parameters, both well-documented in the schema. However, with no annotations and no output schema, the description could provide more context about return values, error conditions, or behavioral guarantees.
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 clearly described in the schema. The description adds little beyond what the schema already states, 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.
Purpose4/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 identifies the exact resource being modified: a custom property becoming a vote property for a Service Desk service. It is clear and distinguishable from the sibling tool that removes vote properties, though it does not explicitly name that alternative.
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, no prerequisites, and no mention of the corresponding removal operation. The description implies a configuration action but leaves the decision context to the agent.
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, so the description carries the full burden of behavioral disclosure. It only says 'Create a new board' and does not mention permission requirements, side effects, duplicate behavior, or what response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the core action, and contains no filler. It is appropriately concise, though it omits useful behavioral 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?
For a mutating tool with no annotations, no output schema, and eight parameters, the description is too sparse. It does not mention expected response, how to obtain a space_id, or any caveats relevant to creating a board.
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 every parameter is already documented in the input schema. The description adds only the context that a board belongs to a Kaiten space, without explaining optional parameters or relationships 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 states a specific verb (Create), an exact resource (board), and the scope (in a Kaiten space). This clearly distinguishes it from sibling tools like kaiten_update_board, kaiten_delete_board, and other kaiten_create_* 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 about when to use this tool versus alternatives such as kaiten_update_board, or about prerequisites like needing an existing space_id. The agent must infer usage solely from the verb and resource rather than from explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Create a blocker on a card,' which conveys the basic mutation but does not disclose side effects, permissions, reversibility, or behavior when blocker_card_id is omitted.
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 with no filler or repetition. It is front-loaded and every word contributes to the 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 tool is relatively simple and the schema covers all parameters, but with no annotations and no output schema, the description leaves some context implicit, such as the meaning of a blocker and how the two card IDs relate. It is minimally sufficient 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter meaning, but the baseline of 3 applies because the schema fully covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: create a blocker on a card. It is distinguishable from sibling operations like kaiten_update_card_blocker and kaiten_delete_card_blocker by the 'create' verb, though it does not explain the blocking relationship in the description itself.
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 about when to use this tool versus alternatives, no mention of prerequisites, and no indication of whether both card_id and blocker_card_id should be supplied. The description implies the operation but offers no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only states the basic mutation. It does not disclose authorization requirements, uniqueness constraints, idempotency, side effects, or what the response will contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise, front-loaded sentence. The only slight redundancy is 'in Kaiten', since the tool name already contains the product, but it is not distracting.
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 with no annotations and no output schema, the description leaves the agent without information about expected return value, required permissions, or behavioral constraints. It is sufficient to know what the tool creates but not to fully anticipate the outcome of invoking 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 schema already covers the single parameter name with a 'Group name' description, so the baseline is 3. The tool description adds no additional semantics about name format, uniqueness, or constraints.
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?
States exactly what the tool does with a specific verb and resource: "Create a new company group." Together with the tool name, this unambiguously identifies the operation and distinguishes it from sibling create_* tools for other resources and from get/update/delete variants of company group.
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 about when to use this tool versus kaiten_update_company_group, kaiten_delete_company_group, or kaiten_get_company_group. There are also no prerequisites, such as required permissions or whether the group must be unique.
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 behavioral disclosure burden. It reveals only that this is a creation operation; it does not disclose what the tool returns, whether duplicate names are rejected, error behavior, or permissions needed. The agent knows it writes but not what to expect.
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 single sentence is efficient, front-loaded, and free of filler. It earns its place, though it could include a bit more useful context (such as return behavior) without becoming bloated.
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 and no output schema, the description does not explain what the call returns, whether names must be unique, or how a created template answer is identified afterward. Parameter schema coverage is complete, but the behavioral context an agent needs for a create operation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters (name with max length, text with its purpose). The description adds no parameter-level detail, 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 uses a specific verb ('Create') and a specific resource ('Service Desk template answer'), which precisely states what the tool does. Among the large sibling set it is distinguished from list/get/update/delete_sd_template_answers by the create verb, and from other create_* tools by the resource being created.
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 that updating an existing answer would use kaiten_update_sd_template_answer, or that listing existing answers should go through kaiten_list_sd_template_answers. An agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states only the basic effect of creating a subcolumn and does not mention required permissions, whether the parent column is modified, what response is returned, or any side effects of optional parameters like col_count.
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 front-loaded sentence with no filler or repetition. It is economical, though extremely sparse; there is no wasted text, but it also makes no effort to elaborate beyond the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with five parameters and no output schema, one sentence is insufficient context. The description does not explain how col_count, wip_limit, and sort_order behave, what the tool returns, or how it relates to the overall column/subcolumn workflow among the many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all five parameters with descriptions, so the description adds no additional parameter meaning. Baseline 3 applies because schema coverage is 100% and the description does not contradict or enrich the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (create) and resource (subcolumn) with a locational qualifier ('inside a Kaiten column'), which clearly distinguishes it from sibling tools such as kaiten_create_column or kaiten_update_subcolumn. Although terse, it leaves no ambiguity about what operation is being offered.
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 about when to choose this tool over kaiten_create_column or how it relates to kaiten_list_subcolumns and kaiten_update_subcolumn. The verb and noun imply a usage context, but the description does not state prerequisites, exclusions, or alternatives.
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 'Delete a company group' and does not mention whether deletion is permanent, whether it cascades to related data, what happens if the group has members, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/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 is appropriately concise for a one-parameter delete operation, though it omits behavioral context that other dimensions account for.
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 destructive, has no annotations, and no output schema, yet the description only restates the action. An agent is left without information about consequences, failure modes, or what happens to associated group users, making the description incomplete for a delete 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% for the single parameter group_uid, so the schema already documents it. The description adds no additional parameter context, which aligns with the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and a specific resource ('company group') in Kaiten. This clearly distinguishes it from sibling tools like kaiten_delete_project or kaiten_remove_group_user, since 'company group' names a distinct entity type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention kaiten_remove_group_user for removing a user from a group, nor does it state prerequisites or conditions under which deletion 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. It only states that a subcolumn is deleted, without mentioning irreversibility, cascading effects on contained cards, permission requirements, or response behavior. For a destructive operation this is a meaningful 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, focused sentence with no filler or repetition. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation, the description plus fully documented schema is minimally sufficient to invoke the tool. However, with no annotations and no output schema, it lacks behavioral context such as whether deletion is permanent, what happens to dependent data, or what the return value is.
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 both column_id and subcolumn_id are already fully documented in the input schema. The description adds no additional meaning beyond what the schema provides, 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 a specific verb and resource: 'Delete a subcolumn from a Kaiten column.' It is unambiguous and distinguishes this from sibling operations like deleting a column or updating a subcolumn, though it does not explicitly name those 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 given about when to use this tool versus alternatives such as kaiten_update_subcolumn or kaiten_delete_column. The intended use is implied by the name and description, but there are no explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It only restates the destructive action without mentioning whether deletion is permanent, what cascading effects may occur, or what permissions are required.
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, scannable sentence with no wasted words. It is appropriately compact for a simple one-parameter tool, though it is minimal enough that it could have included more operational context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is under-specified. It does not mention irreversibility, side effects, or any caution around deleting a workflow, leaving an agent without the risk context needed to invoke it 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 already provides 100% coverage for the single required parameter, workflow_id, describing it as a UUID. The description adds no additional parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Delete a company workflow.' This clearly distinguishes it from sibling delete_* tools like kaiten_delete_project, kaiten_delete_board, or kaiten_delete_sprint, since the target resource is explicit.
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 about when to use this tool versus alternatives, no prerequisites like fetching the workflow first, and no mention that update_workflow should be used for modifications rather than deletion. The usage context is entirely absent.
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 'Get', implying a read operation, but does not describe error behavior, permissions, or how property_id and value_id relate. This leaves meaningful uncertainty about what the tool does beyond the most basic read intent.
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 six-word sentence with the verb and resource front-loaded. There is no redundant wording or unnecessary detail. It is appropriately concise for the information it conveys.
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 two-parameter get operation with full schema coverage, this is nearly adequate, but it omits the Kaiten-specific context: what a select value is, why property_id is required, and what the response contains. Since there is no output schema, the description should add at least a clarifying clause about the relationship between the two IDs and the returned object.
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 both parameters with descriptions, so the baseline is 3. The description's 'by ID' adds marginal context but does not clarify the relationship between property_id and value_id. No additional semantic value is provided 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 names a specific verb ('Get'), a specific resource ('select value'), and a selection mechanism ('by ID'). It distinguishes from sibling list_select_values by emphasizing 'single' and from create/update/delete_select_value by the 'Get' verb. It could be even stronger with an explicit alternative, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like kaiten_list_select_values or kaiten_create_select_value. There is no mention of prerequisites, such as needing a property_id, or when a caller should choose a different operation. The agent must infer usage entirely from the 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 carries the full burden of behavioral disclosure. It only says 'List all child cards' without clarifying whether this returns direct children only or all descendants, what fields are included, whether pagination applies, or what the response structure is. It is not misleading, but it is materially incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is appropriately sized and front-loaded. It contains no filler and directly states the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter listing tool this is minimally adequate, but the lack of an output schema and the absence of any notes on return shape, pagination, or distinction from similar siblings leaves meaningful gaps. An agent could call it correctly, but would lack context about what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the card_id parameter already has a description 'ID of the parent card.' The main description adds no additional semantic detail beyond what the schema provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all child cards of a given card.' This clearly identifies the operation and distinguishes it from tools like kaiten_list_card_parents, though it does not explicitly address closely related siblings such as kaiten_list_children.
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 kaiten_list_children or kaiten_get_tree. It does not mention prerequisites, context, or conditions that would help an agent choose between this and similar list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden. It only restates the basic operation; it does not disclose whether this is read-only, whether pagination applies, whether special permissions are needed, or what happens when a card has no parents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the operation with no filler. 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 one-parameter readonly-style list operation, the description is minimally adequate, but it lacks any mention of return format, pagination, or edge cases, and there is no output schema or annotations to fill that gap.
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 fully documents the only parameter (card_id) with a description, and schema coverage is 100%. The description adds no additional meaning about card_id beyond what the schema already states, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specifier: 'List all parent cards of a given card' uses a specific verb and resource, and the meaning is obvious even from the name. It does not explicitly contrast with closely related sibling tools like kaiten_list_card_children, so it falls 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 such as kaiten_list_card_children or the parent-card modification tools. There is no indication of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of explaining behavior. It only restates that the tool lists lanes; it does not mention pagination, ordering, authorization requirements, or whether archived/inactive lanes are included.
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 filler, front-loading the verb and resource before the scope. Every word contributes 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?
For a one-parameter list operation, the invocation path is clear: supply board_id. However, with no annotations and no output schema, the description leaves return-value details and behavioral constraints unspecified, and it offers no sibling differentiation.
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 fully documents the single parameter board_id as 'Board ID', providing 100% coverage. The description adds no parameter-specific meaning beyond restating that lanes are on a board, so the baseline score 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 the resource ('lanes/swimlanes') scoped to a Kaiten board, so an agent can understand the tool's basic purpose. However, it does not explicitly differentiate this from sibling list tools such as kaiten_list_columns or kaiten_list_subcolumns.
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 listing columns, subcolumns, or workflows. With a very large sibling set, this lack of disambiguating context forces the agent to rely on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'List cards' and does not mention read-only semantics, pagination, sorting, permissions, or response format. It is not misleading, but it is too sparse to give an agent meaningful expectations 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 wasted words and the core action and target resource appear immediately. It is appropriately minimal for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a simple two-parameter schema, the one-line description plus schema is minimally sufficient to make a call. However, the lack of an output schema and the presence of several similar card-list siblings mean the description does not fully clarify what to expect from the response or how this tool fits among its alternatives.
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 documents both parameters, including the UUID type for project_id and the meaning of compact, so schema description coverage is 100%. The description adds no additional parameter-level meaning, which matches the baseline of 3 when the schema carries the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('cards in a Kaiten project'), so an agent can identify what the tool does. However, it does not explicitly distinguish this from sibling tools like kaiten_list_cards or kaiten_list_all_cards, leaving some ambiguity about scope differences.
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 the other card-listing tools in the sibling list, such as kaiten_list_cards, kaiten_list_all_cards, or kaiten_get_card. The description gives no exclusions, prerequisites, or alternative-selection hints.
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 conveys a read-style operation via the word 'List' but discloses nothing about pagination defaults, response shape, filtering, scoping, or access requirements. For a tool with zero annotation coverage, this is a meaningful gap, even if the operation is simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence, front-loaded with the verb, with zero filler. Every word earns its place; there is nothing to trim or reorganize.
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 low-complexity read tool with only 2 optional parameters and no output schema, the definition is minimally viable but spare. Without an output schema or annotations, a brief indication of what the returned SLA policies look like or how pagination behaves would round it out, though the operation is simple enough that an agent can infer standard list semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both 'limit' (Max results) and 'offset' (Pagination offset) are already documented in the input schema. The description adds no parameter-level meaning beyond those schema descriptions, so the baseline 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?
States verb 'List' + resource 'Service Desk SLA policies', making the operation unambiguous. The verb distinguishes it from mutate siblings like kaiten_create_sd_sla, kaiten_update_sd_sla, kaiten_delete_sd_sla, and from single-item retrieval (kaiten_get_sd_sla). Minor deduction: it doesn't explicitly contrast with siblings, but the collection-vs-single distinction is inferable from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as kaiten_get_sd_sla for a specific policy, or how SD SLA policies relate to kaiten_list_sd_requests/kaiten_list_sd_services. The limit/offset parameters imply a paginated listing use case, but no context about selection criteria or prerequisites is given.
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 for behavioral disclosure. It only says 'List users' and does not mention pagination, response shape, ordering, permission requirements, or the impact of the compact flag. The read-only nature is implied by 'List' rather than 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 or redundancy. It earns its place and is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers its two parameters, so the minimal description is workable. However, with no annotations and no output schema, the description does not explain what the returned user list looks like, whether results are paginated, or how this list differs from kaiten_list_users. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description itself adds no parameter meaning, but it does not need to; the compact parameter has a clear schema description about avoiding heavy fields, and space_id is defined as 'Space ID'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a specific resource ('users of a Kaiten space'), with the required space_id reinforcing the scope. It is clear enough for an agent to understand the primary function, though it does not explicitly contrast with similar sibling tools like kaiten_list_users or kaiten_list_group_users.
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 kaiten_list_users, kaiten_list_group_users, or kaiten_list_sd_users. The phrase 'of a Kaiten space' implies a scoping condition, but no exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full responsibility for behavioral disclosure. It only says 'Remove a user' and does not describe side effects, reversibility, permissions required, idempotency, or what happens if the user is not in the organization. For a potentially destructive removal operation, this is a meaningful 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 filler or redundancy. Every word earns its place, and the core action and target resource are immediately clear.
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 two-parameter tool with full schema coverage, the description is minimally adequate for invocation. However, given the large sibling set and lack of annotations/output schema, it would benefit from usage guidance and behavioral context such as what the removal affects or how it relates to batch removal.
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% description coverage for both parameters, so the schema already documents user_id and organization_id adequately. The description adds no additional parameter semantics beyond what the schema provides, which meets 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 clearly states the action ('Remove') and the resource ('a user from a Service Desk organization'), making the tool's purpose unmistakable. However, it does not explicitly differentiate itself from sibling membership-removal tools like kaiten_remove_space_user or kaiten_remove_group_user beyond the 'Service Desk organization' qualifier.
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 about when to use this tool versus alternatives such as kaiten_batch_remove_sd_org_users or kaiten_remove_space_user. The usage context is only implied by the name and description, not stated explicitly, and no prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It indicates a mutating/generation action but does not explain whether the existing password is replaced, whether the temporary password is returned in the response, or any side effects, leaving the agent to infer important outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the action and target are front-loaded and 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 one-parameter tool, the description is minimally usable. However, since there is no output schema or annotations, the description should have stated what the caller receives (the generated password) and any side effects, so clear gaps remain.
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 sole parameter user_id is documented as 'User ID'. The description adds some domain context by specifying Service Desk, but it does not clarify the expected ID format or scope beyond that.
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 ('Generate') and resource ('temporary password for a Service Desk user'), making the operation clear. It does not explicitly contrast with related SD user tools like kaiten_update_sd_user, so it stops short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives such as kaiten_list_sd_users or kaiten_update_sd_user. No conditions, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Update a checklist' with no mention of required permissions, partial update semantics, effects on existing checklist data, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant wording. It is appropriately concise for a straightforward update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema covers all parameters, and no output schema exists. However, the description lacks usage guidance and behavioral context, leaving the agent to infer mutation effects and prerequisites from the tool name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameter meanings. The description adds no additional parameter context, but it does not need to because the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Update') and resource ('a checklist on a Kaiten card'). It is distinct from checklist creation/deletion or checklist item updates, though it does not explicitly differentiate itself from those sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like creating a checklist, deleting a checklist, or updating a checklist item. The usage context is only implied by the verb 'Update' and the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely says 'Update', implying mutation, but it does not describe partial-update semantics, required permissions, side effects on existing services, or behavior around archival/visibility.
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, front-loaded sentence with no filler. It is efficient, though it under-specifies for a tool with 17 parameters; still, there is no wasted text.
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 17 parameters, nested objects, no output schema, and no annotations, a one-sentence description is inadequate. It omits return value information, side effects, and any operational context an agent would need beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every one of the 17 parameters already has a meaningful description. The tool description adds no additional parameter-level context, 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 states a specific verb and resource: 'Update a Service Desk service.' It clearly distinguishes this from sibling tools like kaiten_get_sd_service, kaiten_create_sd_service, and kaiten_delete_sd_service by indicating the update operation on the Service Desk service resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description only conveys the basic action; it does not mention exclusions, prerequisities, or compare with other update_* siblings like kaiten_update_sd_request or kaiten_update_sd_settings.
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 carry the full burden of behavioral disclosure. It only says 'update', implying mutation, but does not describe side effects, permissions required, reversibility, partial-update semantics, or return values. For a write operation with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the core purpose without fluff. It is front-loaded and every word earns its place, but it is so terse that it lacks useful structure or elaboration that could aid an agent.
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 zero annotations and no output schema, the description is woefully incomplete. It does not explain whether fields can be partially updated, what the effect of col_count is, whether wip_limit and sort_order are mutually exclusive, or what the response will look like. An agent would likely need to guess at expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are at least named. However, the schema descriptions are minimal (e.g., 'New title', 'Number of sub-columns to split into') and the tool description adds no additional meaning beyond that. The description itself does not explain how parameters relate or what constraints apply, but the schema already provides basic semantics, so the 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 states a specific verb ('update') and a specific resource ('subcolumn of a Kaiten column'), which clearly differentiates it from sibling tools like kaiten_update_column and kaiten_delete_subcolumn. The purpose is immediately 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, nor any prerequisites or context. The description is a single declarative sentence that gives no indication of when updating a subcolumn is appropriate or how it contrasts with updating a column or deleting a subcolumn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral context, but it only restates that the tool adds a subscriber. It does not mention side effects, duplicate handling, permissions, notifications, or response behavior, leaving the mutation's consequences opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clean, front-loaded sentence with no filler or redundancy. It is appropriately compact for a simple operation, though it could have used the space to add behavioral guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with fully documented parameters, an agent can likely invoke it correctly with column_id and user_id. However, the lack of annotations and behavioral details such as optional type handling, side effects, or expected response leaves small but real gaps. It is minimally complete but not richly contextual.
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 documents all three parameters with 100% coverage, including the meaning of the type parameter (1=all, 2=mentions only, default 1). The description adds no additional parameter semantics, so the baseline of 3 is appropriate given the schema already carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add') and a specific resource ('subscriber to a Kaiten column'), making the tool's purpose immediately clear. It is naturally distinguished from sibling tools like kaiten_add_card_subscriber and kaiten_remove_column_subscriber because of the explicit 'column' target.
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 such as adding a card subscriber or listing/removing column subscribers. An agent must infer usage from the tool name alone, with no explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It only provides character limits for title and description; it does not state that creating a card is a mutating operation, any permission requirements, how failures are surfaced, or side effects such as linked child/parent cards or tags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It leads with the operation and resource, then adds the two key constraints. It is appropriately sized for what it attempts to convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 26 parameters and no output schema, this two-sentence description is inadequate. It does not explain relationships among board_id, lane_id, column_id, position versus sort_order, or how to supply custom properties, all of which an agent needs to 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?
Schema description coverage is 100%, so the baseline is 3. The description only restates the title and description length constraints that already exist in the schema, adding no new meaning for the other 24 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 states a specific action ('Create') and a specific resource ('a new Kaiten card'). It clearly distinguishes itself from sibling tools like kaiten_update_card, kaiten_archive_card, and kaiten_delete_card, so an agent can select it correctly 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 gives no guidance on when to use this tool versus alternatives like kaiten_update_card or kaiten_move_card. It does not mention prerequisites (e.g., board_id being required) or scenarios where this tool should not be used, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core 'create' action, without mentioning side effects, permissions, idempotency, return behavior, or whether existing entities must already exist. This is minimal disclosure at best.
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 with no filler. It front-loads the action and quickly identifies the target resource, making it easy to parse and remember.
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?
Despite a simple schema, there is no output schema and no annotations, and the description adds only a bare statement of intent. An agent is left without information about return values, error handling, prerequisites, or any special behavior when creating a checklist item.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds no additional meaning or context about parameter relationships, defaults, or optionality, 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 clearly states a specific action and resource: creating an item within a checklist on a Kaiten card. This distinguishes it from sibling tools like kaiten_create_checklist, kaiten_update_checklist_item, and kaiten_list_checklist_items because the verb and object are explicit.
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 about when to use this tool versus alternatives, such as kaiten_update_checklist_item for modifying an existing item or kaiten_list_checklist_items for viewing items. There are no context cues, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention side effects, permissions, visibility implications, internal comment behavior, or response behavior. For a mutation tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the action and target. There is no wasted wording, fluff, or redundancy; it is optimally concise for a purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema, yet the description provides only a minimal action statement. It omits guidance on expected results, required permissions, or when a user would prefer this over related comment tools. The schema covers parameters, but the surrounding context needed for confident invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema itself thoroughly documents parameters including format, internal, card_id, and text. The description adds no parameter-level 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.
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 card.' uses a specific verb and resource, clearly identifying the operation as creating a comment. This distinguishes it from sibling tools like kaiten_update_comment, kaiten_delete_comment, and kaiten_list_comments without needing to open schemas.
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 updating an existing comment or listing comments. There are no exclusions, prerequisites, or contextual tips for an agent to decide between creating and modifying comments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses only that the tool creates a custom property, with no additional behavioral context such as permission requirements, whether the operation is destructive, how type-specific data affects the created property, or what the response will be. Since no annotations are provided, the description carries the full burden but does not meaningfully go 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, compact sentence with no filler or repeated schema content. It is front-loaded with the key action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 11 parameters, many type-specific conditional requirements, and no output schema, a one-sentence description is insufficient. The schema helps, but the description does not mention the need to pass type-specific configuration via the 'data' object or any expected behavior after creation, leaving the agent without enough high-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description itself adds no parameter-level insight, but the schema already documents all parameters clearly, including type-specific data and conditional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action ('Create') and a specific resource ('company custom property'), which distinguishes it from sibling tools like list/get/update/delete custom property and from other create_* tools. Even though it is short, the verb and resource are 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?
The description provides no guidance on when to use this tool versus alternatives such as kaiten_update_custom_property or kaiten_create_select_value. No exclusions, prerequisites, or context are given, so the agent must infer usage entirely from the 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 present, the description carries the full burden of behavioral disclosure. It only says 'Delete,' implying destructiveness, but does not mention permanence, cascading effects on cards or lanes, required permissions, or any other operational consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It front-loads the action and the object, making it instantly 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?
For a destructive operation with no annotations and no output schema, this description is under-specified. It omits important context such as whether the deletion is irreversible, what happens to dependent entities, and whether special permissions are required.
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 descriptions for both parameters at 100% coverage, so the description does not need to repeat them. However, it adds no additional meaning about the relationship between space_id and board_id or any constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('a Kaiten board'). It is unambiguous and distinguishes itself from the many sibling delete_* tools by naming the exact target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like delete_project or delete_space, nor any prerequisites or caveats. The agent must rely solely on the tool name to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the destructive action already implied by the tool name. It does not explain whether deletion is permanent, affects other data, or has permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or unnecessary detail, which suits a simple two-parameter tool. It is concise but does not add much beyond what the tool name already communicates.
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 minimally adequate: an agent can identify the operation and the required IDs from the schema and tool name. However, it lacks useful context such as whether deletion is irreversible, what the response looks like, or how this relates to other blocker operations. Given no annotations or output schema, this is a moderate gap.
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 adds no parameter-specific meaning, but the input schema fully documents both required parameters with 100% coverage. Since the schema handles parameter semantics, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('a blocker'), and the scope ('from a card'), making it immediately distinguishable from sibling operations like create, get, update, or list blocker. The meaning is unambiguous and specific.
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 such as kaiten_create_card_blocker or kaiten_update_card_blocker. There is no mention of prerequisites, workflow context, or when deletion would be 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Delete,' which implies a destructive operation, but it does not state whether deletion is irreversible, whether it cascades to contained documents, what permissions are required, or what the response looks like. 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 filler or repetition. It is appropriately front-loaded and every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is under-specified. It does not explain the consequences of deletion, whether associated content is affected, or what happens on success or failure. A more complete description would mention reversibility, scope of deletion, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single required parameter group_uid as 'Document group UID,' so schema coverage is 100%. The description adds no additional meaning or format details beyond this, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') and a specific resource ('a Kaiten document group'), which clearly differentiates this tool from siblings like kaiten_delete_document, kaiten_get_document_group, and kaiten_update_document_group. An agent can understand what the tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. Usage context is only implied by the name and the verb; there is no mention of when not to use it or what to use instead in related 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?
No annotations exist, so the description carries the full burden of disclosing behavior. 'Delete' signals destructiveness, but the description does not state whether deletion is permanent, whether it cascades to related entities (boards, cards, etc.), what permissions are required, or what happens to existing project data. This is a significant transparency gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. 'Delete a Kaiten project.' is front-loaded and contains exactly the information needed to state the primary purpose, not more.
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 simple one-parameter tool, the description is functionally minimal but not complete enough for a destructive action with no annotations and no output schema. Missing context includes reversibility, cascading effects, required permissions, and any response or confirmation behavior. Compare with mutation tools that received similar scores for lacking these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete documentation for the single parameter: 'Project ID (UUID)' with 100% coverage. The description adds no additional parameter context, but per the rubric, the baseline of 3 applies because the schema already carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb + resource: 'Delete a Kaiten project.' This clearly distinguishes it from sibling delete tools like kaiten_delete_board or kaiten_delete_workflow, since the resource is named explicitly and no other tool in the list deletes a project.
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, exclusions, or situations where a different project-related operation (e.g., kaiten_archive_card, kaiten_delete_space) would be more appropriate. The agent is left to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the operation. It does not mention whether the response includes member lists, whether invalid UIDs return null or an error, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the key identifier detail 'by UID' is front-loaded. It is appropriately short for a simple get operation, though it sacrifices behavioral context.
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 one-parameter get operation, the description is minimally adequate: it names the resource and the required identifier. However, with no output schema and no annotations, a bit more context about what is returned or how to handle missing groups would make it 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?
The single parameter group_uid is fully described in the schema with 'Group UID', and the description merely echoes the lookup-by-UID semantics. Since schema description coverage is 100%, the baseline of 3 applies; the description adds no meaningful parameter information 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 states a specific verb and resource: 'Get a company group by UID.' It clearly identifies this as a single-item retrieval operation, distinguishing it from kaiten_list_company_groups, kaiten_create_company_group, and kaiten_delete_company_group without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need a specific company group identified by UID. However, it provides no explicit guidance about alternatives, when not to use it, or how it relates to list_company_groups or other company-group operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only restates the condition and state numeric mappings that already appear in the parameter schemas. It does not mention read-only behavior, response shape, pagination, or any operational caveats, so it adds little transparency beyond the structured schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and front-loads the primary action before the enum reminder. It is appropriately short, though the condition/state sentence is partly redundant with the schema, keeping it from a perfect score.
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 27-parameter read/list tool with no annotations and no output schema, the description is a bare minimum: it gives the primary purpose and two enum references, but omits high-level context such as what the result contains, how filters combine, or how this differs from kaiten_list_all_cards. The complete parameter descriptions in the schema prevent this from being a serious failure.
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 every parameter already has a meaningful description, so the baseline is 3. The prose description adds only the condition/state enums already present in the schema and no new parameter semantics, so it neither hurts nor improves on 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 states a specific action ('Search and list Kaiten cards') and highlights filtering as its core capability, which is sufficient to identify what the tool does. It does not explicitly differentiate it from siblings like kaiten_list_all_cards or kaiten_get_card, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'With filtering' implies the tool is appropriate when the agent needs to search or filter cards rather than fetch a single card or list all cards. However, no alternative tools are named and no when-not-to-use conditions are provided, leaving the selection guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool lists properties and shows valid types, but it does not disclose pagination behavior, default filtering (e.g., active and inactive), response format, or whether any side effects occur. For a read-only list tool this is a meaningful gap, though the absence of mutation language weakly implies a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action is stated first, and the supporting type list follows. Every sentence contributes useful information, and the structure is immediately scannable for an agent.
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 list endpoint with 10 optional parameters, 100% schema coverage, and no annotations, the description is minimally adequate but leaves several gaps. It does not describe the return payload, default pagination, or default condition behavior, and it does not help an agent choose between this and sibling custom-property tools. The type enumeration adds useful domain context, but the overall definition is not complete enough for an agent acting without additional documentation.
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 already documents all 10 parameters with 100% coverage, so the baseline is 3. The description adds value by enumerating the exact valid type names ('string, number, date, email, checkbox, select, formula, url, collective_score, vote, collective_vote, catalog, phone, user, attachment'), which directly informs the `types` filter parameter and is information not present in the schema. It does not add meaning for the other nine parameters, but the schema handles those adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List company custom properties.' It also enumerates the supported property types, which further clarifies what kind of entities this tool returns. However, it does not explicitly distinguish itself from the related kaiten_get_custom_property or kaiten_list_select_values tools, so it misses the explicit sibling differentiation needed for 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?
There is no guidance about when to choose this tool instead of related ones such as kaiten_get_custom_property, kaiten_create_custom_property, or kaiten_list_select_values. The list semantics are implied by the name, but the description does not state any context, prerequisites, or exclusions, so an agent receives no direct routing help.
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 full behavioral burden. It only restates the action ('List') and the resource, without disclosing whether the result is paginated, scoped to a service, or requires particular permissions. The verb implies a read-only operation, but no additional behavioral 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, short sentence with no filler. It is fully front-loaded and every word carries meaning, making it highly concise for a parameter-less list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-free list operation, the description is mostly complete. However, with no output schema and no annotations, it misses useful context such as the shape of the returned list or any filtering scope. An agent can call it correctly, but might not know what to expect in the response.
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 input schema fully covers parameter semantics. The description does not need to add parameter details, and the baseline 4 for a parameter-free tool 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 names a specific verb ('List') and a specific resource ('Service Desk template answers'), making the operation clear. It is distinguishable from sibling tools like kaiten_get_sd_template_answer or kaiten_list_sd_requests, though the description relies on the resource name rather than explicitly differentiating scope or behavior.
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 about when to use this tool instead of alternatives. There is no mention of use cases, exclusions, or related tools such as kaiten_get_sd_template_answer or kaiten_create_sd_template_answer.
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 indicates a read/list operation but does not clarify scope ('all' could mean all users' timers or the current user's), authentication needs, pagination, or return format.
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 zero filler. Every word contributes to naming the operation and its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, this is minimally sufficient: an agent knows what action to perform. However, without an output schema or annotations, the description leaves 'user timer' undefined and does not clarify scope or response structure, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty and has 100% coverage, so there are no parameters requiring documentation. The word 'all' reinforces that no filtering or pagination parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb ('List') and resource ('user timers'), with 'all' signaling an unfiltered retrieval. It is distinguishable from siblings by the resource name, though it does not explicitly contrast with kaiten_get_user_timer or kaiten_list_card_time_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The description only implies 'use when you need all user timers' and does not explain when to choose this over get_user_timer or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core action but omits details such as whether moving affects other card properties, whether destination fields are mutually exclusive, what permissions are required, or what the response contains. 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, front-loaded sentence with no filler or redundant information. Every word contributes 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?
Given the lack of annotations and output schema, the description is too minimal. It does not clarify whether at least one destination parameter is required, how board/column/lane interactions work, or what the expected result is. An agent would need to infer important behavior from the parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description adds no additional parameter-level meaning, 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 uses a specific verb ('Move') and names the exact resource (Kaiten card) plus the destination dimensions (board, column, lane). This clearly distinguishes it from sibling tools like update_card, archive_card, or delete_card.
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 such as kaiten_update_card or kaiten_create_card. It does not state exclusions, prerequisites, or when another tool would be more 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core mutation action but does not disclose whether removal is idempotent, what happens if the user is not a subscriber, whether permission is required, or whether the operation is reversible via kaiten_add_card_subscriber. No information is provided beyond what the tool name already implies, and 'Remove' itself is the only behavioral signal.
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?
A single front-loaded sentence with no filler. The 'watcher' synonym earns its place by clarifying terminology. It is appropriately sized for a simple two-parameter operation, though it could have used the same brevity to add an idempotency or alternative-tool note.
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 two-parameter mutation with full schema coverage and no output schema, the description is minimally viable but not complete. It omits the relationship to sibling tools (add/list card subscribers) and any error or idempotency behavior, which an agent would need to reason about side effects. Adequate for a trivial remove operation, but no more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both card_id ('Card ID') and user_id ('User ID to unsubscribe') are already documented in the schema. The description adds marginal value by mapping the noun 'subscriber' to the user_id parameter, but it does not add format, constraint, or relationship details beyond the schema. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove') and a clear resource ('a subscriber (watcher) from a Kaiten card'). The parenthetical 'watcher' disambiguates the domain terminology, and the action is immediately distinguishable from sibling tools like kaiten_add_card_subscriber and kaiten_list_card_subscribers. 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 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 description does not reference the obvious sibling pairs kaiten_add_card_subscriber or kaiten_list_card_subscribers, nor does it state conditions such as what happens if the user is not currently subscribed. The usage context must be entirely inferred from the tool name, which is a narrow miss given the large 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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only states the action itself and does not mention whether removal is permanent, whether the user must already be in the group, what permissions are required, or what the response/result looks like. For a destructive mutation, 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, focused sentence with no wasted words. It communicates the core operation immediately and clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and only the bare action stated, the description is incomplete. An agent would not know about side effects, reversibility, error conditions, or whether removal is idempotent. More context is needed for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (group_uid and user_id) with 100% coverage, so the baseline is 3. The description adds no further semantic detail about parameter formats, relationships, or constraints.
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 ('Remove') and specifies a concrete resource ('a user from a company group'), which clearly conveys the action. It also distinguishes itself from sibling tools like kaiten_add_group_user, kaiten_remove_space_user, and kaiten_remove_card_member by naming the exact scope: company group.
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 kaiten_add_group_user for adding users or kaiten_list_group_users for viewing membership. It gives no prerequisites, no conditions, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Update' with no detail on mutation semantics, permission requirements, partial-update behavior, idempotency, or what happens if optional fields are omitted. For a write operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the core action and resource are front-loaded. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations, no output schema, and 8 parameters, yet the description provides only a one-line summary. It lacks guidance on update semantics, required identifiers are only in the schema, and it does not clarify how to set or clear optional fields like checked, user_id, or due_date.
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 input schema already documents all 8 parameters with terse but adequate descriptions. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline 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 states a specific verb ('Update'), resource ('an item in a checklist'), and containment context ('on a Kaiten card'). This distinguishes it from related tools like kaiten_update_checklist, kaiten_create_checklist_item, and kaiten_delete_checklist_item, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying an existing checklist item, and that creating or deleting items would belong to sibling tools. However, it does not explicitly state when to choose this over alternatives or provide any exclusions or usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states that an update occurs, but does not disclose whether the update is partial or full, whether it is reversible, what permissions are required, or what side effects may occur on existing webhook configuration.
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 redundant filler. It efficiently communicates the core action and resource, earning its place without unnecessary detail.
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 mutating tool with 9 parameters, no output schema, and no annotations, the description is too sparse. It does not explain how the update behaves, which of the optional fields are actually updatable, or how this differs from updating a regular webhook. The rich schema covers parameter meaning but not usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter. The description adds no additional parameter-level meaning beyond the tool's name and the phrase 'incoming (card-creation) webhook,' which is a minor clarification but not enough to exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a precise resource ('incoming (card-creation) webhook') and scope ('in a Kaiten space'). The parenthetical '(card-creation)' clearly differentiates it from the sibling kaiten_update_webhook and other webhook-related tools.
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 related tools like kaiten_create_incoming_webhook, kaiten_list_incoming_webhooks, or kaiten_update_webhook. The context is implied only by the word 'update'; there are no exclusions or alternatives 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 must disclose side effects, but it only says 'Add', implying mutation without explaining idempotency, permissions, whether an existing child relationship is replaced, or what happens on failure. It adds little beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word carries meaning and it is appropriately sized for a two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and fully parameter-documented, so an agent can assemble a call from the schema alone. However, with no annotations or output schema, the description omits behavioral context such as return values, required permissions, or relationship constraints, leaving some ambiguity for correct 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 both parameters are clearly labeled as parent and child IDs. The description only restates the relationship without adding format, constraints, or ordering semantics.
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?
States a clear action ('Add') and resource ('child card' to 'a given card'), and the child/parent direction distinguishes it from sibling tools like kaiten_add_card_parent and kaiten_remove_card_child.
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 choose this over closely related sibling tools (e.g., kaiten_add_card_parent, kaiten_remove_card_child) or any prerequisites such as whether the child card must already exist. Usage is only implied by the name and one-line 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 carries the full burden of behavioral disclosure. It only states the action and does not mention whether attaching replaces an existing SLA, requires specific permissions, is idempotent, or has any side effects on SLA measurements.
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 content. It conveys the core operation in the fewest words possible.
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 two-parameter mutation, the description provides a minimal viable invocation path. However, with no annotations, no output schema, and no usage/behavior guidance, it leaves gaps about the operation's effects and prerequisites that an agent may need to know.
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 card_id and sla_id already described in the input schema. The tool description does not add further semantic meaning beyond the schema, but it also does not need to because the schema is sufficient.
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 'Attach an SLA policy to a card' clearly identifies the verb (attach), the resource (SLA policy), and the target (card). It is distinguishable from sibling tools like kaiten_detach_card_sla and kaiten_get_card_sla_measurements without requiring schema inspection.
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 such as kaiten_detach_card_sla or kaiten_create_sla_rule. There are no conditions, exclusions, or contextual signals that would help an agent decide between related SLA operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing effects. It only states that a value is created, with no mention of uniqueness failure behavior, side effects, permissions, or response format. This is minimal for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler words; the key action and resource are front-loaded. It is appropriately sized for the tool's simplicity.
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 and the schema covers all parameters, but the description omits return value expectations and prerequisites such as property type and existence. An agent could invoke it, yet it is not fully complete without output schema or extra 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?
Input schema coverage is 100%, so the schema fully documents the four parameters. The description adds only a slight contextual link between select values and custom properties, which does not materially enhance what the schema already 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 states a specific action ('Create') on a specific resource ('select value') and scopes it to a custom property. This clearly distinguishes it from sibling tools like kaiten_update_select_value and kaiten_delete_select_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?
No when-to-use or alternative guidance is provided. The description does not mention prerequisites such as the custom property needing to exist, nor does it direct the agent to kaiten_list_select_values for uniqueness checks.
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, but it only repeats the destructive intent already visible in the name. It does not mention that deletion is permanent/irreversible, whether active API access is immediately revoked, or what permissions are required.
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 declarative sentence with no filler, and the action is front-loaded. This is appropriately sized for a tool with one required parameter and no nested objects.
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 one-parameter delete operation, the core invocation is covered by the schema and the clear action statement. However, because this is a destructive operation with no annotations and no output schema, the description would be stronger if it noted irreversibility or the effect on active API keys.
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 only parameter key_id is clearly described as 'API key ID'. The description adds no extra parameter detail, but none is necessary because the schema fully documents the single required input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and a specific resource ('API key'), which precisely distinguishes it from sibling tools like kaiten_list_api_keys, kaiten_create_api_key, and other delete_* tools. The action is unambiguous and complete.
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, no mention of obtaining the key_id first via kaiten_list_api_keys, and no exclusions or alternatives. Usage context is only implied by the verb and resource, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral burden, but it only restates the delete action. It does not disclose whether deletion is permanent/irreversible, whether active automation triggers are affected, or what the success/failure response looks like — material gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eight-word sentence conveys the full operation with zero wasted words, and the action is front-loaded at the very start.
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?
Complete on the parameter side — both required params are documented and simple, and no output schema is expected for a delete. However, with no annotations and no output schema, a note that deletion is permanent and an indication of the success response would meaningfully improve completeness for a destructive 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 adequately described ('Space ID' and 'Automation ID (UUID)'), so the schema carries the semantic weight. The description adds no parameter detail, which is acceptable at this coverage level.
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?
States a specific verb ('delete') with a precise resource ('automation') and scope ('from a Kaiten space'), leaving no ambiguity about what the tool does. It distinguishes clearly from sibling tools like kaiten_delete_workflow and kaiten_delete_board, and from the automation-focused siblings (list/create/get/update/copy).
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 when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives such as kaiten_update_automation for modifying an automation or kaiten_copy_automation for duplicating one, nor any prerequisites like the automation needing to exist in the space.
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 'Delete,' which implies destructiveness, but does not state whether deletion is permanent, whether it affects associated cards or SLA measurements, or whether any confirmation or special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with zero filler. The resource and action are front-loaded and unambiguous.
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 two-parameter delete operation with a fully documented schema, the description is minimally adequate. However, it lacks any caution about irreversibility or downstream effects, which would be valuable for a destructive action with no annotations.
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 sla_id and rule_id described in the schema. The tool description adds no additional parameter meaning, but the schema already provides sufficient semantic detail, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete') on a specific resource ('a rule from an SLA policy'). It clearly distinguishes this from sibling tools like kaiten_create_sla_rule and kaiten_update_sla_rule without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or context. Usage is only implied by the tool's name and description, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only restates the delete action without explaining whether deletion is permanent or reversible, whether it cascades to boards/cards/documents, or what permissions are required. For a destructive operation, this is a siginificant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff and the action verb is front-loaded. It is efficient and easy to parse, though it is slightly too sparse to qualify as a fully exemplary 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?
With no output schema and no annotations, an agent needs at least some context about the consequences of the operation, such as irreversibility or cascade deltions. The current description only restates what the tool does, leaving an agent unprepared for the destructive and possibly far-reaching effects of deleting a space.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, space_id, with a clear description 'Space ID' and 100% schema coverarge. According to the baseline, the schema already documents the parameteer adequately, and the tool description adds no additional parameter-specific context, which is acceptable here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Delete') and the specific resource ('a Kaiten space'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like kaiten_delete_project and kaiten_delete_board by naming the resource type, so an agent can select it correctly.
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 context is implied by the verb and resource, but the description provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions such as 'do not use if you only want to archive the space.' It relies entirely on the agent inferring that deleting a space is the right action.
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 indicates a listing/read operation only implicitly and says nothing about return shape, pagination, ordering, permissions, or side effects, which is a significant gap for an unannotated 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?
A single sentence communicates the action and scope with no filler or redundancy. The core information is front-loaded and every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is minimally viable: it identifies the resource and the required card_id. However, with no annotations and no output schema, it leaves return-value details and behavioral specifics unstated, so it is not fully 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% because card_id is already documented as 'Card ID.' The description adds no additional meaning about the parameter beyond identifying the card whose files should be listed, so it stays at the schema-covered baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('file attachments'), and a scope ('on a Kaiten card'), making it immediately clear what the tool does. This wording distinguishes it from related siblings such as kaiten_list_documents and kaiten_list_external_links.
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 explicit guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites beyond the obvious card_id. The one-sentence description only states the operation, leaving the agent to infer usage context from the tool 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must convey behavioral expectations. 'List' clearly indicates a read-only retrieval operation, but the description does not disclose response format, default pagination behavior, or any filtering semantics beyond what the schema already provides.
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 filler or redundancy. It is front-loaded with the action and resource, which is appropriate for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description and schema together are minimally sufficient. However, there is no output schema and no mention of what a 'document group' is, what the response contains, or how pagination behaves, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters limit, query, and offset are already fully documented. The description adds no additional meaning beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and a specific resource ('Kaiten document groups'), which makes the tool's function immediately understandable. It distinguishes itself from sibling tools like kaiten_list_documents and kaiten_get_document_group by naming the exact resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as kaiten_list_documents or when to prefer a specific document group retrieval tool. There is no mention of context, exclusions, or related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List' indicates a read-only operation, and the response-field listing helps set expectations. However, it does not mention permissions, whether archived or public documents are excluded by default, or any side-effect-free guarantees explicitly.
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. It states the action and resource immediately, then provides a compact, useful list of response fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only three optional parameters and no output schema, so the basics are adequately covered. The main gaps are lack of routing guidance and missing behavioral details like default ordering or whether archived documents are returned, but these are minor for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning for limit, query, or offset beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List Kaiten documents.' It also clarifies the tool's output by enumerating response fields. However, it does not explicitly distinguish itself from kaiten_get_document or other document-related list tools beyond the verb.
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 such as kaiten_get_document or kaiten_list_document_groups. The only usage signal is the word 'List', which implies collection retrieval but provides no exclusions or context about when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'List,' implying a read operation, but does not disclose pagination behavior, return format, scope, authentication needs, or any other behavioral traits.
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, front-loaded sentence with no wasted words. It communicates the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with three optional pagination/search parameters and no output schema. However, the description does not explain what role data is returned, how pagination works, or what 'available' means in Kaiten's role model, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (limit, query, offset), so the schema already explains them. The tool description adds no additional parameter context, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List available roles in Kaiten.' It clearly distinguishes this listing tool from its sibling kaiten_get_role, which retrieves a single role, so an agent can tell them apart.
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 about when to use this tool versus alternatives such as kaiten_get_role, or whether there are prerequisites or exclusions. Usage is only implied by the tool's name and minimal 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 present, so the description carries the full responsibility for disclosing behavioral traits. It only says 'Remove a child card,' which does not clarify whether this unlinks the child, deletes the child card, or what side effects occur. It also does not mention permissions, reversibility, or the response after removal, leaving significant ambiguity for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It is front-loaded with the action and object, and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter relationship operation, the schema covers the inputs well, and no output schema exists to explain. However, the description does not clarify the operational semantics of 'remove' (unlink vs. delete) or provide any usage context, so an agent may not fully understand the consequence of invoking it. The definition is adequate but leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions in the schema already explain that card_id is the parent and child_id is the child to remove. The tool description adds no additional semantic detail beyond restating the relationship. Baseline 3 applies because the schema carries the parameter meaning.
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 ('Remove') and a clear resource/relationship ('a child card from a given card'), so an agent can understand the core action. It does not explicitly name or contrast the sibling tools like kaiten_add_card_child or kaiten_remove_card_parent, but the direction of the relationship is clear enough to distinguish it from its inverse.
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 intended use is implied by the wording: call this when a child card needs to be removed from a parent card. However, the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as kaiten_remove_card_parent for removing a parent relationship. The context is clear but the burden is on the agent to infer 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 of behavioral disclosure. It discloses that the tool removes a user but does not mention irreversibility, permissions, side effects on memberships, or what happens if the user is not in the space. For a destructive operation this is a notable 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 sentence with no wasted words, and the key action is front-loaded. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with clearly named parameters and full schema coverage, the description gives the essential information. However, the absence of annotations, output schema, and any behavioral caveats leaves some gaps around consequences and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented as 'User ID to remove' and 'Space ID'. The description adds no additional meaning beyond what the schema provides, so the 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 ('Remove') and resource ('a user from a Kaiten space'), which clearly distinguishes it from sibling tools like kaiten_add_space_user, kaiten_update_space_user, and kaiten_remove_group_user. An agent can immediately tell what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as kaiten_remove_group_user or kaiten_remove_card_member. The description only states the action, leaving the selection logic to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears the full burden of behavioral disclosure. It only states the action and affected fields, without mentioning whether updates are partial or full replacement, permission requirements, reversibility, or response/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the action and key editable attributes. It contains no filler, and the examples help convey scope without unnecessary detail.
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 9-parameter mutation tool with no annotations and no output schema, the description is adequate at a high level: it states what the tool updates and which attributes are involved. However, it omits usage context and behavioral detail that would help an agent invoke it correctly in a real workflow.
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 every parameter is already documented, including the enum values for type and the meaning of card_cover and sort_order. The description's brief field list 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update') and resource ('file attachment on a card'), and enumerates the editable fields. This clearly distinguishes the tool from sibling create/delete/list card-file tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives, and no prerequisites are mentioned. Usage is only implied by the verb 'update' and the sibling naming convention.
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 for behavioral disclosure. It states the update action and repeats the active=false finishing behavior that is already present in the input schema, but it does not disclose whether updates are partial or full, what side effects occur (beyond the schema's archive_done_cards field), or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the primary action. It contains no filler or irrelevant detail.
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 plus full schema coverage is adequate for basic invocation, but without annotations or an output schema it leaves gaps around return values, side effects of finishing a sprint, and required permissions. It is minimally viable but not rich enough for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no new parameter meaning beyond the schema; the active=false guidance duplicates the active parameter's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Update a Kaiten sprint.' It is unambiguous about the operation, though it does not explicitly differentiate itself from sibling tools such as kaiten_create_sprint or kaiten_delete_sprint beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one useful usage hint: set active=false to finish/complete the sprint. However, it does not mention when to use this tool versus creating, getting, or deleting a sprint, and provides no exclusions or alternative routing.
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 does disclose one meaningful constraint ('author only'), but it does not explain whether omitted optional parameters leave existing values unchanged, whether the update is partial or full, or what happens after a successful update. For a mutating operation this is thin.
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. It front-loads the action and resource, then adds the author-only permission caveat, which is directly useful for invocation decisions.
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?
All parameters are documented and the core intent is clear, making the tool minimally callable. However, with no annotations and no output schema, the agent is left guessing about update semantics such as partial updates, response behavior, and whether the author-only restriction refers to the authenticated caller.
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 descriptions for all six parameters, including constraints like min/max and format hints, so schema description coverage is 100%. The description adds no additional parameter-level meaning beyond identifying that the time log belongs to a card.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update') and a specific resource ('time log entry on a card'), and the '(author only)' qualifier adds useful scope. It is clearly distinguishable from sibling tools like kaiten_create_time_log and kaiten_delete_time_log.
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 kaiten_create_time_log, kaiten_delete_time_log, or kaiten_list_card_time_logs. The only contextual hint is the author-only restriction, which is a permission constraint rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool updates a timer, without stating whether the update is partial, what happens when paused is omitted, what the response looks like, or any permission requirements. For a mutation tool, this is a notable 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 filler. The example 'pause or resume' earns its place by clarifying the intended behavior, and there is no redundant framing or unnecessary detail.
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 two-parameter tool, this is minimally viable, especially since the schema fully documents the parameters. However, with no annotations and no output schema, the description leaves return behavior, partial-update semantics, and omission behavior unspecified. It is adequate but not fully 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?
The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds only a slight semantic hint that paused corresponds to pause/resume, but timer_id gets no additional meaning. It does not meaningfully compensate beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation (update) and resource (user timer), and adds concrete examples (pause or resume) that clarify the intended state change. It is clear and not a tautology, but it does not explicitly differentiate among sibling timer tools like kaiten_create_user_timer, kaiten_get_user_timer, or kaiten_delete_user_timer.
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 examples 'pause or resume' imply the tool is for changing timer state, which provides some usage context. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions. An agent must infer when this tool is appropriate versus the sibling timer 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, the description carries the full burden. It does communicate read-only behavior through 'Get' and 'Returns,' and it discloses that the result is a completed tasks summary with due-date filtering. However, it does not mention permissions, output format, pagination, or whether any side effects exist, so transparency is only partial.
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 with no filler. It front-loads the primary purpose and then gives the output nature, making efficient use of space.
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?
This is a 12-parameter tool with no annotations and no output schema, so the description carries a heavy burden. It provides only a high-level 'completed tasks summary' as the return description and omits details about how the date filters combine, what fields the summary contains, and what the response structure looks like. The schema documents parameter names, but the description is not complete enough for confident invocation without further 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 description coverage is 100%, so the baseline is 3. The description adds marginal value by connecting card and checklist item date ranges to the filtering behavior, but it does not explain parameter interactions, required combinations, or the purpose of the generic 'due_date' 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 uses a clear verb and resource: 'Get due dates analysis for a space.' It also specifies the output category ('completed tasks summary') and the two filtering dimensions (card and checklist item due dates), which distinguishes it from sibling chart tools like kaiten_chart_summary or kaiten_chart_cfd.
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 about when to use this tool versus alternatives, no exclusions, and no indication of how it differs from other chart endpoints. Usage context must be inferred entirely from the name and the single-sentence 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 carries the full burden. It only states the creation action and does not disclose side effects, required permissions, validation constraints, duplicate-name behavior, or what the response contains. This is a gap for a mutating tool with no annotation safety hints.
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 redundancy. Every word earns its place, and it is as compact as possible while still naming the resource and 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?
Given the nested 'rules' object, no output schema, and no annotations, the description is too sparse to fully orient an agent. It does not explain how rules should be structured, whether v2 is required for certain cases, what the return value is, or how this relates to sibling tools like kaiten_create_sla_rule.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters and their meaning. The description adds no additional parameter-level context, which lands at the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a specific resource ('Service Desk SLA policy'), and clearly differentiates from sibling tools like kaiten_update_sd_sla, kaiten_delete_sd_sla, kaiten_list_sd_sla, and kaiten_get_sd_sla. The phrase 'new' reinforces that this is the creation 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 the tool should be used when creating a new SLA policy, but it offers no explicit conditions, prerequisites, or alternatives such as 'use update_sd_sla to modify an existing policy.' It relies on the name and the verb 'Create' to convey usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'create' and adds no context about side effects, whether an existing timer is affected, authorization requirements, or what happens after creation. The schema hint 'to start timer for' slightly implies behavior, but the description itself is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is easy to scan. The word 'new' is slightly redundant with 'Create', but overall there is no wasted structure or excessive detail.
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 one-parameter create tool, the description and schema are minimally sufficient to make a call. However, with no annotations and no output schema, the definition lacks any information about the result, side effects, or conditions under which creation could fail, leaving meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the single parameter card_id is described as 'Card ID to start timer for'. The tool description restates the same idea without adding new meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('user timer'), and the target ('for a card'). This distinguishes it from sibling tools like kaiten_update_user_timer, kaiten_delete_user_timer, and kaiten_list_user_timers without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: create a new timer rather than update or delete an existing one. However, it does not explicitly state when to use this tool versus its CRUD siblings, nor does it mention any prerequisites or conditions.
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 behavioral disclosure burden. The verb 'Get' and the word 'current' imply a read-only operation resolved from the current context, but the description does not mention response contents, possible errors, or any side effects. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded six-word sentence with no filler or redundant information. It is appropriately concise for a zero-parameter getter.
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 no-parameter getter, the description is minimally sufficient to invoke the tool, but it does not explain what 'company information' includes or what the response will contain. Without an output schema, this vagueness leaves some ambiguity about the returned data.
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's 'current' reinforces that no input is needed and that the company is determined by the active context, which adds a small amount of meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource, 'current company information.' The word 'current' helps distinguish it from kaiten_update_company and kaiten_get_company_group, though it does not explicitly name sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 kaiten_get_current_user, kaiten_get_company_group, or kaiten_update_company. The description implies a retrieval need but lacks explicit context, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly implies a read-only fetch of the current settings, which is useful since no annotations are provided. However, it does not disclose the response shape, permission requirements, or whether the settings returned are scoped to the authenticated user. It is transparent about the core behavior but not fully detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant phrasing. It is appropriately sized for a parameterless getter and immediately states the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description is sufficient to invoke the tool, but it does not explain what the returned settings contain or how they relate to sibling tools. There is no output schema, so the description could have added more context about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% schema description coverage, so there is nothing for the description to add about parameter meaning. The baseline of 4 applies because zero parameters makes parameter documentation unnecessary.
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 and resource: 'Get current Service Desk settings.' The word 'current' signals a read-only snapshot and helps distinguish this from kaiten_update_sd_settings and kaiten_get_sd_stats. It is not a tautology, though it could be slightly more specific about which settings are included.
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 about when to use this tool versus alternatives such as kaiten_update_sd_settings or kaiten_get_sd_stats. There is no mention of prerequisites, when not to use it, or what makes it preferable to a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It correctly signals a non-destructive list operation, states company-wide scope, and lists supported filters. However, it does not mention pagination behavior, result size limits, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb, resource, and scope, followed by the key filtering capability. There is no filler and every word contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, optional-parameter read operation with a fully documented schema, the description is adequate. It omits return format and pagination details, but those are less critical for a list tool with rich parameter descriptions and no output schema requiring explanation.
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 already has a descriptive doc including defaults and valid values. The description's phrase 'category, action, and date range' mirrors the existing schema fields but adds no new 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.
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') with a clear resource ('Kaiten audit logs') and scope ('for the company'), and mentions the main filter dimensions. It is clear on its own, but it does not explicitly contrast with similar activity/log tools like kaiten_get_company_activity or kaiten_get_space_activity, leaving differentiation to name inference.
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 when-to-use guidance, no exclusions, and names no alternative tools. With several activity-related siblings, an agent has no explicit basis for choosing this over those alternatives.
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 burden of behavioral disclosure. It states the action but does not disclose whether removal is irreversible, what happens if the property does not exist, or whether removing a vote property affects existing votes.
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 one concise sentence that directly states the action and object with no filler or redundant information. It is appropriately sized for the tool's simplicity.
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 low-complexity operation with two clearly described required parameters, the description adequately identifies what the tool does and what it acts on. However, the lack of any behavioral or usage context slightly reduces completeness, though not severely.
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 service_id and property_id described in the schema. The description adds minimal additional meaning beyond restating 'vote property', 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 states a specific verb ('Remove'), a specific resource ('vote property'), and the target scope ('Service Desk service'). It clearly distinguishes this from the sibling kaiten_add_service_vote_property, leaving no ambiguity about the 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?
The description provides no guidance on when to use this tool versus alternatives, such as kaiten_add_service_vote_property or get_sd_service. The intended usage is only implied by the verb 'Remove' and is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation mutates URL and enabled state, but it does not mention permissions, whether updates are partial or full, side effects on event delivery, reversibility, or error/response behavior. This is a thin disclosure for a write 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?
Two sentences, front-loaded with purpose, and no filler. The second sentence is somewhat redundant with the schema, but it gives a compact overview of allowed changes.
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 schema fully covers the parameters and the tool is simple, so the description is minimally viable. However, with no output schema and no behavioral annotations, it leaves return values, failure modes, and update semantics 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 description coverage is 100%, so the schema already documents all four parameters. The description's 'Can change URL and enable/disable' restates the schema rather than adding deeper meaning such as URL format or enabled-state semantics, so the baseline 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?
Description uses a specific verb ('Update') and resource ('external webhook for a Kaiten space'), and names the two mutable aspects (URL, enabled). The qualifier 'external' distinguishes this from sibling kaiten_update_incoming_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for external webhooks, and 'external' hints at the boundary with incoming-webhook tools, but it does not explicitly state when to use this over kaiten_update_incoming_webhook or mention prerequisites like the webhook needing to exist. No exclusions or alternatives are named.
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 states the action and does not mention whether adding an existing subscriber is idempotent, whether special permissions are required, what side effects occur (e.g., notifications), or how errors are surfaced.
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 filler. It is front-loaded and an agent can parse it instantly.
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 two-parameter mutation, the description gives enough to invoke the tool with card_id and user_id. However, with no annotations and no output schema, key contextual details such as idempotency, permission requirements, and expected behavior on duplicate subscriptions remain unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents both parameters clearly ('Card ID' and 'User ID to subscribe'). The description adds minimal semantic value beyond the synonym 'watcher', 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 states a specific verb ('Add'), a specific resource ('subscriber (watcher)'), and the target ('a Kaiten card'). It clearly distinguishes this from related siblings like kaiten_remove_card_subscriber and kaiten_add_card_member.
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 intended use is implied by the verb and resource: use this when you need to add a watcher to a card. However, it does not explicitly compare itself to alternatives like kaiten_add_card_member, kaiten_remove_card_subscriber, or kaiten_list_card_subscribers, and gives no guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the key behavior — setting the card condition to archived — but it does not mention whether the operation is reversible, what permissions are required, or what side effects occur. Core behavior is clear; broader consequences are not.
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 compact sentence with a useful clarifying parenthetical. It is front-loaded with the action and contains no filler or redundant detail.
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 only one parameter, so the description is nearly adequate. However, with no annotations and no output schema, the description leaves the agent to infer success/error behavior and whether archiving can be undone. A short note on reversibility or expected outcome would make it 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?
The single parameter card_id is already fully described in the schema as 'Card ID or key' and is required. Schema description coverage is 100%, so the description adds no extra param semantics, but none are necessary here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and object: 'Archive a Kaiten card', and adds a clarifying parenthetical 'set condition to archived' that explains what archiving means. This distinguishes it from related mutations like kaiten_delete_card, kaiten_update_card, and kaiten_move_card.
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 about when to use this tool versus alternatives such as delete_card or move_card. The intended use is implied by the name and one-line description, but no explicit conditions, exclusions, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Add multiple users' without explaining behavior for duplicate users, idempotency, failure handling, permissions, or whether the operation is atomic. This is a mutating batch operation, and the description provides minimal behavioral detail beyond the action itself.
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 filler. The key distinction ('multiple' and 'at once') is front-loaded and every word adds 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?
This is a low-complexity tool with only two parameters and full schema coverage, so the description plus schema are minimally sufficient for invocation. However, with no output schema and no annotations, the description does not cover edge-case behavior, response details, or relation to the singular add operation, leaving meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both organization_id and user_ids are already documented. The description adds no additional parameter semantics, such as max batch size, duplicate handling, or ID format. Baseline 3 is appropriate given the schema fully explains 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 states a specific action ('Add multiple users') and the target resource ('Service Desk organization'), and the 'multiple ... at once' phrasing clearly distinguishes it from the singular sibling kaiten_add_sd_org_user. An agent can immediately understand 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 use for batch operations with 'multiple users' and 'at once', but it does not explicitly say when to prefer this over kaiten_add_sd_org_user or mention any limitations. Usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It makes the destructive nature of the operation clear, but it does not disclose partial failure behavior, atomicity, irreversibility, permissions, or other side effects. This is a minimal mutating operation description with no added behavioral 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 short sentence that front-loads the operation and object. It contains no filler and conveys the essential batch intent efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the required parameters, and the description states the core operation, so an agent can construct a valid call. However, with no annotations and no output schema, the description omits batch-specific caveats and consequences of removal, leaving some important context missing for a mutating 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 both parameters with 100% coverage, including their types and roles. The description adds no additional meaning beyond the schema, 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 uses a specific verb ('Remove') and clearly identifies the resource ('multiple users from a Service Desk organization'). The phrase 'at once' distinguishes it from the singular sibling kaiten_remove_sd_org_user, so the tool's scope is 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for batch removal by saying 'multiple users' and 'at once', which suggests when to prefer it over the singular removal tool. However, it does not explicitly name the alternative or provide exclusion criteria, so the guidance remains implied rather than direct.
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 bears the full burden of behavioral disclosure. It does disclose the critical asynchronous behavior and the polling mechanism, but it omits other behavioral details such as job lifecycle, compute cost, or whether results are persisted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the purpose, then state the metric, then provide the async workflow and polling instruction. Every sentence earns its place, and the structure is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the call lifecycle reasonably well for an asynchronous chart tool: what it builds, that it returns a job ID, and how to retrieve results. It lacks context about when to select this specific chart versus its siblings and does not describe the final result shape, which would be helpful given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description adds only high-level meaning by referencing 'space' and 'delivery throughput', but does not clarify parameter relationships or expected values 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 that the tool builds a Throughput Capacity Chart for a space and measures delivery throughput, giving a specific verb and resource. However, it does not differentiate itself from sibling chart tools like kaiten_chart_throughput_demand, which also relates to throughput metrics.
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 gives clear operational guidance: the call is asynchronous, returns a compute_job_id, and should be followed by polling via kaiten_get_compute_job. It does not, however, explain when to choose this chart over competing chart tools or any 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 full burden of behavioral disclosure. It does disclose the asynchronous nature, the compute_job_id return, and the polling mechanism, which is valuable. However, it does not state whether this operation is read-only, requires special permissions, or produces any side effects, which is a notable gap for a chart-building tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action and the critical async workflow are stated upfront, and the polling instruction is a compact, high-value addition.
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 adequately covers the essential call-and-poll workflow. However, with 8 parameters and no output schema, the agent is left without context on what the chart data will look like, what 'incoming demand' means in terms of columns, or how the optional filters/grouping affect the result. It is sufficient for invocation but not fully 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 schema already documents all 8 parameters. The description adds no additional parameter-level meaning (e.g., how group_by works or how date ranges interact), so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Build') and resource ('Throughput Demand Chart for a space') and adds the metric it measures ('incoming demand'). It is reasonably distinguishable from the many chart siblings by name and stated metric, though it does not explicitly differentiate itself from kaiten_chart_throughput_capacity.
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 gives clear follow-up usage ('Use kaiten_get_compute_job to poll for results'), which is genuinely useful. However, it does not explain when to choose this chart over other chart tools (cfd, control, throughput_capacity, etc.), leaving selection guidance to be inferred from the name and metric.
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 behavioral burden, but it only states the action. It does not disclose whether the source automation is left unchanged, what permissions are required, whether the copy overwrites an existing automation, or what the operation returns. This is a material gap for a mutation-like 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, front-loaded sentence with no filler or redundant phrasing. Every word contributes to identifying the action and its object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core operation and all required parameters are clear, making the tool invocable with the provided schema. However, because there is no output schema and no annotation layer, the description is missing behavioral context such as return value, success/failure behavior, and permission requirements, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all three parameters are already described in the input schema. The description adds only the directional nuance 'another space,' which reinforces that target_space_id should differ from space_id, but it does not meaningfully enrich parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('copy') with a clear resource ('automation') and destination ('another space'), making the operation unambiguous. It also differentiates from sibling automation tools such as kaiten_create_automation, kaiten_update_automation, and kaiten_delete_automation by naming the copy action.
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 intended use case ('copy an automation to another space') is implied by the operation itself, but the description gives no explicit guidance about when to choose this tool over kaiten_create_automation or when copying is not appropriate. No alternatives, exclusions, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that an external link is created and does not mention side effects, return behavior, uniqueness constraints, or permissions, which are relevant 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, front-loaded sentence with no filler. It communicates the essential purpose and adds no redundant or repetitive 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 tool is simple and the schema fully documents parameters, but there is no output schema and no annotations to clarify expected behavior or return value. The description is minimally sufficient for selecting the tool but leaves some invocation context undisclosed.
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 already has a direct description in the input schema. The tool description does not add parameter-level detail, 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 identifies the action (create), the resource (external link), and the target (a Kaiten card). This distinguishes it from sibling tools like kaiten_update_external_link and kaiten_delete_external_link without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'create' implies the tool is for adding a new external link, but the description gives no explicit guidance about when to prefer it over kaiten_update_external_link or kaiten_delete_external_link. It relies on the sibling names and general API conventions rather than stating exclusions or alternatives.
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 alone must disclose behavioral traits. It only states the mutation ('Create') and reveals nothing about permissions, uniqueness constraints, idempotency, or what the API returns on success/failure. This is a minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler words. Every element earns its place for a straightforward creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with complete schema coverage, but the lack of annotations and output schema means the description should convey more about expected behavior and results. It remains minimally adequate for an agent to select and invoke, though it omits return-value and failure details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already documents the 'name' and 'description' parameters with max lengths. The description adds no additional meaning beyond the schema, 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 uses a specific verb ('Create') and resource ('Service Desk organization'), clearly distinguishing this creation tool from sibling get/update/delete/list organization tools. No ambiguity about what action is performed.
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 action 'Create a new Service Desk organization' implies when to use it, but the description provides no explicit guidance about prerequisites, constraints, or alternatives (e.g., using update_sd_organization for existing orgs). Usage context is only inferred from the verb and name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only repeats the destructive verb 'Delete' and provides no additional context about permanence, cascading effects on checklist items, or required permissions. This is a noticeable gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It says exactly what is needed and nothing more, making it appropriately concise for a simple delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The operation and both required parameters are present, but there is no output schema or annotations, and the description does not address what happens to associated checklist items or what response is returned. For a minimal 2-parameter delete, this is adequate but not fully 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?
Both parameters are already fully documented in the input schema with 'Card ID' and 'Checklist ID.' The description adds no further parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and names the exact resource, 'a checklist from a Kaiten card.' This distinguishes it from sibling tools like kaiten_delete_checklist_item or kaiten_update_checklist without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever a whole checklist should be removed), but it does not explicitly contrast with alternatives such as kaiten_delete_checklist_item or mention prerequisites like permissions or existence checks. The intended use is inferred 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the organization is deleted, but it does not disclose whether deletion is permanent, whether related data is cascaded or removed, what permissions are required, or what response to expect. For a destructive operation, this leaves important behavioral 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, direct sentence with zero filler. It is front-loaded with the action and resource, and every word earns its place. The simplicity fits the tool's low parameter count and straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter deletion tool, the core call contract is complete: an agent knows what to delete and which ID is required. However, because there is no output schema and no annotations, the description should ideally provide at least a hint about expected outcomes, side effects, or irreversibility. This gap keeps it from being fully complete, but the tool's low complexity makes the missing context less critical than for a multi-parameter mutation.
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: organization_id is described as 'Organization ID' and is clearly required. The description adds no parameter-level detail, but it does not need to because the schema already documents the only parameter adequately. This is the baseline case where schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and a specific resource ('Service Desk organization'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like kaiten_create_sd_organization, kaiten_update_sd_organization, and kaiten_get_sd_organization, which operate on the same resource with 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?
The description implies the tool is used when a Service Desk organization needs to be removed, but it provides no explicit guidance on prerequisites, alternatives, or situations where deletion should be avoided. No sibling tool performs this exact deletion, so the lack of alternative routing is not a major issue, but usage context is still only implied.
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 present, so the description carries the burden of disclosing behavior. The 'archive' qualifier is useful because it signals that deletion is not necessarily a permanent hard delete. However, it does not mention permissions, side effects on related requests or SLAs, reversibility, 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 a single, front-loaded sentence with no filler. Every word adds meaning, and the key action and resource are immediately clear.
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 low complexity of a one-parameter delete operation, the description is minimally adequate. But with no annotations and no output schema, it could still disclose more about what archiving entails, whether deletion cascades, and any admin or permission requirements. It is not incomplete enough to prevent a call, but it leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents service_id with 100% coverage, so the baseline is 3. The description helps by clarifying that the 'service' in question is a 'Service Desk service,' but it adds no additional format, validation, or contextual constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and a specific resource ('Service Desk service'), and the parenthetical '(archive)' clarifies the exact semantic of the operation. This clearly distinguishes it from sibling delete tools targeting other resources like sd_requests, sd_sla, or sd_organizations.
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 such as kaiten_update_sd_service or kaiten_delete_sd_request. An agent must infer that this is the tool for removing an entire service, and no prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether the SLA policy itself is deleted, whether measurements are recalculated, or reversibility). This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with zero redundant words. It front-loads the core action ('Detach an SLA policy') and specifies the target ('from a card'), making it easy to scan and understand instantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (two simple parameters, no output schema, no annotations), the description is minimally acceptable but lacks important behavioral context. It does not clarify what 'detach' entails (e.g., whether it deletes the SLA policy, affects SLA measurements, or requires specific permissions), which could be important for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides clear descriptions for both parameters (SLA ID as UUID, Card ID as integer), achieving 100% schema description coverage. The description adds no additional meaning beyond what the schema already states, so it meets the baseline without enhancement.
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 ('Detach') with a clear resource ('an SLA policy') and target ('from a card'). It unambiguously distinguishes this from sibling tools like attach_card_sla and get_card_sla_measurements, making the action and scope immediately obvious.
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 states exactly what the tool does but provides no guidance on when to use it versus alternatives or any context on preconditions. There is no mention of when not to use it or which sibling tools might be better suited, so the agent must infer usage from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must stand alone. 'Get' clearly signals a read/retrieval operation and implies no side effects, but the description does not disclose response shape, permissions, or error behavior. It is minimally transparent but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven words and no filler; the verb-resource-ID structure is front-loaded and every word earns its place. This is an appropriately small description for a one-parameter getter.
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 and the schema covers the only parameter, so the core invocation is clear. However, with no output schema and no annotations, the description does not clarify what the response contains or what permissions are needed, leaving a moderate gap.
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 already fully documents calendar_id as a UUID, and the description only restates 'by ID' without adding format, source, or usage details. At 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('calendar'), and 'specific ... by ID' distinguishes this retrieval tool from the list_calendars sibling. It lacks a little explicit context about what a calendar is, but the operation 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies this tool should be used when a calendar ID is already known, but it never states when to prefer list_calendars or another sibling. No exclusions or alternatives are mentioned, so guidance is merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The verb 'Get' weakly implies a read-only operation, but the description does not state whether the call mutates anything, how pagination behaves, what the default limit is, or what permissions are required. This adds little 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, front-loaded sentence with no filler or redundant phrases. It states the action immediately and remains appropriately sized for a straightforward card-activity retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The required parameter and optional pagination fields are enough to make a call, but there is no output schema and no description of what the activity feed contains, how results are ordered, or any constraints. The description is minimally adequate but leaves meaningful gaps for an agent trying to interpret the response.
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 already described in the schema ('Max results', 'Pagination offset', 'Card ID'). The description does not add extra parameter semantics such as ranges, defaults, or ordering behavior, but the schema already provides adequate baseline 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 uses a specific verb and resource: 'Get activity feed' scoped to 'a Kaiten card.' This clearly differentiates it from sibling tools like kaiten_get_company_activity and kaiten_get_space_activity, which target different scopes, and from kaiten_get_card_location_history, which is a different kind of feed.
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?
There is an implied usage cue: use this tool when you need activity for a specific card. However, the description does not explicitly mention alternatives, when not to use it, or how it differs from other activity-scoped tools, leaving selection partially to inference.
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 responsibility for behavioral disclosure. It usefully mentions cursor-based pagination and the feed's company-wide scope, but it does not disclose auth requirements, rate limits, or return format. The read-only nature is implied by 'Get' but not explicitly confirmed.
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?
Exactly two sentences with no filler. Scope is front-loaded ('Get company-wide activity feed') and the mention of cursor pagination earns its place by signailing an important behavior for large datasets.
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?
All 10 parameters are optional and well-documented, so an agent can construct valid calls from the schema alone. However, with no output schema and no annotations, the minimal description leaves the agent without explicit information about response structure, permission expectations, or the practical difference from 'all space activity' tooling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and every parameter has a meaningful description, including cursor guidance ('use with cursor_created') and defaults. The description adds no parameter-level semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specic verb ('Get') and resouce ('company-wide activity feed'), and 'company-wide' provides scope that distinguishes it from the space/card activity siblings. However, it does not explicitly differentiate it from similar siblings like kaiten_get_all_space_activity, leaving mild ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used for company-wide activity, but it does not state when to prefer this tool over alternatives like kaiten_get_space_activity, kaiten_get_card_activity, or kaiten_list_audit_logs. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the retrieval action; it does not explicitly confirm side-effect-free behavior, mention whether any permissions are required, or describe what is returned. The verb 'Get' implies read-only, but no additional behavioral context is 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?
A single, front-loaded sentence states exactly what the tool does with no filler or redundant elaboration. 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 single-parameter getter this is nearly adequate, but with no output schema the description does not mention return value shape, error conditions, or any special behaviors. Given the low complexity, these gaps are relatively minor but still leave an agent to infer the response format.
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 fully documents the only parameter (service_id, type integer, description 'Service ID') with 100% coverage. The description's 'by ID' phrase merely restates the schema; it adds no extra meaning about formats, constraints, or source of the ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a concrete resource ('Service Desk service'), and a scoping mechanism ('by ID'). This clearly distinguishes it from sibling tools like kaiten_list_sd_services (which lists services) and kaiten_create_sd_service (which creates one), even without naming them.
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 intended usage is implied: call this when you have a specific service_id and need the corresponding service object. However, there is no explicit guidance about when not to use it or which alternative to choose (e.g., kaiten_list_sd_services for browsing), leaving a small gap in routing the agent.
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. 'List all items' indicates a read operation and an all-items scope, but it does not disclose output format, pagination, or prerequisites. Minimal behavioral context is added 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 concise sentence with no filler or redundancy. It is front-loaded with the verb and resource and every word contributes to 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?
This is a simple tool with two fully documented parameters, but there is no output schema. The description adequately implies the return type ('items') but leaves return-field details, error conditions, and checklist-card relationship assumptions unstated.
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 card_id and checklist_id adequately described. The description itself adds no parameter-level meaning, but the schema already covers that need, 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.
Purpose4/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 items in a checklist on a Kaiten card, with a specific verb and resource. It is unambiguous and easily understood, though it does not explicitly contrast itself with related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the description: call this when you need the items from a specific checklist. However, there is no explicit guidance on when to use this versus alternatives like list_checklists, nor any exclusion statements.
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 clearly indicates a read-only list operation, but it does not mention ordering, pagination, depth of comment data, or any API-specific behavior, so an agent has limited insight into what the call returns or how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to defining the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with fully documented schema, the description is minimally viable. However, with no output schema and no annotations, it leaves the return shape, ordering, and pagination behavior unspecified, so it is not fully complete on its own.
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 are already fully documented in the input schema. The description adds no extra meaning beyond what is present, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('list') and resource ('comments on a card'), making the operation unambiguous. It is easily distinguished from sibling mutation tools like kaiten_create_comment, kaiten_update_comment, and kaiten_delete_comment.
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 wording implies the appropriate context—retrieving comments for a card—but it does not explicitly state when to prefer this over alternatives such as kaiten_get_card_activity or how it differs from other list tools. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only restates the action. It does not mention pagination, return shape, required permissions, or any other behavioral detail beyond the fact that it lists users.
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 the core action and resource, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the input parameters, so an agent can invoke the tool correctly. However, with no output schema and no annotations, the description does not clarify the response format or list behavior, leaving minor but real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains group_uid and compact clearly. The tool description adds no additional parameter meaning 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 uses a specific verb ('List') and a specific resource ('users in a company group'), matching the tool name exactly. It also distinguishes this tool from siblings like kaiten_list_users and kaiten_list_space_users by scoping to company groups.
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 scope 'in a company group' implies the intended use case and helps separate this tool from broader user-listing tools. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions or prerequisites.
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 disclosure burden. 'List all' indicates a read-only operation with broad scope, which is helpful, but it does not disclose pagination behavior, ordering, return format, or potential size limitations. It provides some behavioral context but leaves meaningful 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 with no filler and the key fact is front-loaded: 'List all subcolumns of a Kaiten column.' Every word contributes to meaning, making it an appropriately concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool, the description is minimally sufficient but leaves gaps. There is no output schema, so return fields are not described, and pagination or large-result behavior is not mentioned. However, the operation is simple and the required parameter is fully documented, so the definition is adequate but not exceptional.
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%: column_id is documented as 'Column ID'. The description does not add meaning beyond that, such as how to find a valid column_id or whether the column must belong to a specific board or space. Baseline 3 is appropriate because the schema already fully documents the only 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 uses the specific verb 'List' and the resource 'subcolumns of a Kaiten column,' making the operation unambiguous. It clearly distinguishes this tool from siblings like kaiten_list_columns, kaiten_create_subcolumn, and kaiten_update_subcolumn by focusing on the subcolumn list 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 when-to-use guidance is provided. The description does not mention alternatives or conditions that would make this tool preferable, such as distinguishing it from kaiten_list_columns or noting that a column_id must first be known. Usage must be inferred entirely from the tool's name and minimal description.
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 behavioral burden. It discloses that the operation is a list operation and supports pagination, which implies a non-mutating read. However, it does not describe response format, ordering, potential filtering limitations, or any scoping details beyond 'company'.
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 with no filler. The core purpose is front-loaded, and the pagination note adds value without repetition. 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 list tool with two optional pagination parameters, the purpose and pagination support are adequate. However, there is no output schema and no guidance on alternatives, default limits, result ordering, or whether any other constraints apply. An agent can call it, but may not fully understand what to expect in the response.
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 already fully describes both parameters: limit as 'Maximum number of results' and offset as 'Offset for pagination', giving 100% schema coverage. The description only adds 'Supports pagination', which reinforces but does not add meaning beyond the schema. 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 uses a specific verb ('List'), a concrete resource ('company workflows'), and a scope qualifier ('company'). This clearly distinguishes it from get_workflow, create_workflow, update_workflow, and delete_workflow among the siblings.
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. The verb 'List' implies enumeration, but the description does not mention that it should be used to enumerate workflows while get_workflow retrieves a single one, nor does it state any exclusions or preferred conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does reveal two important behavioral traits: the operation is asynchronous and returns a job_id to track progress. However, it does not disclose side effects on existing measurements, whether the operation mutates data, prerequisites (e.g., the SLA being attached to cards), or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the action and its async nature are front-loaded, and the job_id return contract follows immediately. Every word contributes 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?
Adequate for a one-parameter tool — it states the action and the return contract — but it does not point to kaiten_get_compute_job as the mechanism for tracking the returned job_id, and the SLA-type ambiguity remains unresolved. Given no output schema and no annotations, a bit more context would close the loop.
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% — sla_id is already documented as an SLA ID UUID — so the baseline of 3 applies. The description adds no parameter-level meaning and, notably, does not resolve which SLA concept sla_id refers to, given the API distinguishes sla_rule, card_sla, and sd_sla entities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('trigger'), a specific resource ('recalculation of SLA measurements'), and an async execution mode in a single sentence. 'Recalculate' is a unique operation among the sibling set, clearly separating it from the read-only getters kaiten_get_card_sla_measurements/kaiten_get_space_sla_measurements and from attach/detach operations like kaiten_attach_card_sla.
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 about when to invoke recalculation — e.g., after SLA rule changes or when measurements are stale — nor when a read-only sibling like kaiten_get_card_sla_measurements would be the right choice. There are no exclusions, alternatives, or situational 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 of behavioral disclosure. It only states the mutation action itself and gives no information about required permissions, idempotency, behavior when the user is not already a member, irreversibility, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 content. Every word earns its place and the core action is stated immediately.
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 two-parameter mutation, the description plus fully documented schema is adequate for basic invocation. However, with no annotations and no output schema, it leaves unanswered behavioral questions such as error conditions, permission requirements, and whether the removal is reversible.
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 clear, complete descriptions for both required parameters with 100% coverage. The description adds no additional parameter semantics beyond what the schema provides, 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 uses a specific verb ('Remove'), a specific resource ('member from a card'), and clearly distinguishes this from sibling operations like kaiten_add_card_member and kaiten_list_card_members. Even without extra context, an agent can identify exactly 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?
Usage is implied rather than explicit: an agent can infer to use this when the goal is removing a member from a card. However, the description does not state when not to use it, mention prerequisites, or highlight alternatives such as using kaiten_add_card_member for the inverse operation.
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 behavioral disclosure burden. It does convey that the action is scoped to the card-tag relationship, but it omits important details such as whether the operation is idempotent, what happens if the tag is not currently attached, and whether special permissions are required.
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 filler or redundant phrasing. It immediately states the core operation and earns its place without unnecessary elaboration.
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 two-parameter tool with fully documented inputs, the description is adequate for invoking the tool correctly. However, with no annotations and no output schema, it could be more complete by noting behavioral outcomes, such as that the tag itself is not deleted and only the card-tag association is removed.
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 100% coverage with descriptions for both card_id and tag_id, so the baseline of 3 applies. The description adds no additional parameter semantics beyond what is already expressed in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove'), a specific object ('a tag'), and a scope ('from a Kaiten card'). This clearly differentiates it from similar siblings like kaiten_add_card_tag, which adds a tag, and kaiten_delete_tag, which likely deletes the tag itself rather than a card-tag association.
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 when to use the tool: when the goal is to remove a tag association from a card. However, it does not explicitly mention alternatives or exclusion conditions, leaving the agent to infer the right choice from sibling tool names rather than from direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only says 'Add a user to a company group' and provides no details on idempotency, duplicate handling, required permissions, or response behavior. For a mutation operation this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple tool, though it is brief enough that some behavioral context is absent.
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 two-parameter mutation with no annotations, the description and fully covered schema give a minimally sufficient picture of what to call and with which parameters. It lacks edge-case behavior and response semantics, so it is not fully 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% for both parameters, so the schema already explains user_id and group_uid. The description adds no extra parameter context, which matches the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and a precise resource ('a user to a company group'), clearly distinguishing this tool from sibling operations like kaiten_add_space_user or kaiten_add_card_member. It states exactly 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: add a user to a company group. It does not explicitly mention alternatives or exclusions, but the company-group target provides enough context to route an agent to this tool rather than the space/card membership add operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does add meaningful context by stating that the operation registers an external link rather than uploading binary data, and it enumerates supported file types. However, it does not disclose other relevant behaviors such as required permissions, side effects, response format, or failure cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded: the first sentence clearly states the operation, and the second adds a crucial behavioral distinction. The file type enumeration is somewhat redundant with the schema, which prevents a perfect score, but the overall structure wastes little space.
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 fully-covered schema, provides enough to understand the core operation and parameters. However, there is no output schema and no description of return values, prerequisites, or post-condition behavior, so the agent is left without a complete picture 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 description coverage is 100%, so the schema already documents all eight parameters. The description mostly repeats the file type enum that is already present in the schema, and it does not add new semantic detail for card_id, url, name, size, card_cover, sort_order, or custom_property_id. 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 opens with a specific verb and resource: 'Create a file attachment on a card by URL.' It clarifies the exact scope by noting that this 'registers an external file link as a card attachment' and explicitly distinguishes itself from binary upload operations. This makes the tool's purpose immediately clear even among many card-related siblings.
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 when to use this tool: when attaching an external file link by URL rather than uploading binary data. However, it does not name any alternative tools or provide explicit when-not-to-use guidance, so an agent must infer the selection context from the phrase 'does not upload binary data.'
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 behavioral burden. It usefully discloses that text content is auto-converted and data content is raw ProseMirror JSON. It does not disclose success/error behavior, whether text and data are mutually exclusive, or any permission requirements, leaving notable gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences state the operation and the key content-format decision without filler. Every sentence 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?
The rich input schema covers parameter details, but without annotations or an output schema the description leaves important context unstated: what a successful create returns, how the API behaves on invalid input, and whether text and data can be combined. Adequate for a straightforward create call, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, putting the baseline at 3. The description adds value by framing text and data as alternative content paths ('use text ... or data ...'), clarifying the relationship between the two main parameters beyond what each individual schema description 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 action (Create) and the resource (a new Kaiten document), so an agent can identify the operation. It does not explicitly distinguish this from sibling document tools like kaiten_update_document or kaiten_create_document_group, but the verb and resource make 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 offers useful input-format guidance ('text' for markdown vs 'data' for raw ProseMirror JSON), which helps with parameter selection. It does not, however, say when to choose this tool over alternatives, nor does it mention prerequisites such as needing a parent_entity_uid; the creation use case is implied rather than explicitly contrasted with other 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 present, so the description carries the full burden of behavioral disclosure. It only states the deletion action without disclosing permanent side effects, failure conditions, permission requirements, or consequences. The word 'delete' implies destructiveness, but no additional behavioral 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 short sentence with no fluff, filler, or repetition. It is front-loaded with the action and resource, and every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool with fully documented parameters, the description is mostly sufficient. It clearly states what is deleted and from where, but a note about permanence or how to obtain the link_id (e.g., via kaiten_list_external_links) would make it fully complete. The absence of an output schema is not a gap here.
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 already provides full descriptions for both parameters ('Card ID' and 'External link ID'), and the description adds no additional parameter-level meaning. Since schema_description_coverage is 100%, the baseline of 3 applies and the description neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), a specific resource ('external link'), and a location ('from a Kaiten card'). This clearly distinguishes the tool from sibling tools like kaiten_create_external_link, kaiten_update_external_link, and other deletion tools such as kaiten_delete_card.
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 intended use is implied by the verb and resource, but the description does not explicitly state when to use this tool or mention alternatives such as kaiten_list_external_links for finding the link_id. No when-not-to-use guidance or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently identifies this as a destructive operation targeting a specific resource, which is the core behavioral trait. However, with no annotations provided, it does not mention whether the deletion is permanent, requires special permissions, or has side effects, leaving some behavioral 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 with no filler, and the operation and resource are front-loaded. This is appropriate for a tool with one simple parameter.
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 one-parameter delete operation, the description plus schema is largely sufficient for an agent to invoke the tool correctly. It would be slightly stronger if it noted irreversibility or authorization requirements, but these are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the single parameter, already identifying it as a template_answer_id UUID. The description adds no additional parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Delete') and the exact resource ('Service Desk template answer'). This matches the tool name and distinguishes it from the many sibling operations on the same resource, such as create, update, get, and 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?
The description gives no guidance about when to use this tool versus alternatives like update, get, or create. The only signal is the verb 'Delete', which is implicit usage information rather than explicit when-to-use or when-not-to-use 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?
With no annotations provided, the description carries the full behavioral disclosure burden. It usefully warns that company tag management permission is required and that deletion may be blocked during an async operation, which goes beyond the obvious 'delete' semantics. It does not mention permanence or side effects, but it covers the most important operational caveats.
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 with no filler. The primary purpose is front-loaded, and the critical requirements and caveats follow immediately.
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 single-parameter delete operation with no output schema, the description covers the key behavioral concerns: permission and potential async blocking. However, it misses a brief pointer to disambiguate from kaiten_remove_card_tag, which would make it more complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the only parameter, tag_id, as 'Tag ID'. The description adds no additional meaning about the parameter, which is acceptable given the thorough 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 states a clear action and resource: 'Delete a Kaiten tag.' It is unambiguous about what the tool does, but it does not explicitly distinguish itself from related sibling tools like kaiten_create_tag, kaiten_update_tag, or especially kaiten_remove_card_tag, which could be confused with deleting a tag.
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 explicit guidance on when to use this tool versus alternatives. It mentions permission and an async blocking condition, but it does not clarify that this deletes the tag itself rather than removing a tag from a card, which is the role of kaiten_remove_card_tag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does disclose a key behavioral trait: DELETE may return 405 and removal may not be supported via the API. However, it does not mention permissions, idempotency, or success/error response behavior beyond the HTTP status warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The primary action is front-loaded, and the important caveat immediately follows, making the most critical behavioral information easy to notice.
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 delete operation, the description includes the critical unsupported-API caveat and clarifies the resource type as external. It omits return/output details, but no output schema exists and the action is straightforward; a brief note about expected success behavior would make it fully 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 schema already documents both parameters. The description adds the 'external webhook' resource qualifier, but does not provide additional meaning about the space_id or webhook_id values 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 states a specific verb and resource: 'Delete an external webhook from a Kaiten space.' The qualifier 'external' distinguishes it from sibling tools like kaiten_delete_incoming_webhook, and the caveat about API support does not obscure the core 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 such as kaiten_delete_incoming_webhook or kaiten_list_webhooks. The only context is a limitation note, not an explicit when/when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does state the key behavioral outcome — the returned board includes columns and lanes — but it does not mention permissions, error behavior for invalid board IDs, or whether this is a pure read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise, front-loaded sentences with no filler. The first sentence states the core operation, and the second adds useful return-shape detail.
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 one-parameter get operation with no output schema, the description is largely complete: it identifies the resource, the required identifier, and the principal content of the response. It could be enriched with failure/permission notes, but for the tool's low complexity, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage: board_id is described as 'Board ID'. The description adds no additional 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 states a specific action ('Get'), a specific resource ('Kaiten board'), and the lookup mechanism ('by ID'). It also adds meaningful return context ('Returns board with columns and lanes'), which clearly distinguishes it from list_boards and other board-related 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 about when to use this tool versus alternatives such as kaiten_list_boards, kaiten_get_space, or kaiten_get_card. It does not mention how the board_id should be obtained, nor any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'Get' indicates a read-only operation, but the description does not disclose response format, not-found behavior, or any side effects. For such a simple getter this is minimally adequate, but it leaves some behavioral context unspecified.
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 filler. The key qualifier 'by ID' is present and the sentence is appropriately sized for a one-parameter 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?
For a simple one-parameter tool with no output schema, the description conveys the essential call semantics: retrieve a custom property using its ID. It does not cover error cases or return structure, but these are relatively minor gaps 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: property_id is already documented as an integer 'Property ID'. The description adds no further semantic meaning to the parameter, 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 names a specific verb ('Get'), a specific resource ('custom property'), and a lookup method ('by ID'), clearly distinguishing it from sibling tools like kaiten_list_custom_properties, kaiten_create_custom_property, and kaiten_delete_custom_property. The 'by ID' qualifier also signals this is a single-resource fetch rather than a list 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?
There is no guidance about when to prefer this tool over alternatives. An agent must infer that it should be used when a known property_id exists, rather than using kaiten_list_custom_properties to discover properties, but the description does not state this.
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 full behavioral burden. It only states the operation ('Get') and gives no additional behavioral context such as read-only guarantees, authentication requirements, error behavior, or what is returned. This is a minimal disclosure with no value 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 short sentence that states the action, resource, and lookup key with no wasted words. For a one-parameter retrieval tool, this is appropriately sized and immediately scannable.
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 very simple one-parameter retrieval operation, the description is nearly complete. Since there is no output schema, a note on the return format would add value, but 'Get X by ID' is generally sufficient guidance for an agent to invoke this 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?
Schema description coverage is 100%, so the input schema already fully documents the only parameter. The description adds no extra semantic detail beyond 'by ID', which is appropriate as a baseline but not an enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the exact resource ('Service Desk template answer'), and adds the key qualifier ('by ID'). This clearly distinguishes it from sibling tools like kaiten_list_sd_template_answers, kaiten_create_sd_template_answer, and kaiten_delete_sd_template_answer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: retrieve a single template answer when you already have its ID. However, it does not explicitly state when to prefer this over listing template answers or how to obtain the ID if missing, leaving usage guidance largely implicit.
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 restates the get-by-ID operation and gives no detail about side effects, authentication requirements, error behavior, or whether the timer is returned directly or wrapped. Although 'Get' implies a read-only action, the description adds little 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, front-loaded sentence with no filler. Every word carries meaning, and it is appropriately sized for the tool's simplicity.
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 one-parameter get-by-ID tool, the description plus fully documented schema is nearly sufficient. It does not describe the return payload, but the absence of an output schema and the straightforward nature of the operation make this a minor gap rather than a blocking one.
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 describes timer_id as an integer 'Timer ID' with 100% coverage. The description's 'by ID' simply repeats that semantic without adding format, scope, or relationship details, so it does not exceed the baseline set by fully covered schema documentation.
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 user timer by ID' states a clear verb, resource, and selection method. It distinguishes itself from sibling CRUD tools like kaiten_list_user_timers, kaiten_create_user_timer, and kaiten_update_user_timer by emphasizing retrieval of a single item by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you already have a timer_id and need one specific timer. However, it does not explicitly mention alternatives such as kaiten_list_user_timers for enumeration or kaiten_get_current_user for current-user context, so the guidance is only implied.
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. 'List' implies a read-only operation, but no additional behavior is disclosed—such as return format, pagination, or whether heavy fields are included by default. It is not misleading, but it provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, front-loaded sentence with no redundant words or filler. It communicates the essential purpose immediately.
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 2-param list operation with full schema coverage. The descrition is adequate to guide invocation, though the lack of an output schema and absence of any note about pagination or permissions leave minor gaps. Overall itis complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: card_id is described as 'ID of the card' and compact is described as 'Return compact response without heavy fields (avatars, etc.).' The description adds no extra 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 states a specific verb ('List') and resource ('members assigned to a card'), which clearly identifies the operation. It is easily distinguishable from sibling tools like kaiten_add_card_member and kaiten_remove_card_member that perform mutations.
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 such as kaiten_list_card_subscribers or kaiten_list_users. There are no stated exclusions or conditions directing selection among the many list-type 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, the description carries the burden of behavioral disclosure. It does disclose a meaningful failure mode ('may return 405; subscriber listing may not be available'), but it does not mention response shape, pagination, permissions, or other potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action is front-loaded, and the important caveat is appended concisely.
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 list operation with only two parameters and no output schema. The description states the purpose and an important edge case (405). It could mention return value details, but for this level of complexity the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents column_id and compact. The description adds no extra meaning about how these parameters affect the call, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('subscribers of a Kaiten column'), and the scope ('all'). This clearly distinguishes it from sibling tools like kaiten_list_card_subscribers by naming the column resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as kaiten_list_card_subscribers or the add/remove column subscriber tools. It gives a caveat about 405 responses but no selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It adds a useful non-obvious caveat: the API may return empty for company-level tags, which helps manage expectations. It does not mention response format, pagination defaults, or auth, but the read-only intent is clear from the verb 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the purpose and the second adds a meaningful scope caveat, though the caveat's wording is slightly vague and could have been clarified further.
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 tool with fully documented parameters, the description covers the main quirk but omits default list behavior, possible ways to handle company-level tags, and the response shape. These gaps are moderate, so the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds only general card-scoped context, which is not parameter-specific. Per the rubric, this is a baseline 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation and resource: 'List Kaiten tags.' This distinguishes it from sibling tag mutations like create_tag, update_tag, and delete_tag, but it does not add detail about the returned data or whether it lists all tags or only card-scoped tags.
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 gives relevant context but no explicit when-to-use guidance. The note that 'tags are primarily card-scoped' implies this tool is appropriate for card-scoped tag lookups, but it does not name alternatives or state exclusions for when another tool should be used.
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 behavioral disclosure burden. It conveys a read-style operation and says what data is returned, but it does not explicitly confirm read-only behavior, describe output format, or mention pagination or aggregation behavior. The description adds some behavioral context but not full 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 two short sentences with no filler. The primary action and the output are stated immediately, making it easy for an agent to process quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with schema-complete parameters, the description gives enough high-level information to attempt invocation. However, without an output schema or annotations, it omits useful context such as output shape details, whether the data is paginated, and how this chart relates to other chart endpoints in the sibling list.
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 already documented in the input schema. The description does not add further semantic detail about space_id or category_ids, matching the baseline of 3 for schemas that already cover parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb and resource: 'Get blocker resolution time data for a space' and specifies the output ('resolved blockers with their resolution durations'). This distinguishes it from card blocker CRUD tools and other chart metrics well.
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 gives clear context that this tool operates 'for a space' and returns blocker resolution durations, so an agent can infer when it is relevant. However, it does not explicitly state when to prefer this tool over other similar chart tools, nor does it mention any alternatives or exclusions.
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 behavioral burden. It discloses that the operation is asynchronous, returns a compute_job_id, and requires polling with another tool. It also clarifies the measurement window (start to end column). It does not mention permissions or failure/cancellation behavior, but the key behavioral trait is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, all useful. The main action is front-loaded, the metric definition is next, and the asynchronous polling note is concise. No redundant or filler content.
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 adequately explains the core purpose and the async workflow, and the schema covers all parameters. However, with 9 parameters, no output schema, and a large family of sibling chart tools, it would benefit from explaining what the computed chart contains and when this chart is the right choice. It is sufficient 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?
Schema description coverage is 100%, so the baseline is 3. The description adds some semantic context for start_column and end_column by framing them as the cycle time boundary, but it does not meaningfully explain tags, card_types, group_by, or only_asap_cards beyond the schema. It neither hurts nor substantially enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Build a Cycle Time Chart for a space') and defines the core metric ('Measures time from start to end column'). This is more than a tautology. However, it does not explicitly distinguish itself from sibling chart tools like kaiten_chart_lead_time, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when a cycle time chart for a space is needed, this tool builds it. It also gives important follow-up guidance by naming kaiten_get_compute_job for polling. But it does not explicitly state when to prefer this tool over the many sibling chart tools or mention any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It adds one useful constraint (color 1 is reserved for the default type), but does not state side effects, required permissions, idempotency, or what is returned on success. 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?
Two short sentences with no filler. The purpose is front-loaded, and the extra color constraint is stated concisely without repeating all schema details.
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 definition is adequate for a simple create call since all parameters and required fields are documented in the schema. However, there is no output schema and the description does not mention return values, uniqueness requirements, or preconditions, leaving some ambiguity about the result of a successful call.
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 description coverage is 100%, so the baseline is 3. The description adds non-obvious parameter meaning by noting color must be 2-25 and that 1 is reserved for the default type, which goes beyond the schema's simple 'Color (2-25)'.
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 first sentence uses a specific verb ('Create') and resource ('Kaiten card type'), which immediately distinguishes it from siblings like kaiten_update_card_type and kaiten_delete_card_type. The 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given, but the create verb implies it should be used when a new card type is needed. It does not name alternatives or conditions, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose one important behavioral trait—soft deletion via a deleted flag—which prevents assuming permanent removal. However, it omits side effects, reversibility, permissions, and return behavior, which are relevant 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?
A single 9-word sentence that front-loads the action and the key qualifier ('soft'). There is no filler; every word contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete, the description plus the fully covered schema is adequate for basic invocation. However, with no output schema and no annotation context, the agent is left without post-invocation expectations or knowledge of consequences for existing data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning beyond the schema's 'Select value ID' and 'Property ID', and it does not explicitly state that value_id must belong to the given property_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Delete (soft)'), a specific resource ('a select value'), and the mechanism ('marking it as deleted'). This distinguishes it from hard-delete operations and from sibling tools like kaiten_delete_custom_property or kaiten_delete_card.
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 intended use is implied by the verb and resource, but there is no explicit when-to-use, when-not-to-use, prerequisites, or alternatives. It does not clarify whether this should be preferred over update_select_value for hiding a value, nor what happens if the value is in use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It communicates that the operation is a read ('Get') and specifies the scope of the history ('column/lane moves'), but it does not disclose response format, ordering, time range, or whether other card changes are excluded.
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 value by naming the resource, the history concept, and the specific domain of column/lane moves.
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 one-parameter getter, the description is adequate for basic invocation, but with no output schema and no usage guidance it leaves gaps. An agent cannot tell how the response is structured or when to prefer this tool over kaiten_get_card_activity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the card_id parameter is already described as 'Card ID'. The description only adds minimal context that the card is a Kaiten card, which does not meaningfully enhance the schema's parameter documentation.
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 and resource: 'Get location history of a Kaiten card' with an explicit parenthetical clarifying 'column/lane moves'. This clearly distinguishes it from related siblings like kaiten_get_card_activity and kaiten_get_card.
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 usage is implied rather than stated explicitly. The description tells what the tool does but does not say when to choose it over alternatives such as kaiten_get_card_activity, nor does it mention any exclusions or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The verb 'Get' indicates a read-only operation, but the description does not clarify whether measurements are computed on demand, what the response includes, or whether there are side effects. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 detail. It communicates the operation, resource, and scope in the fewest possible 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?
For a simple one-parameter read tool, the description is sufficient for invoking the call correctly. However, there is no output schema and no explanation of what the returned measurements contain, so the description leaves some context to be inferred by the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the only parameter, card_id, as 'Card ID'. The description adds no additional parameter meaning, so the baseline of 3 applies due to 100% 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 uses the specific verb 'Get' with the resource 'SLA rule measurements' and scopes it 'for a card'. This distinguishes it from sibling tools like kaiten_get_space_sla_measurements without requiring schema inspection.
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 phrase 'for a card' implies the intended use case, but the description does not explicitly mention alternatives or when to prefer them. There is no clear guidance about when to use this tool versus space-level or SD-level SLA tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Get' communicates a read-only operation, which is useful, but it does not disclose the return shape, error behavior, or any permissions needed. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no wasted words. The key qualifier 'by UID' is front-loaded, and every word contributes to identifying the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with full schema coverage, this is close to minimally acceptable. However, with no output schema or annotations, the description does not explain what the returned document group object looks like or how errors are handled, leaving some context for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single required parameter, group_uid, which is already documented as 'Document group UID'. The description's 'by UID' phrase adds no additional format or semantic detail beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact verb-resource pair: 'Get a Kaiten document group'. The 'by UID' qualifier makes clear this fetches a single specific group, distinguishing it from kaiten_list_document_groups and kaiten_get_document without any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by UID' phrasing implies the tool is for retrieving one known group rather than listing groups, but the description does not explicitly state when to use it versus kaiten_list_document_groups or kaiten_get_document, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' conveys a read operation and implies no mutation, but the description does not disclose response scope, permission requirements, or whether the result is minimal by default. It provides core behavior but little extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying what the tool does.
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 getter with two parameters, the description plus schema is broadly sufficient, but there is no output schema and no annotations. The description does not explain what fields the returned project contains or the default behavior of with_cards_data, leaving some ambiguity about the response.
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 project_id and with_cards_data both described. The tool description itself adds no parameter detail 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 uses the specific verb 'Get' with the clear resource 'Kaiten project' and the identifying mechanism 'by ID.' This cleanly distinguishes the tool from sibling listing operations like kaiten_list_projects and other getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a single project when its ID is known, but it does not explicitly say when to prefer this over kaiten_list_projects or kaiten_update_project. There is no exclusion or alternative guidance beyond the 'by ID' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Get' clearly signals a non-mutating lookup, but it does not disclose response format, error behavior, or access requirements. This is adequate for a simple read but not rich.
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 zero wasted words. Every part adds meaning: the verb, resource, and retrieval method.
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 trivial get-by-ID operation with a fully documented schema, this is minimally viable. The lack of annotations, output schema, and any mention of alternatives leaves minor gaps in an agent's ability to decide when 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 schema already fully documents role_id as a UUID string with 100% coverage. The description adds no new parameter semantics beyond rephrasing 'by ID', 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 states a specific verb ('Get'), a concrete resource ('role'), and the retrieval key ('by ID'). It clearly distinguishes this from sibling tools like kaiten_list_roles and other get_* operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by ID' qualifier implies the tool is for fetching a single role when a role_id is already known, which provides some usage context. However, it does not explicitly mention when to prefer this over kaiten_list_roles or any 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 provided, the description carries the behavioral burden. 'Get' conveys a read-only retrieval operation, but the description does not disclose response shape, not-found behavior, or permission requirements, leaving meaningful 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 precise sentence with no filler. The verb and resource are front-loaded, and 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?
For a simple one-parameter getter, the description is minimally sufficient for invoking the tool when an ID is known. However, there is no output schema and no description of return values or error behavior, so an agent gets no confirmation of what the response will look like.
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 schema already defines filter_id as an integer Filter ID. The description only repeats 'by ID' and adds no new meaning beyond the parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (get), names the exact resource (saved filter), and scopes the operation by ID. This distinguishes it from the sibling list/create/update/delete saved-filter tools without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the tool should be used when the caller already knows a specific filter_id and needs that single filter. However, there is no explicit guidance about when to use kaiten_list_saved_filters instead, nor any stated exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' clearly signals a read-only operation, but the description does not disclose response shape, error behavior, permissions, or whether nested resources are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler or redundancy. It says exactly what the tool does and is immediately 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?
For a one-parameter getter, the definition is nearly adequate, and the schema fully covers the input. However, with no output schema and no annotation, the description stops short of stating what the response contains or how failures are surfaced.
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 single parameter is already documented as 'Space ID'. The description adds only the word 'by ID', which confirms the parameter's role but does not provide meaningful semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('Kaiten space'), and the lookup method ('by ID'). This immediately distinguishes it from listing, creating, updating, or deleting spaces, and from activity-based sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' implies the tool is for retrieving a single known space, which is enough for basic routing. However, it never explicitly names alternatives like kaiten_list_spaces or kaiten_get_space_activity, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 restates the listing action and adds no details about return format, pagination, authentication needs, or whether sensitive key values are included.
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 puts the verb and resource first, with no redundant wording. It earns its place efficiently for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation, the description conveys the essential purpose. However, with no output schema and no annotation coverage, it leaves unspecified what fields each API key contains and whether the result is paginated or includes secret values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is reported as 100%, so the baseline of 4 applies. The phrase 'all API keys' reinforces that no filtering or arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('API keys'), and the scope ('for the current user'), making the operation unambiguous. It distinguishes itself from sibling tools like kaiten_create_api_key and kaiten_delete_api_key by the action while sharing the same resource.
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 scope 'for the current user' implies when this tool is relevant, but there is no explicit guidance about when to use it versus alternatives or any exclusions. For a simple list operation this is acceptable, but the description leaves all usage routing to inference.
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 states that boards are listed, but it does not mention read-only behavior, pagination, the shape of the returned collection, or any other runtime characteristics. The word 'List' implies a read operation, but the description does not actively disclose these traits.
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 that directly states the resource and scope. There is no verbose or repetitive content; every word contributes to understanding the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but there is no output schema and no annotation support. The description plus the schema is enough to perform the basic call, but an agent lacks information about the response structure, pagination, and whether the returned boards include full or compact fields by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains space_id and compact. The description adds little beyond reinforcing that the boards must be scoped to a space. This meets the baseline for a schema that fully documents its parameters without adding extra parameter nuance.
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'), a concrete resource ('boards'), and a clear scope ('in a Kaiten space'). It naturally distinguishes itself from siblings like kaiten_get_board, kaiten_create_board, and kaiten_update_board by indicating a plural collection read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when you need to enumerate boards within a given space, with the required space_id serving as the scope identifier. It does not explicitly exclude situations where a single board should be retrieved via kaiten_get_board, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses a potential 405 error and that the feature may be unavailable, which is useful behavioral context. However, it does not mention anything about response format, heavy fields, or other potential failure modes.
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 plus a brief note. It is front-loaded with the core purpose and includes a necessary caveat without any wasteful elaboration.
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 tool with complete parameter documentation, the description covers the purpose and a key failure mode. However, it lacks details about the response structure (e.g., user objects, avatars) or pagination, which the compact parameter implies could vary. Without an output schema, these gaps leave some uncertainty 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 coverage is 100%: both card_id and compact are described in the input schema. The description adds no additional parameter information beyond what the schema already provides, 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 the action ('List') and the resource ('subscribers of a Kaiten card'), with a synonym ('watchers') for disambiguation. It is distinct from sibling add/remove subscriber tools and other list tools, making its 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 implicitly indicates this is the read-only listing counterpart to the add/remove subscriber tools, but it does not explicitly state when to use this versus alternatives or exclude scenarios. No guidance on pagination or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates the destructive nature of the operation ('Remove') and the exact effect: unlinking two cards as predecessor and successor. It does not disclose potential irreversibility, permissions, or what happens if the relation does not exist, but for a simple link removal 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 compact and front-loaded: the primary action and object appear first, followed by the one clarifying detail that matters most for correct invocation. Every sentence adds value and there is no redundant filler.
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 gives enough information to identify the tool and parameters correctly, but it omits details about return behavior, error cases, and any side effects. Given this is a mutating operation with no annotations or output schema, slightly more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds a useful restatement of the directional relationship (card_id = predecessor, target_card_id = successor), but it does not provide significantly new information beyond the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove a planned relation') and identifies the exact resource and the roles of both card IDs. It clearly distinguishes this from related operations like add or update planned relation by focusing on removal.
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 when to use the tool: when a planned predecessor/successor link should be removed. However, it does not explicitly mention alternatives or conditions for when not to use it, such as preferring update_planned_relation when the relation should be modified rather than removed.
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 disclosing behavior. It mostly restates schema facts: condition=2 is already documented as archived, and column_id/board_id are already described as 'Move to column/board.' It does not disclose whether updates are partial or full replacements, whether null clears fields, what permissions are needed, 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 two short sentences with no filler. The core operation is front-loaded, and the second sentence efficiently highlights the two most non-obvious use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema fully documents all parameters, which compensates for much of the missing parameter context. But with no annotations and no output schema, the description leaves important behavioral context implicit, such as update semantics, required permissions, and return value expectations. For a 27-parameter mutation tool, this is a noticeable gap.
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% description coverage across 27 parameters, so the baseline is 3. The description's archive and move hints add no new meaning beyond what the schema already provides for condition, column_id, and board_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update a Kaiten card.' This clearly distinguishes it from card creation, deletion, retrieval, and listing operations, and the added hints about archiving and moving further clarify its scope among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides actionable guidance for common sub-operations: 'Use condition=2 to archive, set column_id/board_id to move.' This gives clear context for when to use these parameters. However, it does not explicitly mention alternatives like kaiten_archive_card or kaiten_move_card or state when those dedicated tools should be preferred.
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 burden of behavioral disclosure. It does reveal important behavior: text content is auto-converted to ProseMirror, raw JSON is accepted, and text takes precedence if both are supplied. However, it does not describe side effects like whether unspecified fields are left unchanged, whether this is a partial or full update, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core action is front-loaded, and the key content-format guidance is delivered immediately. The precedence rule is stated in a compact, direct way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief but supplemented by a rich input schema that documents all parameters, including the required document_uid and conversion caveats. The main omission is the absence of explicit update semantics (e.g., partial vs full replacement) and return-value expectations, but the schema and name cover most practical needs.
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 adds meaningful value beyond the schema by explicitly stating the precedence rule ('If both provided, 'text' wins'), which is not present in any parameter description. This is an important semantic for agents to choose between text and data correctly.
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 action ('Update a Kaiten document') and identifies the resource type. It does not explicitly differentiate from sibling tools like create or get, but the verb 'Update' combined with the resource makes 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 provides guidance on choosing between the 'text' and 'data' parameters, which is useful internal usage guidance. However, it does not explicitly state when to use this tool versus alternatives (e.g., create_document for new documents, or get_document for reading), leaving the usage context to be inferred from the tool name.
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 disclosure burden. It usefully reveals the non-obvious behavior that the endpoint may return 405 and that update functionality may be limited to the portal. However, it does not disclose side effects, required permissions, partial-update semantics, or what a successful response looks like.
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 with no filler. The core action is front-loaded, and the critical 405/portal caveat is placed immediately after without repeating schema details.
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 four-parameter update with no output schema and no annotations, the description is mostly adequate and the 405 caveat adds real value. Still, it does not specify under what conditions the 405 occurs, does not describe the success response, and does not mention authentication or authorization needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents title, priority, request_id, and description. The description adds no parameter-specific meaning beyond the schema, so it meets the baseline but does not exceed it.
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 ('Update') and a specific resource ('Service Desk request'), so the action is unambiguous. It clearly distinguishes this tool from sibling update tools like kaiten_update_sd_user or kaiten_update_sd_service, and from the get/create/delete SD request tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that updates may return 405 and may only be available via the Service Desk portal, which provides an important constraint. However, it does not explicitly say when to use this tool versus alternatives or state clear when-to-use/when-not-to-use conditions; the portal hint is implied rather than directive.
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 a non-obvious side effect (it creates the tag if missing), which is valuable for a write operation. However, it doesn't clarify idempotency (what happens if the tag is already on the card) or whether tags are scoped per board/space.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero waste. The primary action is frond-loaded, followed by the side effect. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with full schema coverage and no output schema, the description adequately covers the action and its key side effect. The only gap is behavior when the tag already exists on the card, but this is minor given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The phrase 'by name' adds minor meaning by indicating the tag is idenified by name rather than a tag ID, but both params are already documented in the schema and the description adds no format or value details.
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?
States a specific verb (add), resource (tag), target (Kaiten card), and mechanism (by name). The create-if-not-exist behavior and 'by name' distinguishes it from siblings like kaiten_remove_card_tag (inverse op) and kaiten_create_tag (standalone creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative routing. The create-if-not-exist behavior impliedly signals it's the right choice when you don't want to pre-create a tag, but the description never mentions siblings like kaiten_remove_card_tag or kaiten_create_tag. Usage is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does disclose the most critical trait: the operation is asynchronous and returns a compute_job_id requiring polling via kaiten_get_compute_job. This tells the agent not to expect an immediate CFD result. It does not address mutation/read-only status, but for a chart-building operation the lack of destructive side effects is implied and the async warning is the key missing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: one for purpose and one for the async workflow. It is front-loaded with the key action and ends with the actionable follow-up, with no filler or 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 an asynchronous, 9-parameter tool with no output schema and no annotations, the description covers the essential workflow: it names the input scope ('for a space'), the async behavior, the returned compute_job_id, and the polling tool. It does not explain the final result shape of the CFD, but the lack of an output schema is mitigated by the clear pointer to kaiten_get_compute_job. The duplicate cardTypes/card_types quirk is left to the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; every parameter has a description in the schema. The description itself adds no parameter-level detail, but none is needed because the schema already documents each filter (tags, cardTypes, selectedLanes, etc.), including the alternative field name note for cardTypes. Thus it neither exceeds nor falls below 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 states a specific verb ('Build') and resource ('Cumulative Flow Diagram (CFD) for a space'), making the tool's core function immediately clear. It also notes the asynchronous nature and the returned compute_job_id, which further distinguishes it from the synchronous sibling chart tools. However, it does not explicitly contrast with the many kaiten_chart_* siblings, so differentiation rests on the name and the CFD concept.
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 gives a clear follow-up instruction: 'Use kaiten_get_compute_job to poll for results,' which tells the agent what to do after invoking this tool. It does not, however, provide any guidance on when to choose CFD over the other chart tools (cycle_time, lead_time, etc.) or when not to use it. The context 'for a space' is present but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does this well by stating that the operation is asynchronous and returns a compute_job_id, which is critical for the agent to avoid expecting an immediate chart result. It could also explain poll failure or cancellation, but the core async 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 is three short sentences with no filler. The main purpose is front-loaded, the output behavior is stated next, and the follow-up tool is explicitly named. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 11 parameters and no output schema, the description covers the essential operational context: what it produces, the metric shown, and how to retrieve results asynchronously. The absence of detail about the final chart payload is mitigated by the clear 'cycle time per card' statement and the schema's full parameter coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter. The description adds no parameter-specific meaning beyond the schema, which is acceptable under the baseline. It does not confuse or mislead about any 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 that the tool builds a Control Chart for a specific space and shows cycle time per card. The verb 'Build' plus the resource 'Control Chart' give the agent a concrete idea of what the tool does, though it doesn't explicitly distinguish itself from the similar sibling kaiten_chart_cycle_time.
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 gives an explicit directive to use kaiten_get_compute_job to poll for results, and it warns that the operation is asynchronous. However, it provides no guidance on when to choose this chart tool over the many sibling chart tools, so the agent is left to infer selection based on the chart name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it does so well by explicitly stating this is asynchronous and returns a compute_job_id. It also gives the follow-up action of polling, which is critical for correct invocation. It does not mention authentication or side effects, but for a chart-building operation this is a minor 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 three tight sentences with no filler. The core purpose is front-loaded, and the asynchronous polling instruction is included 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?
Given the tool's complexity, the absence of an output schema, and lack of annotations, the description covers the most essential contextual fact: the operation is asynchronous and must be polled. It does not describe the final result format, but it correctly routes the agent to kaiten_get_compute_job for results, which is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters, including the nested lane mapping examples. The description adds no additional parameter-level meaning beyond the already-documented schema, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a Spectral Chart for a space and shows cycle time distribution, using a specific verb and resource. It does not explicitly differentiate from sibling chart tools like kaiten_chart_cycle_time, but the distinctive chart type name provides enough separation.
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 clearly explains the asynchronous workflow and directs the agent to poll with kaiten_get_compute_job, which is valuable operational guidance. However, it does not state when to choose this tool over sibling chart tools or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It accurately communicates that this is a mutating create operation, but it does not mention permissions, side effects, whether duplicate checklist names are allowed, or what the response contains. The key behavior is stated, but depth is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero filler, and the action is front-loaded. It is minimal but complete at the sentence level.
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 create operation with three flat parameters and no output schema, the definition is largely sufficient. It could name the sibling create_checklist_item to indicate next steps, but that is not necessary for invoking this 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 schema covers 100% of parameters with descriptions for name, card_id, and sort_order. The tool description adds no extra semantic detail beyond the schema, so the 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 ('create') with a clear resource ('checklist') and target ('a Kaiten card'). It distinguishes itself from sibling update/delete/list checklist tools and from checklist item tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a checklist needs to be created on a card, but it does not explicitly mention alternatives or exclusions. There is no guidance about when to prefer create_checklist_item or update_checklist, so usage guidance is only implicit.
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 behavioral disclosure burden. It adds one useful restriction: files on blocked cards cannot be deleted. It does not disclose other behavioral aspects like permanence, permissions, or response behavior, but the destructive nature is self-evident from 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?
The description is two sentences with no filler. The primary action is front-loaded, and the second sentence adds a valuable constraint about blocked cards. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter deletion tool with full schema coverage, the description is nearly complete. It states the operation and an important failure condition. It could mention irreversibility or permission requirements, but the low complexity makes the current level adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are adequately described as 'Card ID.' and 'File ID.' The tool description does not add additional semantic context beyond the schema, 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 clearly identifies the verb ('Delete'), the resource ('a file attachment from a card'), and is specific enough to distinguish from sibling tools like kaiten_delete_document. It precisely describes what operation is performed.
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 when to use the tool — to remove a file attachment from a card — and explicitly warns that files on blocked cards cannot be deleted. However, it does not mention alternatives or explicitly state when to choose this tool over other deletion 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, the description carries the behavioral disclosure burden. It does add useful non-obvious behavior: replace_type_id reassigns existing cards and omitting it causes a 500 error. Still, it does not mention the destructive nature beyond the verb 'delete,' nor does it explain how the optional workflow/automation/restriction replacement flags affect existing configurations.
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 tight sentences with no filler. It front-loads the core purpose and immediately follows with the most important usage warning. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description covers the essential operational details: what is deleted, what happens to existing cards, the required parameter, and the failure mode. The optional replacement flags are well described in the schema, so their absence from the narrative description is acceptable. Minor gaps remain around irreversibility and response behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds a small amount of value by restating the critical role of replace_type_id and noting the 500 failure mode, but it does not meaningfully elaborate on the boolean parameters beyond what the schema already 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 starts with a specific verb and resource: 'Delete a Kaiten card type.' It also explains the key semantic of deletion — existing cards are reassigned to replace_type_id — which clearly distinguishes this destructive operation from sibling tools like kaiten_update_card_type or kaiten_get_card_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage prerequisite: replace_type_id must be provided, otherwise the API returns 500. However, it does not explicitly contrast this tool with alternatives such as kaiten_update_card_type or state when deletion should be preferred over updating. Usage context is implied rather than fully articulated.
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 full burden of behavioral disclosure. It only states the action 'Delete' and gives no indication of irreversibility, permission requirements, error behavior, or impact on related data. This leaves an agent without important context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action, object, and container with no redundant wording. It is appropriately sized for the tool's low complexity.
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 three-parameter delete operation with 100% schema coverage, the description plus schema provides enough information to select and invoke the tool correctly. It lacks explicit behavioral caveats, but the low complexity means these are not severe gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already described (Card ID, Checklist item ID, Checklist ID). The description adds no additional meaning about formats, constraints, or relationships between the parameters, 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 uses a specific verb ('Delete'), a precise object ('an item'), and locates it in a hierarchy ('checklist on a Kaiten card'). This clearly distinguishes it from sibling operations such as kaiten_delete_checklist or kaiten_update_checklist_item. An agent can understand exactly what resource is affected without opening the schema.
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 'Delete an item from a checklist on a Kaiten card' establishes clear context for when the tool should be used. It does not explicitly name alternatives or exclusions, but the object scope is enough to separate it from checklist-level deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses one meaningful behavioral constraint: only the comment author can delete it. However, it does not mention permanence, side effects, or response behavior, leaving partial 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 sentence that front-loads the action and resource, then appends the key access constraint in a parenthetical. Every word earns its place with no 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?
For a simple two-parameter delete operation, the schema and description together provide sufficient information to select and invoke the tool. The author-only restriction is the main non-obvious context and it is explicitly stated.
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 both card_id and comment_id with clear descriptions, giving 100% schema coverage. The description adds no additional parameter-level detail, so the baseline score 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 states a specific verb ('Delete'), a specific resource ('comment from a card'), and an important scope constraint ('author only'). This clearly distinguishes it from sibling tools like kaiten_update_comment and kaiten_delete_card.
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 gives a clear precondition ('author only') but does not explicitly name alternatives or state when not to use the tool. The usage context is implied by the tool name and the parenthetical constraint rather than fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds a useful caveat: the call may return 405 and deletion may only be available via the Service Desk portal. However, it does not mention whether deletion is permanent, whether special permissions are required, or what a successful response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The action is front-loaded, and the 405/portal caveat is a valuable, non-obvious detail that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete operation, the description is reasonably complete: it names the resource, the schema documents the required parameter, and it flags a key failure mode. It could be more complete with permission or success-response details, but the low complexity keeps this from being a significant gap.
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 fully documents the only parameter, request_id, with a description and integer type. The tool description adds no additional parameter-level detail, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a Service Desk request.' This clearly distinguishes the operation from sibling SD tools like kaiten_update_sd_request, kaiten_get_sd_request, and the various other delete_* tools, which target 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Delete' implies when to use this tool, and the note about a possible 405 and portal-only availability hints at a fallback path. However, it does not explicitly state when to prefer this tool over alternatives like kaiten_update_sd_request, nor does it provide clear when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing a non-obvious failure mode: the API may return 405 because sprint deletion may not be supported. It also explains the domain rule that sprints can only be completed. It stops short of discussing permissions, side effects, or success response, but the key behavioral trap is surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The main action is front-loaded, and the important caveat follows immediately. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter mutation with no output schema, and the description plus schema cover the essential selection and invocation needs. The 405 warning is critical context that an agent needs before calling. A mention of expected success response would round it out, but nothing essential is missing for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter, sprint_id, with type and description, so schema coverage is 100%. The description adds no additional meaning about the parameter, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a Kaiten sprint.' It clearly identifies the operation and distinguishes it from other sprint tools like kaiten_get_sprint or kaiten_update_sprint, though it does not explicitly name a sibling alternative.
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 when deletion may not be appropriate by noting sprints can only be completed, giving an agent a hint to consider completion instead. However, it does not explicitly direct the agent to an alternative tool or state concrete conditions for choosing this tool over others.
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 transparency burden. The verb 'Get' correctly implies a read-only operation, and the supported identifier formats are stated. But it does not disclose behavior such as what happens when the card is not found, required permissions, or return-shape nuances.
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 clauses, front-loads the core action ('Get a Kaiten card by ID'), and immediately follows with the only important variation (numeric ID or key). Every 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?
For a single-parameter retrieval tool, the description provides enough information to invoke it correctly: the resource, the action, and the acceptable identifier formats. It does not describe return values or failure modes, but the simplicity of the operation makes those gaps minor and non-blocking.
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 already documents the single parameter with 100% coverage, including the allowed types and the 'e.g. PROJ-123' example. The description adds no substantive meaning beyond restating what the schema already says, 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 states a specific action ('Get') and a precise resource ('a Kaiten card by ID'), and clarifies that both numeric IDs and card keys are acceptable. This clearly distinguishes it from sibling tools like kaiten_list_cards, which enumerate cards, and other card-scoped getters like kaiten_get_card_activity.
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 usage context is implied: use this tool when you already have a card ID or key. However, it does not explicitly name alternatives such as kaiten_list_cards or kaiten_list_all_cards for situations where the ID is unknown, so the agent must infer the appropriate routing.
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 behavioral disclosure burden. 'Get' clearly signals a read operation with no mutation, which is transparent for a simple fetch. However, it does not mention behavior for invalid IDs, missing resources, or permissions, so the disclosure is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence contains the verb, resource, and selection criterion with zero filler. Every word earns its place and the key scope is front-loaded.
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 one-parameter get-by-ID tool, the description plus full schema coverage is sufficient for an agent to select and invoke the tool correctly. It would be richer with return-shape or error details, but the low complexity keeps this from being a significant gap.
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 already documents type_id as an integer 'Card type ID' with 100% coverage. The description only echoes 'by ID' and adds no additional meaning about format, constraints, or relationships, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('Kaiten card type'), and the selection scope ('by ID'). This cleanly distinguishes it from siblings like kaiten_list_card_types, kaiten_update_card_type, and kaiten_delete_card_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'by ID' wording implies this tool is for retrieving one specific card type when its ID is known, but it never explicitly contrasts it with kaiten_list_card_types for fetching all types. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. 'Get' implies a read-only operation, which is some behavioral transparency, but it does not disclose return format, error behavior, or any permissions. It adds little beyond the action itself.
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 states the action, resource, and key parameter in under 10 words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is largely sufficient: it identifies the action, resource, and required identifier. The lack of an output schema is mitigated by the implied return of the document, though adding expected response format could make it stronger.
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 parameter document_uid is already described as 'Document UID'. The description merely repeats 'by UID' without adding format, scope, or usage details, so it does not add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('Kaiten document'), and a retrieval key ('by UID'). This clearly distinguishes it from siblings like kaiten_list_documents (list vs get) and kaiten_get_document_group (different resource).
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: one uses this tool when they have a document UID and need the document. However, there is no explicit guidance about when to prefer this over kaiten_list_documents or other retrieval tools, and no exclusions are 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 behavioral burden. 'Get' signals a read-only operation, but the description adds no detail about response contents, not-found behavior, or required permissions. This is adequate for a simple fetch but thin given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple: one required integer parameter, no output schema, and no annotations. The description plus schema are enough for an agent to select and invoke it correctly. A little more context about return shape or errors could still help, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since organization_id is already described as 'Organization ID'. The description's 'by ID' reinforces the parameter's role but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a concrete resource ('Service Desk organization'), and a clear lookup scope ('by ID'). This clearly distinguishes it from list/create/update/delete siblings.
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 phrase 'by ID' implies the tool is used when an organization_id is already known, and not for listing all organizations. However, it never explicitly names alternatives like list_sd_organizations or states when not to use this tool, so guidance remains only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Get' signals a read operation and no side effects, but the description gives no detail on return shape, error behavior, permissions, or whether the SLA policy is a plain read; it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the verb, object, and lookup key with no redundant words. It earns its place and leaves nothing to trim.
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 one-parameter getter with no annotations or output schema, the description plus the schema fully supplies the information an agent needs to invoke the tool correctly: a single UUID identifies the SLA policy. Absence of a return-value description is a minor gap given no output schema exists, but it does not block correct 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%; the sla_id parameter is already documented as 'SLA ID (UUID)'. The description's 'by ID' reinforces that the sole parameter is the identifier but adds no new syntax or format details, matching the baseline for complete 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 states a specific verb ('Get'), a specific resource ('Service Desk SLA policy'), and the lookup mechanism ('by ID'), which clearly distinguishes it from sibling list/create/update/delete SLA tools even without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single SLA when the ID is known, but it does not explicitly say when to prefer it over kaiten_list_sd_sla or kaiten_get_sd_sla_stats. This is clear context without exclusions or alternatives, so it falls at the implied-usage level.
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 responsibility for conveying safety and side effects. The verb 'List' signals a non-mutating read operation and the space scoping clarifies scope, but the description does not disclose pagination, ordering, output shape, or any authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence communicates the essential purpose with no 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter list operation, the description plus schema are sufficient for an agent to call the tool correctly: it knows the required space_id and that the result is the set of automations for that space. The lack of an output schema means return details are not required, though a note on response format would make it fully 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?
The schema already documents space_id at 100% coverage, so the baseline applies. The description reinforces that the operation is scoped to a specific Kaiten space, but it adds no format, validation, or behavioral details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('automations'), and scopes the action to 'a Kaiten space'. This clearly distinguishes it from single-item automation tools like get_automation, update_automation, and delete_automation.
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 phrase 'List all automations' makes the tool's role as a collection-level query clear enough, and it is implicitly the right choice when the full set of automations in a space is needed. However, it does not explicitly name alternatives or describe when to prefer get_automation or other list tools.
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?
Annotations are absent, so the description carries the full burden. It discloses the meaning of column type codes and lists key response fields, which helps an agent interpret the output. However, it does not explicitly state that the operation is read-only or describe any error conditions, though the 'list' verb implies a safe read.
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, two sentences, with the primary purpose in the first sentence and supplementary details (column types and response fields) in the second. It is front-loaded and every sentence adds value.
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 there is no output schema, the description compensates by listing key response fields and explaining column type semantics. It is reasonably complete for a single-parameter list operation, though it could mention pagination or errors. Overall, it provides enough for an agent to call it 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?
Schema coverage is 100% with the parameter board_id already described as 'Board ID'. The description does not add any extra meaning about parameters beyond the schema, staying at the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'columns on a Kaiten board', which is specific and unambiguous. It distinguishes itself from other list tools by naming the exact resource, and the column types detail adds clarity about what constitutes a column.
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 kaiten_list_boards or kaiten_create_column. There is no mention of prerequisites (e.g., needing a valid board_id) or when this tool should be preferred over other list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does convey the read-only list behavior and explains that incoming webhooks accept external payloads and create cards. It does not mention pagination, required permissions, or response shape, but for a simple list operation 'List all...' provides reasonable baseline 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?
Two short sentences with no wasted words. The first sentence states the action and scope directly, and the second adds a useful explanatory note about the webhook type.
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 one-parameter read-only listing tool, the description is mostly sufficient: it names the target resource, scope, and required input via the schema. It does not describe the return fields, but the absence of an output schema makes that less critical for an obvious list 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?
The schema already documents the sole required parameter, space_id, as 'Space ID', so description-level documentation is not necessary. The description adds no extra semantics for the parameter, matching the baseline for full schema description 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 uses a specific verb ('List') with a precise resource ('incoming (card-creation) webhooks') and a clear scope ('for a Kaiten space'). It also distinguishes this from general webhook tools like kaiten_list_webhooks by narrowing to incoming, card-creating webhooks.
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 scope is clear: the tool lists incoming webhooks for a specific space, and the second sentence clarifies what those webhooks are for. However, it never explicitly says when to prefer this over alternatives such as kaiten_list_webhooks, so the usage guidance remains 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose a notable non-obvious behavior: the endpoint may return 405 and may not be available. However, it does not mention whether this operation is read-only, what the response shape looks like, or any pagination or error-handling details beyond the 405 caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first sentence front-loads the purpose and resource, and the second adds a critical reliability caveat. Every sentence earns its place, and the structure makes the key information immediately visible.
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 low-complexity list operation with two fully documented parameters, the description provides adequate context: it names the resource, the source location, and a key failure mode. An output schema is absent, so a bit more detail about the returned card shape could help, but the description is largely sufficient for an agent to select and call 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 input schema already fully documents both parameters (limit and offset) with clear descriptions, so schema coverage is 100%. The tool description adds no additional meaning about parameter usage, formats, or defaults, which keeps this at 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 states a specific verb ('List'), a specific resource ('removed (deleted) cards'), and a specific scope ('from the recycle bin'). This clearly distinguishes it from sibling tools like kaiten_list_cards and kaiten_list_removed_boards, since the target is deleted cards rather than active ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving deleted cards from the recycle bin, which gives the agent a clear context of use. However, it does not explicitly state when to use this tool over alternatives such as kaiten_list_cards, kaiten_list_all_cards, or kaiten_list_removed_boards, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing the mutation. 'Remove' clearly signals a state-changing operation, but the description does not mention potential non-idempotent behavior, permissions required, or what happens if the user is already not subscribed. It is adequate for a simple removal but leaves some behavioral details unstated.
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 redundant or filler content. It immediately communicates the action and the target resource, making it easy for an agent to parse and act on.
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: two required parameters, no nested objects, and no output schema. The description plus the complete input schema provide enough context to call the tool correctly. It does not explain return behavior or edge cases, but these are less critical for such a straightforward removal 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?
The input schema already covers both parameters with clear descriptions: user_id is 'User ID to unsubscribe' and column_id is 'Column ID'. Schema description coverage is 100%, so the description does not need to add parameter semantics; baseline 3 applies appropriately.
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 ('Remove') and a specific resource ('subscriber from a Kaiten column'), making the tool's purpose immediately clear. The mention of 'column' also distinguishes it from card-related subscriber tools among the sibling list, such as kaiten_remove_card_subscriber.
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 clearly implies the tool is for removing a user from a column's subscriber list, but it does not explicitly state when to choose this over alternatives like kaiten_add_column_subscriber or kaiten_remove_card_subscriber. The usage context is inferable from the wording and tool name, but not directly articulated.
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 behavioral disclosure burden. It does reveal a key behavioral constraint ('author only'), which is valuable for an update operation, but it does not mention side effects, error behavior, or what happens when the caller is not the author. This is a minimal but not fully transparent disclosure.
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 states the action, resource, and key restriction efficiently.
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 4-parameter update operation with fully documented parameters and no output schema, the description is largely sufficient. It includes the essential permission caveat, though it could have briefly noted alternatives or expected behavior when the caller is not the author.
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 are already well documented in the schema. The tool description adds no additional parameter-level meaning, which is acceptable given the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update'), a clear resource ('a comment on a card'), and adds an important scope restriction ('author only'). This clearly distinguishes it from sibling tools such as kaiten_create_comment and kaiten_delete_comment, so an agent can tell which action applies.
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 phrase 'author only' provides a useful condition for when this tool is applicable, but the description does not explicitly mention alternatives or when to prefer create/delete/list comment tools. Usage context is implied by the verb and resource rather than 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 behavioral transparency burden. It clearly discloses the mutation ('update') and explains the domain semantics of the gap, including predecessor/successor direction and the Timeline/Gantt context. However, it does not disclose behavior around missing relations, whether updates are idempotent, permission requirements, 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 two sentences with no filler. The primary action is stated immediately, and the second sentence defines the key domain term 'gap' in a way that directly supports parameter understanding. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update operation with 100% schema description coverage and no nested objects, the provided description plus schema is largely sufficient for an agent to invoke the tool correctly. The main missing context is explicit guidance about preconditions and return behavior, but these are minor given the clarity of the operation and parameter definitions.
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 all four parameters, including null-to-clear behavior, valid gap range, and gap_type enum values. The description adds modest context by framing the gap as the time distance between the predecessor's end and the successor's start, but the schema already covers the essential parameter meanings. 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 states a specific action ('update'), a specific resource ('planned relation between two cards'), and the exact field being modified ('gap (lag/lead)'). It also explains what a gap is, removing ambiguity. The focus on updating a gap clearly distinguishes it from the sibling tools kaiten_add_planned_relation and kaiten_remove_planned_relation.
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 verb 'update' and the concept of an existing planned relation imply this tool is for modifying an already-created relation's gap. However, the description does not explicitly tell the agent when to use this tool instead of kaiten_add_planned_relation or kaiten_remove_planned_relation, nor does it state preconditions such as 'the relation must already exist'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It usefully discloses the permission requirement ('Requires company tag management permission') and implies partial-update semantics via 'name and/or color'. However, it does not disclose error behavior (e.g., what happens if the tag_id does not exist), mutability side effects, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The action is front-loaded, the permission requirement follows, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three flat, fully documented parameters, the description covers the essential context: what it does, what fields it affects, and the required permission. Minor gaps are the lack of an output/return description (no output schema exists) and no explicit differentiation from related tag tools, but these are not critical for a straightforward update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds mild value by clarifying that name and color are independently updatable ('name and/or color'), but it does not materially extend beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Update'), a clear resource ('a Kaiten tag'), and the exact scope ('name and/or color'). It is easily distinguished from siblings like kaiten_create_tag, kaiten_delete_tag, kaiten_add_card_tag, and kaiten_remove_card_tag without needing to inspect schemas.
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 usage context is implied by the verb 'Update' — the tool modifies an existing tag's name/color — and the permission requirement provides a precondition. However, there is no explicit guidance on alternatives (e.g., use kaiten_create_tag if the tag does not exist, or kaiten_add_card_tag to attach tags to cards) and no when-not-to-use 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 behavioral disclosure. It states that only cards reaching specified done columns are included and that it returns aggregated statistics, but it doesn't disclose whether the aggregation is count/velocity, whether the date range is based on completion date or entry to done, or whether pagination applies. It is not contradictory, but it leaves important behavioral details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource. Every phrase earns its place; there is no redundancy given the tool's simple scope.
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 adequately scoped for a chart-summary tool with four self-explanatory parameters, but it lacks details on the exact output shape and the definition of the date-range semantics (e.g., date when card entered done column vs. moved into it). Since there is no output schema, some guidance on what statistics come back would have improved 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 having at least a brief description in the schema. The main description adds the concept that 'done_columns' are exactly the columns whose reaching defines 'done', and that the date range is for a space. This is some added meaning but largely a restatement of the schema names and types.
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 done-card summary'), the resource ('for a space within a date range'), and the scope ('statistics for cards that reached the specified done columns'). This clearly distinguishes it from the many other chart tools like kaiten_chart_lead_time or kaiten_chart_cfd.
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 defines what kind of data this tool returns ('done-card summary', 'aggregated statistics'), making it distinguishable from siblings that provide activity or lead-time charts. However, it doesn't explicitly state when to choose this over related chart tools or give exclusions, which would have made it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose two useful non-obvious facts: the paid feature requirement and where created cards will be placed. However, it does not mention whether the response returns a webhook URL, any permissions needed, or rate-limit/authentication implications, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the action and object, then gives the prerequisite and the placement behavior. Every sentence 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 creation tool with 100% parameter coverage, the description covers purpose, prerequisite, and effect on cards. However, there is no output schema and no mention of what the API returns (such as a webhook URL), nor any guidance distinguishing this from kaiten_create_webhook. The definition is adequate but leaves some operational context 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?
All eight parameters have descriptions in the input schema, providing 100% schema coverage, so the baseline is 3. The description's phrase 'specified board/column/lane' only summarizes board_id, column_id, and lane_id, which the schema already documents clearly. No additional parameter-level meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and object: 'Create an incoming (card-creation) webhook for a Kaiten space.' The parenthetical 'card-creation' adds meaning beyond the tool name and helps distinguish it from the more generic sibling kaiten_create_webhook. It clearly states what the tool does and its scope.
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 prerequisite: 'Requires webhooks paid feature.' It also explains the operational context: cards created via the webhook will land at the specified board/column/lane. It does not explicitly contrast this tool with kaiten_create_webhook or state when not to use it, but the incoming/card-creation framing implies the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the disclosure burden. It does surface a non-obvious behavioral trait — the API may return 405 and creation may be restricted to the portal — which is critical for an agent to know. It does not describe success responses or side effects, but the disclosed limitation is material and beyond what the schema reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the purpose is front-loaded and the caveat is positioned after. 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 4-parameter create tool with a fully documented schema, the main missing contextual element is the success/error response shape (no output schema) and what to do when the portal-only restriction applies. The 405 caveat is a step in the right direction, but the description stops short of telling the agent how to recover or find the required service_id.
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%: title, priority, service_id, and description all have schema-level descriptions. The tool description adds no parameter semantics, so it stays at the baseline for fully-covered schemas.
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 leads with a specific verb and resource — 'Create a new Service Desk request' — which unambiguously distinguishes it from the many sibling sd_* tools (list/get/update/delete). The 405 note is secondary and does not obscure the primary purpose.
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?
There is no explicit when-to-use-versus-alternatives guidance; the description relies on the tool name and first sentence to imply its use case. The note that creation may only be available via the Service Desk portal is a useful caveat for deciding whether to attempt the call, but it does not name alternative tools or say when to prefer them.
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 behavioral burden. It usefully discloses the predecessor/successor direction and the planned-date prerequisite. However, it does not mention what happens if the prerequisite is unmet, whether duplicate relations are prevented, or what the API returns on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The primary action is front-loaded, and the key semantic detail and prerequisite are stated efficiently.
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 three-parameter mutation with a fully documented schema, the description covers the operation, direction, and critical precondition. It could add expected return behavior or duplicate-handling details, but these are not essential for selecting and correctly 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?
The input schema already provides 100% parameter coverage, including descriptions for card_id, target_card_id, and type. The description mostly restates the source/successor roles rather than adding new parameter-level meaning, so it stays at the baseline for fully documented schemas.
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 identifies the resource ('planned relation') and the target context ('Timeline/Gantt'). It clearly defines source as predecessor and target as successor, which distinguishes it from the sibling update and remove planned-relation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: creating a successor link between two cards on Timeline/Gantt, with an important prerequisite that both cards have planned_start and planned_end dates. It does not explicitly name alternatives like kaiten_update_planned_relation or kaiten_remove_planned_relation, but the create framing makes the intended use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the most important behavior: the operation is asynchronous and returns a compute_job_id rather than a direct chart result. It also notes the Control Chart engine relationship and the required polling step. It does not mention side effects or auth/rate limits, but the async contract is the key behavioral disclosure for this 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 three short sentences with no filler, front-loading the action and then giving the essential engine and async/polling context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and no output schema, the description covers the key non-schema knowledge: it is async, returns a compute job ID, and names the exact sibling to call for polling. It does not describe what the final job result will look like, but the chart type makes that largely inferable and the schema handles parameter detail.
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, and the description adds no parameter-level detail. All 11 parameters are described in the schema, including examples for the nested lane mappings, so the agent has enough information to populate them.
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 opens with a specific verb and resource: 'Build a Lead Time Chart for a space,' making it clear this tool constructs that chart. It references the Control Chart as a close sibling, which helps distinguish it within the chart family, though it does not explicitly contrast it with other chart tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it to build a lead-time chart for a space, and it explicitly points to kaiten_get_compute_job for polling, which is the essential follow-up workflow. It does not state when not to use it or compare it with alternatives such as cycle-time or control charts, so exclusion guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that color is randomly assigned by the server (1-17), which prevents an agent from assuming a color can be chosen. The write side effect is clear from 'Create,' and no additional behavioral surprises exist for such a simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, both informative and free of fluff. The core operation is front-loaded, and the behavioral note follows naturally. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter creation tool, the description and schema together provide sufficient context: what is created, what the input is, and the notable server-side color behavior. It does not detail error cases or return values, but the simplicity of the operation makes those omissions minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already documents the parameter 'name' with its length and uniqueness constraints. The description adds no new parameter-level detail, 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 uses a specific verb and resource: 'Create a new Kaiten tag.' It clearly distinguishes this from sibling tools like kaiten_update_tag and kaiten_delete_tag. The additional note about color assignment further clarifies the exact behavior.
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: call this tool when the goal is to create a new tag. However, it does not explicitly mention alternatives or conditions, such as checking existing tags first or distinguishing tag creation from associating tags with cards (kaiten_add_card_tag).
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 present, so the description carries the burden of behavioral disclosure. It does disclose important constraints: creation limit, URL length, and the paid-feature requirement. However, it does not explain what happens if a webhook already exists, whether special permissions are required, or what the tool returns, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the purpose and then states the key constraints concisely, every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter creation tool, the description covers the main invocation concerns: scope, usage limit, and feature requirement. It is slightly incomplete because there is no output schema and the description does not specify the return value or behavior on duplicate creation, but these are minor for calling 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?
Schema description coverage is 100%, and both parameters have meaningful descriptions already. The tool description restates the URL max length but adds essentially no new meaning beyond the schema for either 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 states a specific action ('Create an external webhook') and resource ('for a Kaiten space'), and the parenthetical 'outbound event notification'clarifies its purpose. The term 'external'explicitly distinguishes it from sibling webhook tools such as kaiten_create_incoming_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear contextual guidance by stating 'Only 1 per space allowed' and 'Requires webhooks paid feature,' which signal when this tool can and cannot be used. It does not explicitly name sibling alternatives like kaiten_list_webhooks or kaiten_update_webhook, but the constraints give an agent enough to decide whether creation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the creation behavior and a validation constraint ('requires at least 2 stages and 1 transition'), which is useful. However, it does not describe response behavior, permissions, or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main purpose is front-loaded, and the secondary sentence adds a genuinely useful constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All required parameters are described in the schema, and the description highlights the key validation rule. The main missing piece is return-value behavior, but for a straightforward create operation this is not a critical gap given the rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description. The tool description adds no new parameter-level meaning beyond what the schema already documents, 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 states a specific action ('Create') on a specific resource ('a new company workflow'). This clearly distinguishes the tool from siblings like kaiten_update_workflow, kaiten_list_workflows, and kaiten_delete_workflow.
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 'Create a new' clearly signals this is for initial workflow creation rather than modifying or deleting an existing one. It does not explicitly name alternatives or provide when-not-to-use guidance, but the context is clear enough for an agent to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states this is a soft-delete rather than a destructive delete, which is a meaningful behavioral trait. It also discloses the time log restriction. It does not mention response behavior or reversibility, but the disclosed behavior exceeds the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The main action is front-loaded and the critical constraint is stated immediately after. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete operation with complete schema coverage, the description provides the core behavior and the key edge-case restriction. It does not describe the response format or restoration path, but these are not essential for a simple, well-scoped delete 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 schema already fully describes card_id as 'Card ID or key' with 100% coverage. The description adds no further meaning to the parameter. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Soft-delete') and resource ('Kaiten card'), and clarifies that this is not a permanent/hard delete by noting the condition is set to deleted. This clearly separates it from related card operations like archive_card or remove_card_child.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use: to soft-delete a card. It also provides a clear when-not condition ('Cards with time logs cannot be deleted'). However, it does not name alternatives or explain what to do when the card has time logs, so the guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully discloses that deletion is soft and highlights two blocking conditions, but it does not mention permissions, side effects, idempotency, or what happens on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the second sentence provides valuable exclusion criteria that every word earns.
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 one-parameter delete operation, the description is largely complete: it states the action, the soft-delete behavior, and the key failure conditions. It does not describe return values, but the absence of an output schema and low operation complexity make this a minor gap.
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 the only parameter, property_id, with a clear description and type. The tool description adds no additional parameter-level meaning, so it stays at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete (soft)') and the resource ('a custom property'), making the tool's purpose unambiguous. It is easily distinguished from the many sibling delete tools because it names the exact resource type and clarifies the deletion mode.
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 practical constraints on when the tool cannot be used: properties used as progress or attached to Service Desk services. This helps the agent avoid invalid calls, though it does not explicitly name alternative tools or state a broader 'use this when...' scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that this is a delete operation on an incoming webhook, which is useful, but it does not mention permanence, side effects on card creation, required permissions, or response behavior. Acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. The parenthetical '(card-creation)' adds valuable disambiguation at minimal length.
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 2-parameter destructive tool with no output schema and fully documented parameters. The description provides enough context for correct invocation, though it could mention the irreversible effect on card creation for greater 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 both space_id and webhook_id already described. The description adds no additional parameter-level meaning, 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 uses a specific verb ('Delete') and names the exact resource ('incoming (card-creation) webhook') scoped to a 'Kaiten space'. This makes it clearly distinguishable from sibling tools like kaiten_delete_webhook and other delete operations.
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 qualifier 'incoming (card-creation)' clearly signals when this tool applies versus generic webhook tools. It gives clear context but does not explicitly state when-not to use alternative webhook tools, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only behavioral signal. It discloses that the tool returns board structure with columns and lanes, but it does not mention permissions, filtering behavior, or whether any boards are excluded from chart configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no filler or repeated schema data. Every sentence earns its place by stating either the purpose or the expected return content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with a simple purpose, the description covers what is needed: the input space and the returned board columns/lanes structure. Without an output schema, a little more detail about the exact shape of the returned structure could help, but the tool is simple enough that this is a minor gap.
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 already documents space_id with the description 'Space ID' and has 100% coverage for its single parameter. The description only references 'in a space' and adds no additional meaning, syntax, or formatting guidance for 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 opens with a specific verb and resource: 'Get board structure for chart configuration in a space,' which clearly identifies what the tool does. The second sentence adds what is returned—boards with columns and lanes—which separates it from generic board-listing tools like kaiten_get_board or kaiten_list_boards.
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 chart configuration' and 'available for building charts' provides clear context for when this tool is appropriate, distinguishing it from general board or column retrieval. It does not explicitly name alternatives or say when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully documents the 'status' field values and explains that 'result' contains chart data only when status is 'done.' However, it does not describe failure details, error handling, or polling behavior, leaving moderate 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?
Three tight sentences, each earning its place. The main purpose is front-loaded, the usage context follows, and the response fields are summarized efficiently with no 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?
For a simple one-parameter polling tool, the description is nearly complete: it explains the job_id origin, the statuses, and the result semantics despite lacking an output schema. The only minor gap is not detailing what happens when status is 'failed' (e.g., error message format).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter job_id is already described in the schema as 'Compute job ID returned by an async chart tool,' achieving 100% coverage. The description adds a little workflow context but does not materially expand parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get the status and result of an asynchronous compute job') and distinguishes this from the chart-request and cancel siblings by framing it as the polling counterpart. An agent can immediately identify this as the retrieval tool for async job outcomes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use the tool: 'Use this to poll for results after requesting an async chart.' It provides clear context for the polling workflow, though it does not explicitly list alternatives or exclusions beyond the implied chart tool relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It explicitly discloses the async nature and the return of a compute_job_id, which is the most critical behavioral trait. It does not mention failure modes, permissions, or scope limits, but the core non-obvious behavior is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The purpose is front-loaded, followed immediately by the critical async behavior and the exact polling tool to use. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an async statistics tool, the description tells the agent what it returns and what to do next, which is the essential workflow. It does not explain the shape of the final statistics result, and there is no output schema, but the compute job indirection makes that less critical for initial 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?
All 7 parameters have schema descriptions covering 100% of parameters, so the schema already conveys parameter meaning. The description adds no additional parameter-level context such as default behavior when filters are omitted or how filters combine, which keeps this at 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 states a specific verb and resource ('Get Service Desk SLA statistics') and is unambiguous about what the tool does. It does not explicitly distinguish itself from sibling tools like kaiten_get_sd_stats or kaiten_get_sd_sla, but the async behavior noted in the next sentence provides a distinguishing detail.
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 tells the agent the follow-up action: use kaiten_get_compute_job to poll results. This is concrete usage guidance for an async operation. However, it does not discuss when to choose this tool over related SLA/stats siblings or mention any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It clearly indicates this is a read operation ('Get') and describes what the caller will receive: a sprint summary with cards, path data, and custom properties. It does not discuss failure cases or permissions, but for a simple read-by-ID tool the disclosure is reasonably complete.
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 that captures both the purpose and the main return content. There is no fluff, repetition, or unnecessary detail.
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: one required integer parameter, one optional boolean, and no output schema. The description, combined with the complete schema documentation, gives an agent enough context to call it correctly and know what kind of result to expect. Minor gaps like error behavior or pagination are not critical for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both sprint_id and exclude_deleted_cards. The description does not add any extra parameter-level detail beyond the schema, which is acceptable given the high schema coverage but means no bonus credit is earned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get'), a specific resource ('sprint'), and the retrieval key ('by ID'), which cleanly distinguishes it from listing, creating, updating, or deleting sprints. It also gives a brief sense of the returned payload, making the tool's function immediately recognizable.
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 'by ID' phrasing implies this tool is appropriate when a specific sprint ID is already known, rather than when listing sprints. However, it never explicitly names kaiten_list_sprints or kaiten_get_sprint-related alternatives, and it gives no guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 — and it discloses meaningful behavior: the recursive nature with 'children' arrays, the entity types returned (spaces, documents, document groups), and the effect of root_uid and depth on traversal scope. It does not warn about potentially very large payloads when depth=0 (unlimited) on a big sidebar, and it never states this is a read-only operation, but the core runtime behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero fluff: purpose first, return-structure second, parameter hints third. Every sentence earns its place and the key distinction (recursive tree) is front-loaded in the first sentence.
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 2-param, 0-required, 100%-schema-coverage tool, this is nearly complete: it covers the return shape (nested tree, children arrays, entity types) and both parameters' roles. The main gap is that with no output schema, the per-node shape beyond 'children' is underspecified. A brief caution about unlimited depth producing huge responses would also strengthen it, but this is close to complete for a read-style tree tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents depth (Max recursion depth, 0 = unlimited, default 0) and root_uid (Start tree from this entity UID, omit for full tree). The description's 'Use root_uid... Use depth...' essentially paraphrases the schema with no added detail such as UID format or depth semantics beyond what the schema states. 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 opens with a specific verb+resource ('Build a nested entity tree from the Kaiten sidebar') and specifies exactly which entity types are included (spaces, documents, document groups). Describing the result as a 'recursive tree with children arrays' clearly distinguishes this from flat-list siblings like kaiten_list_documents, kaiten_list_spaces, and kaiten_list_document_groups. An agent can tell this tool apart without opening any sibling schema.
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 when to use it — when you need the hierarchical sidebar structure rather than a flat list — but it never names an alternative or states an exclusion. The 'Use root_uid...' and 'Use depth...' sentences explain parameter usage, not tool-vs-alternative selection. No explicit when-not-to-use guidance is present.
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, and it delivers: automatic pagination, combined results, the 50-page/5000-card safety limit, and which timing/audit fields are present in responses. It does not disclose rate limits, errors, or ordering, but for a read-style list tool the disclosed behavior is substantial.
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?
Four sentences with the core behavior front-loaded before use-case guidance, and every sentence serves a purpose. The audit-field sentence is long, but it earns its place by supporting the audit use case without extra fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 31-parameter tool with no output schema and no annotations, the description covers pagination, safety limits, and two concrete use cases — but it omits the distinction from kaiten_list_cards, rate limits, error/edge-case behavior, and how filters compose. Solid but not complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already contains the exact metrics and audit field strings for the 'fields' parameter. The description adds marginal interpretive value — linking the timing fields to the location-history alternative and tying the 5000-card cap to pagination — but most of its field lists are redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource — 'Fetch ALL cards matching filters' — and immediately distinguishes this tool from siblings like kaiten_list_cards by emphasizing 'ALL', automatic pagination, and combined results across pages. An agent can tell this is the bulk-fetch variant without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-not guidance: for basic Kanban metrics the returned timing fields mean 'no need to call kaiten_get_card_location_history for each card', naming the alternative directly. However, it never addresses the most likely confusion — when to use this over the near-identical kaiten_list_cards — so the routing is incomplete.
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 itself must carry the behavioral disclosure burden. 'List' implies a read-only operation with no mutation, but the description does not say anything about response shape, pagination, ordering, or permissions. This is adequate for a simple list read but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. Every word contributes to identifying the action and the target resource.
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 low-complexity tool with one required parameter and full schema coverage. There is no output schema, but 'List all checklists' reasonably implies a list of checklists is returned. A small gap remains: it does not clarify whether checklist items are included or how the result is structured.
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 already fully describes the only parameter, card_id, as an integer Card ID. The description adds no additional meaning or usage detail beyond what the schema provides, 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 uses a specific verb and resource: 'List all checklists on a Kaiten card.' It clearly distinguishes this tool from siblings like kaiten_list_checklist_items and kaiten_create_checklist by naming exactly what is returned.
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 intended context is clear: use this tool when you need the checklists belonging to a particular card. It does not explicitly name alternatives or exclusions, such as using kaiten_list_checklist_items for the items inside a checklist, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'List all external links on a Kaiten card' clearly communicates a read-only operation with a defined scope. It does not mention pagination or return shape, but for a simple list operation the behavioral contract is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the action and object, and contains no filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, full schema coverage, and no output schema, the description gives enough context to select and invoke the tool correctly. A note about the returned link fields would be helpful but is not essential for a straightforward list call.
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 required card_id parameter is already documented as an integer 'Card ID'. The description adds no additional parameter meaning, but none is needed since the schema fully covers the only argument.
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 names a specific verb ('List'), a precise resource ('external links on a Kaiten card'), and scopes the result set with 'all'. This clearly distinguishes it from sibling tools like kaiten_create_external_link, kaiten_delete_external_link, and kaiten_list_documents.
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 intended use is implied: select this tool when you need the external links attached to a Kaiten card. However, there is no explicit when-not-to-use guidance or reference to alternative tools, so the routing decision relies mostly on inference.
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 behavioral burden and does indicate a read-only listing behavior with company-wide scope. It does not disclose caveats such as pagination, required permissions, or whether archived/inactive projects are included, but for a parameterless list tool the core behavior is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is immediately front-loaded with the action and resource, with no filler or redundancy. Every word adds relevant scope information ('all', 'in the company').
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 zero-parameter, read-only list operation, this description gives sufficient context to invoke the tool correctly and understand the intended result. It would be slightly stronger if it described the shape of the returned project list, but the low complexity keeps the gap minor.
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?
There are no parameters in the input schema, so there is no semantic burden on the description. The 0-parameter baseline of 4 applies, and the description correctly requires no additional parameter details.
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') and resource ('all Kaiten projects'), with explicit scope ('in the company'). It is clearly distinct from sibling tools like kaiten_get_project (single project), kaiten_create_project, and kaiten_list_project_cards.
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 phrase 'all Kaiten projects' implies this is the tool to use when a complete project listing is needed, and the resource name separates it from get/create/update/delete variants. However, it does not explicitly mention alternatives or conditions such as using kaiten_get_project for a single project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses a non-obvious and actionable caveat: the endpoint may return 405 and may not be available. The read-only nature is implied by 'list,' and no side effects or output shape are discussed, but the explicit failure mode is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the operation and source, the second warns about a possible 405. There is no redundant or filler content.
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 only two optional parameters and no output schema. The description covers the resource, source, and a key failure mode. It could explicitly describe the return format, but for a straightforward list operation the current text is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: limit is described as 'Max results' and offset as 'Pagination offset.' The description adds no parameter-specific detail, so the baseline score of 3 is appropriate because the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List removed (deleted) boards from the recycle bin.' This clearly distinguishes it from the active-board listing sibling kaiten_list_boards and other board operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear from 'removed (deleted) boards' and 'recycle bin,' but the description does not explicitly contrast with kaiten_list_boards or state when not to use this tool. The usage guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It discloses that this is a list/read operation and describes the array shape, but it does not clarify whether archived spaces are returned by default or whether pagination applies, and 'all' is slightly ambiguous given the archived parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences place the operation first and the return shape second. There is no filler, and every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list endpoint with two optional parameters and no output schema, the description plus schema gives enough to invoke it correctly. It could be more complete by stating the default behavior of the archived parameter, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents compact and archived. The description adds no parameter-level meaning, which is acceptable but earns only 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?
Begins with a specific verb-resource pair, 'List all Kaiten spaces,' and names the key returned fields (id, title, description, access type). The tool is clearly distinct from the sibling get/create/update/delete space tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the context obvious: use it when you need the full collection of spaces, and the return-type note signals it is appropriate for enumeration. It does not explicitly name alternatives like kaiten_get_space for single-space lookups, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful context by clarifying these are outbound notifications and that at most one exists per space. However, it does not mention whether the operation is read-only, how results are returned, or what happens when no webhook exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words. The core operation is front-loaded, and the uniqueness constraint is a valuable piece of context that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation with no output schema, the description is largely sufficient: it identifies the resource type, scope, and the one-per-space constraint. It could additionally describe the shape of the returned list or behavior when no webhook exists, but low complexity and full schema coverage reduce the need.
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 fully documents the only parameter, space_id, with 100% description coverage. The description's phrase 'for a Kaiten space' aligns with the parameter but adds no additional format or semantic detail. With full schema coverage, 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?
States an explicit verb ('List'), a specific resource ('external webhooks'), and a scope ('for a Kaiten space'). The parenthetical '(outbound event notifications)' and the word 'external' clearly distinguish this tool from sibling kaiten_list_incoming_webhooks.
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 establishes the context: listing external/outbound webhooks for a specific space. It also adds the useful constraint that only one external webhook per space is allowed, which helps an agent know what to expect. It does not explicitly name alternatives like kaiten_get_webhook or kaiten_list_incoming_webhooks, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the transparency burden. It discloses a concrete side effect: setting a canceled_at timestamp and preventing further processing. It does not mention failure cases or permissions, but the core behavioral outcome is clearly 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 two short sentences: the first states the action, the second states the consequence. It contains no filler and does not redundantly repeat the schema's parameter description.
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 one-parameter cancellation tool, the description provides the action, applicable state, and resulting effect. It omits return-value details, but no output schema exists and the behavior is straightforward enough that this is not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter job_id is already fully described in the input schema ('Compute job ID to cancel'), giving 100% schema coverage. The description adds no additional parameter-level meaning, 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 uses a specific verb ('Cancel') and a specific resource ('compute job'), and further narrows scope to 'running or queued' jobs. This makes it clearly distinguishable from the read-only sibling kaiten_get_compute_job and other compute-related operations.
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 conveys the relevant condition for invoking the tool: the job must be running or queued. It does not explicitly name alternatives or exclusions, but the cancellation action has no close sibling alternative among the listed tools, so the implied usage context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly discloses that this is an asynchronous operation, returns a compute_job_id, and requires polling for results. This is key behavior not visible in the schema, though it could add failure modes, permissions, or compute-job lifecycle 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?
Three short sentences, front-loaded with the primary purpose and immediately followed by the critical async behavior and polling tool. No filler or redundant detail.
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 an async chart operation with no output schema, the description names the response handle (compute_job_id) and the exact polling tool. It doesn't describe the final chart result shape or cancellation, but it gives enough for an agent to select 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?
All six parameters are already documented in the schema (100% coverage), so the baseline is 3. The description adds no param-specific explanation beyond 'for a space' implicitly aligning with space_id.
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?
States a specific verb 'Build' + resource 'Task Distribution Chart' and scope 'for a space'; the second sentence clarifies what it shows ('how tasks are distributed across the board'). This distinguishes it from the many sibling chart tools by naming the specific chart type.
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?
Clearly identifies the intended use case and gives direct follow-up guidance: the operation is asynchronous and should be polled via kaiten_get_compute_job. It does not explicitly compare with alternative chart siblings, but the scenario is clear enough to route an agent.
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?
There are no annotations, so the description carries the transparency burden. It discloses a key behavioral restriction ('author only') beyond what the name alone conveys. It does not explicitly state permanence or side effects, but for a delete operation the action and permission constraint are 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 compact sentence with no filler. It front-loads the action and resource, then adds the important authorization caveat in a parenthetical.
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 delete operation with no output schema, the description is complete enough: it names the resource, target, and permission constraint. A minor gap is that it does not explicitly note that deletion is permanent or how to obtain the time_log_id, but these are inferable and not blocking.
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 card_id and time_log_id already have clear descriptions in the input schema. The tool description adds no additional parameter-level 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 states a specific verb ('Delete'), a specific resource ('a time log entry'), and the containing context ('from a card'). It also adds the 'author only' restriction, which clearly distinguishes this deletion tool from create/update/list time-log siblings and from kaiten_delete_user_timer.
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 usage constraint: only the author may delete the time log. It does not name explicit alternatives, but the wording makes the intended use obvious among the time-log related sibling tools, and the 'author only' condition is a useful when-to-use signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses automatic pagination, a concrete safety limit ('50 pages (5000 events)'), and the efficiency tradeoff versus per-card calls. What is missing is a description of the response shape or payload structure, since there is no output schema to fall back on.
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?
Four dense sentences with no filler: purpose and pagination up front, actions guidance, safety limit, and the efficiency rationale. Every sentence earns its place and is ordered from 'what it does' to 'when to use it'.
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 9-parameter tool with no output schema and no annotations, the description covers purpose, pagination behavior, safety limits, and a common use case. It does not explain the return format (mport, since there is no output schema) and one could argue it is light on failure/rate-limmit behavior, but the core selection-and-invocation decisions an agent needs are well supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all 9 parameters are already documented in the schema; the description adds only modest extra meaning. The 'complete card flow history' actions example adds contextual value beyond the flat list in the schema, and the safety-limit mention reinforces max_pages. This is a solid baseline-3 contribution rather than a meaningful layer of new semantic.
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 opening sentence 'Fetch ALL activity for a space with automatic pagination' states a specific verb, resource, and key behavioral trait (automatic pagination). The final sentence explicitly contrasts it with per-card requests, distinguishing it from siblings like kaiten_get_card_activity and kaiten_get_space_activity. An agent can confidently identify what this tool does and what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool: 'the EFFICIENT way to get location history for all cards in a space', and names the alternative ('hundreds of individual card requests'). It also prescribes a specific actions value for a common use case. However, it does not explicitly address when NOT to use it or how it differs from the similarly named kaiten_get_space_activity sibling, so it stops just short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description bears the behavioral transparency burden. It conveys that authentication is required and that this is a read operation ('Get'), but it does not describe the shape of the returned profile, potential errors, or any side effects. This is acceptable for a simple getter but leaves the response contract unspecified.
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 detail, exactly matching the trivial scope of the 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?
For a zero-parameter, no-output-schema tool, the description names the returned resource and the authentication context, which is enough for selection and invocation. It could optionally specify the profile fields or response shape, but such detail is less critical when no input is accepted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so schema coverage is effectively 100% and there are no parameter semantics to explain. Baseline for zero-parameter tools is 4, and the description does not misrepresent 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 uses a specific verb ('Get') with a precise resource ('current authenticated Kaiten user profile'), clearly defining scope. The word 'current' distinguishes it from sibling tools like kaiten_list_users, which target all users or space/group user lists.
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 'current authenticated' makes the invocation context clear: use this when the profile of the logged-in caller is needed. It does not explicitly name alternatives or exclusions, but for a zero-parameter self-profile endpoint the context is sufficient.
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 behavioral burden, and 'Get' clearly signals a read-only retrieval operation. It does not mention error cases, permissions, or response details, but for a simple single-resource fetch the core behavior is transparent enough.
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 or repetition. The core action and target are front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one required parameter, and no output schema, the description plus the input schema are sufficient for an agent to make the call. Slightly more context about what the returned workflow contains or what happens if the ID is invalid would make it fully 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%, and the only parameter, workflow_id, is already documented as 'Workflow ID (UUID)'. The description adds no new semantic detail beyond reinforcing that the lookup is by ID, so the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('a specific company workflow') plus the selection mechanism ('by ID'). This clearly distinguishes it from sibling tools like kaiten_list_workflows, which retrieves multiple workflows.
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 'specific...by ID' makes the usage context clear: use this when you have a workflow UUID and need one workflow. It does not explicitly name alternatives such as kaiten_list_workflows for retrieving all workflows, so it stops short of full explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose meaningful behavior: it returns only direct children, supports root-level listing when the parameter is omitted, and fetches spaces, documents, and document groups in parallel. However, it does not mention pagination, result ordering, authentication requirements, or potential for large result sets, which are relevant for a list operation without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no fluff. The primary purpose is front-loaded, the conditional behavior follows immediately, and the parallel-fetch detail is a useful addition without unnecessary length.
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, the description is largely complete: it explains the input semantics, the scope of results, and the entity types returned. The only notable omission is return-value shape and pagination behavior, but the description is sufficient for correct invocation in most use cases.
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 schema already documents the parameter. The description adds value by clarifying that omitting produces root-level entities and that supplying it returns only direct children of that entity. This goes beyond the schema's brief 'Parent entity UID' text and helps an agent understand the exact semantics.
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 and resource: 'List direct children of an entity in the Kaiten sidebar tree.' It clearly distinguishes this from sibling tools like kaiten_list_card_children by scoping to the sidebar tree and explicitly naming the returned entity types: spaces, documents, and document groups. The root-level vs. parent-child behavior is also made explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditional usage context: 'Without parent_entity_uid: returns root-level entities. With parent_entity_uid: returns direct children of that entity.' It does not explicitly name alternative tools or state when not to use this tool, but the context is clear enough for an agent to decide to call it for sidebar tree child listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful behavior details beyond the tool name: search support, pagination, inactive-user filtering, and the response fields. It does not disclose every edge case, such as default inactive-user behavior, but it gives a solid behavioral picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, with the core action front-loaded and every sentence adding value: what it lists, what capabilities it supports, and what the response contains. No filler 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 list operation with no output schema, the description usefully enumerates response fields and key capabilities. Minor gaps remain, such as the default behavior of include_inactive and explicit guidance versus sibling user-listing tools, but the core information is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description's mention of search, pagination, and filtering maps to those parameters but adds no new semantic 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 states a specific verb and resource: "List company users." The company-level scope clearly distinguishes it from sibling tools like kaiten_list_group_users or kaiten_list_space_users, so an agent can select it confidently.
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 by indicating this lists company users and supports search, pagination, and inactive-user filtering. It does not explicitly name alternatives or state when not to use it, but the scope is unambiguous enough to guide selection.
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 behavioral burden. It does disclose a key limitation (the on_workflow exclusion), which is genuinely useful. However, it does not disclose update semantics such as whether omitted fields are left unchanged (patch vs replace), permission requirements, or failure behavior — all relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The primary purpose is front-loaded, and the exception with alternative is stated immediately after. Every clause 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?
The tool has 8 parameters including nested objects, no output schema, and no annotations. The description plus schema cover how to invoke it, and the cross-reference to create_automation compensates for undocumented nested structures. Still, partial-update semantics and return behavior are left unstated, which is a notable gap for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by cross-referencing kaiten_create_automation for supported action/trigger/condition types, which matters because the schema defines several nested objects only as plain objects ('{type, data}') with no enumerated options.
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+resource ('Update an automation in a Kaiten space') and immediately distinguishes scope by naming what it cannot do ('Cannot update automations of type on_workflow'), which separates it from sibling tools like kaiten_create_automation, kaiten_get_automation, kaiten_delete_automation, and kaiten_update_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit when-not-to-use rule ('Cannot update automations of type on_workflow') and names the alternative ('use Workflow API instead'), which maps to the sibling kaiten_update_workflow. An agent can route correctly without opening schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly communicates that the call is asynchronous, returns a compute_job_id, and requires polling via kaiten_get_compute_job. This is a critical behavioral trait beyond what the schema states, though it omits error/permission 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?
Three sentences, each purposeful: purpose, prerequisites, and async handling. Information is front-loaded and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description supplies the necessary workflow (compute_job_id + polling), the key board_configs prerequisites, and enough framing to choose the tool. It doesn't detail every param, but the schema already describes those; the missing result-shape detail is delegated to kaiten_get_compute_job.
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 adds value by constraining board_configs: columns must be marked 'won' or 'lost' and each enabled board needs a sum property in settings. This explains requirements the schema only partially encodes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Build a Sales Funnel Chart for a space', naming a specific verb, resource, and scope. This uniquely identifies the tool among the many kaiten_chart_* siblings and is clear without requiring the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational context: board_configs must reference enabled boards, won/lost columns, and a configured sum property. It also states the async workflow and names kaiten_get_compute_job for polling. It does not explicitly compare with alternative chart tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does a good job by disclosing the endpoint's possible 405 failure. It could also state what a 405 means for handling the result, but the warning is strong, specific, and actionable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core operation is stated first, then the critical caveat and fallback are placed immediately after, which is the optimal front-loaded structure for agent decision-making.
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 definition is complete for a simple two-parameter GET tool: it identifies the resource, names required parameters through the schema, and warns about the likely failure mode with a clear fallback. It does not describe the return shape, but with no output schema defined, a brief note on what the response contains could add small value; however, for a simple retrieval the missing return description is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented in the schema. The description itself does not add deeper semantic meaning about space_id or automation_id formats beyond the schema, but the schema provides sufficient meaning, 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?
States a specific verb ('Get') and resource ('a specific automation in a Kaiten space'), which clearly identifies what the tool does. It also distinguishes itself from kaiten_list_automations by naming that sibling as the recommended alternative when the GET-by-ID approach may fail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says GET by ID may return 405 and advises using kaiten_list_automations with client-side filtering. This is a concrete when-to-use-this-tool vs alternative condition, giving the agent actionable routing guidance beyond basic context.
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 discloses a meaningful failure mode (405) and a workaround, which goes beyond a typical 'get by ID' description. It doesn't elaborate on return shape or error cases beyond 405, but for a simple read operation that is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core purpose is front-loaded, and the important fallback note is placed second for visibility. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with no output schema, the description covers the essential call context: what the tool does, the required input, a known failure mode, and the recommended alternative. It could mention what the response contains, but that is not essential for calling 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 schema covers the only parameter, request_id, with description 'Request ID', so schema coverage is 100%. The tool description adds no additional meaning to the parameter, but the baseline of 3 applies because the schema already fully documents it.
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'), resource ('Service Desk request'), and identifier ('by ID'), making the tool's purpose unambiguous. It also implicitly distinguishes itself from kaiten_list_sd_requests by focusing on individual retrieval rather than listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool 'may return 405' and instructs to 'use kaiten_list_sd_requests and filter client-side' instead, naming the exact alternative and the condition that should trigger it. This is direct, actionable 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?
With no annotations, the description carries the transparency burden. It discloses the key failure mode ('GET by ID may return 405') and recommends a workaround. It does not add much else about response shape or permissions, but the 405 caveat is meaningful behavioral information not available in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry all essential information: the operation and the critical fallback note. There is no filler, and the caveat is placed immediately after the 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 getter with no output schema, the description is nearly complete: it identifies the resource, the required scope, and the likely failure mode with a fallback. It would be slightly stronger with a hint about the response shape, but 'Get a specific external webhook' makes the return value reasonably predictable.
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 both parameters at 100% coverage. The description only restates 'space' and 'webhook' context without adding ID format, lookup behavior, or relationship details, so it stays at the schema-driven baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Get'), a specific resource ('a specific external webhook'), and a scope ('for a Kaiten space'). It also distinguishes the tool from the list and incoming-webhook siblings, especially by naming kaiten_list_webhooks and by qualifying the webhook as 'external'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note provides an explicit alternative and a condition: if GET by ID returns 405, use kaiten_list_webhooks instead. This directly tells an agent when not to use the tool and which sibling to fall back to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses non-obvious behavior: combining five specific actions yields complete card location history, and offset pagination is required for a full result set. It also notes the efficiency advantage, though it does not cover auth, rate limits, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core purpose comes first. The bulk-alternative guidance is dense but every element earns its place: the action list, the pagination tip, and the efficiency comparison all help an agent decide and invoke correctly.
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 9-parameter feed tool with no output schema or annotations, the description provides the main decision-relevant context: what the feed does, how to get complete history, and when it is the efficient choice. Exact response fields and auth requirements are not covered, but the schema already documents all parameters thoroughly.
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 adds real value by recommending a specific `actions` value, connecting `offset` to the complete-history pagination strategy, and explaining why this tool is more efficient than the per-card sibling. This goes beyond simply restating field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get activity feed for a Kaiten space.' It then adds a concrete bulk-use pattern and explicitly contrasts the tool with kaiten_get_card_location_history, making it easy for an agent to distinguish this tool from a key sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The uppercase 'EFFICIENT BULK ALTERNATIVE' tells the agent exactly when to choose this tool: to retrieve location history for all cards in a space without per-card calls. It also prescribes the actions filter and offset pagination, giving actionable selection and invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![kaiten-mcp MCP server](https://glama.ai/mcp/servers/ViktorOgnev/kaiten-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ViktorOgnev/kaiten-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/ViktorOgnev/kaiten-mcp'

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