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

With no annotations, the description carries the full burden and does deliver two genuinely useful traits: the 8-tag cap and that changes are not reflected in realtime until the board is refreshed. It does not cover idempotency (behavior if the tag is already attached), what happens when the cap is exceeded, or permission requirements for a mutation.

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 short sentences, zero filler, with the cardinality constraint in parentheses right after the action and the realtime caveat front-loaded before any agent would act.

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?

An output schema exists, so return-value explanation is not needed, and the two most agent-relevant behavioral facts (cap and refresh requirement) are present. Remaining gaps are the failure mode at the limit and ID provenance, which are minor for a simple attach 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 is 0% — all three parameters (board_id, item_id, tag_id) are bare titles. The description clarifies only that the 'item' can be a card or sticky and that a tag_id is involved; it adds no format, ID-source, or scoping guidance for board_id versus item_id, so the coverage gap is unaddressed.

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?

States a specific verb (attach) and resource (tag to an item), plus the affected item types (cards/stickies) and a hard limit of 8 tags. This distinguishes it clearly enough from detach_tag and create_tag by name, though it does not explicitly name an alternative.

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?

Usage is implied by the verb and the cardinality limit, but the description never states when to prefer this tool over detach_tag/get_item_tags, nor any preconditions (e.g., tag must already exist via create_tag, item must exist on the board).

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 the full disclosure burden. It usefully states the batch limit of 20, the expected item shape, and supported types, but it does not mention permissions, atomicity/partial-failure behavior, or other operational constraints for this 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.

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

The description is front-loaded with the core action and limit, then supplies the payload shape and type list without unnecessary prose. The compact JSON example earns its place by clarifying the otherwise undocumented `items` schema.

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 two-parameter bulk-create tool with an output schema, the description provides enough payload detail to invoke it correctly. It is slightly incomplete on `board_id` semantics and operational behavior, but the core invocation requirements are covered.

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 0%, so the description must compensate. It does this well for the complex `items` parameter by showing the entry shape and supported types, though it does not explain the required `board_id` parameter beyond its name.

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 a specific verb and resource ('Create ... items') and adds the bulk scope ('up to 20 items in one call'), which distinguishes it from the singular create_* siblings. It also names the supported item types, making the tool's scope clear 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.

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

The bulk framing and 'up to 20 items in one call' imply when to use this instead of individual creators, but there is no explicit guidance naming alternatives or stating when not to use it. Usage is inferable but not fully spelled out.

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 usefully discloses the destructive safety gate ('Requires confirm=true') and an audit behavior ('ids are logged when confirmed'). However it omits the crucial traits of a destructive bulk operation: irreversibility, permission requirements, behavior on partial failure, and any batch-size or rate limits.

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 short sentences with zero waste; the concurrency scope, the confirm gate, and the logging side effect are all front-loaded and each sentence carries information an agent needs.

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?

An output schema exists, so return values need no explanation, and the confirm/logging details are present. But for a destructive bulk mutation with no annotations and zero schema descriptions, the definition is not complete enough: it lacks reversibility, permission, and partial-failure context an agent needs before firing 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It explains only 'confirm' (must be true); board_id and item_ids – including whether all ids must belong to the given board or any count limit – are undocumented anywhere, so the coverage gap is largely uncompensated.

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?

States a specific verb and resource ('Delete many items concurrently'), which is distinguishable from the single-item sibling delete_item by the word 'many'. It does not name an alternative explicitly, so it stops 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.

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

Usage is only implied by 'many items' – an agent can infer this is for batches rather than single deletes, but there is no explicit statement of when to prefer this over repeated delete_item calls, nor any exclusions or preconditions beyond the confirm flag.

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 the full burden and does well: it discloses that batching is client-side, that field dicts are sent verbatim, and that results are per-item ok/error — signalling partial success/partial failure semantics rather than atomicity. It does not state concurrency limits, ordering, or rate-limit behavior, which matters for a batch mutation.

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?

Front-loaded with the operation and its most important caveat (client-side batch, no REST endpoint), followed by the entry shape. Dense and mostly waste-free, though the docstring-style backtick formatting is heavier than needed for an agent-facing description.

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?

An output schema exists, so return-value detail is not required, yet the description still flags per-item ok/error results. Combined with the endpoint-selection rule for item_type, an agent can invoke this correctly. Missing batch-size limits and concurrency guidance leaves a small gap for a mutation tool with no annotations.

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 0% and `updates` is an untyped array of free-form objects, so the description does the heavy lifting by enumerating the expected entry keys (item_id, optional item_type, plus data/style/position/geometry/parent) and how item_type changes endpoint selection. board_id is left undefined, and there is no guidance on error entry shape, so it falls short of a 5.

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?

States a specific verb and resource (update many items) and immediately scopes it as a client-side batch with no REST bulk endpoint, which distinguishes it from update_item and the create/delete bulk siblings. An agent knows exactly what operation this performs 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.

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

Implied when-to-use is clear (many items at once, and note that update_item exists for singles). It also explains the routing rule between the typed endpoint (when item_type is supplied) and the generic position/parent endpoint, which is genuinely useful selection guidance. No explicit exclusions or caveats about when not to batch, so not a 5.

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 the full burden. It implies the source board is untouched, but says nothing about whether the copy is deep (all items/widgets duplicated), whether new IDs are generated, what permissions are required on the source or target team, 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.

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

A single well-formed sentence with zero filler, front-loaded with the operation. Its brevity is efficient rather than padded, though it verges on under-specification for a mutation tool.

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 copy operation the agent most needs to know what gets duplicated and whether the original is affected; neither is stated. An output schema exists, so return values needn't be described, but with 0% schema coverage and no annotations the description leaves too much unknown.

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 0%, so the description must compensate for all four parameters. It partially does: 'renaming' maps to name and 'moving it to a team' maps to team_id, and the source is implicitly board_id. The description parameter is entirely undocumented, and none of the params are explained in terms of constraints or defaults.

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?

Clear verb+resource pair: 'Copy an existing board', with the additional scope that the copy can be renamed or relocated. It reads distinctly from create_board (new board) and update_board (modify in place), though it never names those siblings explicitly.

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?

