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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that the tool is read-only (critical safety context), lists allowed and blocked operations, and provides detailed examples showing input structure and expected behavior. It doesn't mention rate limits, authentication needs, or pagination, but covers the core operational constraints well.

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

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

The description is front-loaded with the core purpose, but includes extensive stage listings and two lengthy examples. While the examples are helpful, they make the description quite long. Some information (like listing all supported/blocked stages) could be more concise. Every sentence adds value, but the overall structure could be tighter.

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

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

For a complex tool with 4 parameters, no annotations, and no output schema, the description does well. It explains the tool's purpose, behavioral constraints, parameter usage through examples, and distinguishes it from write operations. The main gap is lack of output format explanation (what the aggregation returns), but given the examples show expected transformations, it's mostly complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the 'pipeline' parameter's semantics through supported/blocked stages and two comprehensive examples that illustrate how to construct pipelines. This goes beyond the schema's generic description of 'MongoDB aggregation pipeline stages (read-only operations only).'

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

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

The description clearly states the tool's purpose: 'Execute a read-only aggregation pipeline on a collection.' It specifies the verb ('execute'), resource ('aggregation pipeline'), and scope ('read-only'), distinguishing it from write operations. This differentiates it from siblings like 'query' or 'count_documents' by focusing on multi-stage data 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 clear context for when to use this tool by listing supported stages (e.g., $match, $group) and explicitly blocking unsafe stages (e.g., $out, $merge). It implies usage for complex data transformations and joins. However, it doesn't explicitly compare when to use 'aggregate' versus alternatives like 'query' or 'get_distinct_values' for simpler tasks.

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 adds useful behavioral context about efficiency benefits and optimization use cases, but does not disclose critical details like performance characteristics, error handling, or authentication requirements. The example helps illustrate usage but doesn't fully compensate for the lack of 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 well-structured with a clear purpose statement, bullet-pointed benefits, and a practical example. It is appropriately sized and front-loaded, though the benefits section could be slightly more concise as some points overlap (e.g., 'Good for understanding data volume' and 'Can help planning query strategies').

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

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

Given no annotations and no output schema, the description provides adequate context for a read-only counting tool with good schema coverage. It covers purpose, benefits, and usage example, but lacks details on return format, error cases, or performance limits, which would be helpful for a tool with behavioral implications like database queries.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description does not add any parameter-specific semantics beyond what's in the schema, such as explaining filter syntax or default behaviors, though the example implicitly shows filter usage. Baseline 3 is appropriate when schema does the heavy lifting.

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: 'Count documents in a collection that match a filter.' It specifies the verb ('count'), resource ('documents in a collection'), and scope ('match a filter'), but does not explicitly differentiate it from sibling tools like 'query' or 'aggregate' that might also involve counting.

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

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

The description provides clear context for when to use this tool through the 'Benefits' section, highlighting efficiency over retrieving full documents and use cases like data volume understanding and pagination planning. However, it does not explicitly state when not to use it or name specific alternatives among sibling tools.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool's output (execution plan details) but lacks behavioral details like whether it executes the query, potential performance impact, or error handling. It mentions what the tool helps understand but not how it behaves operationally.

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

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

The description is front-loaded with the core purpose, followed by bullet points for clarity and a concluding usage guideline. Every sentence earns its place by adding value, with no redundant or vague language. It's 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?

Given the tool's complexity (analyzing query execution) and lack of annotations or output schema, the description is adequate but incomplete. It covers purpose and usage but omits details like output format, potential side effects, or limitations. For a diagnostic tool with no structured output, more context would be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'filter' relates to query optimization. Baseline 3 is appropriate when the schema handles parameter documentation.

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 with specific verbs ('get the execution plan for a query') and distinguishes it from siblings by focusing on query analysis rather than data retrieval or schema inspection. It explicitly mentions what the tool helps understand, making its purpose unambiguous.

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

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

The description provides explicit usage guidance: 'Use this to optimize slow queries.' This directly tells the agent when to use this tool versus alternatives like 'query' or 'aggregate', which execute queries rather than analyze them. The context is clear and actionable.

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

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

With no annotations provided, the description carries the full burden and does so effectively by disclosing key behavioral traits: it explains efficiency benefits, result ordering ('preserves ID order in results when possible'), input flexibility ('handles both string and ObjectId identifiers'), and optional filtering ('can filter specific fields with projection'). It does not cover error handling or performance limits, but adds substantial value beyond basic function.

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

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

The description is well-structured with a clear purpose statement, bullet-pointed advantages, and a practical example. Every sentence adds value, but it could be more front-loaded by integrating the example more seamlessly. It avoids redundancy and is appropriately sized for 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?

