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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description itself adds no additional behavioral context, though the schema's pipeline description does disclose mandatory $unset stages and response size limits, which are not in annotations. The description alone is transparent 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 main description is concise but minimal, while the pipeline parameter description is extremely long (several hundred words), albeit well-organized with section headers and an example. Some instructions are repeated (e.g., 'use the collection-indexes tool') and the length may challenge readability, though it is justified by the tool's complexity.

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

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

An output schema exists, and the pipeline description covers advanced features (vector search, hybrid fusion, reranking) and mentions responseBytesLimit. However, the tool-level description lacks a high-level overview of what aggregation can do or when to prefer it over simpler tools, leaving some context to the AI agent's prior knowledge.

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 pipeline parameter description is exceptionally detailed, covering $vectorSearch with classic and auto-embed variants, $search, $rankFusion, $scoreFusion, $rerank, pre/post-filtering rules, and mandatory $unset. This goes far beyond the basic schema and provides essential operational guidance for complex aggregations.

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 'Run an aggregation against a MongoDB collection' uses a specific verb+resource and clearly distinguishes from the sibling tool 'aggregate-db' by explicitly targeting a collection. It unambiguously communicates the core operation.

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 does not explicitly state when to use this tool versus alternatives like 'find' or 'count', and no exclusions are mentioned. The extensive pipeline rules in the schema cover how to build an aggregation but not when to choose this tool over siblings, so usage is only implied.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description adds no additional behavioral context such as side effects, permissions, output format, or performance implications. With annotations present, the description is neutral but does not enrich understanding beyond the structured fields.

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 that immediately states the tool's purpose. 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?

For a tool invoking arbitrary MongoDB aggregation pipelines, the description lacks context about database-level vs collection-level operations, when to use it, or the requirement for the first stage. The sibling tool 'aggregate' creates ambiguity. The schema and output schema provide technical detail, but the description fails to orient the agent 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?

Schema description coverage is 100% for all 4 parameters, so the schema carries the parameter documentation. The description itself does not mention any parameters, 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 runs an aggregation against a MongoDB database, providing a specific verb and resource. However, it does not differentiate from the sibling tool 'aggregate', which likely refers to a collection-level aggregation.

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 on when to use this tool vs alternatives such as 'aggregate'. The schema mentions the pipeline must start with database-level stages, but this is not in the tool description and does not constitute usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, while the description adds behavioral context by stating each call establishes a new independent connection and that multiple connections can be active simultaneously. This adds value beyond the annotations and does not contradict them.

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 exceptionally concise, consisting of two sentences that front-load the core action and return value. There is no filler or redundant repetition of schema 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 covers the main purpose, return value, and the key behavioral nuance of independent connections. Given the presence of an output schema and annotations, this is enough for a simple connect tool. It lacks details on cleanup or connection limits, but these are not critical for an initial selection decision.

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?

All three parameters have complete descriptions in the schema, so the description does not need to elaborate on them. The baseline of 3 is appropriate because the schema covers parameter semantics fully, and the description adds no extra parameter-level guidance.

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 connects to a MongoDB Atlas cluster and returns a connectionId for use with other MongoDB tools, identifying the specific action and resource. It does not explicitly distinguish this from the sibling 'connect' tool, so it misses the top score.

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 frames usage through the connectionId flow for other tools and notes that every call creates a new independent connection. It provides clear context but does not mention alternatives or exclusions, such as when to use 'connect' or 'disconnect'.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by specifying that it returns a sample of the most recent slow query logs (max 50) and listing the types of recommendations, which gives insight into response content beyond the annotations.

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

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

The description is a single, front-loaded sentence with no redundant wording. It efficiently conveys the tool's purpose and main included features, 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?