No indication of when to choose copy_board over create_board or get_board + manual reconstruction, and no prerequisites or context about permissions. The word 'optionally' hints at default behavior but nothing tells the agent when copying is the right move.

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 for a mutation tool, yet it discloses nothing about side effects, required permissions, failure modes, or how the card interacts with board_id/parent_frame_id. It only loosely explains three optional fields, which is insufficient behavioral disclosure for a creation operation.

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 purpose statement is front-loaded and the parameter notes are compact with no filler. The double-backtick formatting is slightly noisy, and the terse one-line-per-param style borders on under-specification, but the text is appropriately sized.

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 12-parameter creation tool with zero schema descriptions and no annotations, the description is far too thin; an output schema exists so return values need not be covered, but the input side is largely unexplained. An agent would have to infer the meaning of board_id, coordinates, sizing, and parent_frame_id entirely from parameter names.

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 0%, so the description must compensate, but it only touches 3 of 12 parameters (status, fields, border_shape) and even those only restate the enum values already visible in the schema. Required parameters like board_id, x, y, and title, plus width/height/card_theme/description/parent_frame_id, receive no explanation at all.

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 opens with a specific verb and resource ("Create an app card") and adds a clarifying parenthetical, "widget card linked to an app," which distinguishes it conceptually from a plain card. It stops short of explicitly contrasting with the sibling create_card or update_app_card, so the agent must 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.

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

There is no guidance on when to choose create_app_card over create_card, create_embed, or create_code_widget, all of which exist as siblings. No prerequisites (board membership, permissions) or placement context are stated, leaving the agent to guess 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.

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 says nothing about required permissions/scopes, whether the board starts empty, or what happens when both team_id and project_id are omitted. It adds only the naming clarification about projects having been renamed to spaces.

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 short sentences, front-loaded with the action and followed by the parameter clarification. No filler, though the restructured RST backticks are slightly noisy.

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 mutation tool with no annotations and zero schema description coverage, the description leaves key questions open: default behavior when no team/space is specified, permission requirements, and the undocumented fourth parameter. The explanation of team vs. space is helpful but insufficient on its own.

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 0%, so the description must compensate; it explains what team_id and project_id target and clarifies the deprecated 'projects' terminology, which is genuinely useful. However, the 'description' parameter is never mentioned and the interaction between the two optional IDs is left implicit.

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?

States a specific verb and resource ('Create a new board') in the first sentence, which is unambiguous against siblings like update_board, copy_board, or create_doc. It does not explicitly contrast with copy_board, but the create semantics are clear enough that no confusion is likely.

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?

There is no guidance on when to use this versus copy_board, create_doc, or other creation tools, and no stated prerequisites. The second sentence only explains parameter targeting, not usage conditions or exclusions.

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 the full burden and does so well: it discloses enterprise plan restriction, Discovery access token requirement, board limit, supported formats, asynchronous job ID return, polling requirement, and 14-day result retention.

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 compact and front-loaded: the core action and limit come first, followed by prerequisites, format details, and next steps. Every sentence adds useful information.

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 an output schema exists, the description need not document return values in detail. It still covers the key async lifecycle, prerequisites, formats, limits, and result retention, which is complete for an agent to call this tool correctly.

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 0%, so the description must compensate. It explains the format parameter (SVG default, HTML, PDF) and implies board_ids via the 1000-board limit, but does not explain org_id or provide detail about board_ids contents.

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?

States a specific verb and resource: 'Start a board export job', with scope 'up to 1000 boards'. This clearly distinguishes it from sibling tools like get_board_export_job_status and get_board_export_job_results.

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 the workflow: start the job, poll get_board_export_job_status, then download via get_board_export_job_results. It also states the enterprise-only requirement, giving the agent clear when-to-use context.

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 behavioral burden. It says the tool creates a card but does not disclose side effects, required permissions, validation behavior, or what happens on failure, leaving significant gaps for a mutation tool with 12 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 front-loaded and wastes no words, but it is too terse for a 12-parameter creation tool. Conciseness is achieved at the cost of necessary detail.

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?

An output schema exists, so return values need not be explained. However, with no annotations and zero schema description coverage, the description is incomplete: it does not explain required spatial parameters, positioning semantics, or how this differs from sibling creation tools.

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 0%, so the schema alone provides no parameter meaning. The description explains only due_date formatting; the other 11 parameters, including required fields like board_id, title, x, and y, are undocumented.

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 a specific verb and resource: create a card. It does not differentiate this from sibling tools such as create_app_card, create_sticky_note, or create_frame, leaving ambiguity about which creation tool to choose.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only extra detail is the due_date format, which is parameter semantics 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.

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 discloses that the widget is experimental and syntax-highlighted, but says nothing about permissions, coordinate system, reversibility, default sizing, or whether language is auto-detected from the code.

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 terse lines with no filler and the purpose is front-loaded. However, the brevity reflects under-specification rather than disciplined conciseness, and the standalone 'EXPERIMENTAL.' line is vague rather than 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?

An output schema exists so return values need not be explained, but for a 10-parameter creation mutation with no annotations and 0% schema description coverage, the description omits essential calling context: coordinate space, parent frame behavior, and permission requirements.

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 0% across 10 parameters, so every parameter relies on title alone. The description adds no meaning for x/y positioning, board_id, parent_frame_id, width/height, language, line_numbers_visible, or optional defaults, leaving all semantics undocumented.

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 names a specific verb and resource ('Create a code widget') and the parenthetical clarifies the artifact ('syntax-highlighted code block'). It does not explicitly distinguish itself from siblings like update_code_widget or list_code_widgets, but the 'create' verb and resource name make the distinction inferable.

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?

There is no guidance on when to use this versus create_text, create_card, or create_embed, and no stated prerequisites such as required board membership or permissions. 'EXPERIMENTAL' is a warning flag, not usage 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 the full behavioral burden. It reveals that captions and stroke caps/styles are configurable, but never states that this mutates board state, whether the operation fails if items are on different boards or missing, or whether the connector is deletable/reversible — all material 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.

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

Two sentences, front-loaded with the core action before the optional-styling notes, with no filler. The reST-style double backticks and embedded example syntax are slightly noisy but do not obscure meaning.

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?

An output schema exists so return values needn't be explained, but for a 12-parameter, unannotated creation tool the description is thin: it omits prerequisites (valid board_id, both items existing), the color/stroke field distinctions, and any failure or side-effect behavior. An agent would have to guess at several required-to-styling choices.

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 0% across 12 parameters, so the description must compensate and only partly does: it clarifies caption, end_stroke_cap, and stroke_style. It leaves the ambiguous fields unresolved — notably the distinction between color, stroke_color, and stroke_width, plus font_size and text_orientation — meaning most non-obvious parameters remain undocumented anywhere.

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 opens with a specific verb+resource — 'Connect two items' — which maps cleanly onto create_connector and sets it apart from get/update/delete_connector siblings. It does not explicitly say the items belong to a board or that the result is a connector object, so the object being created is only implied.

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?

There is no statement of when to use this versus update_connector, list_connectors, or the create_shape/create_text siblings that might also draw links. The only conditional language concerns optional styling parameters, not tool selection or prerequisites such as both items needing to exist on the same board.

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 the full behavioral burden. It usefully discloses the key immutability constraint after creation, but it omits other important behavior such as permissions, how x/y positioning works, or how parent_frame_id affects placement.

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 short sentences, front-loaded with the action and followed by the two most important caveats. There is no 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?