Given no annotations and no output schema, the description provides good contextual completeness for a read operation: it covers purpose, advantages, and usage example. However, it lacks details on output format (e.g., result structure or error cases), which would be helpful since there's no output schema. It adequately addresses the tool's functionality but has minor 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?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema, such as implying 'ids' can include mixed types and 'projection' for field filtering, but does not elaborate on syntax or defaults (e.g., 'idField' default is only in schema). It compensates slightly with the example showing parameter usage.

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 specific action ('Find multiple documents by their IDs') and resource ('documents'), distinguishing it from siblings like 'query' or 'get_distinct_values' by emphasizing batch ID-based lookup. It explicitly mentions efficiency advantages over single lookups, making the purpose distinct and well-defined.

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

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

The description provides clear context for when to use this tool ('more efficient than multiple single document lookups') and implies alternatives by mentioning its batch nature, but does not explicitly name when-not-to-use scenarios or compare to specific siblings like 'query' for non-ID-based searches. The example illustrates typical usage, enhancing practical 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?

With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It explains prerequisites (geospatial index requirement), coordinate format conventions, and provides concrete examples showing how to structure queries. The examples demonstrate practical usage patterns including parameter combinations and distance calculations, though it doesn't mention rate limits, authentication needs, or error conditions.

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

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

The description is well-structured and efficiently organized with clear sections (overview, supports, requirements, examples). Every sentence earns its place by providing essential information without redundancy. The front-loaded purpose statement is followed by progressively detailed information, making it easy to scan while maintaining comprehensive coverage.

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

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

For a complex tool with 12 parameters, no annotations, and no output schema, the description provides substantial context through examples, requirements, and operation explanations. It covers the main use cases and parameter combinations effectively. However, without an output schema, it doesn't describe what the tool returns (document format, distance calculations in results), which is a notable gap for a query 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 schema description coverage is 100%, so the baseline is 3. The description adds some value by mentioning coordinate format conventions and providing examples that show how parameters like 'point', 'maxDistance', and 'geometry' are used in practice, but it doesn't add significant semantic information beyond what's already documented in the comprehensive schema descriptions.

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

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

The description clearly states the tool's purpose as 'Execute geospatial queries on a MongoDB collection' with specific verbs and resources. It distinguishes itself from sibling tools like 'query' or 'text_search' by focusing exclusively on geospatial operations, listing supported query types (near, within polygons/circles/boxes, distance calculations) and supported formats (GeoJSON, legacy coordinate pairs).

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

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

The description provides clear context for when to use this tool through its 'Requirements' section, specifying that the collection must have a geospatial index and coordinates should follow MongoDB conventions. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the sibling tools for non-geospatial queries, which prevents a perfect score.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what information is returned but doesn't describe whether this is a read-only operation, performance characteristics, permission requirements, error conditions, or response format. The description adds some context about return content but lacks critical behavioral details.

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 appropriately sized with two sentences: a clear purpose statement followed by a bulleted list of return information. The structure is front-loaded with the main purpose, though the bulleted list could potentially be more concise. Overall, it's efficient with minimal waste.

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

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

For a read operation with 2 parameters and 100% schema coverage but no output schema, the description provides adequate but incomplete context. It explains what statistics are returned but not the format, structure, or units of the response. Given the complexity of statistical data and absence of output schema, more detail about the return format would be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 is appropriate since the schema provides complete parameter documentation.

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: 'Get detailed statistics about a collection' with specific metrics listed. It distinguishes from siblings like 'list_collections' (which lists names) and 'get_schema' (which describes structure), but doesn't explicitly differentiate from all statistical siblings like 'count_documents' or 'get_distinct_values'.

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 doesn't mention when this statistical overview is preferable to specific tools like 'count_documents' for document count or 'get_indexes' for index information, nor does it specify 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?