Given the tool's moderate complexity (5 parameters) and the presence of an output schema, the description does not need to explain return values. The description, combined with the schema's parameter documentation, provides sufficient context for an agent to invoke the tool correctly. A minor gap is that the description doesn't mention parameter interdependencies (e.g., 'since' only relevant for slowQueryLogs), but the schema covers this.

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%, meaning each parameter is documented in the schema. The description does not add further meaning to the parameters themselves, so the baseline score of 3 applies. The description's mention of 'operations' aligns with the schema's operation enum, but no additional semantic detail is provided.

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 ('Get') and resource ('MongoDB Atlas performance advisor recommendations and suggestions'), and enumerates the specific operations included (suggested indexes, drop index suggestions, schema suggestions, slow query logs). This distinguishes it from all sibling tools, none of which cover performance advisor functionality.

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 explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. However, the schema descriptions for parameters (e.g., projectId suggests using atlas-list-projects if only name is known) offer some contextual usage hints, but the tool description itself lacks this. Usage context is only implied by the tool's name and purpose.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context (e.g., authentication requirements, rate limits, or side effects) beyond what the annotations already convey. It only restates the inspect action, which is consistent with the read-only hint.

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, front-loaded sentence that delivers the core purpose without unnecessary words. It is efficient and easy to parse, with no filler 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?

Given the tool's simplicity (one parameter, output schema present) and strong annotations, the description is nearly complete. It could have explicitly mentioned that it lists the access list entries, but the current phrasing along with the output schema sufficiently conveys the expected behavior. Minor ambiguity exists in the phrase 'with access to your MongoDB Atlas clusters,' but it does not hinder usability.

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 a single parameter (projectId) with full description coverage (100%), and the description does not add any additional meaning about the parameter. Since schema coverage is high, the baseline of 3 applies; the description contributes no extra parameter-level insight.

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 ('Inspect') and a well-defined resource ('Ip/CIDR ranges with access to your MongoDB Atlas clusters'), which aligns with its name. This distinguishes it from sibling tools like atlas-inspect-cluster, which targets cluster configuration rather than access lists.

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 for inspecting access list entries but does not provide explicit context for when to choose this tool over alternatives such as atlas-inspect-cluster. There is no mention of exclusions or sibling comparisons, leaving the agent to infer the tool's role from its 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?

The description 'Inspect metadata' aligns with the readOnlyHint and destructiveHint annotations, but adds no behavioral context beyond what the annotations already declare. It does not disclose additional details such as return format, limitations, or any special behaviors. Since it provides no new information beyond the structured annotations, it falls short of adding value.

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 that is front-loaded with the verb 'Inspect' and contains no redundant words. It is concise and effectively communicates the core purpose without unnecessary elaboration.

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 presence of readOnlyHint and destructiveHint annotations, full schema description coverage, and an output schema, the description is adequate for a simple metadata inspection tool. It could have explicitly contrasted with atlas-list-clusters to aid selection, but the structured data sufficiently covers the essential selection 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?

The input schema has 100% description coverage for both parameters ('Atlas project ID' and 'Atlas cluster name'), so the schema already provides sufficient semantics. The description does not add any additional parameter-level detail beyond what is already structured, but this is acceptable given the baseline for high schema coverage.

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

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

The description uses the specific verb 'Inspect' and clearly identifies the resource as 'metadata of a MongoDB Atlas cluster', specifying a single cluster scope. This distinguishes it from sibling tools like atlas-list-clusters and atlas-connect-cluster, which are not about inspecting detailed metadata.

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 does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate, leaving the agent to infer usage solely from the tool's name and brief 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?

Annotations already declare read-only and non-destructive behavior. The description adds valuable context beyond that: it clarifies that the tool returns raised alerts rather than configurations, and explains the default status behavior. This is useful behavioral information an agent would not infer from annotations alone.

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 core purpose, and directly follows with the key distinction and status guidance. Every sentence earns its place, with no redundant or verbose content.

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?

This is a simple list operation with a full schema and output schema. The description adequately covers the essential context—what alerts are returned, how to filter them, and the distinction from configurations—making it complete for an AI agent to use correctly.

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

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

