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

With no annotations, the description carries the full burden. It discloses the permission structure, wildcard usage, and the option for a no-access token, which adds value. However, it does not mention security implications, that the token may be shown only once, or what happens on invalid input. The description adequately explains the core behavior but omits some operational consequences.

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

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

The description is well-structured: it opens with the main purpose, then explains the permissions format, and lists examples. It is slightly longer than ideal but every sentence contributes necessary information, especially the examples. It is concise for the complexity involved.

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

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

The tool has two parameters with full schema descriptions, and the description adds detailed permission examples, making it sufficiently complete for invocation. It lacks any mention of the response format (e.g., what the API returns), but since there is no output schema, that is a gap. Overall, for a creation tool with well-documented inputs, it is nearly 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by providing a detailed permission format, examples for no-access, read-only, mixed, and full-access tokens, and clarifying the wildcard '*' behavior. This enriches the parameters with practical usage semantics that the schema alone does not convey.

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

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

The description clearly states the tool's purpose: 'Create a new database token for InfluxDB Cloud-Dedicated/Clustered cluster.' It uses a specific verb ('Create') and resource ('database token'), and distinguishes it from sibling tools like cloud_delete_database_token and create_admin_token by focusing on database tokens with per-database permissions.

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

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

The description explains the context (Cloud-Dedicated/Clustered) and provides concrete examples of how to use permissions. While it does not explicitly name alternatives or say when not to use this tool, the permission format and examples make its intended use clear. It implies this is the tool for creating database-scoped tokens, contrasting with admin or resource tokens.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It discloses 'This action cannot be undone,' which is a critical irreversible trait. However, it does not mention permissions, potential cascading effects, or what happens to the token's associated resources, leaving the disclosure incomplete.

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 concise sentences that front-load the core action and then add the key irreversible caveat. No wasted words or irrelevant details.

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

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

For a simple one-parameter delete operation with no output schema and no annotations, the description adequately covers purpose and the most important caveat (irreversibility). It does not explain prerequisites or return behavior, but these are less critical for a delete tool.

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

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

The input schema has 100% description coverage for the single parameter 'token_id' as 'The ID of the token to delete.' The tool description does not add further meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the action ('Delete'), the resource ('database token'), and the specific environment ('InfluxDB Cloud-Dedicated/Clustered cluster'), which distinguishes it from the generic 'delete_token' sibling. This is a specific verb+resource+scope definition.

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 the tool is for deleting database tokens in a Cloud-Dedicated/Clustered environment, providing clear context. However, it does not explicitly contrast it with the sibling 'delete_token' or state when not to use it, so it lacks explicit alternatives/exclusions.

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

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

With no annotations, the description carries the burden. It clearly indicates a read operation ('Get details'), but it does not disclose what happens if the token is not found, whether the full token value is returned, or any permissions required. This is adequate but lacks richer behavioral detail.

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

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

A single, clear sentence that directly states the tool's purpose and scope. No fluff or redundant 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 a simple one-parameter get tool, the description and schema together are reasonably complete. The agent knows the required parameter and the resource type. However, the absence of an output schema means the return format ('details') remains vague, so it's not a 5.

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 100% (token_id is fully described in the schema), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.

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

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

The description uses a specific verb and resource: 'Get details of a specific database token by ID.' It clearly differentiates from sibling tools like list, create, update, and delete database tokens by focusing on retrieving a single token by its 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 phrase 'by ID' implies the tool is for fetching one specific token, and the context of Cloud-Dedicated/Clustered clusters helps. However, it does not explicitly mention alternatives like cloud_list_database_tokens for listing all tokens, so when-to-use guidance is only implied rather than clearly 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?

With no annotations, the description carries the burden of disclosing behavior. It clearly indicates a read-only listing operation and mentions returned fields (permissions, creation dates), but omits authentication requirements, error conditions, or scope limitations. Adequate but minimal.

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

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

