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

Annotations supply the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description doesn't need to restate mutation semantics. It does add valuable non-structured behavior: the query is NOT validated server-side and a bad query/column silently yields an empty panel, plus the space default. This warns the agent about a silent-failure mode the annotations never express.

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 core action and result, then parameters with examples, then the alternative tool, then the critical caveat. Every sentence carries information the agent needs; nothing is padding.

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. Given that, the description covers purpose, the routing alternative, per-parameter meaning for the tricky fields, and the silent-failure caveat — everything needed to invoke this 5-parameter mutation 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 coverage is 0%, so the description must carry parameter meaning, and it does for the non-obvious ones: 'esql' is the query (with a worked example) and 'column' names the output column to display (with example), and 'space' targets a Kibana space by id. The obvious 'title' and 'dashboard_id' are left to inference, which is a minor gap but not misleading.

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 precise verb+resource ('Add an ES|QL metric panel to an existing dashboard') and narrows the outcome to 'show one of its output columns as a single-number metric'. It distinguishes itself from siblings by explicitly routing field-based charts to add_panel with a VizSpec, so the agent can tell it apart from add_esql_table_panel and add_esql_xy_panel.

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 states a clear alternative for the field-based case ('use add_panel with a VizSpec instead'), which is genuine when-to-use guidance. It stops short of naming the other ES|QL panel siblings (table/xy) as alternatives, so the routing is helpful but not exhaustive.

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?

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false). The description adds genuinely useful context beyond them: no server-side validation, and a wrong query or column name silently produces an empty panel. It stops short of describing the response or idempotency 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?

Front-loads the core action, then the two column parameters with concrete examples, then the critical validation caveat, then the alternative tool and the space default. Dense but every clause earns its place; the parameter definitions could be tightened slightly.

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

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

With an output schema present, return values needn't be explained, and annotations cover the safety profile. The description supplies the mutation caveat, all non-obvious parameter meanings, and the space default, leaving little an agent would need before invoking 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 carries the full burden and mostly delivers: columns are defined as grouping/dimension columns (one row per distinct value, with example), metric_columns as numeric value columns (example given), esql as the query, and space as the target Kibana space with its default. Only title and dashboard_id are left implicit, which are self-evident.

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 (add) and resource (ES|QL table panel to an existing dashboard) and clarifies the panel's role: 'show a query's output columns as a table.' It explicitly distinguishes itself from the sibling add_panel for field-based charts, so an agent can tell it apart from the ES|QL metric/xy siblings by the table semantics.

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 routes field-based charts to add_panel with a VizSpec, and warns that esql is not validated server-side so wrong input yields an empty panel. It doesn't directly contrast with the closest siblings add_esql_metric_panel and add_esql_xy_panel, leaving that distinction to inference from the name.

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?

Annotations declare the write/non-idempotent profile (readOnlyHint=false, idempotentHint=false), and the description adds a genuinely useful trait beyond them: 'esql is NOT validated server-side — a wrong query or column name yields an empty panel.' That failure mode is important and not encoded anywhere in the schema. It does not cover permissions, panel placement within the dashboard, or return behavior, but the output schema covers the last of those.

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 core action followed by the parameter mapping, then the caveat. The backtick-heavy line wrapping makes it slightly choppy to parse, but every sentence (scope, param roles, validation warning, sibling routing, space scoping) carries 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?

For an 8-parameter mutation tool with a rich output schema already documenting returns, the description covers the query semantics, the column mapping, the validation caveat, and space scoping. It omits panel positioning within the dashboard and the chart_type default, which are minor given the schema and 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%, so the description must carry the load, and it does for the non-obvious parameters: x_column (x axis), y_columns (each a plotted series), breakdown_column (splits each series), esql (the query), and space (Kibana space id, default space). Only title and dashboard_id are unmentioned, and those are self-evident; chart_type's default of 'bar' is never stated.

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 ('Add an ES|QL bar/line/area panel to an existing dashboard') and then enumerates the exact semantic role of x_column, y_columns, breakdown_column, and esql. It explicitly distinguishes itself from the field-based sibling add_panel, so an agent can select it without reading 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 an explicit routing rule: 'For field-based charts use add_panel with a VizSpec,' which tells the agent when NOT to use this tool. However, it never distinguishes itself from the nearest siblings add_esql_metric_panel and add_esql_table_panel, which the agent must infer from the 'bar/line/area' phrasing.

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?