The schema provides 100% parameter coverage with descriptions, including detailed enum semantics for status. The description echoes the default status but does not introduce any new parameter meaning beyond what the schema already contains.

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 action and resource: 'List triggered alerts for a MongoDB Atlas project.' The second sentence disambiguates from alert configurations, making the purpose specific and distinctive.

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 on what is being listed (triggered alerts) and how to use the status parameter (defaults to OPEN; set to TRACKING or CLOSED for others). It does not explicitly name an alternative tool, but the distinction from configurations guides correct use.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the tool name, such as optional filtering, output scope, pagination, or authentication requirements. It does not contradict annotations, but it contributes nothing new.

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 one short, front-loaded sentence with no filler or unnecessary detail. It is maximally concise, though it essentially restates the tool name without elaboration.

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 (1 optional parameter, full schema coverage, output schema present, and read-only annotations), so the minimal description combined with structured fields is sufficient for basic invocation. It would benefit from explicitly noting that omitting projectId returns clusters across accessible projects.

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 and clearly describes the single projectId parameter ('Atlas project ID to filter clusters'). The description adds no parameter-level information, 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 a specific verb ('List') and resource ('MongoDB Atlas clusters'), making the core operation clear. It does not mention the optional projectId filter that would scope results, so it lacks some specificity but is still distinctly about listing clusters.

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 over siblings such as atlas-inspect-cluster (for cluster details) or atlas-list-projects (for project IDs). The description provides zero context for tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context such as pagination, return format, authentication needs, or rate limits. With annotations covering the safety profile, a neutral score is appropriate.

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, direct sentence with no wasted words. It is immediately clear and front-loaded, making it 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 an output schema provided. The description is minimal but adequate when combined with the annotations and schema. It could explicitly mention that the listing is scoped to a project, but the schema already communicates this, so the overall context 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?

The input schema fully documents projectId with a description and validation pattern, giving 100% schema coverage. The description does not mention parameters, but the schema carries the burden. Baseline 3 is appropriate since the description does not add extra meaning 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 description clearly states the action ('List') and the resource ('MongoDB Atlas database users'). It distinguishes itself from sibling tools like atlas-list-clusters, atlas-list-projects, and atlas-list-alerts by specifying the exact entity being listed.

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, no exclusions, and no context about the required projectId. It merely states the action without any usage policy, leaving the agent to infer the appropriate context from the tool name and schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. However, the description adds no behavioral context beyond the basic 'list' action, such as pagination behavior or scope limitations. It does not contradict annotations, so a mid-range score is appropriate.

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 states the purpose with zero superfluous words. It is appropriately sized for a simple list operation, though it could have added a bit more context without hurting conciseness.

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 only two optional parameters well-documented in the schema, and the annotations cover safety. However, the description lacks any usage guidance or behavioral details, and while an output schema exists, additional context about when to use this tool versus alternatives would improve completeness.

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 full descriptions for both parameters (limit and pageNum) with constraints and defaults, achieving 100% schema coverage. The description does not add any extra meaning beyond what the schema already documents, 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 'List MongoDB Atlas organizations' clearly states the verb (list) and the resource (MongoDB Atlas organizations), distinguishing it from sibling tools that operate on projects, clusters, alerts, etc. It 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 no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It simply states what the tool does, leaving the usage context entirely to the agent's inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no additional behavioral context such as pagination behavior, rate limits, or response structure. It essentially restates the tool name without enriching 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, concise sentence with no filler or redundant words. It is efficiently front-loaded with the core action and resource.

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 a simple list operation with a rich schema and output schema, so the description does not need to explain return values. However, it lacks any mention of pagination defaults or org filtering behavior, leaving some contextual gaps that the schema only partially fills. Overall, it is minimally sufficient for a simple list tool.

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

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

Schema description coverage is 100%, meaning all parameters (limit, orgId, pageNum) have detailed descriptions in the schema. The description adds no extra meaning beyond what the schema already provides, 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 'List MongoDB Atlas projects' uses a specific verb ('List') and resource ('MongoDB Atlas projects'), making the core purpose clear. However, it does not explicitly distinguish this from sibling tools like atlas-list-orgs or atlas-list-clusters, though the resource type itself provides differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention that orgId can filter projects or that results are paginated. There is no 'use this when' or mention of prerequisites, so the agent receives no direction on appropriate usage scenarios.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining what the tool returns: diagnose-processor includes 'state, stats, connection health, and recent errors', and get-networking returns 'PrivateLink and account details.' This goes beyond the simple read-only hint.

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 and front-loaded with the primary purpose. The second sentence lists practical use cases, and the third maps specific actions to their outputs. Each sentence contributes value, though the quoted use cases add a bit of density without being wasteful.

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

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