For a creation tool with no annotations and a schema that has no parameter descriptions, the description covers the main action and the critical non-editable constraint. It is still incomplete on positioning parameters, parent-frame behavior, and alternatives among creation siblings, though the output schema reduces the need to describe return values.

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 0%, so the description should explain the six parameters. It only restates content_type values that are already in the enum schema and says nothing about board_id, content, x, y, or parent_frame_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 gives a specific verb and resource: 'Create a doc format item on the board.' It also points to replace_doc for editing, which helps separate creation from replacement. However, it does not distinguish this creation path from sibling creation tools such as create_document_from_url or upload_document.

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 note 'Docs cannot be edited via REST after creation — see replace_doc' gives a clear edit-time alternative, implying create_doc is for initial creation and replace_doc for later changes. But it does not state when to use this tool versus create_document_from_url, upload_document, or other creation siblings.

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 does not say whether the server fetches the URL, whether the URL must be publicly reachable or authenticated, whether the call blocks until the file is processed, or what limits apply to file types and sizes.

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?

One short, front-loaded sentence with no waste. However, the brevity reflects under-specification rather than disciplined compression.

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 output schema covers return values, but for a write operation with no annotations and zero parameter documentation, the description leaves too much unknown: URL fetch semantics, placement behavior, and the difference from sibling creation tools.

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 0% across 6 parameters, and the description only gestures at the URL and the board. Required x/y positioning, the optional title override, and parent_frame_id placement are entirely undocumented.

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?

Names a specific verb+resource: adding a document item (PDF, etc.) to a board, sourced from a URL. This distinguishes it reasonably from create_image_from_url, but it does not differentiate from near-neighbours like create_doc, upload_document, or update_document.

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?

There is no guidance on when to use this rather than upload_document (local file) or create_doc. An agent must guess from the name that the URL-based variant is the right one.

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 the full burden and does not disclose whether the URL must be oEmbed/embed-compatible, what permissions are needed, or what happens on unsupported URLs. It only restates the mode enum 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?

Two short sentences, front-loaded with the core action. Nothing wasted, though the mode clarification is placed without context on why the choice matters.

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?

An output schema exists, so return values needn't be explained, but a 13-parameter creation tool with no annotations and zero schema descriptions warrants far more than a one-line description. The agent has almost no basis for filling in required x/y/board_id semantics or optional sizing/metadata fields.

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 0% across 13 parameters, and the description only explains the 'mode' enum (inline vs modal). Positional parameters (x, y), sizing (width, height), and oEmbed metadata fields (provider_url, preview_url, parent_frame_id) remain entirely unexplained.

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?

States a specific verb and resource ('Create an embed item from a URL'), which is clearly distinguishable from siblings like create_card or create_image_from_url. However it does not acknowledge the closely related update_embed sibling.

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?

No guidance on when to use this tool versus alternatives such as create_document_from_url, create_image_from_url, or update_embed for existing embeds. The only guidance-like text concerns the mode values, not tool selection.

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 the full behavioral burden. It adds limited context about show_content hiding/shows children and format accepting custom, but does not disclose permissions, side effects, whether the frame is empty or mutable, or other mutation behavior.

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 very short, front-loaded, and free of filler. However, it is arguably too terse for a 9-parameter mutation tool, and the backtick formatting is slightly noisy.

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 creation tool with 9 parameters, no annotations, and 0% schema description coverage, the description is not complete enough. It covers only a couple of behavioral details and omits most parameter semantics and side-effect context; an output schema does exist, so return values need not be explained.

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 0% across 9 parameters. The description explains show_content, format, and a default frame type, but leaves board_id, x, y, title, width, height, and fill_color without added meaning. The mention of frame 'type' is also not present in the input 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 a specific verb and resource: 'Create a frame.' It is clear what the tool does, but it does not distinguish frames from sibling creation tools like create_shape, create_card, or create_group.

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?

There is no explicit guidance on when to use create_frame versus alternatives, nor any prerequisites or exclusions. Usage is only implied by the verb 'Create.'

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 says only that items are grouped, without disclosing permissions required, whether the operation is reversible, what happens to existing group membership, or whether board_id must identify an existing board.

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 short, front-loaded, and free of filler. Its second sentence earns its place by clarifying item_ids, though the overall structure is extremely terse for a mutation tool.

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 tool has two required parameters and no annotations, with 0% schema description coverage. Although an output schema exists and need not be explained, the description is incomplete regarding board_id, permissions, and grouping behavior.

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 0%, so the description must compensate for the undocumented parameters. It clarifies item_ids minimally as 'the items to group,' but does not explain board_id at all, leaving one of two required parameters without added meaning.

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 a clear action, 'Group items together,' which makes the purpose understandable. However, it does not differentiate this create operation from sibling tools such as update_group, ungroup, or get_group_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?

The description provides no guidance on when to use create_group versus alternatives like update_group or ungroup. It also omits prerequisites, such as whether items must be ungrouped before being grouped.

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 behavioral burden, yet it only implies a write operation. It says nothing about whether the source URL is fetched server-side, what happens if the URL is unreachable or non-image, what permissions are needed, or whether board_id must reference an existing board.

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?

One short, front-loaded sentence with no filler. It is efficient but so terse that the brevity borders on under-specification.

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?

An output schema exists so return values need not be explained, but a 7-parameter mutation tool with no annotations and zero schema descriptions leaves out essentials: coordinate semantics, board/frame targeting, and failure behavior for the URL.

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 0% across 7 parameters. The description only gestures at 'url' and says nothing about board_id, required x/y coordinates, optional width/title, or parent_frame_id, all of which risk misplacement or errors if used wrongly.

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?

States a concrete verb+resource (create an image item) and adds a scoping qualifier ('from a public URL') that hints at the difference from upload_image, but never names that sibling explicitly. An agent can infer the purpose, though it must compare schemas to be sure.

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?

No guidance on when to use this versus upload_image or update_image, and no prerequisites (board must exist, URL must be publicly reachable). Usage must be inferred 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.

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 does add the material disclosure that the endpoint is EXPERIMENTAL, which is valuable and non-obvious. Beyond that it omits required scopes, whether a root node is auto-created, and what errors arise if board_id or parent_node_id are invalid – gaps that matter for a write operation with zero annotation coverage.

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 short sentences with the action and the EXPERIMENTAL caveat front-loaded, no repetition. The second sentence's line break is cosmetic waste but the content density is high.

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?