Annotations already declare readOnly=false, idempotent=false, destructive=false and openWorld=false, so the agent knows this is a non-destructive, non-idempotent mutation. The description adds the additive/'existing dashboard' constraint and the space-targeting semantics, but says nothing about failure behavior, duplicate handling, or what happens when a panel reference is invalid.

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, purpose front-loaded, followed by the one non-obvious parameter note. No filler or restatement of the name, and nothing that could be trimmed 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 and the nested panel schema is rich, so return values and parameter structure need not be re-explained. What is missing is the routing context: for a tool with three near-identical ES|QL panel siblings and an update_panel sibling, the description should say when this generic panel builder is the right choice. Adequate but with a clear gap.

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?

Top-level schema coverage is 0% (dashboard_id and panel carry no top-level description), but the nested `panel` object is documented in exhaustive detail in the schema, and dashboard_id is self-evident. The description compensates for exactly one parameter, `space`, by explaining its meaning and default, which is useful but partial given the low coverage.

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

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

The description states a specific verb and resource ('Add a visualization panel to an existing dashboard'), which is unambiguous on its own. However, it does not differentiate this tool from close siblings like add_esql_metric_panel, add_esql_table_panel, add_esql_xy_panel, or create_visualization, so an agent cannot tell which add-panel variant applies without opening the schemas.

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 context given is the `space` default behavior. There is no guidance on when to choose this tool over the ES|QL panel variants or over create_visualization, nor any prerequisite (e.g. the dashboard must already exist, which is only implied). The 'existing dashboard' phrasing hints at a precondition but never states 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?

Annotations already declare non-readOnly and idempotentHint=true, but the description goes well beyond them: it specifies the normalization rules (case-insensitive, whitespace/punctuation-normalized), the exact side effect (panels replaced, but filters/query/tags/display options preserved), and the return `status` values `created`/`replaced`. This is high-value behavioral context for a mutating tool.

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

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

Front-loads the core purpose, then layers idempotency, prerequisite, and space semantics. Each sentence is substantive, though the idempotency clause is dense with parenthetical detail that could be tightened marginally.

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 documented (the description still usefully names the `status` values). The description covers the mutation semantics, idempotency, prerequisite, and space scoping; only the undocumented top-level params (time_range, description) leave a small gap for a 5-param 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?

Top-level schema description coverage is 0%, so the description must carry the load, and it only clarifies `space` (targets a Kibana space by id, defaulting to the default space). It says nothing about `time_range` defaults/semantics or the `description` parameter, leaving those to inference despite 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+resource ('Create a dashboard') and scopes it to input from 'one or more visualization specs', which distinguishes it from siblings like create_visualization (single viz) and add_panel (mutating an existing dashboard). An agent can tell what this does without opening the schema.

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

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

Gives an explicit prerequisite ('Call describe_data_view first to learn real field names') and explains the idempotent routing behavior (same title updates rather than duplicates), which steers correct invocation. It does not, however, explicitly contrast against sibling tools such as add_panel or create_visualization for building up dashboards incrementally.

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?

Annotations declare this is a mutation (readOnlyHint=false) that is non-destructive, non-idempotent, and closed-world, so the safety profile is already covered. The description adds useful context on time_field for time-series data and the space scoping with its default, but says nothing about auth needs, failure modes, or behavior when a view already exists.

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 core action and followed by optional fields and the space qualifier. Tight and readable, with only minor overlap between the first sentence and the parameter statements.

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, and the description covers all four parameters plus the space default. Gaps remain around duplicate-view behavior and permissions, but for a straightforward create tool this is largely 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 carries the burden and largely succeeds: it clarifies index_pattern via an example, name as a display name, time_field as for time-series data, and space as targeting a Kibana space by id with a default. This meaningfully compensates for the empty schema descriptions.

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

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