Given the complexity of 9 parameters and 8 distinct actions, the description covers the main action groups and provides a mental map for when to use each. The existence of an output schema means return-value details need not be in the description. It is complete enough for an agent to understand the tool's scope and select it appropriately.

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 every parameter documented in the input schema. The tool description itself does not add new parameter semantics beyond what the schema already provides, so the baseline 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 opens with a clear verb-resource pair: 'Discover and inspect Atlas Stream Processing resources.' It then reinforces with concrete use cases like 'why is my processor failing' and 'what workspaces do I have', which clearly distinguishes it from sibling tools focused on other resource types. The scope is unmistakably Atlas Stream Processing.

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 explicit action-to-purpose mappings: 'Use list-workspaces to see all workspaces', 'Use inspect actions for details', 'Use diagnose-processor for a combined health report', and 'Use get-networking for PrivateLink and account details.' This gives clear context for when to use each action, though it does not explicitly cover when not to use the 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?

The description does not add behavioral context beyond what the annotations already declare (readOnlyHint=true, destructiveHint=false). It is consistent with being a read-only operation, but lacks details about output structure or edge cases. With strong annotations, the bar is lower, but no extra context is given.

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

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

The description is a single succinct sentence with no redundant information, front-loaded with the verb 'Describe'.

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 metadata inspection tool with a complete schema and output schema present, the description sufficiently conveys the tool's purpose. No critical information is missing for an agent to select and invoke 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?

The input schema already provides full descriptions for all three parameters (database, collection, connectionId), and the tool description does not add any parameter-specific meaning. With 100% schema coverage, 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 'Describe the indexes for a collection' uses a specific verb ('Describe') and identifies the resource (indexes for a collection). It is distinct from sibling tools like collection-schema and collection-storage-size, which cover different aspects of a collection.

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 on when to use this tool versus alternatives. The description only states the tool's function without specifying prerequisites, exclusions, or alternative tools, resulting in no usage 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them. However, the description adds no behavioral context such as document sampling, cost implications, or that the schema is inferred rather than authoritative. It essentially restates the tool's 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 short sentence and is front-loaded, but it is so terse that it borders on under-specification. It is concise in length yet says little beyond the tool's name, making it only minimally valuable.

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 input schema is comprehensive and an output schema exists, but the description does not explain when to use this tool or that it infers schema by sampling documents. The sampleSize parameter hints at sampling, but the description itself provides no operational context, so completeness is adequate but lacking.

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 descriptions for all 5 parameters, including sampleSize and responseBytesLimit, achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already states.

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 'Describe' with the resource 'schema for a collection', clearly identifying a read-only introspection operation. It is distinguishable from sibling tools like collection-indexes or list-collections, though it stops short of mentioning that the schema is inferred from sampled documents.

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

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

No guidance is given about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is purely definitional and leaves the agent to infer use cases from the name and parameters.

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 annotations already declare this as read-only and non-destructive. The description adds no behavioral context beyond that, such as units, performance implications, permission requirements, or whether the size includes indexes. It fails to disclose any nuances that could affect the agent's interpretation of 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 description is a single, concise sentence with no extraneous text. It is front-loaded with the core purpose and contains 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?

This is a simple tool with clear annotations and a full parameter schema, and an output schema exists. However, the description leaves the meaning of 'size' ambiguous (e.g., storage vs. data vs. index size), which could lead to misinterpretation. The output schema may clarify returns, but the description itself is minimally 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?

Schema coverage is 100% with each parameter fully described in the input schema. The description adds no additional parameter semantics, which is acceptable given the schema already documents all three parameters (database, collection, connectionId) clearly.

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 gets the size of a collection, using a specific verb and resource. It is distinct from sibling tools like count or collection-schema, though it does not explicitly differentiate itself or clarify what type of size (e.g., storage, data) is returned.

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 on when to use this tool versus alternatives like db-stats or count, nor any exclusions or prerequisites. The description simply states what the tool does without contextual usage advice.

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 adds meaningful behavioral context beyond the annotations: each call spawns a new independent connection and multiple can be active simultaneously. It also discloses the existence of a preconfigured connection. This goes beyond the readOnlyHint and openWorldHint annotations, though it does not detail connection cleanup or failure modes.

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

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

The description is concise and well-structured: three sentences that front-load the primary purpose, then add behavioral details and the preconfigured exception. Every sentence contributes important information without unnecessary 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?