An output schema exists, so return values need not be described, and the parent/root distinction covers the central call decision. For an experimental mutation tool with 0% parameter documentation, however, the description does not give enough to invoke it confidently – coordinate behavior for x/y/width and required permissions are unaddressed.

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 0% and there are 6 parameters, so the description must compensate and mostly does not. It explains only parent_node_id semantics; content, board_id, x, y, and width remain bare schema titles with no format, units, coordinate system, or width constraints given.

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?

States a specific verb and resource ('Create a mind map node (text type)') and names the node subtype, which separates it from create_text and create_sticky_note. It stops short of comparing itself to those siblings explicitly, so an agent must infer that mind-map nodes are a distinct item class.

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 the one meaningful branch in usage – supplying parent_node_id vs. omitting it to extend the root structure – which is real guidance. It never says when to choose this over create_text/create_sticky_note, nor what preconditions (existing mind map, board state) apply, leaving usage largely implied.

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 at all, the description carries the full behavioral burden and discloses almost nothing: no mention of required board permissions, no statement of what defaults apply (width/height/font_size null), no note that `content` becomes text inside the shape, and no indication of what the call returns. Only the shape vocabulary and hex color format are conveyed.

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?

Front-loaded with the one-line purpose, followed by two compact factual notes on shape values and color format. The long enumerations occupy space but carry real information; little is wasted, though the shape list could have been compressed.

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 15-parameter mutation tool with zero annotations, the description covers only two parameters and omits permissions, defaults, coordinate semantics, and the fill/border color split. The presence of an output schema covers return values, but the input-side gaps are substantial.

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 0% across 15 parameters, so the description must compensate and only partly does: it defines the `shape` enum values and that `color` is a hex string. It leaves the critically ambiguous `color` vs `fill_color` vs `border_color` distinction unexplained, and says nothing about x/y units, width/height defaults, font_size, text_align, border_*, or parent_frame_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?

States a specific verb+resource ("Create a shape") and enumerates the 22 accepted shape values, which lets an agent tell it apart from the sibling update_shape without opening either schema. It does not explicitly name the alternatives (create_sticky_note, create_text, create_frame) that also produce board objects.

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?

There is no guidance on when to use this versus create_sticky_note, create_text, create_frame, or the bulk item tools, and no note that board_id/x/y are mandatory with the rest defaulting. The agent is left to infer that x/y are board coordinates and that shapes are positioned objects.

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 behavioral burden for a mutation tool. It mentions HTML support in content and the fill_color palette, but does not disclose permissions, side effects, whether the board must exist, how x/y positioning behaves, or what happens with parent_frame_id.

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 and front-loads the purpose, and the two parameter notes are specific. However, it is too sparse for a 10-parameter creation tool and omits information that would make the short text more useful.

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 tool has 10 parameters, no annotations, and an output schema, but the description only covers two parameters and does not address mutation behavior or placement semantics. It is not complete enough for an agent to invoke the tool confidently without inspecting the 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?

Schema description coverage is 0%, so the description must compensate, but it only explains content and fill_color. It does not explain required parameters such as board_id, x, y, or optional parameters such as shape, width, text_align, text_align_vertical, and parent_frame_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 first sentence states a clear verb and resource: 'Create a sticky note.' This is enough to distinguish it from update_sticky_note and from generic item creators such as create_shape or create_text, although the description does not explicitly call out those sibling boundaries.

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 no guidance on when to use this tool versus create_text, create_shape, create_card, or bulk_create_items. It also omits prerequisites such as needing an existing board and where on the board the note should be placed.

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 disclosure burden. It does add one genuinely useful behavioral detail: fill_color is "required by Miro" despite the schema showing a default and marking it optional, plus the full set of accepted values. It says nothing about permissions, duplicate-title behavior, or whether the tag is board-scoped.

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 short sentences with no filler, and the core action is front-loaded before the color detail. The long inline color list is defensible as it replaces a missing enum, though it makes the sentence slightly unwieldy.

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?

An output schema exists so return values need not be described. The color constraint is well covered, but for a three-parameter creation tool with zero schema descriptions, the absence of any statement about board scoping, prerequisites, or duplicate handling leaves meaningful gaps.

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 0%, so the description must compensate. It thoroughly defines fill_color (enumeration plus the Miro-side requirement) but leaves title and board_id completely unexplained beyond their names, so only one of three parameters is enriched.

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?

States a specific verb and resource ("Create a tag") in the first two words, so an agent immediately knows the operation. It does not explicitly distinguish itself from update_tag, delete_tag, or attach_tag, but the create verb makes the distinction largely self-evident.

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?

There is no guidance on when to call this versus the sibling tag tools, no note that a board_id is needed to scope the tag, and no mention of what to do if a tag with that title already exists. The agent must infer all usage context.

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 behavioral burden and does not meet it. It says nothing about required positioning behavior (x/y are mandatory), what happens when parent_frame_id is set versus omitted, whether the item is auto-sized to content, default styling applied, or what permissions are needed 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.

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

Two short, front-loaded sentences with no filler. The brevity is appropriate structurally, though in this case it reflects under-specification rather than discipline, which is penalized in other dimensions.

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 mutation tool with 11 undocumented parameters, zero annotation coverage, and no parameter descriptions, two sentences are far too thin. An output schema exists so return values need not be explained, but the spatial/style parameters and the frame-versus-standalone distinction should have been covered.

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 0% across 11 parameters, and the description only clarifies that content accepts simple HTML. It leaves unexplained the semantics of x/y coordinate space, units and defaults for font_size, rotation, and width, the color format, and the relationship between standalone placement and parent_frame_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?

States a specific verb and resource ("Create a standalone text item"), with "standalone" hinting at independence from other items. However, it never distinguishes this from sibling creators like create_sticky_note or create_card, which also create free-placed text-bearing items on a 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?

No indication of when to choose create_text over create_sticky_note, create_card, or create_doc, nor any prerequisites such as required board access or coordinate space. The only guidance is the implicit "standalone" in the first sentence, which is not enough to route an agent among several near-identical creators.

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 must carry the behavioral load. It does disclose the two most important traits of a mutation: the deletion is permanent (irreversible) and gated behind confirm=true. It says nothing about permissions required, cascade effects on contained items, 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.

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

Two short sentences, zero waste, with the destructive nature front-loaded and the confirmation requirement immediately following.

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?

An output schema exists so return values need no explanation, and the required confirm gate is covered. However, for a permanent board deletion the description omits whether child items are removed, who may perform it, and whether it can be undone — material gaps for an agent deciding to call 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?

Schema description coverage is 0%, so the description must compensate. It adds real meaning for `confirm` (must be true, despite defaulting to false in the schema), but leaves `board_id` entirely unelaborated. Partial compensation for two parameters.

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?