States a specific verb (Create) and resource (Kibana data view) with the object it operates over (an index pattern like 'logs-*'). The create/list/describe split among siblings is inferable from the verb, so an agent can tell it apart from list_data_views and describe_data_view.

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 index-pattern example, but there is no explicit when-to-use/when-not guidance, no mention of prerequisites (e.g. index must exist), and no reference to alternatives like list_data_views or describe_data_view. It is adequate but leaves routing to inference.

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?

Annotations already declare the write/non-idempotent/closed-world profile, so the bar is lower. The description adds real context beyond that: the Technical-Preview API status, where the created slug resolves (/s/<space>/goto/<slug>), and the space-routing consequences of path prefixes. It does not call out that repeated calls produce distinct slugs (relevant given idempotentHint=false), which keeps it from a 5.

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?

Purpose is front-loaded and each subsequent sentence carries a distinct, non-redundant rule about space/prefix handling. The middle section is dense and reads as an undifferentiated block of edge cases rather than being broken into clean, scannable statements.

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. For a preview mutation tool with a free-form params object, the description supplies the space semantics, locator pattern, and resolution behavior an agent needs to call it correctly; only the non-idempotency implication is left implicit.

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

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

With 0% schema description coverage the description must carry the load, and it does: it documents locator_id (LEGACY_SHORT_URL_LOCATOR), the expected params shape ({'url': '/app/...'}), and the space parameter's prefix interaction rules. It is not exhaustive, though, since params is an open object (additionalProperties: true) and no keys beyond url are described.

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?

Opens with a specific verb+resource ('Create a Kibana short URL') and immediately distinguishes itself from the sibling resolver by naming resolve_short_url as the consumption side. An agent can tell what this does and how it relates to sibling tools 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?

Provides substantial conditional guidance on correct invocation (when space is set, drop the /s/<space> prefix; a /s/<id> path without space lands in the default space), which is genuinely useful. However, it never states when to prefer this tool over alternatives or any exclusion, so tool-selection guidance is only implied.

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

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

Annotations already declare readOnly=false, destructive=false, and idempotent=false, so the mutation profile is largely covered. The description usefully adds that the artifact is created in the library (reusable, not dashboard-scoped) and that `space` defaults to the default space, but it says nothing about permissions, duplicate-title behavior, or where the created object can be found afterward.

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: the core action and its dashboard exclusion come first, then the parameter note. Every element earns its place with 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?

An output schema exists so return values need not be explained, and the nested spec schema is richly documented. However, for a non-idempotent creation tool with a complex required nested object, the description omits any note about permissions, failure modes, or what to do with the created object — leaving gaps the schema cannot cover.

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?

Top-level schema coverage is 0%: the required `spec` object has no description in either the schema or the description, so the description only compensates for the `space` parameter (id targeting, default space). The shape of `spec` is discoverable from its extensive nested field descriptions, but the description itself adds no meaning for the primary 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 gives a specific verb+resource ("Create a reusable visualization in the library") and explicitly scopes it away from dashboard placement with "(not on a dashboard)", which meaningfully separates it from add_panel and create_dashboard siblings. It stops short of naming the alternative tools outright.

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 parenthetical "(not on a dashboard)" implies when-not to use this in favor of panel tools, but no explicit when-to-use, prerequisites, or named alternatives are given. Usage is inferable rather than stated.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds workflow context (a read-only pre-flight check before visualization creation), but says nothing about auth requirements, failure behavior for unknown data views, or result size.

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, zero waste, with the core purpose front-loaded and the workflow hint and parameter note following economically.

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, and annotations cover the read-only nature. The remaining gap is the undocumented `data_view` parameter; otherwise adequate for a simple two-param read 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 the description must carry parameter meaning. It explains `space` well (Kibana space by id, default space), but never explains `data_view` beyond the tool's overall purpose, leaving one of two parameters 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?

Specific verb+resource: 'Get a data view's fields and types.' An agent can immediately tell this apart from list_data_views and create_data_view without opening any 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?