Given the simplicity of the tool, the presence of an output schema, and rich annotations, the description is largely complete. It explains the key behavior and the preconfigured shortcut. A minor gap is that it does not mention when to use disconnect or how connection IDs should be managed, but this is not essential for selecting the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add much parameter-specific meaning beyond the schema: connectionString is merely implied as the MongoDB URI, and connectionName is not mentioned in the description at all. The schema already provides adequate descriptions for both 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 clearly states the tool's purpose: connecting to a MongoDB instance and returning a connectionId for use with other MongoDB tools. It distinguishes this from siblings like list-connections and disconnect by focusing on the act of establishing a connection.

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 notes that a preconfigured connection exists and that there is no need to call this tool in that case, which serves as a when-not-to-use guideline. It also explains that each call creates an independent connection, implying use when a new, separate connection is desired. However, it does not discuss alternatives like atlas-connect-cluster or mention when to prefer those.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing this as a safe read operation. The description adds the underlying method db.collection.count() and clarifies the query parameter, but does not disclose additional behavioral traits like performance implications or consistency guarantees. Given the annotations, the extra context is marginal.

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-loading the core functionality ('Gets the number of documents') and providing relevant detail about the method and filter. There is no unnecessary repetition or 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, the annotations covering safety, and the presence of an output schema, the description is complete. It explains the primary purpose and the optional filter, and does not leave critical gaps for a count 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?

All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description mentions query is an optional filter, which aligns with the schema but adds no new semantic information beyond what's already documented.

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 MongoDB collection, using a specific verb and resource. It differentiates from siblings like find and aggregate by focusing on count, and mentions the optional query filter. This fully clarifies what the tool does.

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 (when you need a document count, optionally filtered), but does not explicitly mention alternatives or when not to use it. It lacks exclusion scenarios, so it falls short of a perfect score but is still clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'single database' scope and 'use state' semantics, but does not disclose details about return format or performance implications, providing minimal additional behavioral context.

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

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

The description is a single, concise sentence that gets directly to the point. Every word earns its place, with no redundancy 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?

The tool is simple with two well-documented parameters, rich annotations, and an output schema. The description covers the core purpose, and the output schema handles return value specifics. The only minor gap is the vague term 'use state', but overall the context is 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?

Schema description coverage is 100%, with both parameters (database and connectionId) fully described in the schema. The description adds no parameter-specific information beyond the schema, so a 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 it 'Returns statistics that reflect the use state of a single database', providing a specific verb and resource scope. This distinguishes it from sibling tools like list-databases or collection-storage-size, which operate at different levels.

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 explicit guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusion criteria, or compare with sibling operations, leaving the agent to infer usage from 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?

The description contradicts the annotations: readOnlyHint=true implies no state modification, but disconnecting and revoking a connectionId is a state-changing operation. The description does add context about auto-reconnect behavior, but the contradiction makes the behavioral transparency invalid.

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

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

The description is two compact sentences with a front-loaded verb and no filler. Every phrase earns its place, including the valuable preconfigured-connection caveat.

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?

Although this is a simple one-parameter tool with an output schema, the description omits the return value and fails to clarify the inconsistency with readOnlyHint. It provides a useful behavioral note about auto-reconnect, but the contradictory annotation undermines overall completeness.

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 only parameter, connectionId, is fully described in the schema (100% coverage), so the description adds no further parameter semantics. A baseline of 3 is appropriate because the schema carries the full burden.

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: closing a MongoDB connection and revoking its connectionId. It uses a specific verb and resource, and it is distinguishable from sibling tools like connect or list-connections, though it does not explicitly differentiate them.

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 on when to use disconnect versus alternatives, nor are exclusions or prerequisites mentioned. The caveat about the preconfigured connection is useful but not enough to orient an agent choosing among connection-related 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?

The description adds context beyond the annotations by clarifying that the tool returns optimizer plan statistics rather than the actual query results. Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. No contradiction exists, but the description does not disclose additional behavioral traits such as whether the query is actually executed or any cost implications.

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 15 words, front-loaded with the action 'Returns statistics,' and contains zero redundant or filler content. It is appropriately sized for a tool whose parameters are fully documented in the schema.

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

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

