Server Quality Checklist

Tool Scores

• update_panelC
  2.9/5.0
  Behavior2/5

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

  No annotations are supplied, so the description must carry the behavioral load. 'Replace the visualization' implies mutation (consistent with readOnlyHint=false) and hints the prior visualization is gone, but it never states whether the operation is destructive to the old content, whether it's idempotent (destructiveHint=false), or whether it requires the panel to already exist. The agent must infer all of this.

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

  Conciseness4/5

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

  Two compact, readable sentences that front-load the main purpose and then add a useful parameter note. There is no fluff, but the brevity causes it to under-deliver on behavioral and usage context.

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

  Completeness2/5

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

  For a tool that overwrites a visualization on a dashboard Affecting whether an existing panel is silently destroyed, how indexes are obtained, and whether the operation is idempotent, the description provides only the index source and space semantics. There is no note on outcome, error conditions, or interaction with the existing panel, so an agent lacks a full picture of what calling this does.

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

  Parameters3/5

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

  The description clarifies two parameters: panel_index (which indexes come from get_dashboard) and space (id, defaults to default space). The nested panel fields (chart_type, metrics, group_by, etc.) already carry rich descriptions in the schema. However, dashboard_id receives no extra meaning and the interplay (e.g., does space apply to all params?) is left vague. Description partially supplements the schema, so a 3 is fair.

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

  Purpose4/5

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

  The verb 'Replace' is specific and 'visualization at panel_index' clearly identifies the target resource, with a useful pointer to get_dashboard for the index. However, the description does not name or distinguish from sibling tools like add_panel or update_panel variants, so an agent could confuse scope. Minor ambiguity: does 'visualization' mean the chart, its config, or the whole panel?

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

  Usage Guidelines2/5

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

  The only guidance is a cross-reference to get_dashboard for indexes. There's no statement about when this tool should be used versus the many create/add siblings, no prerequisites, and no exclusion of alternatives. Nothing tells the agent what should be fetched first (though indexing is implied) or what happens if the panel doesn't exist.

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

• add_panelA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds meaningful context about spaces and existing dashboards, but does not describe what happens on repeated calls, whether multiple panels can be added, or how failures affect the dashboard. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is only two sentences, front-loaded with the action, and contains no fluff. It communicates the main behavior and one key parameter nuance without repetition.

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

  Completeness3/5

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

  For a tool with a complex nested panel object, the description covers the basics but omits workflow guidance such as needing `data_view` to exist, how this relates to the ES|QL panel tools, or whether a dashboard must be fetched first. The schema and annotations carry much of the load, so it is viable, but it has clear contextual gaps.

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

  Parameters3/5

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

  The description adds real value for the `space` parameter by explaining it targets a Kibana space by id and defaults to the default space. The nested panel definition is rich and well-described in the schema, so the limited description is less harmful, but `dashboard_id` receives no added semantic detail beyond the tool description.

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

  Purpose4/5

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

  The description clearly states the action: 'Add a visualization panel to an existing dashboard.' This is a specific verb + resource and communicates the core purpose well. It does not explicitly differentiate from sibling tools like `add_esql_metric_panel` or `add_esql_table_panel`, so it falls short of a 5.

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

  Usage Guidelines3/5

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

  The phrase 'to an existing dashboard' implies the dashboard must already exist, and the space note gives targeting context. However, it does not explicitly say when to prefer this tool over alternatives such as `create_dashboard`, `create_visualization`, or the `add_esql_*` tools.

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

• create_data_viewA
  3.8/5.0
  Behavior2/5

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

  Annotations provide no safety hints (readOnlyHint=false, destructiveHint=false), so the description must disclose behavioral traits. It explains the `space` parameter but does not mention permissions, what happens if the data view already exists, whether it is idempotent, or any side effects. This leaves significant ambiguity for an agent.

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

  Conciseness5/5

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

  The description is compact (three short sentences) and front-loads the core purpose. Every sentence adds value: the first explains the primary action, the second lists optional parameters, and the third clarifies the `space` argument. No wasted words.

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

  Completeness4/5

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

  For a creation tool with one required parameter and three optional ones, the description covers the essential context: what it does, the index pattern example, and the optional fields. It does not mention error handling or prerequisites, but the output schema likely covers return values. Overall, it is complete enough for a competent agent to use the tool correctly.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates by explaining each parameter's role: index_pattern (with example 'logs-*'), name (display name), time_field (for time-series data), and space (targets a Kibana space by id). This adds meaning beyond the schema's bare field definitions.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Create a Kibana data view over an index pattern' with a concrete example. This is specific and distinguishes it from sibling tools like list_data_views or describe_data_view, which serve different purposes.

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

  Usage Guidelines3/5

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

  The description implies the use case—creating a data view for an index pattern—and mentions optional settings for time-series data. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or prerequisites (e.g., that the index pattern must exist).

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