Explicitly states when to call it: 'Call this before creating a visualization so you use real field names.' This ties it to the create_visualization sibling workflow. No exclusions or alternative-name routing (e.g., vs list_data_views), so it stops short of a 5.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds valuable behavior beyond them: the result is a server-side NDJSON file with an opaque handle rather than inline content, and the readable scope is bounded by the API key's privileges rather than this tool. It does not, however, describe file lifetime, size limits, or pagination of the underlying export.

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 core action and the key distinction (returns a handle, not content), followed by the parameter-selection constraint and the space note. Dense but nearly every sentence carries load; the terse backtick fragments are slightly abrupt but not 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 four-parameter export tool with an output schema present, the description supplies the workflow (handle to import), the space context, and the parameter-selection rule, so an agent can call it correctly. The only material gap is the unexplained include_references_deep parameter, plus non-essential export mechanics that the output schema can cover.

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, and it does for three of four params: space (targets a Kibana space by id, defaults to default space), types (with concrete examples and the ["*"] wildcard), and objects (list of {"type":…, "id":…}), plus the exclusivity rule between types and objects. include_references_deep is never explained, leaving one undocumented 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?

States a specific verb (export) and resource (saved objects: dashboards, data views) and, crucially, clarifies the output shape: an NDJSON file on the server plus a summary and opaque handle, not the content itself. It explicitly names the sibling it feeds (import_saved_objects), so an agent can distinguish export from import and from search/get tools without opening a 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?

Gives clear conditional guidance: select EITHER types (e.g. ["dashboard"] or ["*"] for the whole space) OR objects, not both, and explains that the returned handle is passed to import_saved_objects. It also notes the space-default behavior. It stops short of stating when NOT to use this tool versus read-only siblings like search_dashboards or get_dashboard.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the shape of the result (title, description, panels) and the space targeting/default, which is modest extra context, but nothing on failure modes or scoping 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, front-loaded with the core purpose and the result contents, then the one parameter note that needs explanation. No filler, no redundancy with the 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 read-only single-resource getter with an output schema present, the definition covers purpose, result content, and the space-scoping default. The only real gap is that dashboard_id semantics rest entirely on its name, which is low risk here.

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 carries the burden. It fully explains `space` (a Kibana space id, defaulting to the default space), which is the non-obvious parameter, but says nothing about `dashboard_id` beyond implying it identifies the dashboard. Partial compensation only.

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 pairs a specific verb (Get) with a specific resource (dashboard) and even enumerates the return content (title, description, panels). It is clearly distinguished in kind from create_dashboard/search_dashboards by name and phrasing, though it never explicitly names a sibling to contrast with.

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 rather than stated: fetching a single dashboard by id is evident from the name and the summary language, but there is no explicit 'use this instead of search_dashboards when…' routing or any precondition. Adequate but leaves the agent to infer when this tool is preferable.

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?

Annotations cover the safety profile (destructiveHint=false, idempotentHint=false), and the description goes further: existing objects are never touched, ids are regenerated, the return maps source id -> new destination id, and a stale handle errors. The space-independence of a handle is non-obvious behavioral context that could not be inferred from annotations.

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

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

Well front-loaded with the semantics of the operation before the alternatives, and every sentence carries information. It is dense and slightly repetitive in restating 'clone' versus 'existing objects never touched', but it stays well within a useful length.

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

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

An output schema exists, yet the description still briefly notes the return shape (source id -> new id), and it covers handles, error cases, space targeting, and the destructive alternative. Nothing an agent needs to call this correctly 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 coverage is 0%, so the description carries the full burden and does: `handle` is defined as the value returned by export_saved_objects, with its error behavior and space-independence spelled out; `space` is defined as a Kibana space id with the default space as fallback. Both parameters are documented beyond their bare types.

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 (import saved objects) and immediately qualifies the mode: creates NEW copies with regenerated ids rather than an in-place restore. It explicitly distinguishes itself from the sibling overwrite_saved_objects, so an agent can choose 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?

Explicitly names the alternative ('To restore in place instead, use overwrite_saved_objects (destructive)') and the condition that selects it. It also defines when the handle is valid and what happens when it is not (missing/expired handle errors).

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one behavioral detail beyond that: the `space` parameter defaults to the default space, which is useful scoping context but not rich disclosure.

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, purpose first, parameter detail second, with no filler. Everything 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 need not be described, and annotations cover the safety profile. For a single-optional-parameter list tool the description is nearly complete; only explicit sibling routing 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%, so the description must carry the parameter burden, and it does: it explains that `space` targets a Kibana space by id and states the default behavior. That meaningfully compensates for the undocumented schema, though it doesn't note the id pattern constraint present in the schema.

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

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