The description is concise, two sentences, and front-loaded with the action ('List all database tokens'). It adds no redundant 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?

The description states the tool's scope and key return fields, which is good for a simple list tool. It could mention pagination or boundaries of 'all', but the core functionality is covered adequately.

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

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

The tool has zero parameters, so parameter semantics are not applicable. The description clarifies what the tool lists and returns, which is sufficient given the parameterless schema.

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

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

The description clearly states the tool lists database tokens for InfluxDB Cloud-Dedicated/Clustered clusters, specifying the resource (database tokens) and scope. It distinguishes itself from sibling tools like list_admin_tokens by focusing on database tokens.

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

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

The description provides context (targets cloud-dedicated/clustered clusters) but does not explicitly mention when to use this tool versus alternatives like list_admin_tokens or list_resource_tokens. The name implies usage, but no direct guidance is given.

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?

Since no annotations are provided, the description carries the full burden. It discloses a critical behavioral trait: 'Permissions completely replace existing ones - include all desired permissions.' This is valuable. However, it does not clarify whether omitted fields (like description) remain unchanged, nor does it mention response behavior, authorization requirements, or reversibility.

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

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

The description is well-structured: a clear opening sentence, a permissions format note, and bulleted examples. It is slightly padded with phrases like 'with precise control' that add little value, but overall the content is purposeful and the examples earn their place.

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

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

The description covers the main operational detail (permission replacement) and provides examples, which is good for a moderate-complexity tool. However, it lacks information about the return value or success/failure response, and it does not explicitly state that omitting optional fields leaves them unchanged. Given no output schema and no annotations, these gaps leave the description incomplete.

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

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

The input schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds substantial value by explaining the permissions format in detail, providing concrete examples (no-access, read-only, mixed, full access), and clarifying the replacement semantics. This goes beyond the schema's generic 'Array of permission objects'.

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 begins with a clear verb+resource phrase: 'Update an existing database token for InfluxDB Cloud-Dedicated/Clustered cluster.' It explicitly states what can be updated (description and/or permissions) and distinguishes itself from sibling tools like cloud_create_database_token and cloud_delete_database_token.

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 makes clear this tool is for updating existing tokens, and it provides essential usage guidance about permissions replacing existing ones. However, it does not explicitly mention alternatives or when-not-to-use (e.g., 'use create for new tokens'), though the context with sibling tools makes this somewhat implicit.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It usefully states permission scope and an important limitation (cannot manage other admin tokens), but it omits auth requirements and how the generated token secret is handled, which are important for a privileged credential 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?

A single, front-loaded sentence with no wasted words. The key purpose, permission scope, edition restriction, and limitation are all communicated efficiently.

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

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

For a privileged credential-creation tool with no annotations and no output schema, the description covers purpose and permission boundaries but omits auth prerequisites and return-value behavior (e.g., whether the token secret is surfaced). It is adequate but incomplete for safe invocation.

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

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

Schema description coverage is 100%, so both optional parameters are already well documented. The description adds no additional parameter syntax or constraints beyond what the schema provides, warranting the baseline score.

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

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

The description names a specific verb ('Create'), resource ('InfluxDB named admin token'), and scope ('full administrative permissions'), with parenthetical edition gating. It also distinguishes what the token can and cannot manage, making the purpose unambiguous.

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

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

The description implies creation of an admin token and notes Core/Enterprise-only availability, but does not explicitly state when to choose this over sibling tools like cloud_create_database_token or regenerate_operator_token. Usage is inferable but not guided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds value by detailing naming rules and cloud-specific parameter applicability, which are behavioral constraints. However, it does not mention permissions, side effects (e.g., what happens if the database already exists), or whether the operation is reversible, leaving gaps that are typically expected 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?