No annotations are provided, so the description carries the full burden. It describes the tool's function and includes an example, but lacks details on behavioral traits such as performance considerations (e.g., impact on large collections), error handling, or output format. The example clarifies usage but doesn't fully compensate for the absence of 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 appropriately sized and front-loaded, starting with a clear purpose statement followed by a bulleted list of use cases and a practical example. Every sentence earns its place by adding value without redundancy, making it efficient and well-structured for quick understanding.

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 (4 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the tool's purpose and usage but lacks details on behavioral aspects like performance or error handling. Without an output schema, it doesn't describe return values, leaving the agent to infer results from the example.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description does not add meaning beyond what the schema provides, such as explaining parameter interactions or constraints. The example illustrates usage but doesn't enhance parameter semantics, resulting in a baseline score of 3.

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

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

The description clearly states the verb 'Get' and resource 'distinct values for a field in a collection', making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'count_documents', 'query', or 'sample_data' by focusing on unique value extraction rather than counting, filtering, or sampling.

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 with a 'Useful for' section listing scenarios like understanding data distribution and data quality checks. However, it does not explicitly state when to use this tool versus alternatives like 'query' for filtered results or 'sample_data' for sampling, nor does it specify exclusions or prerequisites for usage.

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 full burden. It discloses return details (index names, types, sizes, etc.), which is helpful. However, it lacks critical behavioral traits: whether this is a read-only operation, performance implications (e.g., if it locks the collection), authentication needs, or rate limits. For a tool with zero annotation coverage, this is insufficient.

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 efficiently structured: a clear purpose statement followed by a bulleted list of return details. Every sentence (and bullet point) earns its place by providing specific value. No wasted words or redundancy.

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 2 parameters with full schema coverage, no output schema, and no annotations, the description is adequate but has gaps. It explains what information is returned, which compensates for missing output schema. However, for a tool that likely interacts with a database system, more behavioral context (e.g., read-only nature, performance impact) 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?

Schema description coverage is 100%, so the schema already fully documents both parameters (database and collection). The description adds no parameter-specific information beyond what's in the schema (e.g., no examples, format details, or constraints). Baseline 3 is appropriate when the schema does all the work.

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: 'Get information about indexes on a collection' (verb+resource). It distinguishes from siblings like 'get_collection_stats' or 'get_schema' by focusing specifically on indexes. However, it doesn't explicitly differentiate from all possible alternatives, keeping it at 4 rather than 5.

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 context through 'on a collection,' suggesting this is for database/collection analysis. However, it provides no explicit guidance on when to use this vs. alternatives like 'get_collection_stats' (which might include index info) or 'explain_query' (which uses indexes). No when-not-to-use or prerequisite information is included.

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 explains the core behavior (inferring schema by analyzing samples) and mentions a best practice, but doesn't disclose important behavioral aspects like whether this is a read-only operation, potential performance impact of sampling, error conditions, or what the output format looks like. The description adds some context but leaves significant gaps.

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

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

The description is well-structured with purpose statement, best practice guidance, and an example. It's appropriately sized and front-loaded with the core functionality. The example could be slightly more concise, but overall the description earns its place with useful information.

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

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

For a schema inference tool with 3 parameters and no output schema, the description provides good purpose and usage guidance but lacks details about the output format, error handling, and behavioral constraints. The absence of annotations means the description should do more to explain what kind of schema is returned and any limitations of the inference process.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. The example shows parameter usage but doesn't provide additional semantic context. Baseline 3 is appropriate when the schema does the heavy lifting.

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 with specific verb ('Infer schema') and resource ('from a collection'), and distinguishes it from siblings by focusing on schema analysis rather than querying or data retrieval. It explicitly mentions analyzing sample documents, which differentiates it from tools like get_indexes or get_collection_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 explicit guidance on when to use this tool ('Use this before querying to understand collection structure'), which clearly positions it as a preparatory step for other operations like querying. This distinguishes it from siblings such as query, sample_data, or find_by_ids that perform actual data operations.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool lists collections but doesn't describe behavioral traits like whether it requires authentication, has rate limits, returns paginated results, or what happens if the database doesn't exist. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 concise and well-structured with two sentences: the first states the purpose, and the second provides usage guidance. Every sentence adds value without redundancy, and it's front-loaded with the core functionality. There's no wasted text or 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 tool's low complexity (one optional parameter, no output schema), the description is minimally adequate. It covers purpose and usage but lacks behavioral details due to no annotations. For a simple list operation, this might suffice, but without output schema or annotations, it doesn't fully prepare an agent for invocation (e.g., missing info on return format or error handling).

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, with the 'database' parameter documented as optional if a default is configured. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.

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: 'List all collections in a database.' It specifies the verb ('List') and resource ('collections'), and distinguishes it from siblings like 'list_databases' by focusing on collections within a database. However, it doesn't explicitly differentiate from other collection-related tools like 'get_collection_stats' or 'get_schema'.

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

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

The description provides clear usage context: 'Start here to understand what collections are available before querying.' This indicates when to use the tool (as a preliminary step before querying) and implies it's for discovery rather than data retrieval. However, it doesn't explicitly state when not to use it or name alternatives like 'list_databases' for broader scope.

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 but only states the action without behavioral details. It doesn't disclose permissions needed, pagination, rate limits, or what 'all databases' entails (e.g., system databases included). This leaves significant gaps for a tool with zero annotation coverage.

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, efficient sentence with zero waste. It's front-loaded and directly states the tool's function without unnecessary elaboration, 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 tool's simplicity (0 params, no output schema), the description is minimally adequate but lacks context about behavioral aspects like permissions or output format. Without annotations or output schema, it should provide more guidance on what to expect, leaving room for improvement.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but this is appropriate given the schema completeness, warranting a baseline above 3 for clarity in a no-param 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 clearly states the verb ('List') and resource ('all databases in the MongoDB server'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_collections' or 'get_schema', which prevents a score of 5.

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. For example, it doesn't mention if this is for high-level inventory vs. detailed metadata, or how it relates to siblings like 'list_collections' or 'get_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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'read-only' which is crucial safety information. It also mentions output formats (JSON/CSV) and best practices like adding limits. However, it doesn't cover important behavioral aspects like pagination, error handling, timeout behavior, or authentication requirements that would be helpful for an agent.

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

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

The description is well-structured with clear sections: purpose statement, output format explanation, best practices, and examples. However, the two detailed examples are quite lengthy and could potentially be summarized more concisely. The front-loaded purpose statement is excellent, but the overall length might be slightly excessive for what needs to be communicated.

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

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

For a complex query tool with 8 parameters, no annotations, and no output schema, the description provides good basic coverage but has gaps. It explains the core functionality and output formats well, but doesn't describe what the return value looks like (structure, pagination, error formats). Given the complexity and lack of output schema, more information about response format would be beneficial.

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 schema already documents all 8 parameters thoroughly. The description adds some value by explaining outputFormat options and providing examples, but doesn't add significant semantic meaning beyond what's in the schema. The examples show parameter usage but don't explain semantics that aren't already in the schema descriptions.

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

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

The description clearly states the tool's purpose: 'Execute a read-only query on a collection using MongoDB query syntax.' It specifies the verb ('execute'), resource ('collection'), and technology ('MongoDB query syntax'), distinguishing it from siblings like 'aggregate', 'count_documents', or 'text_search' which serve different query 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 clear context for when to use this tool: for read-only queries with MongoDB syntax. It mentions best practices like using projections and limits, which implicitly guides usage. However, it doesn't explicitly state when to choose this over alternatives like 'aggregate' for complex aggregations or 'find_by_ids' for ID-based lookups.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it explains the random sampling nature, output format options (JSON/CSV with defaults), and provides concrete examples showing how to invoke it. However, it doesn't mention potential limitations like performance implications for large collections or whether sampling is truly random versus pseudo-random.

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 appropriately sized and well-structured: it starts with the core purpose, then explains output formats with clear bullet points, provides usage contexts in a concise list, and includes practical examples. While comprehensive, every sentence adds value, though the examples could be slightly more 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?

For a 5-parameter tool with no annotations and no output schema, the description does well by covering purpose, usage guidelines, parameter guidance, and examples. However, it doesn't describe the return format or structure of results (though examples hint at it), and doesn't mention error conditions or limitations, leaving some gaps in full contextual understanding.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds meaningful context beyond the schema: it explains the purpose of outputFormat parameter with specific guidance on when to use JSON vs CSV, provides default values not in schema (outputFormat='json' as default), and shows formatOptions usage in examples. However, it doesn't explain the database parameter's optional nature or size constraints beyond what's in 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 specific action ('Get a random sample of documents from a collection') with the resource ('documents from a collection'). It distinguishes from siblings like 'query' (which filters) or 'find_by_ids' (which selects specific documents) by emphasizing random sampling for analysis/testing 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 explicitly provides usage contexts ('Useful for: Exploratory data analysis, Testing with representative data, Understanding data distribution, Performance testing with realistic data subsets') and distinguishes from alternatives by focusing on random sampling rather than filtered queries or specific document retrieval. It clearly indicates when this tool is appropriate versus other data retrieval 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond basic functionality: it lists features (e.g., word stemming, stop words removal) and requirements (e.g., text index needed), which helps the agent understand operational constraints. However, it doesn't cover aspects like error handling, performance implications, or authentication needs, leaving gaps for a tool with complex behavior.

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

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

The description is well-structured with sections (Requirements, Features, Example) and front-loaded with the core purpose. It's appropriately sized, but the example is lengthy and could be more concise. Most sentences earn their place by adding value, though some redundancy exists (e.g., repeating parameter names in the example).

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 complexity (6 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose, requirements, and features, but lacks details on output format, error cases, or integration with sibling tools. Without an output schema, the agent might struggle to interpret results, making this description adequate but with clear gaps for effective use.

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

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

Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description doesn't add significant meaning beyond the schema—it mentions 'searchText' and 'filter' in the example but without extra semantics. The baseline score of 3 is appropriate as the schema does the heavy lifting, though the description could have elaborated on parameter interactions.

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: 'Perform a full-text search on a collection.' It specifies the verb ('full-text search') and resource ('collection'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'query' or 'geo_query' that might also search collections but with different methods.

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 some usage context through 'Requirements' (e.g., collection must have a text index, only one text index allowed), which implies when this tool is applicable versus alternatives. However, it doesn't explicitly state when to use this tool over sibling tools like 'query' for non-text searches or 'geo_query' for spatial queries, leaving some ambiguity.

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