Names a specific verb and resource ('Delete a board') and adds the scope qualifier 'permanently'. It reads distinctly from sibling operations like delete_item or delete_doc via the resource name, though it does not explicitly distinguish itself from those siblings in prose.

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 when to use it (to remove a board) and gives one hard prerequisite ('Requires confirm=true'), but offers no when-not-to-use guidance, no mention of alternatives like archiving, and no preconditions about board contents.

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 behavioral burden. Disclosing the confirm=true safety gate is genuinely useful, but for a destructive operation it says nothing about irreversibility, cascade effects on anything referencing the connector, required scopes, or failure modes. An output schema exists, but that does not cover the destructive semantics.

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 short sentences, zero padding, with the destructive action front-loaded before the precondition. It is efficient but borders on under-specified rather than wasteful.

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, unannotated tool with 0% schema coverage and two undocumented identifiers, the description is too thin. Output schema coverage means return values needn't be explained, but the safety and scoping context an agent needs before deleting a connector is missing.

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 0% – all three parameters have only titles. The description adds meaning for exactly one parameter (confirm must be true), while board_id and connector_id remain undocumented in both the schema and 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?

States a specific verb and resource: 'Delete a connector'. This clearly separates it from get_connector, create_connector and update_connector in the sibling list, though it never explicitly names those alternatives or the scope of what a connector is.

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 only guidance is the mechanical precondition 'Requires confirm=true'. There is no statement of when to delete versus update or re-create, no warning about what happens to dependent content, and no note on permissions or 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?

No annotations are supplied, so the description carries the full burden. It does disclose one genuinely behavioral fact beyond the schema: the operation is gated on an explicit confirmation flag. It does not say whether deletion is irreversible, what permissions are needed, or what the response contains, leaving the destructive-mutation risk largely unexplained.

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 short sentences, front-loaded with the action, no filler. The doubled backticks around confirm are cosmetic noise but do not bloat the 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?