The description is front-loaded with the purpose and is concise at about four sentences. It efficiently summarizes naming rules and cloud-specific parameters, though some content duplicates the schema descriptions. Overall, it earns its place without being bloated.

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 tool with five parameters, no annotations, and no output schema, the description is adequate but not complete. It explains naming constraints and parameter applicability, but it omits the return value, error behavior, and prerequisites (e.g., authentication). Given the lack of structured annotations, these gaps make it only minimally viable.

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

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

The input schema already provides 100% coverage with detailed descriptions for all five parameters, including cloud-specific notes. The description's grouping of parameters by cloud type is helpful but largely redundant with the schema descriptions, so it adds only marginal semantic value beyond the baseline.

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 begins with 'Create a new database in InfluxDB', a specific verb+resource statement. This clearly distinguishes it from sibling tools like update_database, delete_database, and list_databases, so there is no ambiguity about its purpose.

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

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

The description provides clear context about which parameters apply to Cloud Dedicated/Clustered vs Cloud Serverless, guiding the agent on what to use in different environments. However, it does not explicitly state when this tool should be used instead of alternatives or mention any exclusions, such as checking if a database already exists first.

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

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

With no annotations provided, the description must fully disclose behavioral traits. It states the action but does not explicitly mention that the deletion is permanent, cannot be undone, or that it removes all data in the database. It also does not address permission requirements or error conditions, which is a significant gap for a destructive operation.

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

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

The description is two concise sentences with no redundant information. It front-loads the core function and adds a practical usage tip, making it efficient and easy to parse.

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

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

The tool is simple with one parameter and no output schema. The description covers the main action and parameter sourcing, but omits details about the permanence of deletion and potential error scenarios. Given the simplicity, the description is adequate but could be enhanced with a note on irreversible consequences.

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

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

The schema fully documents the single 'name' parameter with a description. The description adds value by instructing the agent to use the exact database name returned by list_databases, providing a reliable source for the parameter value. This goes beyond the schema's basic field description.

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

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

The description clearly states the tool's function with a specific verb and resource ('Delete a database from InfluxDB'), distinguishing it from sibling tools like create_database, update_database, and list_databases. The added guidance about using the exact name from list_databases reinforces the purpose.

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

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

The description provides clear context for when to use this tool (when a database needs to be deleted) and offers a specific prerequisite (use the exact database name from list_databases). It does not explicitly mention when not to use it or enumerate alternatives, but no direct alternatives are apparent among the sibling tools.

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

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

No annotations are provided, so the description must disclose side effects. It indicates the action (delete) but does not mention irreversibility, permission requirements, or consequences, leaving important behavioral context out.

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

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

One short sentence that is front-loaded with the action and scope, with no unnecessary words.

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

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

Given no output schema and no annotations, the description is too sparse to be fully complete; it omits return behavior, error conditions, and token type clarity, and offers no guidance on successful deletion outcomes.

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

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

The input schema fully documents token_name with description (100% coverage). The description adds no new information beyond echoing 'by name', so it meets the baseline without adding value.

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

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

The description clearly states the tool deletes an InfluxDB token by name and specifies it is Core/Enterprise only, distinguishing it from cloud token deletion sibling tools.

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

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

The description provides a scoping constraint (Core/Enterprise only) implying it is not for Cloud, but it does not name alternative tools or specify when to use this versus other token deletion options.

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

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

With no annotations, the description carries the burden of disclosing behavior. It adds a key behavioral trait: 'Unknown tag/field roles are returned as category=unknown instead of guessed.' This clarifies non-guessing behavior. However, it does not disclose other aspects like return format, error handling, or read-only safety, leaving some gaps.

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

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

Two sentences, front-loaded with the purpose, followed by a clear usage directive. No filler or redundant repetition of schema fields. Every sentence earns its place, making it highly concise and well-structured.

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

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