• create_visualizationA
  3.9/5.0
  Behavior3/5

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

  Annotations indicate the tool is not read-only, not open-world, not idempotent, and not destructive, which is minimal. The description adds context that the visualization is reusable and placed in the library, but it doesn't disclose what happens to existing visualizations, permissions needed, or that creating is a write action. With annotations already covering the basic traits, the description adds some value but lacks detailed behavioral context.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences, zero waste. It front-loads the core purpose and adds a necessary detail about the space parameter. Every word earns its place.

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

  Completeness4/5

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

  Given the tool's complexity with nested objects and an output schema, the description is adequate but could be more complete. It doesn't describe return values, but the output schema likely covers that. It focuses on the creation location and the space parameter, which are key differentiators. However, it lacks guidance on required spec fields or common usage patterns, leaving some gaps for an agent to fill.

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

  Parameters2/5

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

  The input schema has rich descriptions for all parameters, covering 0% schema coverage in the description itself means the schema provides all the meaning. However, the description adds minimal parameter-level information beyond the schema. It only mentions that 'space' targets a Kibana space by id, which is useful context not in the schema. Given the schema is comprehensive, the description's contribution is marginal but positive for the space parameter; still, it doesn't compensate for the overall lack of parameter guidance beyond the schema.

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

  Purpose5/5

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

  The description states "Create a reusable visualization in the library (not on a dashboard)" with a specific verb and resource, and explicitly distinguishes it from dashboard-based creation. It clearly contrasts with sibling tools like create_dashboard and add_panel, making its purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context by noting the visualization is placed in the library rather than a dashboard, which helps differentiate from sibling tools. However, it does not explicitly state when to use this tool versus alternatives like create_dashboard or add_panel, nor does it mention when not to use it.

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

• get_dashboardA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description is consistent with that. The description adds the output fields and the space targeting behavior, but does not disclose potential errors, permissions, or limitations of what 'summary' includes. Given annotations cover the safety profile, the description adds modest but not rich behavioral context.

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

  Conciseness5/5

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

  Two sentences, no filler. The first sentence states purpose and output, the second explains a parameter; both are necessary and the most important information is front-loaded.

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

  Completeness4/5

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

  For a simple get-by-id tool with output schema and annotations, the description covers the essential purpose and parameter semantics. It doesn't address usage relative to siblings or potential edge cases, but those are not critical given the low complexity and available schema.

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

  Parameters4/5

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

  Schema has no descriptions (0% coverage). The description explains the non-obvious `space` parameter by stating it targets a Kibana space by id and defaults to the default space. `dashboard_id` is not described but its meaning is self-evident from the parameter name and tool name; still, a brief mention would be better. This partially compensates for the schema gap.

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

  Purpose5/5

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

  The description uses the specific verb 'Get' and names the resource 'dashboard', and specifies the returned contents: 'title, description, and its panels'. This clearly distinguishes it from sibling search_dashboards and create_dashboard by being a targeted read operation on a single dashboard.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or comparison with alternatives is provided. The description implies the tool is for retrieving dashboard details, but it does not say when to prefer get_dashboard over search_dashboards or how the space parameter interacts with search. Thus usage guidance is only implied, not explicit.

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