Given the high complexity of the input schema (nested method alternatives, vector search rules) and the presence of an output schema and safety annotations, the description is largely sufficient. It clearly states the tool's purpose, and the schema covers all method and parameter details. However, the lack of usage guidance is a notable gap, preventing a perfect score.

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 detailed descriptions for all five parameters, including the complex 'method' parameter and verbosity enum. The description itself adds no parameter-level detail, so it earns the baseline score of 3 for relying on the rich 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 uses a specific verb and resource: 'Returns statistics describing the execution of the winning plan chosen by the query optimizer for the evaluated method.' It clearly indicates this is an EXPLAIN-style tool for a given method. However, it does not explicitly distinguish itself from sibling tools like find or aggregate, though the nature of the output implies it is not the actual 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used instead of find/aggregate/count for analyzing query performance, nor does it state any exclusions or prerequisites. The only hint is the tool name and the phrase 'for the evaluated method,' which is insufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the EJSON format context, but it does not disclose what happens during export (e.g., whether results are returned as files, streamed, or stored) or any other behavioral traits.

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

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

A single front-loaded sentence with zero filler. It states the core function immediately and does not waste words, making it highly concise.

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 complex exportTarget parameter and no output schema, yet the description is only one sentence. It does not explain the export flow or return value (e.g., whether the tool returns a file, job ID, or stream URI), which is a significant gap given the tool's complexity and the absence of an output schema.

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

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

Schema description coverage is 100%, with detailed descriptions for all six parameters including the complex exportTarget structure. The description only mentions 'EJSON format', which is already captured by the jsonExportFormat parameter, so it adds no additional parameter-level meaning.

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

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

The description uses a specific verb 'Export' and names the resource ('query or aggregation results') and the target format ('EJSON'), clearly distinguishing this tool from read-only siblings like find and aggregate. It immediately tells the agent what function the tool performs.

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 sentence implies the tool is for exporting query/aggregation results, but it gives no explicit guidance on when to prefer this over alternatives such as find/aggregate, nor any prerequisites or exclusions. The use case is inferable but not elaborated.

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 adds no behavioral context beyond the annotations. Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description merely restates what a find query is, without adding specifics like pagination behavior, permission requirements, or response format.

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 with no wasted words. It is immediately clear and front-loaded, containing the essential action and target.

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 rich input schema (100% parameter coverage), output schema, and annotations, the one-line description is minimally viable but lacks contextual guidance. It does not mention default limit, filtering capability, or relationship to other query tools, so an agent must rely entirely on schemas and sibling 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?

The input schema covers 100% of parameters with descriptions, so the schema carries the semantic load. The tool description itself does not elaborate on any parameters. Baseline 3 applies because the schema is comprehensive and the description adds no extra parameter context.

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 'Run a find query against a MongoDB collection' states a specific verb ('run'), resource ('MongoDB collection'), and operation ('find query'). This clearly distinguishes it from sibling tools like count and aggregate, which serve different retrieval 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. It does not mention that this is for retrieving documents, nor does it point to siblings like aggregate or count for other query types. Usage context is entirely implicit and left to the agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context beyond 'for a given database' (which is already in the schema). It is consistent with annotations but does not disclose potential large result sets, pagination, or system collection inclusion.

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 five words that conveys all essential information. It is front-loaded with the verb and resource, and every word earns its place 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?

Given the tool's simplicity (2 parameters, output schema present, strong annotations), the description fully covers what the tool does. The output schema explains return values, and annotations cover side effects, so no additional context is necessary. It is complete for its complexity.

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 parameters 'database' and 'connectionId' are already well-documented. The description does not add any new meaning or format details beyond what the schema provides, meeting the baseline for high coverage.

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

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

The description 'List all collections for a given database' uses a specific verb ('List'), resource ('collections'), and scope ('for a given database'), which clearly differentiates it from sibling tools like list-databases or list-connections. It fully states what the tool does without ambiguity.

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 list-databases for available databases or collection-schema for details. There is no mention of prerequisites (e.g., an active connection) or explicit exclusions, leaving the agent without decision-making support.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by specifying it lists 'active' connections and introduces the concept of a 'preconfigured' connection, which goes beyond a generic read-only declaration. No contradiction with annotations.

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

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

Two sentences, each earning its place. The first states the core function, the second adds usage context. No filler 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?

With an output schema present and safe-read annotations, the description is complete. It explains the purpose, when to use it, and what to expect (connectionIds), making it fully sufficient for a listing 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 tool has zero parameters, and the schema coverage is trivially 100%. Per guidance, the baseline for 0 params is 4, and the description appropriately doesn't need to elaborate on parameter semantics.

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 resource as 'active MongoDB connections and their connectionIds'. It clearly distinguishes from sibling tools like connect or disconnect by focusing on discovery of existing connections, including preconfigured ones.

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 states when to use the tool: 'Use this to discover the preconfigured connection or to find a connectionId established earlier.' This gives clear context, though it doesn't explicitly mention when not to use it or name alternatives, which is acceptable for a simple listing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds little beyond the name, but it does confirm the operation is scoped to a connection without contradicting annotations.

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

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