The tool has no output schema and no annotations, so the description must carry more weight. It explains the purpose, a key behavior, and a usage scenario, which is decent. However, it does not describe the returned schema structure or error behavior, leaving some contextual gaps for an agent to fully rely on 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 100%, so the schema already fully documents both parameters (db, table). The description adds no additional parameter semantics beyond the existing schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: 'Describe table schema using InfluxDB metadata.' It distinguishes its behavior by noting unknown roles are returned as 'category=unknown' rather than guessed. However, it does not explicitly differentiate from the similarly named sibling tool 'get_measurement_schema', so it misses 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?

Provides explicit usage context: 'Use this before retrying SQL queries that fail on quoted wildcard or unknown-field selectors.' It gives a clear workflow instruction: 'expand matching fields explicitly and run one bounded query_sql.' It does not mention when not to use it or alternatives, but the guidance is specific and actionable.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses deprecation status, the default JSON output, that Cloud Dedicated/Serverless/Clustered support only JSON, and a large-dataset safety protocol (COUNT(*) first, then LIMIT/OFFSET). It stops short of describing error behavior, authentication requirements, or pagination/truncation semantics of the response, which keeps it below 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?

Deprecation and the sibling hand-off are correctly front-loaded, and the version-specific requirements are grouped under a heading. It loses a point for redundancy, since the advice to use query_sql appears in both the opening and the closing lines.

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 three-parameter tool with no output schema and no annotations, the description covers the important failure modes: version-gated format support, unsafe result sizes, and SQL dialect differences that would otherwise produce malformed queries. Return-value structure is only partly described, but the main operational risks are addressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning about the `query` parameter: version-specific SQL rules for GROUP BY column inclusion and CAST/alias requirements for aggregations, plus the row-volume strategy. That is query-construction semantics the schema does not provide.

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 ("Execute a SQL query against an InfluxDB database") and immediately scopes it against the sibling query_sql and, implicitly, query_influxql. An agent can distinguish this from the other query tools without reading 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?

Explicitly says the tool is deprecated since 2.0.0 and that query_sql should be used for SQL, while giving a concrete reason to still call it (compatibility with existing clients) and a second routing condition ("For bounded reads that report completeness, use query_sql"). The guidance is clear, but the twice-repeated hand-off to query_sql without saying when execute_query is the correct choice beyond legacy compatibility leaves mild ambiguity.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It mentions support for 'specific categories or keyword search', which is a behavioral trait, but lacks details about how the tool actually behaves (e.g., whether it returns a list, requires follow-up, or has restrictions). This is minimal but not absent.

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

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

Two short, front-loaded sentences. Every word is informative and no filler exists. The structure is clean and easily parsed.

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 zero-parameter, no-output-schema tool, the description conveys the core purpose but omits practical details like how the 'keyword search' is initiated given no parameters. It is adequate but leaves questions about the interaction model, so it is not fully complete.

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

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

The tool has zero parameters, so there is no schema detail to augment. The description's mention of categories and keyword search adds context that could guide invocation, though it is somewhat underspecified. Baseline for 0 parameters is 4, and the description does not detract.

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

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

The description clearly states the tool provides 'help and troubleshooting guidance for InfluxDB operations', using a specific verb and resource. It is distinct from sibling tools, which are all operational (queries, tokens, databases), so the purpose is unambiguous.

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

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

The description implies usage as a help resource but does not explicitly state when to prefer it over other tools or any exclusions. The phrase 'Supports specific categories or keyword search' hints at interaction modes but stops short of clear guidance on when to invoke this tool.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool uses InfluxDB's information_schema.columns, implying a read-only metadata query. However, it does not clarify permissions, response format, or the exact meaning of 'all versions', leaving behavioral gaps.

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

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

The description is two sentences with no wasted words. It front-loads the core action and includes a useful technical detail about how discovery works, making it efficient and well-structured.

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

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

For a simple one-parameter list tool, the description covers the main purpose and mechanism. Minor ambiguity around 'all versions' and lack of return structure keep it from being fully complete, but it is sufficient for most invocation scenarios.

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

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

The schema fully describes the 'database' parameter with 100% coverage. The description only repeats 'database/bucket' and adds no extra constraints or format details, warranting the baseline score of 3.

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

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