An output schema exists, so return values need not be described. But for a destructive mutation with zero annotations and 0% parameter documentation, the description omits permissions, irreversibility, and the meaning of the two required ID parameters — significant gaps an agent would need before calling it safely.

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 0%, so the description should compensate. It documents only confirm (and only that it is required to be true), while board_id and item_id — both required — get no explanation of what they identify or how they interact (e.g. whether item_id must belong to 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?

States a specific verb and resource ("Delete a doc format item"), which is better than a bare name restatement. But the doc/board item distinction is left unexplained while siblings delete_item, bulk_delete_items, and delete_board exist, so an agent cannot tell from this line alone what makes a "doc format item" different from a plain item.

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 only usage-like statement is "Requires confirm=true", which is a precondition rather than guidance. Nothing says when to pick delete_doc instead of delete_item or bulk_delete_items, nor what happens if the item is not a doc.

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 the full behavioral burden. It usefully discloses the confirm=true gate and that the item id is logged, which goes beyond the schema, but it omits critical destructive-action details such as irreversibility, cascading effects on child items, permission requirements, and what happens when confirm is false or omitted. These gaps are significant for a delete tool with zero annotation coverage.

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 short sentences, front-loaded with the operation and followed by the critical confirm and logging details. Every sentence earns its place with no repetition or filler.

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 output schema covers return values, and the description covers the confirm gate and logging. However, for a destructive mutation with no annotations, it should disclose irreversibility, failure modes, and permission requirements to be 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 0%, so the description must compensate for three parameters. It explains the confirm parameter's required value and references item_id in the logging behavior, but board_id is entirely unexplained and item_id's role is only indirectly implied. It adds partial meaning but leaves a real 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?

The description states a specific verb and resource: 'Delete any single item.' The word 'single' implicitly distinguishes it from the bulk_delete_items sibling, though no sibling is named explicitly. An agent can determine the core operation 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.

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

Usage is implied by 'single item' (as opposed to bulk deletion) and the confirm=true requirement, but there is no explicit when-to-use guidance, no named alternative, and no statement of when not to use it. An agent must infer that bulk_delete_items handles multi-item cases.

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 does disclose the destructive nature, the confirm guard, and the experimental stability status, but leaves the most important behavioral question unanswered: whether deleting a node also removes its subtree, and 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.

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

Three short sentences, correctly front-loaded with the action before the caveats. The bare "EXPERIMENTAL" token is unqualified, but there is no filler or repetition.

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 mutation with no annotations and 0% schema coverage, this is thin: cascade/child behavior, irreversibility, and the identities of board_id and item_id are all missing. An output schema exists, so return values need not be described, but the input-side gaps remain large.

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 0% across 3 parameters. The description clarifies the semantics of confirm (must be set true to proceed, beyond the schema's default=false) but says nothing about board_id or item_id, leaving two required parameters with no explanation anywhere.

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?

States a specific verb and resource ("Delete a mind map node"), which is unambiguous against the many other delete_* siblings such as delete_item or delete_board. It does not explicitly name alternatives, but the resource name is distinctive enough that an agent can route correctly.

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?

Gives one hard precondition ("Requires confirm=true") and an EXPERIMENTAL warning, which is real usage guidance. It never says when to prefer this over delete_item or what happens to sibling/child nodes, so the when-not side is entirely absent.

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 the full burden, and it does disclose one concrete behavioral fact: the operation requires confirm=true. It says nothing about irreversibility, whether the tag is stripped from every item that carries it, or what permissions are needed.

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 short sentences, zero padding, with the core action front-loaded and the hard requirement placed immediately after it.

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?

An output schema exists, so return values need not be described. However, for a destructive operation with no annotations and no parameter descriptions in the schema, the blast radius of the deletion and permission requirements are gaps an agent would want closed.

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 0%, so the description must compensate. It explains the semantics of the non-obvious parameter (confirm=true as a required gate, matching the schema default of false) but leaves board_id and tag_id to be inferred from their names.

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?

States a specific verb and resource ('Delete a tag') plus a scoping constraint ('from the board'), which separates it from item-level tag tools in the sibling list. It does not explicitly name detach_tag as the non-destructive alternative, so the distinction is inferable rather than stated.

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?

Usage is only implied by the verb: 'delete' contrasts with detach_tag's remove-from-item semantics, but the description never says when to prefer one over the other. No preconditions beyond the confirm flag are mentioned.

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 burden. It does disclose a meaningful behavioral trait: that confirm=true is required, which the schema does not state (confirm is optional, default false). But it omits permissions, reversibility, and what happens if confirm is false, leaving real 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.

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

Two short sentences, front-loaded with the action and followed by the precondition. No filler, though it is arguably too terse given the undocumented parameters.

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 4-parameter mutation with no annotations and 0% schema coverage, the description is under-specified. The existing output schema covers return values, but board/item/tag parameter meaning, permission requirements, and failure behavior are left unaddressed.

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 0%, so the description must compensate. It implicitly covers tag_id and item_id ('a tag from an item') and the confirm requirement, but board_id is never mentioned and none of the id parameters get format or scoping meaning.

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?

States a specific verb+resource: 'Remove a tag from an item.' It clearly implies a distinction from sibling attach_tag (add) and delete_tag (delete the tag itself), so an agent can differentiate without opening schemas. It doesn't explicitly name those siblings, keeping it at 4 rather than 5.

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 'Requires confirm=true' note gives a concrete precondition for invocation, which is useful. However, it offers no explicit when-to-use/when-not guidance versus attach_tag, delete_tag, or get_item_tags, so the selection logic is only implied by the verb.

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 behavioral burden. It implies a safe read by saying 'Get' and listing returned fields, but it does not mention permissions, failure behavior, or other access constraints.

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 front-loaded sentence with no filler. It states the operation, scope, and returned fields efficiently.

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 tool is simple, has one required parameter, and has an output schema, so the description does not need to explain return structure. However, with no annotations and no schema parameter descriptions, it is only minimally complete for actually calling the tool correctly.

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 0%, so the description should compensate for the undocumented board_id parameter. It only says 'one board' and does not explain where board_id comes from, its format, or any constraints.

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 gives a specific verb and resource: 'Get full details of one board.' It also lists representative fields, which helps distinguish it from list/thumbnail-oriented siblings, though it does not explicitly name an alternative.

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?

Usage is only implied: callers should use it when they need full details for a single board. It does not explicitly say when to prefer this over list_boards, get_board_thumbnail, or other board-related siblings.

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 must carry the behavioral burden. It usefully discloses the Enterprise plan and Discovery token requirement, but does not say what happens if the job is not finished, whether links expire, or other operational constraints.

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 short sentences, front-loaded with the core action and followed by the key access constraint. There is no 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?

The tool is simple and has an output schema, so return values need not be explained. However, the missing parameter guidance is a real gap for an agent needing to call it correctly.

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 0%, so the description should explain job_id and org_id. It mentions neither parameter nor where their values come from, leaving the required inputs undocumented beyond their names.

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?

States a specific verb and resource: 'Get the download links of a finished board export job.' This distinguishes it from siblings such as list_board_export_jobs, create_board_export_job, and get_board_export_job_status.

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?

Makes clear this applies only to a finished export job and requires an Enterprise plan plus a Discovery access token. It does not explicitly say to use get_board_export_job_status first, but the 'finished' condition gives clear usage context.

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 present, the description carries the full burden. It usefully discloses an enterprise-only gate and an auth requirement, but says nothing about whether this is a read-only poll, whether repeated calls are expected, throttling, or what status values are returned — materially incomplete for an operation whose whole purpose is polling.

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 short sentences, front-loaded with the purpose and followed by the eligibility constraint. Nothing redundant, nothing padded.

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?

An output schema exists, so return values needn't be described. But with zero annotation coverage, 0% parameter documentation, and no guidance on how the job_id is obtained or how to poll, the definition is only minimally sufficient 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?

Schema description coverage is 0% for both required parameters. The description does not explain job_id (presumably from create_board_export_job) or org_id (organization scope/format), so an agent gets no meaning beyond the bare parameter names.

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?

States a specific verb and resource — get the status of a board export job — which is unambiguous and separable from get_board_export_job_results and list_board_export_jobs by the noun 'status'. It does not explicitly name those siblings, so differentiation is inferred from the resource name rather than stated.

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 supplies a hard eligibility constraint (enterprise plan plus a Discovery access token), which is a real usage prerequisite. However, it never says when to call this versus get_board_export_job_results (fetching output) or list_board_export_jobs (discovering the job_id), and gives no hint about polling behavior.

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 behavioral burden. 'Get' implies a read operation, but the description does not state required permissions, failure behavior, side effects, or rate limits; the output schema covers return values but not operational traits.

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 front-loaded sentence with no wasted text. However, it is terse to the point of under-specification for a tool with two required identifiers.

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 presence of an output schema means return values need not be explained in detail. Still, with no annotations and 0% parameter description coverage, the description is too sparse to explain the required identifiers or access behavior for reliable 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 description coverage is 0%, and both board_id and member_id are required but undocumented beyond their names and string types. The description mentions role and type, which appear to be output fields, without explaining either required parameter.

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 a specific verb and resource: get one board member. The word 'one' implicitly distinguishes it from list_board_members, but it does not explicitly route against sibling tools such as update_board_member or remove_board_member.

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?

There is no guidance on when to use this tool versus alternatives such as list_board_members or get_group. No prerequisites, exclusions, or contextual triggers are provided.

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 the disclosure burden and does well: it explains the tool reads the board's `picture` field and explicitly limits fidelity to a low-resolution preview. It doesn't mention permissions or rate limits, which keeps it from a 5, but the key behavioral caveat (not full fidelity) is front and center.

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 short sentences with zero waste, and the core promise (thumbnail URL, small preview) is front-loaded before the alternative is named. 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?

An output schema exists, so return values needn't be explained. Combined with the fidelity caveat and the pointer to export tools for PDF/SVG, an agent has everything needed to call this correctly for a simple one-parameter getter.

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?

There is one required parameter, `board_id`, and schema description coverage is 0%, so nothing in the schema explains it and the description doesn't mention it either. The parameter is self-evident by name, so this is adequate but not enriched beyond the structured field.

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 a specific verb and resource: 'Get the board's thumbnail image URL.' It also distinguishes itself from the export family by saying it reads the small 'picture' preview rather than a full-fidelity export, so an agent can tell it apart from get_board_export_job_results without opening either schema.

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 gives both when-to-use ('small rendered preview') and when-not-to-use ('For PDF/SVG use the Enterprise export job tools'), naming the concrete alternative. Nothing is left to inference about which sibling handles exports.

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 behavioral burden. It discloses only 'EXPERIMENTAL' instability and does not mention read-only behavior, permissions, or error handling for invalid board/item IDs.

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 short, front-loaded sentences with no filler; the EXPERIMENTAL warning is useful and every sentence earns its place. The description is sparse, but it is not padded or repetitive.

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?

An output schema exists, so return values need not be explained. However, for a retrieval tool with no annotations and zero parameter documentation, key call details are missing: which IDs are needed, what a code widget is, and what happens on invalid input.

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 0%, and both required parameters (board_id and item_id) are entirely unmentioned. The description does not clarify what each identifier refers to or how they relate to a code widget.

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?

States a specific verb ('Get') and resource ('one code widget'), making clear this retrieves a single widget rather than listing. The word 'one' implicitly distinguishes it from list_code_widgets, though no sibling is named.

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?

No guidance is given on when to use this versus list_code_widgets, get_item, or other retrieval siblings. Only an implied single-item retrieval context is present, and 'EXPERIMENTAL' does not aid tool selection.

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 disclosure burden. 'Get' implies a read, but it says nothing about permissions, behavior when the connector or board does not exist, or whether deleted connectors are retrievable. An output schema exists, so return values are covered elsewhere, but the operational profile is left blank.

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?

One short sentence, front-loaded with the verb and resource, with the parenthetical scoping the returned data. Nothing is wasted, though the extreme terseness is part of why other dimensions are thin.

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 two-parameter read tool with an output schema and self-describing ID params, the description is minimally sufficient to call it correctly. It is missing the routing information an agent needs to pick it over list_connectors and any note about failure behavior for a bad connector_id.

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 0%, so the description was expected to compensate, yet it mentions neither board_id nor connector_id. The parameter names are largely self-explanatory (both required string IDs), which limits the damage, but no format, scope, or relationship between the two IDs is clarified.

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 gives a specific verb and resource ('Get one connector') and enumerates the returned facets (start/end items, captions, style), which clearly separates it from list_connectors, update_connector, and delete_connector. It stops short of naming any sibling explicitly, but the singular 'one' plus the connector_id requirement makes the scope 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?

There is no statement of when to use this versus list_connectors (to enumerate) or update_connector (to modify), and no prerequisites such as needing a valid board/connector pair. The only guidance is implicit in the word 'one', which requires the agent to infer that it must already know a connector_id.

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 disclosure burden. It mentions the returned content format, but says nothing about permission/auth requirements, behavior for non-doc item IDs, or whether missing items error versus return empty.

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?

A single front-loaded sentence with no filler. It is efficient and every word earns its place, though the terseness leaves obvious gaps that could have been closed in the same sentence.

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 tool is simple (2 required params) and an output schema exists, so return values need no explanation. However, with no annotations and 0% parameter coverage, the definition does not fully equip an agent to disambiguate from get_item or understand the ID formats.

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 0% and the description explains neither board_id nor item_id. The parameter names are largely self-explanatory for a board-scoped retrieval, so the gap is modest, but no syntax, format, or scoping behavior is added.

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?

States a specific verb and resource ("Get a doc format item") and adds that the content is markdown/html, which tells an agent this returns content rather than just metadata. It does not differentiate from the closely named sibling get_item, so an agent must infer which one to call for non-doc 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?

There is no guidance on when to use this versus get_item, get_document, or list_items, and no prerequisites or exclusions. The agent is left to infer the doc-type scoping condition 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.

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

No annotations are provided, so the description carries the full burden, and it does disclose that the response bundles the group's items rather than returning only group metadata. It says nothing about whether that item list is complete or truncated, whether the group must exist, or what identifiers are valid — a meaningful gap given zero annotation coverage.

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?

A single well-formed sentence with the key scope detail front-loaded and no wasted text. It is concise but under-specified rather than tight — brevity here costs information.

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?

An output schema exists, which relieves the need to describe return shape, but with zero annotation coverage and zero parameter documentation the definition leaves an agent guessing on ID sourcing and result scoping. The overlap with get_group_items is also unresolved.

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?

Both parameters (board_id, group_id) have 0% schema description coverage and only bare titles. The description never mentions them, so an agent gets no guidance on ID format, where to obtain a group_id, or whether board_id must be the group's parent 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?

A specific verb plus resource ("Get one group") with an added scope note ("with the items it contains"). It stops short of distinguishing itself from the sibling get_group_items, so an agent could easily confuse the two.

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 no indication of when to use this versus list_groups, get_group_items, or get_board. No prerequisites, no exclusions, no alternative named.

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 does disclose the one genuinely important trait — cursor-based pagination — and 'List' implies a non-mutating read, but it says nothing about result ordering, default page size behavior, or what happens when the cursor is exhausted.

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?

A single front-loaded sentence with no filler; the pagination caveat is placed inline where it is immediately useful. Nothing in the sentence could be removed without losing information.

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?

An output schema exists, so return values need not be described. But for a two-required-identifier tool with 0% schema coverage and no annotations, the description is too thin — it never clarifies the board_id/group_id relationship, page size limits, or iteration workflow.

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 0% — all four parameters have only bare titles. The description's '(cursor-paginated)' hint partially covers the cursor parameter, but board_id, group_id and limit (default 50, presumably a max) are left entirely undocumented, including why board_id is required alongside group_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?

States a specific verb ('List') and a precisely scoped resource ('items that belong to a group'), which implicitly separates it from list_items, get_items_by_tag and search_items. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than declared.

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 group-scoped framing implies when this tool applies, but there is no explicit when-to-use guidance, no mention of when to prefer list_items or get_items_by_tag instead, and no stated prerequisites (e.g. that board_id and group_id must both be known).

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 must carry behavioral load; "Get the full JSON" implies a read-only, non-destructive whole-object fetch, which is useful. It does not disclose permission requirements, behavior on unknown board_id/item_id, or whether output is truncated; an output schema exists so return shape is partly covered elsewhere.

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?

A single front-loaded sentence with the resource first and the payload contents in parentheses; every clause adds information and there is no filler.

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 core contract (fetch one item, full JSON) is present and the output schema covers return values, so nothing essential is missing for a simple lookup. Gaps remain around how an item_id is obtained and error behavior, which matter slightly for a two-required-parameter 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?

Schema description coverage is 0%, so both required parameters (board_id, item_id) are undocumented in the schema, and the description says nothing about them at all. The names are largely self-explanatory, which keeps this above the floor, but the description makes no attempt to compensate for the 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?

States a specific verb ("Get") and resource ("one item") and even enumerates the returned facets (data, style, position, geometry, parent, timestamps), which clearly separates it from list_items/search_items. It does not name a sibling explicitly, but the singular-scope wording does the differentiation work implicitly.

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?

There is no statement of when to use this versus search_items, list_items, or get_items_by_tag, and no prerequisite guidance such as needing an item_id obtained from a list/search call. Usage is only inferable from the verb and the singular object.

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?

There are no annotations, so the description carries the behavioral burden. It discloses offset-based pagination and implies a read-only list operation through the verb 'List', but it does not mention permissions, ordering, or other operational constraints.

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 front-loaded sentence with no filler. It is concise, though that conciseness comes at the cost of useful parameter and usage detail.

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 four-parameter tool with zero schema description coverage and no annotations, the description is too sparse. The output schema covers return values, but the description still leaves board_id and the pagination parameters substantially unexplained.

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 0%, so the description needs to compensate for undocumented parameters. It hints at tag_id and offset/limit via 'given tag' and 'offset-paginated', but says nothing about board_id or the defaults and constraints for limit/offset.

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 a specific verb and resource: it lists items that carry a given tag. That is clear enough to distinguish it from generic list_items/search_items, but it does not explicitly name sibling alternatives or clarify how it differs from get_item_tags.

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 says what the tool does but gives no when-to-use guidance, prerequisites, or alternatives. An agent must infer from the name that this is the right tool when filtering items by tag.

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. 'List' weakly implies a read-only operation, but nothing is said about whether this requires board membership, whether results are paginated, or what happens if the item has no tags. An output schema exists, so return shape is partially excused, but the behavioral profile of the call remains undocumented.

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?

A single short sentence with the resource front-loaded and zero filler. It earns its place, though the terseness leaves little structure to guide an agent.

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 two-required-parameter tool with 0% schema coverage and no annotations, the description is too thin: it never references board_id, the item scoping, or any behavioral expectation. The presence of an output schema covers the return-value side only.

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 0% and the description mentions no parameters at all. The non-obvious requirement that board_id must accompany item_id is left entirely to the schema's bare property names, so the description does not compensate for the 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?

Specific verb ('List') and resource ('tags attached to an item') make the operation unambiguous, and it is distinguishable from siblings like get_items_by_tag (reverse direction) and list_tags (all workspace tags). It does not explicitly name those siblings, 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.

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

The phrase 'attached to an item' implies the use case (fetch tags for one known item), but there is no explicit statement of when to prefer this over list_tags or get_items_by_tag, and no mention of prerequisites such as needing the board context.

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 the entire behavioral burden and discloses almost nothing: no statement that it is read-only, no error behavior for missing nodes, no permission requirements. "EXPERIMENTAL" is the one useful disclosure, hinting at instability, but nothing else about the call's behavior 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.

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

Two short sentences, front-loaded with the operation and followed by a caveat – no wasted words. Brevity here is under-specification rather than true concision, since critical parameter and behavior details are absent.

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?

An output schema exists, so return values needn't be explained, but the description still omits parameter meaning, read-only status, and node/board relationships. For a two-required-parameter retrieval tool with zero schema coverage and no annotations, this is far from 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 0%, so both required parameters (board_id, item_id) are undocumented in the schema, yet the description adds no meaning either. An agent must guess whether item_id is the node's ID, a parent item, or something else, and how it relates to 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?

"Get one mind map node" states a verb and resource, and "one" implies single-item retrieval as opposed to sibling list_mindmap_nodes. But the phrasing largely restates the tool name and doesn't explain what a mind map node is in relation to get_item or the other mindmap siblings.

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?

No guidance on when to use this tool versus list_mindmap_nodes, get_item, or the other node retrievers. The only usage signal is the "EXPERIMENTAL" tag, which implies caution but doesn't say when the tool should or shouldn't be called.

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. 'Get' weakly implies a read-only operation, but nothing is said about permissions, error behavior for unknown ids, or whether board_id must match the tag's board.

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 short and front-loaded, but the brevity reflects under-specification rather than efficient communication. There is no wasted text, yet every sentence that should be there is absent.

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?

An output schema exists, so return values needn't be described. But with zero annotations, zero schema descriptions, and no usage context, the definition leaves an agent guessing about scope, preconditions, and the board_id/tag_id relationship.

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 0% — parameters carry only bare titles ('Tag Id', 'Board Id'). The description adds no meaning, such as why a tag lookup requires board_id alongside tag_id or what format ids take. The names are self-explanatory enough to avoid a 1.

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?

States a specific verb and resource ('Get one tag'), which distinguishes it from list_tags and get_item_tags by implying single-resource retrieval. However, it does not clarify key scope questions such as whether 'one tag' means a tag definition on a board versus a tag's occurrences on items, leaving ambiguity against several sibling tools.

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?

No guidance on when to use this versus list_tags, get_item_tags, get_items_by_tag, or attach/detach_tag. The agent must infer that this fetches a tag definition by id rather than tag usage.

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 behavioral burden. It usefully discloses plan and token requirements, but omits pagination behavior, default limit/offset semantics, ordering, and whether listing is filtered or exhaustive.

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 short, front-loaded sentences with no wasted text. The core operation comes first, followed by the critical access restriction.

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?

Because an output schema exists, return values need not be explained. However, for a paginated list endpoint with three parameters and zero schema descriptions, the definition should say more about pagination and result scope to be 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 0%, and the description only indirectly maps to org_id ('for an organization'). The limit and offset pagination parameters are completely undocumented in both schema and 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 names a specific verb and resource ('List board export jobs') and scopes it to an organization. It clearly separates listing from sibling create/get-status/get-results operations by name, though it does not explicitly mention those alternatives.

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 provides an important eligibility constraint ('ENTERPRISE PLAN ONLY') and authentication requirement ('Discovery access token'), but it does not explain when to use this tool versus get_board_export_job_status or get_board_export_job_results, nor 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, the description carries more burden, but it does disclose that results are offset-paginated and that fetch_all walks all pages. It does not mention permissions, whether all member types are included, or other behavioral constraints, though the output schema covers 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 tight sentences with the core purpose front-loaded and the pagination behavior immediately after. There is no 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?

For a simple list operation with an output schema, the description covers the essential pagination behavior. However, the lack of annotations and 0% schema description coverage leaves gaps around parameter semantics and permissions that the description only partially addresses.

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 0%, so the description must compensate for all four parameters. It adds meaning for fetch_all and refers to offset pagination, but it does not explain limit, offset, or board_id beyond their names.

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 uses a specific verb and resource: "List members of a board." This clearly distinguishes the tool from related single-member tools like get_board_member, 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.

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

The description explains the pagination behavior and how to fetch all pages with fetch_all, which is useful usage guidance. However, it does not explicitly state when to use this tool versus get_board_member or other member-related tools, nor does it provide exclusions.

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 the burden and does add real value: it discloses offset-based pagination, that fetch_all walks all pages, and warns about cost on large accounts. It omits permission/auth requirements and result ordering beyond the sort parameter.

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 short sentences, front-loaded with the purpose, then pagination behavior, then parameter semantics. No filler; the warning about large accounts is brief and 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?

The output schema covers return values and the pagination behavior is disclosed, but for an 8-parameter tool at 0% schema coverage, the scoping parameters team_id and project_id are unexplained, leaving a meaningful gap for an agent filtering within a team or project.

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 0%, so the description must compensate. It explains query, owner (with example values), sort (with example values) and fetch_all, but leaves limit, team_id and project_id entirely undocumented; offset/limit are only hinted at by "offset-paginated".

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?

States a specific verb and resource ("List boards") plus the scope ("visible to the token"), which separates it from get_board and create_board in the sibling set. It doesn't explicitly name those siblings, 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.

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

Listing usage is implied by the name and the filter/sort options, but there is no explicit guidance on when to use this versus get_board, or when fetch_all is appropriate beyond a vague caution. The agent must infer the routing.

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