cnvs.app

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behavioral traits: format and size limits for data_url, the role of thumb_data_url in previews. It does not cover error handling or full response, but provides essential transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two focused sentences: first states core function, second provides critical constraints and recommendation. No extraneous content, front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (10 parameters, no output schema), the description covers key aspects: function, format limits, and thumbnail recommendation. Missing details like return value or error conditions, but adequate for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 10%. The description adds meaning to data_url and thumb_data_url, and explains x, y, width, height by context. However, several parameters (id, author, access_key) lack description in the tool description, relying on schema for access_key.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool places a raster or SVG image on a board at specific coordinates with dimensions. It distinguishes from siblings by focusing on image placement and specifying accepted formats (data URI only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit constraints: data_url must be a data URI with specific formats and size limit, and recommends a thumb_data_url for visibility. It implies when to use this tool (for placing images) but does not explicitly mention alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses the rendered form (clickable pill) and coordinate rules, but lacks details like URL validation, truncation, or what happens on click. Some insight but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earned: first states purpose and behavior, second gives usage guidance and coordinate context. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters (4 required) and no output schema, the description misses parameter details and return information (e.g., node ID). It covers purpose and usage well but lacks completeness for the tool's full specification.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 17%; the description adds minimal parameter meaning beyond the schema. It implies `url` is the link content and mentions coordinate rules, but does not explain `board_id`, `author`, or `access_key` usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Drop a URL capsule onto the board' and describes the visual result ('rendered as a clickable pill showing the hostname'). It distinguishes from `add_text` by specifying that this tool is for links only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this instead of `add_text` when the node is just a link' and notes the same coordinate rules, providing clear when-to-use guidance and an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description fully discloses behavioral traits: coordinate system (y down), default width auto-fit, character limit, Mermaid restrictions, rendering details for postit/diagram, and id stability. No contradictions with annotations since none provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and well-structured, covering all necessary details. While it is relatively long, every sentence adds value, though some minor redundancy could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides complete context for an AI agent: purpose, parameter semantics, constraints, and best practices. It covers all aspects needed to invoke the tool correctly, even without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema, explaining x/y coordinates as board-world pixels, content markup support, width auto-fit range, and rendering differences for postit/diagram. It compensates for the 55% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool creates new text nodes or updates existing ones, distinguishing it from sibling tools like add_image or add_link. It provides specific behavior for Mermaid diagrams and sticky notes, making purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear guidelines on when to use (create vs update via id), when to avoid (mixing prose with Mermaid in same node), and recommends checking get_preview to avoid overlaps. It also explains mutual exclusivity of postit and diagram.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that it generates a stable column id, default values for sort, lane, and color, and the behavior of optional parameters. It does not mention error cases or side effects, but for a creation tool, the disclosed behavior is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with no redundant sentences. It front-loads the main action and systematically explains parameters and their defaults, plus a pointer to the sibling tool. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, 2 required, and no output schema, the description is fairly complete. It covers purpose, parameters, defaults, and alternatives. It lacks explicit mention that board_id must reference an existing board, but that is implied. Return format is partially described ('stable column id'). Overall adequate for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 71%, and the description adds meaning beyond schema: it explains sort as ascending, lane as multi-row layout, color options including 'auto', and access_key usage. The two undocumented parameters (title, board_id) are obvious from context, and the description adds board type context ('todo' board).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'Add' and resource 'kanban column (swimlane) to a 'todo' board'. It clearly differentiates from siblings like update_column by mentioning use cases for modification. 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: use this to add a column, and for renaming/reordering/etc., use update_column. It implicitly states when not to use this (for modifications) but does not address prerequisites like board existence or locked boards, though the access_key parameter hints at that.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 transparency. It discloses that it generates and returns a stable task id, and explains the meaning of parameters. However, it does not detail side effects, error conditions, or authorization requirements (e.g., what happens if board_id is invalid). The mention of access_key in params is not integrated into the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with 5 sentences, front-loading the purpose. Every sentence adds value: purpose, return value, and parameter explanations. No redundant or wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 11 parameters and no output schema, the description covers the return value (stable task id) and explains most parameters' semantics. Missing details on done, author, access_key, and error conditions are gaps. For a creation tool, it is fairly complete but could include expected behavior on failure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 55% schema description coverage, the description adds significant meaning beyond the schema for key parameters: column_id (must reference existing column), description (free-form prose), priority (H/M/L), due_date (ISO 8601), assignee (free text), sort (float ordering key, default 0). This compensates for the moderate schema coverage. However, parameters like done, author, and access_key are not explained in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a task (card) in a column on a 'todo' board, with specific verbs and resources. However, it does not differentiate from the sibling tool 'create_tasks' (plural), which might create multiple tasks. The reference to 'list_tasks' for column_id provides some context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that column_id must reference an existing column and refers to list_tasks, giving limited usage guidance. It does not specify when to use this tool vs alternatives like update_task or delete_task, nor does it state prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses non-transactional behavior, stopping on first invalid item, and returns array of created ids, but does not mention the 'author' or 'access_key' parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense paragraph. It is concise and well-structured, though it could be slightly more organized with bullet points, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters, 2 required, and no output schema, the description covers bulk behavior, error handling, and return values adequately. It omits mention of the 'author' and 'access_key' parameters but they are defined in the schema, so completeness is good.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%. The description adds value by explaining the 'tasks' array structure and fields, and the return value/error behavior. However, it does not elaborate on the 'author' and 'access_key' parameters beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Bulk-create multiple task cards in one call' which is a specific verb and resource, and it distinguishes from sibling 'create_task' by highlighting cost efficiency.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'far cheaper than calling `create_task` N times' and explains non-transactional behavior, providing clear context for when to use this tool over alternatives, though it does not explicitly list 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the burden. It discloses that tasks are removed with the column, which is crucial destructive behavior. However, it does not mention authentication requirements or error states, and the access_key parameter's role is not explained in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action, no extraneous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool, the description covers primary effect and side effect. However, it omits return value, error conditions, and prerequisites like board existence or permission. The access_key parameter is also not addressed in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (33%). The description does not add meaning to the id and board_id parameters; it only repeats the schema's access_key description implicitly. Without further explanation, the agent must infer parameter roles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete a kanban column by id') and the resource. It distinguishes from siblings as it is the only delete-column tool. The side effect of removing tasks is also mentioned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a hint on obtaining the id ('Get the id from list_tasks'), but does not specify when to use this tool versus alternatives like update_column or delete_task. 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description only states 'delete' without disclosing side effects (e.g., cascading deletions, irreversibility) or requirements (e.g., authentication, rate limits). 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short (one sentence plus tip), which is concise but at the cost of completeness. No structural issues, but could include more details without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Incomplete given 3 params, no annotations, no output schema. Lacks details on error handling, permissions, and what happens on success. Among many siblings, a deletion tool should warn about irreversibility.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 33% (only access_key described). The description does not explain 'id' or 'board_id' beyond implying id comes from list_tasks. Fails to compensate for missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the action ('Delete a task (card) by id') and resource. Distinguishes from siblings like create_task or list_tasks by specifying deletion. However, it omits that board_id is also required, which could lead to confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a single tip ('Get the id from list_tasks') but lacks explicit guidance on when to use vs alternatives (e.g., update_task) or prerequisites (e.g., permissions, irreversibility).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses fixed stroke width, color acceptance, three point formats with serialization caveats, and return of an id for later deletion—comprehensive behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense single paragraph mixes formats, usage, and deletion advice. Could be better structured (e.g., bullet lists) but remains informative without excessive length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers most aspects: point formats, serialization tips, deletion linkage. No output schema but mentions returned id. Misses explicit mention of board context and access key in narrative, but schema covers it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema: explains color as CSS color, details point formats and recommendations. Schema coverage is 33% but description compensates well, though some params (board_id, id) lack narrative.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Draw a freehand stroke on the board' and provides specific use cases (arrows, underlines, etc.), distinguishing it from siblings like add_image, add_text, and erase.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (for arrows, underlines, etc.), recommends preferred point formats for MCP clients, and directs to erase for deletion, providing clear alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the dangerous consequence of using wrong kind (silently targets wrong table). However, it does not mention permissions, idempotency, or output behavior. Still, it is fairly transparent about 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose, critical warning, and usage guidance. No fluff. Front-loaded with the action and essential details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 params, no output schema, and no annotations, the description covers what, how, and common pitfalls. Could mention return value or error handling, but for a delete tool, current coverage is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is low (25%), but description adds significant meaning: explains the enum mapping for kind, tells how to obtain id from get_board, and clarifies access_key role. This compensates for missing schema descriptions for id and board_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it deletes a single item by id, specifying the exact resource and scope. It distinguishes from sibling tools like delete_task and delete_column by focusing on generic items (text, line, image) and warns against bulk operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (delete single item) and how to avoid common mistakes (kind must match). Mentions that there is no bulk tool and suggests looping for multiple deletions. References get_board for obtaining correct id and type.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. States it returns rendered text and same data as REST endpoints, implying read-only nature. However, does not explicitly state lack of side effects or mention any required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose and resource, second explains format details and return value. No unnecessary words, front-loaded with key action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and three parameters, description covers return format, format options, and access_key. Lacks documentation for board_id, but overall adequate for a relatively simple export operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage 67% (board_id lacks description). Description adds value for format (explains markdown vs csv output) and access_key (source and usage), but does not explain board_id's role or how to obtain it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Export', resource 'board's columns + tasks', and output as 'single text document'. Specifies two formats (markdown, csv) and references REST endpoints, distinguishing from sibling tools like list_tasks or query_tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when needing a formatted text document of board contents, but does not explicitly state when to prefer this over alternatives like list_tasks or get_board. No mention of when not to use or prerequisites like board existence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses image behavior: heavy base64 elided to null, tiny images inlined. Also explains the structure of the returned state. Lacks explicit read-only hint, but overall adds significant 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is front-loaded with purpose, followed by details and usage guidance. Every sentence adds value, though slightly longer than necessary. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of the returned data and no output schema, description adequately lists the elements and their fields, mentions truncation for images, and references usage context. Could include more on nesting, but sufficient overall.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 2 params with 50% description coverage. Description adds meaning for access_key (6-char key, when to omit, how to obtain). Does not describe board_id beyond its existence. Partially compensates for coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool returns 'Full structured JSON state of a board' and lists the types of elements (texts, strokes, images) with their fields. It distinguishes from sibling tool get_preview by noting its purpose for exact coordinates versus layout reasoning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use this for EXACT ids/coordinates/content (needed for `move`, `erase`, editing a text by id).' And when not to: 'For visual layout... call `get_preview` instead.' Provides clear alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Although no annotations are provided, the description discloses key behavioral traits such as the output format (both a viewable SVG and raw text) and the fact that AI-authored items have a purple border. It implies a non-destructive read operation, but does not explicitly state read-only. Overall, it adds useful context 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is reasonably concise, containing four sentences that each serve a purpose. It is front-loaded with the key purpose. Slightly verbose due to parenthetical details, but overall well-structured and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema, the description adequately explains what is returned and typical usage scenarios. It covers the render's purpose, size, and visual cues. It could mention error handling or the need for access_key, but the key information is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, with board_id having no schema description and access_key having a schema description. The tool description does not provide additional meaning for either parameter; board_id is implied by context but not explained, and access_key is not mentioned. It fails to compensate for the schema's gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines that it returns a compact schematic SVG render of the board, specifying the output format (image/svg+xml and raw SVG text). It also distinguishes from the sibling tool 'get_board' by noting that for precise text content, one should prefer get_board. The verb 'render' and resource 'board' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'CALL THIS any time you need to understand where things are — before placing new items, before deciding whether the canvas is crowded, before picking a free region.' It also provides a clear exclusion: 'For precise text content prefer get_board.' This guides the agent on when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It discloses that the output is ordered by sort key and that each task includes hot fields plus an opaque content JSON string. This is good but could mention that it returns all tasks (full state) and no pagination. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The first sentence conveys the return structure and ordering; the second gives usage guidance. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and only 2 parameters, the description covers purpose, usage, and return structure well. It guides the agent to use this tool before mutations, which is critical. No missing information for the stated purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any parameters beyond the schema. With only 50% schema description coverage (only access_key has a schema description), the description should compensate for board_id and access_key but fails to do so, adding no value over the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read the full kanban state of a 'todo' board', specifying the return structure { mode, columns, tasks } and ordering. This distinguishes it from sibling tools like query_tasks (which likely filters) and get_board (which may return different data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells when to use: 'Use this to get exact column/task ids before updating, moving or deleting.' This provides clear context and implies alternatives (the update/move/delete tools) for subsequent actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Details coordinate handling per item kind (text/link use top-left, line uses bounding box, image uses top-left). Mentions backward compat default for kind. No annotations, so description carries full burden and does well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with main action, then per-kind behavior, ending with usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all item kinds, coordinate behavior, and usage recommendation. No output schema, but return value not critical for move. Could mention error cases, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning beyond schema for x, y (top-left vs bounding box), id source (get_board), and kind default. Only 33% schema coverage, so description compensates effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Reposition an existing item to a new (x, y) without retyping its content.' Distinguishes from siblings by recommending use over re-creating items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends using move over re-creating an item, explaining benefits. Lacks explicit when-not-to-use but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 describes the core behavior but lacks details on side effects, authorization, error handling, or return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the purpose, the second details key parameters. No wasted words, front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description covers the main functionality but omits the return value and complete parameter semantics. It is adequate but not fully thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 20%, the description adds meaning for column_id and sort (destination column and float order key), but does not explain id, board_id, or access_key. The schema describes access_key mainly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (move a task to a column at a sort position) and identifies it as the kanban drag-and-drop primitive, distinguishing it from sibling tools like 'move' or 'update_task'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly defines the parameters for destination (column_id) and ordering (sort) but does not provide explicit when-to-use or when-not-to-use guidance or compare with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that auto-creation occurs, a canonical ID is resolved, and a summary is returned. No destructive behavior is implied. It could mention idempotency or side effects, but the provided details are sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences, no wasted words. It is front-loaded with the imperative guidance and then provides sequential steps, making it easy for an AI agent to parse and act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description hints at the return value (summary with item counts and authors). It also integrates well with sibling tools by prescribing a sequence. Could mention the summary structure, but it is complete enough for guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 new parameter information beyond what the schema already provides (url_or_id and access_key are already well-described in the schema). Thus, no extra value for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves a board URL/ID, auto-creates if missing, and returns a summary. It distinguishes itself from siblings by being the mandatory first call, explicitly mentioning subsequent tools like get_preview and get_board.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines: 'ALWAYS call this first' and then specifies the follow-up calls (get_preview and get_board) that must be made before editing, with a warning not to skip get_preview. This clearly communicates when and how to use the tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: filters are optional AND, explains each filter's semantics (including overdue logic), return format (boardId, mode, tasks), and ordering. It also notes tasks have same fields as list_tasks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but well-structured, front-loading purpose and examples. It could be slightly more concise or broken into bullet points, but it's efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters, 1 required, and no output schema, the description covers return format, ordering, and field equivalence with list_tasks, providing sufficient context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even with 63% schema coverage, the description adds critical meaning beyond schema: explains AND logic, provides examples, defines overdue, and clarifies access_key usage. This compensates for any schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read tasks from a 'todo' board with server-side filtering' with specific examples like 'what's overdue?' / 'what's assigned to X?'. It distinguishes from sibling tools like list_tasks by emphasizing server-side filtering.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'handy for ... without pulling the whole board', implying list_tasks for unfiltered access. It provides clear context for when to use this tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description fully discloses behavioral traits: mode switching conditions, what counts as real content, side effect of clearing columns when switching to 'draw', auto-seeding of columns in 'todo' mode, and return value format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph with information front-loaded. While not overly verbose, it could be slightly more structured (e.g., bullet points) for easier parsing. Still efficient and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensive description covering all aspects needed to use the tool correctly: preconditions, behavior, side effects, auto-seeding, return value. No output schema, but the description adequately explains the response. References sibling tools for follow-up actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 75% description coverage. The description adds context to the 'mode' enum by explaining its values, details template options beyond the schema, and explains access_key usage. However, 'board_id' is not described in the description, so the score is slightly reduced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool's function: switching a board between freeform whiteboard ('draw') and kanban task board ('todo'). Distinguishes from sibling tools that operate on tasks/columns rather than board mode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when the tool can be used (board empty of real content) and when it cannot. Recommends using task/column tools after switching to 'todo' mode, providing clear alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the clamping behavior ([200, 480]) and hints at mutation, but lacks details on side effects, authorization, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two short sentences, front-loaded with the purpose, then constraints. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the core behavior and a read alternative, but lacks return value info, error conditions, and authorization needs. Adequate for a simple tool but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% (board_id lacks description). The description does not add meaningful detail beyond the schema for width and access_key; the hint about reading colWidth from list_tasks is tangential.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Set the shared kanban column width in pixels'), the resource ('kanban column width'), and context ('for a 'todo' board (all columns share one width)'). It is specific and distinguishes from siblings like update_column, though could explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides guidance on reading the current value via list_tasks and the clamping range, but does not specify when to use this tool versus alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states that the tool sets or clears a title, without mentioning side effects, permissions, reversibility, or error conditions. This is insufficient transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the core action, and includes necessary context without fluff. It is well-structured and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description adequately explains the tool's purpose and parameter usage, given the absence of an output schema. However, it omits return value expectations, error handling, and authentication details beyond what the schema provides, leaving some gaps for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 80% description coverage. The description adds context beyond schema by explaining that the 'lane' index matches column indices and that an empty string clears the title. This provides moderate additional meaning, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set (or clear) the title of a kanban row (lane).' It uses a specific verb-object pair and distinguishes from siblings like 'update_column' and 'create_column' by focusing solely on lane titles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when lanes are used and how they relate to columns, and suggests using 'list_tasks' to read current titles. However, it provides no explicit guidance on when not to use this tool or how to choose between it and similar sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It adequately states it modifies a column (rename, reorder, etc.) but lacks details on side effects (e.g., impact on task order) or authorization needs (access_key not mentioned in description).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states purpose, second gives prerequisites and parameter info. Front-loaded, no fluff, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 8 parameters (63% schema coverage), description should be more complete. It omits board_id entirely and does not clarify what the tool returns. Also, it doesn't address sibling set_column_width for width changes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description adds value for id (source from list_tasks), title, sort, lane, and color as changeable. However, it misses board_id (required) and access_key (parameter descriptions exist). Schema coverage is 63%, so description partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it renames, reorders, recolor, or moves an existing column, using specific verbs and resource. It distinguishes from siblings like create_column (create) and delete_column (delete).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly requires the column id from list_tasks and lists which parameters to pass for changes. However, it does not mention when not to use it, such as for changing column width (use set_column_width).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes the update action and partial field updates but does not detail error handling, return values, or potential side effects. Adequate but could be more transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with action and key usage, no redundant information. Each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 12 parameters and no output schema, the description covers essential usage, required id, alternative tool, and access_key for locked boards. Missing details on error behavior, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 33% schema coverage, the description adds significant value by listing updatable fields and explaining the priority enum and done field. It compensates for the schema gaps, though not all parameters are covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates an existing task by id, and distinguishes it from sibling tool 'move_task' which is for column moves. The verb 'update' and resource 'task' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use 'move_task' for moving between columns, and advises to pass only fields to change. Provides clear context and alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully discloses behavior: debounce after edit burst, timeout clamping and default, return values for success/timeout, cheap chaining. All behavioral traits are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with sections (WHEN, BEHAVIOUR) and front-loaded purpose. Slightly long but every sentence adds value; could be more concise but organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Completeness is high: explains return values, timeout behavior, use case scenario, and parameters. No output schema but description covers what is returned. Addresses sibling differentiation and context signals.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 3 params with 33% description coverage. Description adds meaning for board_id (implied usage), timeout_ms (clamping and default), and access_key (origin and usage). However, not all param details are exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'blocks until the next edit lands on this board, then returns' with specific verb and resource. Distinguishes from siblings by explaining when to use this vs resources/subscribe.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call (if client does not surface notifications) and when not to (prefer resources/subscribe). Describes typical flow with steps and examples.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.