The description clearly states the tool returns a list of all measurements (tables) in a database/bucket, using a specific verb and resource. It also distinguishes itself from sibling tools like list_tables by specifying InfluxDB context and 'all versions', making the purpose unambiguous.

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

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

The description implies when to use the tool: when you need to discover measurements in an InfluxDB database/bucket. However, it does not explicitly mention alternatives or when not to use it, leaving some room for misinterpretation.

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

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

With no annotations provided, the description is responsible for behavioral disclosure. It states it 'Shows column names, types, and categories' which implies a read-only operation, and adds the behavioral nuance of returning schema for 'all versions'. However, it does not mention potential errors, pagination, or limits, leaving some gaps.

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

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

The description is compact, two sentences long, and front-loads the action ('Get the schema...'). Every word adds value, with no filler or repetition.

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

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

For a simple read-only schema retrieval tool with two parameters and no output schema, the description covers the return value fields (column names, types, categories) and version scope. It could be enhanced by clarifying the relationship to similar sibling tools, but overall it is sufficiently 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 100% (both 'database' and 'measurement' have clear descriptions). The tool description adds no additional parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Get' and the specific resource: the schema (column information) for a specific measurement/table. It further details what is shown (column names, types, categories) and includes the scope '(all versions)', distinguishing it from a simple 'describe' tool.

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 usage is implied: use this tool to retrieve schema information for a measurement. However, there is no explicit guidance on when to use this vs. similar siblings like 'describe_table' or 'list_tables', and no mention of alternatives or exclusions.

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

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

With no annotations, the description must carry the behavioral burden, and it does add real context: health and ping are distinct endpoints, any success confirms health, and a denied credential does not prove permitted databases are down. It still omits what a response looks like, whether latency/status fields are returned, and whether this touches credentials or state.

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?

Four short sentences with no filler, and the core action leads. Some phrasing ('Check health and ping separately') is compressed to the point of ambiguity, which slightly undercuts front-loading.

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 no-param, no-output-schema probe, the description should explain the shape of the result or at least what counts as a failure. It provides useful interpretation caveats but leaves the agent unable to predict the response, and there are no annotations to cover the 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?

The tool takes zero parameters and the description correctly introduces no parameter discussion, so there is nothing to mis-describe. Baseline for a 0-parameter tool applies.

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 opening 'Check health and ping separately' indicates a health-check operation, but it never states what is being checked (the server? a database? a cluster endpoint?) and the word 'separately' is ambiguous — it may describe two distinct endpoints or two modes. An agent can infer a liveness probe, but not the target resource.

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

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

There is no statement of when to call this versus siblings like investigate_database, load_database_context, or query_sql, and no prerequisites. The sentences about credential denial and client initialization guide interpretation of results rather than use, which is useful but not selection guidance.

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

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

No annotations are provided, so the description carries the full burden. 'Bounded reads' usefully signals that sampling is capped rather than a full table scan, which is real behavioral information, but there is no disclosure of read-only safety, required permissions, or the cost/latency of sampling many tables at once.

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

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

A single well-packed sentence with the core capability front-loaded and no filler. It could be marginally tighter by separating the discovery mode from the sampling mode, but nothing in it is wasted.

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 five-parameter exploration tool with no output schema and no annotations, the description should say what comes back (table names, column schemas, sample shape) and what maxTables/default-20 truncation implies. It covers the two operating modes but leaves the result contract and partial-coverage caveats unstated.

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 60%: db, includeSamples, and sampleWindowHours are documented inline, while maxTables and sampleRowsPerTable are not. The description supplies partial compensation by saying sampling happens 'from each table' and is 'bounded', hinting at per-table limits, but it never explains what maxTables truncation means for completeness of the discovery result.

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: 'Discover tables and schemas in a database', plus an optional sampling mode. An agent can tell it is an exploration tool rather than a query executor, but it never names list_tables or describe_table, which occupy adjacent ground in the sibling list.

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

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