• list_data_viewsA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe read nature is covered. The description adds the space-scoping behavior, which is useful, but does not disclose other behavioral traits such as pagination, ordering, or whether all views are returned across the entire stack.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loads the main action, and every word adds value. There is no redundant restatement of the tool name or schema fields.

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

  Completeness5/5

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

  For a simple list operation with one optional parameter, an output schema, and read-only annotations, the description covers the essential semantics: what is listed, what the parameter means, and the default behavior. No significant information gap remains.

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

  Parameters4/5

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

  Although the schema has no descriptions and reported coverage is 0%, the description compensates by explaining the single 'space' parameter: it targets a Kibana space by id and defaults to the default space. This adds semantic meaning beyond the raw schema type and default value.

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

  Purpose5/5

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

  The description uses a specific verb and resource: 'List Kibana data views' and clarifies them as 'the datasets you can visualize.' This clearly distinguishes it from sibling tools like describe_data_view and create_data_view, which operate on a single view or create one.

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

  Usage Guidelines3/5

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

  The intended use is implied by the phrase 'the datasets you can visualize' and the space-targeting comment, but there is no explicit mention of when to choose this over alternatives such as describe_data_view or search_dashboards. No exclusions or conditional guidance are provided.

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

• resolve_short_urlA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds context by flagging Short URLs as a Technical-Preview API and specifying the resolve outcome (locator and target app path). This goes beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  Two short sentences, front-loaded with the core purpose, and no filler. Every sentence adds relevant information, including the technical-preview caveat and the 'space' parameter clarification.

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

  Completeness5/5

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

  The tool is simple, has an output schema, read-only annotations, and the description conveys enough to select and invoke it correctly. The technical-preview warning and space behavior round out the context without needing further detail.

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

  Parameters3/5

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

  With 0% schema description coverage, the description must compensate. It explains 'space' (targets a Kibana space by id, defaults to the default space), which adds meaning beyond the schema. 'slug' is implied but not explicitly detailed, leaving some semantic gap.

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

  Purpose5/5

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

  The description uses a specific verb ('Resolve') and resource ('Kibana short-URL slug') and states the output ('locator and target app path'). This distinguishes it from the sibling 'create_short_url' tool, making the purpose unmistakable.

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

  Usage Guidelines3/5

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

  The description implies usage when a short-URL slug needs resolving, and it clarifies the optional 'space' parameter's default. However, it does not explicitly state when to use this tool over alternatives or provide any exclusions/prerequisites.

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

• describe_data_viewA
  4.2/5.0
  Behavior4/5

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

  Annotations already communicate the read-only safety profile, and the description adds useful behavioral context: `space` targets a Kibana space by id and defaults to the default space. The output schema also covers return shape, so the transparency burden is reasonably met.

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

  Conciseness5/5

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

  The description is compact and front-loaded: one clear purpose sentence, one practical usage sentence, and one terse parameter note. There is no redundant filler.

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

  Completeness4/5

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

  For a low-complexity, read-only metadata tool with an output schema and annotations, the description covers the trigger situation and the space default well. It is slightly incomplete only because the format of the `data_view` parameter is not explicitly specified.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It explains `space` well, but it does not clarify whether `data_view` expects an ID, name, or title. The tool name and first sentence imply it identifies a data view, but this is only partial parameter guidance.

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

  Purpose5/5

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

  The description opens with a specific action and object: 'Get a data view's fields and types.' It also gives a concrete use case ('Call this before creating a visualization so you use real field names'), which clearly distinguishes it from siblings like list_data_views and create_data_view.

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

  Usage Guidelines4/5

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

  The instruction 'Call this before creating a visualization' provides an explicit context for when to use the tool. It does not enumerate exclusions or alternative tools, but the guidance is clear enough for an agent to select this tool appropriately.

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