The description is a single, perfectly front-loaded sentence. Every word contributes meaning, 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 simple, one-parameter, read-only tool with an output schema and clear annotations, the description is fully adequate. It states the core function, and the schema plus annotations cover the remaining 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?

The schema provides 100% coverage for connectionId, including a thorough description. The tool description does not add parameter-level details, but the schema already carries the semantic weight, so a baseline 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 uses a specific verb ('List') and resource ('all databases'), clearly scoped to 'a MongoDB connection'. This distinguishes it from sibling tools like list-collections, which targets collections within a database.

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 clearly implies the use case: listing databases for a given connection. It does not explicitly mention alternatives or exclusions, but the context is unambiguous given the tool's name and the connectionId parameter.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'List' aligns with that. The description adds context about the tool's scope (knowledge base) and its connection to search-knowledge, which is useful behavioral information. No contradictions.

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 core purpose. Every word earns its place, and the second sentence adds actionable guidance. 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?

Given the tool has no parameters, a read-only annotation, and no output schema, the description is largely complete. It explains what the tool does and how it fits with search-knowledge. A potential gap is the lack of detail about the response format, but for a straightforward listing tool this is not a major deficiency.

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 the baseline for zero params is 4. The description correctly implies no parameters are needed. Since the schema is empty, there is nothing 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 it lists available data sources in the MongoDB Assistant knowledge base. The verb 'List' and the specific resource ('data sources in the MongoDB Assistant knowledge base') make the purpose unambiguous. It also distinguishes itself from sibling listing tools by mentioning its role in supporting search-knowledge.

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 says 'Use this to explore available data sources or to find search filter parameters to use in search-knowledge.' This gives clear when-to-use guidance and even names the related tool. It does not provide explicit when-not-to-use or alternatives, but for a simple listing tool this is sufficient 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with these. It adds the 'most recent' scoping but doesn't detail ordering, pagination, or any other behavioral characteristics beyond what annotations already cover.

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

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

The description is a single sentence that states the core functionality without any extraneous words or repetition. It is perfectly 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?

For a simple log retrieval tool, the description is adequate: it names the resource and the recency. The schema covers all parameters and the output schema exists, so the agent has enough information. It could be slightly more explicit about the connection requirement, but the schema handles that.

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 each parameter (type, limit, connectionId) having meaningful descriptions including defaults, ranges, and enums. The tool description itself adds no parameter details, but the schema fully compensates, so the baseline 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 tool returns 'the most recent logged mongod events', using a specific verb ('Returns') and a well-defined resource. This distinguishes it from sibling tools like find or aggregate, which perform other database operations.

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, nor does it mention any context or exclusions. It simply states what it does, leaving the agent to infer usage from the tool name and schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds context about the scope of the knowledge base and filtering capability, but does not disclose additional behavioral traits like return format, pagination, or potential limitations. 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 two sentences, front-loaded with the primary action ('Search for information in the MongoDB Assistant knowledge base'), followed by a concise scope expansion and capability note. Every sentence 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 simple search tool with three parameters and no output schema, the description adequately covers purpose, content scope, and filtering capability. It doesn't explain return values, but that seems acceptable for a search tool where results are expected. No significant gaps given the annotations and schema richness.

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 each parameter well-explained (query, limit, dataSources). The description's mention of filtering by data source and version mirrors the schema's dataSources parameter but adds no extra meaning beyond what the schema already provides. The baseline of 3 applies since the schema carries the full burden.

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 searches for information in the MongoDB Assistant knowledge base, explicitly listing the content types (official documentation, curated expert guidance, other resources). It distinguishes from sibling tools like find and aggregate by focusing on knowledge base resources rather than database operations, and mentions filtering by data source and version.

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 establishes clear context that this tool is for knowledge base searches, but does not explicitly state when to use it over alternatives or when not to use it. The schema mentions calling list-knowledge-sources to enumerate data sources, but the description itself lacks direct comparative guidance.

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