The phrase 'optionally sampling recent rows' implies when to set includeSamples, but there is no explicit when-to-use versus list_tables, describe_table, or query_sql, and no guidance on when sampling is wasteful. Usage must be inferred from the name and the word 'investigate'.

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

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

There are no annotations, so the description carries the transparency burden. It implies a read-only listing operation and provides useful context about named admin tokens' access, but it does not disclose return format, permissions, or any side effects. This is adequate but not rich.

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

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

The description is concise, consisting of two sentences that front-load the core action. Each sentence adds relevant information: the listing scope and the nature of admin tokens.

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

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

The tool is simple with one optional parameter and no output schema. The description covers the purpose, filtering, licensing constraint, and token context. It does not explain the return structure, which would be helpful without an output schema, but the overall completeness is strong for a list operation.

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

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

The schema fully describes the tokenName parameter with a case-insensitive partial-match filter. The description only repeats that filtering is optional, adding little beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool lists all admin tokens (operator and named), with optional filtering. It explicitly distinguishes itself from sibling tools like list_resource_tokens by specifying 'admin tokens' and the operator/named 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?

The description conveys its use case by naming the resource type and mentions the 'Core/Enterprise only' constraint. However, it does not explicitly mention alternatives or when not to use it, though the scope is clear from the name and description.

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

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

With no annotations, the description carries the full burden and does add a meaningful caveat: visibility may be incomplete and read permissions are unknown unless independently observed. This is valuable honesty for a zero-parameter listing tool, though it omits return shape and any ordering or pagination 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?

Two tight sentences with the scope stated first and the caveat second. No filler, and each sentence contributes information about how to interpret the result.

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

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

For a simple, zero-parameter list tool with no output schema, the description covers purpose and a key limitation. It could say more about what a result entry contains (name, id, status), but nothing critical to invoking the tool 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?

The tool takes zero parameters, so the schema baseline of 4 applies. There are no parameter semantics for the description to clarify.

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 ("List databases") and scopes it to credentials, which clearly distinguishes it from mutation siblings like create_database or delete_database. It does not explicitly name a sibling alternative, but the resource is unambiguous.

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

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

The credential-visibility scope implies when this tool is relevant, but there is no explicit guidance on when to prefer it over siblings such as list_tables or investigate_database. 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?

With no annotations provided, the description carries the burden of behavioral disclosure. The word 'List' implies a non-mutating read operation, and the clarification 'also called measurements' adds terminological context. However, it does not mention pagination, authentication, or whether the output includes all tables by default.

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

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

The description is a single concise sentence, front-loaded with the verb and resource. Every word earns its place, and there is no redundant or extraneous 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 a simple list tool with one parameter and no output schema, the description is adequate: it states what is listed and where. It could mention that the output is a list of table names, but this is strongly implied by the verb 'List' and the context is otherwise 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?

The schema fully documents the single parameter 'db' with description 'Database name to inspect', so schema coverage is 100%. The tool description adds no additional parameter semantics beyond restating that the operation is within an InfluxDB database, which is already clear from the parameter description.

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

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

The description uses a specific verb 'List' with a clear resource ('tables, also called measurements') and scope ('in an InfluxDB database'). This clearly distinguishes it from sibling tools like list_databases and describe_table, even though get_measurements may overlap.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as get_measurements or query_sql. The description only states what the tool does, offering no context about when it is preferred or when other tools should be chosen.

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

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

With no annotations, the description carries the full behavioral burden. It mentions the conditional nature ('if available') and the optional context, but does not explicitly state that it is a non-modifying read operation or describe what happens after loading (e.g., whether it returns data or sets internal state). This is a moderate gap for a simple 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?

The description is two sentences, front-loaded with the primary action and followed by value rationale. Every sentence serves a purpose: the first states what it does, the second explains when and why. No wasted words.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description is mostly complete: it explains purpose, timing, and optionality. However, it does not specify what the tool returns or how the context is delivered (e.g., as a string, or loaded into memory), which leaves a small gap for the agent.

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

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