• add_esql_xy_panelA
  4.3/5.0
  Behavior4/5

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

  The description adds important behavioral context: it states that the query is not validated server-side and that a wrong query can yield an empty panel. This is critical for the agent to understand. It also mentions the space targeting behavior手动 with a default. Annotations are all false, so the description carries the burden and handles it well, though it could mention that the operation is not idempotent or destructive but that's less relevant.

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

  Conciseness4/5

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

  The description is concise, with two clear paragraphs: the first explains the tool's purpose and key parameters, and the second covers the 'space' parameter. It avoids redundancy and is front-loaded with the main action. The only minor issue is that the space explanation is placed after the main content, but it's not off-topic.

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

  Completeness4/5

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

  Given the tool's complexity (8 params, 5 required, output schema exists), the description is well-rounded. It explains the core behavior, the parameter relationships, the lack of validation, and the alternative tool. The output schema covers return values, so the description doesn't need to. It could mention the types of panels it creates (bar/line/area) more explicitly, but the chart_type parameter handles that.

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

  Parameters4/5

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

  Despite the schema having 0% description coverage, the description itself explains the roles of x_column, y_columns, breakdown_column, esql, and space, which goes beyond the schema's raw definitions. It does not detail chart_type (though its enum values are self-explanatory) or dashboard_id and title, which are obvious from names, so the coverage is good but not exhaustive.

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

  Purpose5/5

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

  The description clearly states the tool creates ES|QL bar/line/area panels on dashboards, mentions the key parameters (x_column, y_columns, breakdown_column), and distinguishes it from the alternative add_panel for field-based charts. It also indicates the panel type and the optional breakdown column, which is specific and helpful.

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

  Usage Guidelines4/5

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

  The description provides clear guidance on when to use this tool (for ES|QL-based charts) and explicitly contrasts with add_panel for field-based charts, giving a clear alternative. However, it doesn't explicitly mention when NOT to use it, such as for metric or table panels, which could be inferred from sibling tool names.

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

• create_dashboardA
  4.3/5.0
  Behavior5/5

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

  Beyond annotations (idempotentHint=true), the description explains the normalized title matching, that existing panels are replaced while filters/query/tags/display options are preserved, and that the return status is `created` or `replaced`. This is exactly the kind of behavioral nuance the structured fields cannot convey.

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

  Conciseness5/5

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

  Three tight sentences: a clear one-line definition, a compact idempotency/replacement contract with return status, and a prerequisite plus `space` default. No filler.

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

  Completeness4/5

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

  The high-complexity tool has rich nested schema, output schema, and annotations, and the description covers the important behavioral contract and prerequisite. It is not a 5 only because top-level parameter documentation is sparse (e.g., `time_range` and `description` are not explained in prose).

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

  Parameters2/5

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

  The input schema has 0% top-level description coverage, so the prose description must compensate, but it only covers `space` explicitly. `title`, `panels`, `time_range`, and `description` are left to schema inference; nested panel properties are explained in the schema, but the top-level parameter semantics are under-specified.

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

  Purpose5/5

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

  The first sentence names the exact operation ('Create a dashboard') and object ('from one or more visualization specs'), clearly distinguishing it from sibling tools like create_visualization or add_panel. The idempotent-update behavior further clarifies that this is the tool for creating/replacing whole dashboards by title.

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

  Usage Guidelines4/5

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

  It gives a clear prerequisite ('Call describe_data_view first to learn real field names') and explains the title-matching update behavior, so an agent knows when reuse with same title occurs. It does not name sibling alternatives or state explicit when-not-to-use, but the context is sufficient for selection among dashboard/visualization/panel tools.

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

• create_short_urlA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, etc., but the description adds valuable context: how URLs resolve under /s/<space>/goto/<slug>, the difference in behavior when space is set, and the prefix rules. However, it doesn't mention potential side effects (e.g., slug collisions, idempotency) or any output details beyond what's known. The description enhances transparency but doesn't exhaustively cover behavior.

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

  Conciseness4/5

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

  The description is well-structured with a clear definition, a parenthetical usage note, and a separate paragraph for the space parameter. Every sentence adds value, though the second paragraph is slightly repetitive. Overall, it is concise and front-loaded with the primary purpose.

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

  Completeness4/5

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

  Given the 3 parameters and the nested params object, the description provides complete guidance on how to construct valid inputs, including the exact locator_id, the param format, and space-handling rules. It also references output behavior via resolve_short_url. The lack of detailed output schema explanation is acceptable since an output schema exists, and the description covers the complex space-scoping behavior thoroughly.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must fully compensate for parameter semantics. It explains the meaning of three parameters: locator_id (with exact value 'LEGACY_SHORT_URL_LOCATOR'), params (with url field), and space (targets Kibana space, with default behavior). This adds substantial meaning beyond the raw schema, which only provides types and patterns.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Create a Kibana short URL.' It specifies the required locator_id and params format, and distinguishes from the sibling tool resolve_short_url. The mention of 'Technical-Preview API' and supported locator variants adds precision.

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

  Usage Guidelines5/5

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

  The description provides explicit usage context: indicates when to use it (creating a slug), how it interacts with spaces, and obvious distinctions from resolve_short_url (which resolves slugs). It also includes specific guidance on the `space` parameter and path prefixes, which helps agents choose this tool over alternatives.

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

