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 only states the action (add a section) but does not explain side effects, idempotency, whether existing sections are overwritten, what the response looks like, or any special behavior for duplicate identifiers.

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

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

The description is a single, front-loaded sentence with no redundant words. It communicates the core action efficiently and is appropriately sized for the tool's purpose.

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 a nested object parameter and no output schema or annotations. The description omits critical context such as error conditions, return values, behavior on duplicate identifiers, and whether the menu must already exist. This leaves the agent under-informed for a mutation 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 already provides descriptions for clientName and the nested section properties. The description adds little beyond the context of 'dashboard menu', and with 50% schema coverage, it doesn't fully compensate for undocumented aspects like the section object's purpose or constraints.

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

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

The description uses a specific verb ('Add'), names the resource ('a new section'), and identifies the target ('a client's dashboard menu'). It clearly distinguishes from siblings like update_menu_section and remove_menu_section.

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

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

Usage context is implied by the verb 'add' versus sibling names like 'update' and 'remove', but the description does not explicitly state when to use this tool instead of alternatives or mention any prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states 'read-only', which is a useful safety trait, but does not elaborate on potential side effects (e.g., whether $out/$merge stages are blocked), execution limits, or authorization requirements. The read-only claim may also be misleading if the pipeline allows write stages.

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 sentence, front-loaded with the action and resource. It is concise with no wasted words, making it easy to parse quickly.

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 only two parameters and no output schema, the description is adequate but not rich. It omits return behavior, error conditions, and any restrictions on pipeline stages. The presence of sibling tools for listing collections partially compensates for missing context.

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%, with clear descriptions for both 'collection' and 'pipeline'. The description adds no extra meaning beyond the schema, meeting the baseline for schema-heavy tools.

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 ('Execute'), a clear resource ('MongoDB aggregation pipeline on eta data'), and a key qualifier ('read-only'). This clearly distinguishes it from sibling tools like query_eta_data or count_eta_documents, 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.

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

The description provides no guidance on when to use this tool versus alternatives such as query_eta_data, count_eta_documents, or get_eta_collection_stats. It does not mention scenarios where aggregation is preferred or any 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?

No annotations are provided, so the description carries the full burden. It accurately states the core behavior (counting with optional filter) but does not disclose the return type (e.g., an integer) or any edge cases. However, for a simple read-only count operation, this is minimally sufficient.

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

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

The description is a single, front-loaded sentence that directly states the action and scope. Every word earns its place, with no redundancy or filler.

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

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

For a tool of this simplicity, the description adequately covers the core functionality. The schema covers parameters, and the sibling list provides context. However, it does not describe the return value or explicitly differentiate from query_eta_data, which could cause the agent to mis-select. Overall, it is nearly complete but leaves a few gaps.

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

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

The input schema has 100% coverage for both parameters, with descriptions already explaining 'query' (optional, defaults to {}) and 'collection'. The description adds no additional parameter meaning beyond what the schema provides, 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 counts documents in a collection with an optional query filter. The verb 'count' and resource 'documents in a collection' are specific and distinguish it from sibling tools like query_eta_data (returns documents) or aggregate_eta_data (performs aggregations).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is for obtaining a count rather than retrieving documents, nor does it reference any sibling tools or exclusions. For an agent, the differentiation from query_eta_data is implied but not explicit.

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

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

With no annotations, the description carries full burden. It discloses the source (GitHub) and that it returns the complete current config, which is useful. However, it does not mention any side effects (e.g., network call, authentication) or confirm non-mutating behavior explicitly, leaving a minimal but adequate level of 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 a single, front-loaded sentence with no redundant words. Every word contributes meaning (verb, scope, source).

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 getter, the description provides enough context: it identifies the exact data being fetched (complete dashboard config) and the source (GitHub). No output schema exists, but the description's mention of 'complete configuration' gives a high-level idea of the return value.

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 schema coverage is trivially 100%. The description appropriately doesn't need to add parameter details. Baseline 4 applies because the schema fully handles parameters.

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

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

The description uses a specific verb ('Get') and identifies a clear resource ('current complete dashboard configuration') plus source ('from GitHub'). It clearly distinguishes from sibling tools that add, update, remove, or upload dashboard-related items.

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

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

The description implies usage as a read-only getter, especially given sibling tools are mutation-focused, but it does not explicitly state when to use it versus alternatives or provide exclusions. This is implied guidance rather than explicit direction.

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

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

Without annotations, the description carries the transparency burden. It reveals that the tool returns statistics and implies read-only behavior via 'Get', but it does not disclose return format, side effects, or any limitations. It adds some context but not deep 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?

The description is a single, well-structured sentence that front-loads the purpose and provides examples with 'etc.' No unnecessary words, 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?

For a simple single-parameter read tool with no output schema, the description gives sufficient orientation by listing example stats and implying a summary object. It could be more explicit about return format, but the low complexity and clear examples make it adequately 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 describes the only parameter 'collection' with 'Name of the collection to get stats for', achieving 100% coverage. The description does not add further clarification about the parameter beyond what the schema already provides, so it meets 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 clearly states the operation with a specific verb (Get) and resource (statistics about a collection), including examples (document count, size, indexes). This distinguishes it from sibling tools like count_eta_documents or query_eta_data, which have different purposes.

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 indicates the tool's purpose but does not explicitly address when to use it over related tools or mention exclusions. Usage is implied for retrieving summary statistics, but no alternatives or conditions are provided.

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

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

No annotations are provided, so the description carries the full transparency burden. It only restates the basic operation and does not disclose behavior such as result format, ordering, limits, or how the optional query filter affects results. The schema provides some parameter details, but the description adds no behavioral context beyond the name.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It communicates the essential purpose 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?

Given the absence of annotations and output schema, the description is minimally viable but incomplete. It lacks information about return values, behavior with the optional query filter, and any context distinguishing it from sibling tools.

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

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

The input schema provides 100% coverage with descriptions for all three parameters (collection, field, query). The description adds no additional parameter semantics, 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 uses the specific verb 'Get' and clearly states the resource: 'distinct values for a field in a collection'. It accurately communicates what the tool does, though it does not explicitly differentiate from sibling tools like aggregate_eta_data or query_eta_data.

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

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

The description provides no guidance on when to use this tool versus alternatives such as query_eta_data or count_eta_documents. It simply states the function without any context on selection criteria 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. 'List all collections' clearly implies a read-only operation, but it does not disclose output format, ordering, or whether system collections are included. It is minimal but not misleading.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the tool's purpose in eleven words, earning every word.

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 list operation, the description covers the core purpose and target database. However, without an output schema, it would benefit from specifying that the return is a list of collection names, though this is likely implied by 'list all collections'.

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 input schema has no fields. The description correctly implies that no arguments are needed, and there is nothing else to document. The baseline for zero parameters is 4.

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 the specific verb 'list' and identifies the exact resource 'all collections in the eta_raw_data_db MongoDB database'. This clearly distinguishes it from sibling tools that query data, count documents, or fetch stats.

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—use this tool to enumerate collections in the specified database—but it does not explicitly mention alternatives or when not to use it. Sibling tools like query_eta_data or get_eta_collection_stats serve different purposes, but no direct comparison 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?

The description explicitly marks the tool as 'read-only', which is a crucial behavioral safety trait given that no annotations are provided. This adds context beyond the schema, but it does not disclose other behaviors like return format or permission requirements, though the read-only note is substantial.

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 sentence of 12 words, front-loading the verb and object. It is clear, direct, and free of unnecessary wording, 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?

Given the moderate complexity (6 parameters, nested objects) and lack of annotations or output schema, the description is too minimal. It does not explain return values, relationship to sibling tools, or when to choose it over aggregate_eta_data. The read-only note is helpful, but overall contextual guidance is insufficient.

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 provides detailed descriptions for all 6 parameters (100% coverage), including examples for sort, query, projection, and limit. The tool description does not add any additional parameter semantics, so it aligns with the schema-driven 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 states a clear verb and resource: 'Query data from a collection in the eta_raw_data_db MongoDB database.' It distinguishes from some siblings by focusing on direct collection queries, but does not explicitly contrast with aggregate_eta_data or list_eta_collections, so it lacks explicit 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?

There is no guidance on when to use this tool versus alternatives. It does not mention that list_eta_collections can be used to discover collections or that aggregate_eta_data is better for aggregation pipelines. The agent must infer usage from the tool name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states the removal action without addressing permanence, side effects, idempotency, or permissions, which are critical 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 a single, clear sentence with no superfluous content. It is front-loaded with the action and resource, making it highly concise and 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?

Given the absence of annotations and output schema, the description must provide complete context. It fails to disclose return values, error behavior (e.g., missing identifier), or consequences of removal. For a mutation tool, this is a significant 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?

Schema description coverage is 100% for the two parameters (clientName, identifier), so the schema already documents them. The description adds no additional parameter meaning, 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 states a specific verb ('Remove') and resource ('section from a client's dashboard menu'), clearly distinguishing it from siblings like add_menu_section and update_menu_section.

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

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

The description provides no guidance on when to use this tool versus alternatives. It only defines the action, with no mention of conditions, prerequisites, or exclusion cases. The purpose implies usage, but explicit guidance is 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?

No annotations exist, so the description carries the full burden of behavioral disclosure. It does not state whether updates are partial or replace the entire section, whether changing the identifier impacts references, or what response or side effects occur.

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

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

The description is a single, front-loaded sentence with no redundant words or filler. It efficiently conveys the core action and scope.

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

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

For a mutation tool with a nested updates object and no output schema, the description lacks behavior around partial vs. full updates and result/error semantics. However, the schema fully documents all parameters, making the tool minimally selectable without further description.

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

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

The input schema provides 100% coverage with descriptions for clientName, identifier, and the updates object and its fields. The description itself adds little semantic nuance beyond what the schema already states, so it hits the high-schema-coverage 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 uses a specific verb ('update') and identifies the resource ('a specific section in a client's dashboard menu'), clearly distinguishing it from sibling tools like add_menu_section, remove_menu_section, and get_dashboard_config.

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

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

No guidance is provided about when to use this tool instead of add/remove/get siblings, and there are no prerequisites or exclusions mentioned. The tool name and description alone do not establish usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the high-level actions and omits important side effects such as whether existing files are overwritten, whether the client must exist, how the unique filename is generated, or how menu section links are auto-generated. This is insufficient for a mutation tool.

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

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

The description is a single, clear sentence that front-loads the core action. It contains no redundant information and is efficiently structured for quick comprehension.

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?

Despite having 5 parameters, a nested object, no output schema, and no annotations, the description remains minimal. It does not clarify prerequisites (e.g., existing client), outcomes beyond 'add it as a menu section', error behavior, or return values. The schema covers parameter definitions but not the operational context needed 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 schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides; it simply references 'HTML dashboard file' which aligns with the fileContent parameter. No additional semantics are offered.

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: 'Upload an HTML dashboard file to S3 and add it as a menu section'. It uses a specific verb (upload) and resource (HTML dashboard file), and the dual action (upload + add menu section) distinguishes it from the sibling add_menu_section, which likely only handles menu sections.

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 by stating the combined action, but it provides no explicit guidance on when to use this tool versus alternatives like add_menu_section. There is no mention of exclusions or prerequisites, leaving the agent to infer that this is appropriate when both file upload and menu addition are needed.

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