The schema has zero parameters, so the baseline is 4. The description adds meaningful context about what the loaded data contains (e.g., 'database structure, business context, or personal notes'), which implicitly clarifies that the tool itself does not require inputs. There are no parameters to elaborate on.

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

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

The description clearly states the tool's function: 'Check for and load custom database context if available.' It uses a specific verb ('load') and resource ('database context'), and distinguishes itself from sibling tools by highlighting its role as an optional context provider that should be checked first.

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

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

The description explicitly provides usage guidance: 'Always check this first as it can significantly speed up analysis and clarify data nuances.' This tells the agent when to use the tool (before analysis) and why, while noting context is optional—so no misuse if absent.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it states read-only and bounded behavior, rejects SELECT INTO and destructive statements, explains alias conflict rejection, describes deployment-dependent output formats, and says results include rows, warnings, and metadata. It also tells the agent what must be reported from the results.

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

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

The purpose is front-loaded and the sentences are information-dense rather than padded. It is somewhat packed with multiple operational details, but each item is relevant to correct invocation and result handling.

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

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

For a complex query tool with no annotations and no output schema, the description covers the important gaps: what it runs, what it refuses, how aliases behave, deployment-dependent formats, what the response contains, and how to interpret completeness and warnings. It also points to get_help for deeper reading guidance.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining alias equivalence and rejection of conflicting db/database or q/query pairs, plus output-format availability by deployment and the JSON default.

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

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

The description gives a specific verb and resource: 'Run one bounded, read-only InfluxQL query against an InfluxDB 3 database.' It also explicitly distinguishes this tool from query_sql and frames the scope around InfluxQL rather than generic query execution.

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

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

It explicitly says to prefer query_sql for SQL prompts and to use InfluxQL regex field selection only when the user explicitly asks for InfluxQL or regex field matching. That is clear routing guidance with an exclusion condition.

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

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

No annotations are present, so the description carries the full burden and does: read-only, single/bounded execution, JSON default, per-deployment format support, and the required reporting contract (metadata.completeness, cap, warnings, row_count). It also discloses that conflicting alias pairs are rejected.

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 constraint, and every sentence carries operational information. The middle section is dense and long-sentenced, but none of it is 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?

For a complex, no-output-schema query tool, the description covers return shape (structured rows, warnings, query metadata), format availability, alias handling, and a recovery path, plus a pointer to get_help for result interpretation. Nothing an agent needs to invoke it 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 100%, so the baseline is 3; the description adds semantics the schema lacks, notably that db/database and q/query alias pairs must agree or be rejected, and that non-JSON formats are refused on Cloud/Clustered deployments. It does not restate maxRows fallback or timeout behavior beyond 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 first sentence states a specific verb, resource, and constraint set: "Run one bounded, read-only SQL query against an InfluxDB 3 database." It also separates itself from the sibling query_influxql by naming that tool and its distinct use case.

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?

Explicit routing: use query_influxql "only when the user explicitly asks for InfluxQL or regex field selection." It also gives a concrete fallback workflow (call describe_table, expand fields, retry one bounded query) for wildcard-in-quoted-selector cases.

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

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

With no annotations provided, the description carries full disclosure burden. It explicitly states the token is invalidated, the action is irreversible, returns the new token value, and requires explicit user confirmation before proceeding. This covers key behavioral consequences and prerequisites beyond what the tool name alone implies.

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

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

The description is three sentences, each earning its place: purpose, return value, and critical warnings. It is front-loaded with the action and resource, followed by necessary cautionary notes. No redundant or vague filler.

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

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

The tool is simple (0 params, no output schema) and the description fully covers what it does, what it returns ('the new token value'), and the critical downside (invalidates current token, irreversible). The confirmation requirement is also included, making the description complete for safe invocation.

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

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