• search_dashboardsA
  4.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=true, so the description adds value by explaining the effect of an empty query (lists all dashboards) and the default space behavior. These are behavioral details not present in the schema or annotations. However, it does not describe pagination, result limits, or other side effects, which keeps it at a moderate level.

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

  Conciseness5/5

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

  The description is extremely concise, consisting of three short, front-loaded sentences. The first sentence states the core purpose, the second clarifies a key behavior, and the third explains a parameter. No unnecessary words or fluff.

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

  Completeness4/5

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

  For a search tool with an output schema and read-only annotation, the description covers the essential aspects: what it searches, how to list all, and the space-scoping parameter. It omits potential details like sorting or result limits, but given the output schema and the tool's simplicity, it is sufficiently complete.

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

  Parameters5/5

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

  The schema has no descriptions (coverage 0%), so the description fully compensates by explaining both parameters: 'query' searches by title/description, and 'space' targets a Kibana space by id with a default. It also clarifies the default values and behavior, adding meaning far beyond the plain type definitions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Search dashboards by title/description.' It uses a specific verb and resource, and distinguishes this from sibling tools like get_dashboard (which retrieves a specific dashboard) and create_dashboard (which creates one). The mention of empty query behavior further clarifies its scope as a listing/search operation.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool (when searching by text) and provides clear context about the query and space parameters. It does not explicitly mention alternatives or exclusions, but the context is sufficient for an agent to decide to use this over other singular dashboard tools. The note about empty query listing all is a usage hint.

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

• add_esql_table_panelA
  4.6/5.0
  Behavior4/5

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

  The description adds critical behavioral context beyond annotations: 'It is NOT validated server-side — a wrong query or column name yields an empty panel.' This is a valuable warning about failure modes. It also explains the effect of the `space` parameter. Annotations only cover read-only/destructive hints, which are false, so no contradiction. The description does not mention idempotency or side effects, but the provided annotations already handle those, and the description adds useful details about error behavior.

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

  Conciseness5/5

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

  The description is compact but information-dense. It packs the core purpose, parameter roles, failure mode, an alternative, and the space parameter into two short paragraphs. Every sentence adds value, and the structure is logical: purpose → parameter details → caveat → alternative → namespace. No fluff or repetition.

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

  Completeness4/5

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

  Given the tool's complexity (ES|QL query, multiple column types) and the presence of an output schema, the description covers the essential aspects: what it does, parameter semantics, failure mode, and when to use alternatives. It does not explicitly mention prerequisites like 'the dashboard must exist', but that is implied by 'existing dashboard'. It also doesn't describe the return value, but the output schema handles that. Overall, it is sufficiently complete for an agent to understand usage and limitations.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must explain parameters. It does this effectively: `columns` are grouped as 'grouping/dimension columns — one table row per distinct value' with an example; `metric_columns` are defined as 'numeric value columns shown per row' with an example; `esql` is described as the query; `space` is explained with a default. `dashboard_id` and `title` are self-explanatory given their names and the tool's purpose. This compensates well for the lack of schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Add an ES|QL table panel to an existing dashboard: show a query's output columns as a table.' It distinguishes from siblings by explicitly mentioning the table panel type and naming add_panel for field-based charts. The verb 'add' and resource 'table panel' are specific and actionable.

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

  Usage Guidelines5/5

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

  Provides explicit usage guidance: 'For field-based charts use add_panel with a VizSpec.' This directly points to an alternative tool for a different use case. It also clarifies the role of columns vs metric_columns, which helps the agent decide when to use this tool. The note about server-side validation also sets expectations for when to use it cautiously.

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