The description gives a specific verb+resource ("List Kibana data views") and even defines the concept parenthetically ("the datasets you can visualize"), which helps an agent unfamiliar with Kibana. It does not explicitly contrast with sibling tools like describe_data_view or create_data_view, though the verb 'list' implies 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?

Usage is implied by the verb: use this to enumerate all data views, versus describe_data_view for one. However, the description never states when to prefer this over siblings or any preconditions, so the guidance remains inferential.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the API is Technical Preview, and the `space` parameter defaults to the default space, which is behavioral detail the annotations do not supply.

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 plus a parenthetical caveat, with the core action front-loaded. Nearly every phrase earns its place; the parenthetical preview note is short and material.

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, and annotations cover the read-only profile. The description covers purpose, the preview caveat, and the space default, though it omits error behavior for an unresolvable slug.

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 carries the burden. It explains `space` well (targets a Kibana space by id, defaults to the default space), but says nothing about `slug` beyond its self-evident meaning from the purpose sentence. Partial compensation 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 ("resolve") and resource ("Kibana short-URL slug") and names the output ("its locator and target app path"), which is far more than a restatement of the name. It does not explicitly reference the obvious sibling create_short_url, but the verb alone distinguishes it from that counterpart.

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 never says when to use this tool versus alternatives (e.g. create_short_url) or when not to. It implies usage by describing the operation, but provides no context, prerequisites, or exclusions.

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

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

Annotations already declare this is a read-only, closed-world operation. The description adds useful scope context ('Empty query lists all') and the default space behavior, but does not disclose pagination, result limits, or authentication/permission needs beyond what annotations cover.

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 tightly structured sentences with the core purpose front-loaded and the space default clearly called out. No filler or redundant restatement of the name or 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?

Given a low-complexity, read-only search tool with an output schema and annotations, the description covers purpose, empty-query behavior, and the space default. It is nearly complete, but omits routing guidance versus get_dashboard and details about query matching.

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

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

With 0% schema description coverage, the description compensates by explaining both parameters: query searches title/description and lists all when empty, and space targets a Kibana space by id with the default space as fallback. It leaves query matching semantics (substring vs. exact) and null handling 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 ('Search dashboards') plus the search scope ('by title/description') and the empty-query behavior. However, it does not explicitly distinguish itself from the sibling get_dashboard, which likely retrieves a single dashboard by id.

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 implies usage through 'Search dashboards by title/description' and 'Empty query lists all,' but gives no explicit when-to-use guidance, no when-not conditions, and no named alternative such as get_dashboard for direct retrieval.

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?

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds that the operation replaces rather than merges a panel and that space defaults to the default Kibana space. It does not say what happens to unspecified panel fields, whether an out-of-range index errors, or how existing panel ordering is affected.

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 tight sentences, the core replace semantics front-loaded, followed by the one non-obvious parameter clarification. No filler, no restatement of the title.

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 nested panel schema is richly annotated. Still missing is any signal about failure modes (invalid panel_index, unknown dashboard_id) and the relationship to add_panel, which matters given the number of panel-creation siblings.

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?

Top-level schema coverage is 0%, so the description must compensate: it explains panel_index (an index obtained via get_dashboard) and space (Kibana space id, default space). It says nothing about dashboard_id, and the deeply nested `panel` structure is documented only in the schema. This is partial compensation for a real 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 and target: 'Replace the visualization at panel_index'. The word 'Replace' implicitly distinguishes it from the sibling add_panel, and the pointer to get_dashboard clarifies what panel_index refers to. It does not explicitly name add_panel as the alternative, 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?

The description tells the agent where to find valid panel indexes (get_dashboard) and explains the default behavior of `space`, which is genuine usage context. However, it gives no explicit when-to-use/when-not guidance relative to add_panel or the esql panel tools, so the agent must infer that this is for modifying an existing panel rather than adding one.

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