The tool has zero parameters and an empty input schema, so the baseline is 4. The description adds no parameter details because none exist, which is appropriate and sufficient.

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

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

The description clearly states 'Regenerate the InfluxDB operator token' which is a specific verb+resource combination. It also scopes to 'Core/Enterprise only,' distinguishing it from sibling tools like create_admin_token or cloud_create_database_token. The focus on 'operator token' uniquely identifies its purpose.

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

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

The description provides clear context: it is for Core/Enterprise, requires explicit user confirmation, and emphasizes irreversibility. It does not explicitly name alternatives or exclusions, but the 'only' scope and uniqueness of the operator token implicitly guide usage. It falls short of a 5 by not mentioning when not to use or alternative token operations.

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

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

With no annotations provided, the description carries the full burden. It discloses product-specific limitations (e.g., Core/Enterprise can only modify retentionPeriod) and the Core v3.2.0+ requirement, adding meaningful behavioral context. It does not mention authorization, reversibility, or side effects, but the included constraints provide more than minimal transparency.

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

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

The description is two sentences: the first states the core purpose, and the second efficiently maps product variants to allowed fields. Every clause earns its place with no filler or redundancy, and it is structured to front-load the primary intent.

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

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

Given the parameter count (6) and no output schema, the description covers all major usage scenarios across InfluxDB product types and includes version constraints. It does not describe return values or error cases, but for a configuration update tool with strong parameter schema coverage, the provided context is largely sufficient.

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

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

The input schema already documents each parameter with 100% coverage, so the description need not repeat definitions. It adds value by grouping parameters by product type, clarifying that fields like maxTables and maxColumnsPerTable are only for Cloud Dedicated/Clustered, which is not immediately obvious from the schema alone.

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

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

The description clearly states the tool updates InfluxDB database configuration and specifies exact fields per product variant, which distinguishes it from sibling tools like create_database and delete_database. The verb 'update' plus the resource 'database configuration' is specific and unambiguous.

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

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

The description provides clear guidance on which parameters to use for each InfluxDB product type (Cloud Dedicated/Clustered, Cloud Serverless, Core/Enterprise) and includes a version prerequisite. However, it does not explicitly contrast with alternative tools or state when not to use this tool, so it stops short of a perfect score.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It does this well by explaining line protocol syntax, field value types, timestamp precision requirements, and escaping needs. It also states 'all versions' and batch support. It lacks details on error handling or side effects beyond writing, but the write operation itself is clearly described with practical examples.

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

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

The description is long (~200 words) but well-structured with clear sections (Line Protocol Syntax, Components, Field Value Types, Examples, Important). It front-loads the purpose and then provides necessary format details. Some redundancy, like repeating 'comma-separated key=value pairs,' but the structured format and examples justify the 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?

Given the tool complexity (custom line protocol format), 5 parameters, no annotations, and no output schema, the description covers syntax, types, examples, precision, and escaping. It does not explicitly state return values or error behavior, but for a write tool this is reasonably complete. The presence of a detailed schema further supplements parameter usage.

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 100%, so the baseline is 3. The description adds substantial value beyond the schema by explaining the line protocol structure, field types (strings, floats, integers with 'i', booleans), and the importance of matching precision to timestamp format. These details directly help construct the 'data' parameter correctly, which the schema description only handles at a high level.

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

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

The description opens with a specific verb and resource: 'Write data to InfluxDB using line protocol format (all versions).' It clearly distinguishes from sibling query tools by indicating this is for writing data, not reading or managing. The line protocol format is explicitly named, making the tool's core function unambiguous.

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

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

The description provides clear context for when to use the tool: it supports single records or batches and emphasizes precision handling and escaping. While it doesn't explicitly mention alternatives, the sibling tools are predominantly read/query/management operations, so the usage context is clear. No explicit when-not-to-use guidance, but the detailed examples and syntax instructions inherently guide correct invocation.

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