• export_saved_objectsA
  4.6/5.0
  Behavior5/5

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

  Beyond the readOnlyHint, it reveals that the action creates an NDJSON file on the server, that only a summary and opaque handle are returned, and that readable content is bounded by API key privileges. These are behavioral facts not present in annotations, and no contradiction exists.

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

  Conciseness5/5

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

  The description fits four sentences with the primary behavior and handle semantics first, followed by constraints, security caveat, and space. No sentence is redundant or tangential.

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

  Completeness4/5

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

  For a moderately complex export tool with an output schema, the description covers the workflow, selection constraints, security boundary, and relationship to import_saved_objects. Only include_references_deep is not explicitly discussed, so it is nearly complete.

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

  Parameters4/5

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

  Although schema description coverage is 0%, the description explains the main parameters: types/objects exclusivity, wildcard use, and space default. It leaves include_references_deep unmentioned, which is a minor gap given the schema provides no description.

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

  Purpose5/5

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

  The description names a specific verb and resource: 'Export saved objects ... as an NDJSON file on the server.' It also clarifies the return value is a summary plus an opaque handle rather than content, which clearly differentiates this from import_saved_objects and read-only dashboard/data-view tools.

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

  Usage Guidelines4/5

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

  It provides explicit usage constraints: 'Select EITHER types ... OR objects ... not both,' and explains the space parameter's default. It doesn't enumerate when-not cases against sibling tools, but the workflow context is clear enough.

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

• import_saved_objectsA
  4.7/5.0
  Behavior4/5

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

  Annotations provide minimal detail (all false), so the description carries the disclosure burden. It states existing objects are never touched, creates new copies, returns a source-to-destination mapping, and errors on missing/expired handles. However, it does not explicitly mention idempotency (implied by new copies) or other potential side effects, so a 4 is fitting.

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

  Conciseness4/5

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

  The description is well-structured in three sentences, each delivering key information: purpose, alternative, and parameter semantics. It is front-loaded with the main purpose and critical distinction. Slightly verbose but all content is purposeful.

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

  Completeness5/5

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

  The tool description covers all essential aspects: purpose, usage guidance, behavior, parameter semantics, return value, and error conditions. The output schema exists and is not needed for explanation. No significant gaps are evident, making it contextually complete.

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

  Parameters5/5

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

  Both parameters are semantically enriched: `handle` is tied to `export_saved_objects` and its error case, while `space` is explained with default behavior and interaction with the handle. This adds significant meaning beyond the minimal schema definitions, compensating for the low schema coverage signal.

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

  Purpose5/5

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

  The description clearly states the action: import saved objects as new copies with regenerated IDs, and explicitly distinguishes this from an in-place restore by naming the alternative `overwrite_saved_objects`. It also identifies the resource (exported saved objects) and scope (current space), making it highly distinguishable from siblings.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance: for cloning into a space, and when-not-to-use: for restoring in place, suggesting `overwrite_saved_objects` as the destructive alternative. It also clarifies the space-agnostic nature of handles, giving clear context for cross-space imports.

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

• add_esql_metric_panelA
  4.9/5.0
  Behavior5/5

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

  The description discloses important non-obvious behavior beyond the annotations: the query is not validated server-side, a wrong query or column produces an empty panel, and the space parameter targets a Kibana space by id with a default. This gives the agent essential expectations about failure modes.

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

  Conciseness5/5

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

  The description is compact and front-loaded, with the main purpose stated first, followed by useful examples, a sibling-tool pointer, a warning, and a space parameter note. Every sentence adds value without unnecessary padding.

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

  Completeness5/5

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

  Given the output schema exists and annotations are all false, the description sufficiently covers the tool's behavior, parameter semantics, failure modes, and relationship to add_panel. It is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters4/5

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

  With 0% schema description coverage, the description compensates well by explaining `esql` and `column` with concrete examples and clarifying `space`'s default behavior. `dashboard_id` and `title` are not explicitly described, but their meaning is strongly implied by 'existing dashboard' and 'panel title' context.

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

  Purpose5/5

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

  The description states a specific action: 'Add an ES|QL metric panel to an existing dashboard', and clearly describes the core behavior (run query, show one output column as a single-number metric). It also distinguishes itself from the sibling add_panel by saying field-based charts should use add_panel with a VizSpec instead.

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

  Usage Guidelines5/5

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

  The description explicitly gives an alternative: 'For field-based charts use add_panel with a VizSpec instead.' It also provides practical usage guidance by warning that the query is not validated server-side and that wrong input yields an empty panel.

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