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

readOnlyHint=true already covers the key safety trait, and the description adds a useful functional trait: it can execute grouping and $lookup stages. It does not disclose potential performance implications or result-shape behavior, but with the annotation present this is acceptable.

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 sentence that leads with the verb and resource, then gives concrete discriminating examples. No filler or repetition of schema 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?

For a read-only aggregation tool with a fully documented schema, the description plus the pipeline example is enough to select and invoke the tool. It doesn't state the default/optional nature of pipeline and returns, but those gaps are minor given the strong schema coverage.

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 collection, database, pipeline, and limit. The description only mentions pipeline stages conceptually and adds no parameter-specific meaning beyond the schema example.

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

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

The description states a specific verb ('Jalankan') and resource ('aggregation pipeline MongoDB'), and gives concrete use cases (grouping, $lookup joins) that distinguish it from simpler siblings like find/find_one. It doesn't name a sibling explicitly, but the aggregation-pipeline framing is unambiguous.

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

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

The description implies this is for data-analysis workloads requiring grouping or joins, but never states when to prefer it over find/count/distinct or when not to use it. No explicit alternatives or exclusions are provided, so the agent must infer the usage boundary.

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 annotation readOnlyHint=true already covers the read-only safety profile, so the description does not need to repeat that. It adds some behavioral context by listing the metrics the tool returns, though it leaves the meaning of 'index' ambiguous and does not describe output shape or freshness.

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 front-loads the resource and operation and lists the relevant metrics in a scannable list. Every phrase contributes useful information without 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?

For a simple read-only statistics tool, the description is mostly adequate: the operation is clear, the parameters are fully documented in the schema, and the read-only behavior is covered by annotations. However, without an output schema, the return format is unexplained, and the ambiguous 'index' item could leave an agent unsure what statistic is reported.

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 adequately. The description adds high-level meaning by explaining what the resulting statistics cover, but it provides no parameter-specific details 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 identifies the resource (collection) and the operation (statistics), and enumerates the specific metrics returned: number of documents, average size, storage size, and index. It is clear enough to distinguish from database-level tools like db_stats, though it does not explicitly name a sibling.

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 given about when to use this tool versus alternatives such as db_stats, count, or list_collections. The phrase 'Statistik koleksi' implies collection-level scope, but there is no stated context, exclusions, or comparison with 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?

The readOnlyHint annotation already establishes the read-only safety profile. The description adds a useful scoping detail: the count applies only to documents matching the filter, not the whole collection. It does not, however, mention the return format (e.g., a numeric total), behavior on empty collections, or error cases; with the annotation covering safety, this is an average but acceptable disclosure.

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 states the operation and the object of the operation with zero filler. Every word earns its place in the description.

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 count operation, the description plus fully documented schema (filter, database, collection) and readOnlyHint annotation are nearly complete. The only meaningful gap is the absence of an explicit return-type statement or output schema, but 'menghitung jumlah' already conveys that the result is a count.

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 meaningful descriptions, including a MongoDB filter example and the use of {} for all documents. The description itself adds no parameter detail, so the schema carries the burden and the score stays at the baseline.

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

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

The description 'Menghitung jumlah dokumen yang cocok dengan filter' names a specific verb (menghitung/count), a distinct resource (documents matching a filter), and clearly differentiates from sibling tools like find, distinct, and aggregate, whose purpose is to return or transform documents rather than just count 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?

There is no guidance on when to use count versus siblings such as find, distinct, or aggregate, and no exclusions or alternative conditions. The purpose statement implies counting is the intended use, but the description never says 'use this when you only need a count' or mentions any alternative.

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 behavioral burden. It clearly indicates a mutating operation by saying 'Membuat' (create), but does not disclose behavior when the collection already exists, permissions required, or what response is returned.

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 filler words. The key action and target resource are front-loaded, making it easy to parse quickly.

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

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

For a simple two-parameter creation tool, the schema covers the inputs and the description states the core operation. However, the lack of annotations and output schema leaves gaps around error behavior, idempotency, and return values.

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 describes both parameters with 100% coverage, including the optional database and required collection. The description adds no further parameter detail, 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 uses a specific verb, 'Membuat' (create), with a clear resource, 'koleksi' (collection), and scope, 'di dalam sebuah database'. This unambiguously distinguishes it from siblings like rename_collection, drop_collection, and list_collections.

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

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

The usage is implied by the verb 'create': an agent can infer this tool is for creating a new collection. However, the description does not explicitly state when to prefer this over alternatives or mention edge cases like whether a collection is auto-created on first insert.

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 only states the intended effect and does not mention side effects, failure conditions (e.g., duplicate keys when unique is true), whether creation is idempotent, background vs. blocking behavior, or required permissions.

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 redundant wording, and the core action is front-loaded. It could be slightly more structured by adding a usage example or sibling reference, but it is appropriately brief.

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 mutating tool with no annotations and no output schema, the description is too sparse. It omits how to verify the index was created, what happens with existing data when a unique index is enforced, and when the agent should prefer sibling tools like list_indexes or drop_index.

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 including examples for keys and options. The description adds no parameter-level meaning beyond the schema, which matches the baseline 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 ('Membuat' = create), the resource ('index pada koleksi'), and the intended purpose (speeding up queries or enforcing unique constraints). This distinguishes it from index-related siblings like list_indexes and drop_index, though it does not explicitly name any sibling.

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 purpose clause 'untuk mempercepat query atau menegakkan unique constraint' implies when the tool is appropriate. However, there is no explicit guidance about when not to use it, such as checking existing indexes with list_indexes before creating, or handling cases where an index already exists.

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, so no safety concern. Description adds context about the contents of the stats (collection count, objects, data size, index), which goes beyond the annotation. It doesn't disclose units or detail on what 'objects' means, but that is minor.

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

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

One short sentence that front-loads the resource and the key outputs. 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 read-only stats tool with one optional parameter, the description covers the essential information: what stats are returned and the database scope. Output schema absent, but the listed attributes convey expected output.

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 a clear description of the 'database' parameter and its optionality. Description adds no additional parameter detail, but baseline 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?

Description clearly states the tool provides database statistics: number of collections, objects, data size, and index. The resource 'database' is specific and distinct from the sibling 'collection_stats', though it doesn't explicitly contrast 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 explicit guidance on when to use vs alternatives. The description simply states what it does, leaving the agent to infer usage from the name and siblings. No exclusions or routing 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 all-caps PERINGATAN directly discloses that this is a destructive operation affecting all matching documents. It goes beyond the destructiveHint annotation by adding the critical guardrail that an empty filter is only allowed when confirm is true.

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 warning sentence with no filler. It immediately emphasizes the destructive scope and the confirmation rule, making the critical information easy to notice and act on.

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 core behavior, destructive risk, and confirmation prerequisite are all covered, which is enough for safe invocation. Minor gaps remain: it does not clarify what happens when the filter parameter is omitted entirely, and it does not discuss alternatives, but the essential context is present.

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

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

The input schema already documents all four parameters, including filter examples and confirm semantics. The description adds meaningful extra context by highlighting the dangerous empty-filter case and the confirm requirement, enriching the meaning of the filter and confirm 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 states a specific operation: deleting ALL documents matching a filter, with an explicit warning. This distinguishes it from single-document operations like delete_one and from collection-level operations like drop_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?

The description conveys clear context: this tool deletes every document matching the filter and imposes a confirm requirement for empty filters. However, it does not explicitly guide the agent toward this tool versus delete_one or drop_collection, so usage guidance is implied rather than fully stated.

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

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

The destructiveHint annotation already flags this as destructive. The description adds useful behavioral context beyond the annotation by specifying that exactly one document is removed and that it is the first match for the filter. It does not discuss irreversible consequences or no-match behavior, but the annotation and wording cover the core trait.

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 Indonesian sentence communicates the core behavior with no filler. Every word earns its place, and the most important qualifier ('SATU') appears immediately.

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 destructive single-document deletion tool, the description plus complete schema and destructiveHint annotation is nearly sufficient. It is missing minor details such as behavior when no document matches, but an agent can invoke the tool correctly from the provided information.

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 filter, database, and collection. The main description adds little beyond what the schema says; it reinforces the meaning of 'filter' but does not introduce new 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 has a specific verb ('Hapus'), a specific resource ('satu dokumen'), and a clear scope ('pertama yang cocok dengan filter'). The word 'SATU' explicitly distinguishes it from the sibling delete_many, so an agent can select it correctly.

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 when to use it: to delete a single first-matching document. It does not explicitly name alternatives or exclusions like 'for multiple documents, use delete_many', but the single-document qualifier provides sufficient contextual 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?

The annotation readOnlyHint=true already covers the safety profile, and the description reinforces it with 'Ambil'. It adds useful behavioral context by clarifying that the operation is scoped to one field and may apply a filter. However, it does not disclose output format, limits, or behavior when no matching values exist.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the operation, the target field, and the optional filter in minimal space. Every word contributes to 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?

For a simple read-only distinct-values tool, the description plus the fully documented schema is sufficient to invoke it correctly. The word 'daftar' already indicates the return is a list, and the schema covers parameter meanings. It lacks deeper output details, but the tool's low complexity makes that a minor gap.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters. The description only restates field and filter behavior without adding new detail about filter syntax, database fallback, or collection semantics. Baseline 3 is appropriate because the schema carries the parameter 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?

Description clearly states a specific operation: retrieve the list of unique values from a field, with an optional filter. The verb 'Ambil' and resource 'field' make the tool's purpose unambiguous, and the focus on unique values distinguishes it from siblings like find or count. It does not explicitly name a sibling, so it stops just short of a 5.

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

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

The description implies the tool is for distinct-value retrieval and notes that filtering is optional, but it gives no concrete guidance about when to choose this tool over find, aggregate, or count. No alternative tools, exclusions, or prerequisites are mentioned.

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 destructiveHint annotation already flags the operation as destructive. The description adds specific context that the collection is removed together with all of its contents and that this is permanent, which is valuable behavioral disclosure beyond the annotation.

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 warning sentence conveys the core action and its permanent, all-contents consequence with 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 simple two-parameter destructive operation, the description is almost complete: it states the action, the scope, and the permanence. It could be slightly richer by noting the lack of undo or confirming that indexes are also dropped, but these are not necessary for basic correct invocation.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds no additional meaning to the parameters, so 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 states a clear verb and resource: 'Menghapus koleksi' (deletes collection) and clarifies the full scope with 'BESERTA SELURUH ISINYA' (along with all contents). It is not a tautology, but it does not explicitly distinguish itself from sibling tools like drop_database beyond the resource name.

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 delete_many or drop_database. It only warns about permanent deletion, which implies caution but does not explain the appropriate selection 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 goes beyond the destructiveHint annotation by specifying exactly what is destroyed (the entire database and all collections), that the deletion is permanent, and that confirmation via confirm: true is mandatory. This gives the agent the critical behavioral context needed to avoid accidental destructive calls.

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 warning that front-loads the destructive nature of the operation and the required confirmation. Every word earns its place, and there is no 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?

Given that this is a highly destructive tool, the description covers what is deleted, permanence, and the mandatory safety confirmation. The parameters are fully documented in the schema and no output schema is needed, so the context is complete for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both database and confirm. The description repeats the confirm: true requirement but adds little beyond what the schema provides, 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 action (drop the database) and the full scope of the resource (the entire database with all its collections). It is easy to distinguish from siblings like drop_collection because it explicitly says 'seluruh database beserta semua koleksinya' rather than a single 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?

The description implies the tool is for permanently deleting a whole database, but it does not explicitly contrast it with drop_collection or state when not to use it. There is clear contextual meaning, but no explicit when/when-not guidance or named alternatives.

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 destructiveHint annotation already marks the operation as destructive. The description adds a useful behavioral constraint: the default '_id_' index cannot be dropped. It does not mention irreversibility, error behavior for nonexistent indexes, or any permission requirements, but annotations partially cover the destructive nature.

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 focused sentence that communicates the core action and the most important edge case. There is no redundancy or unnecessary detail; it is appropriately sized for a simple destructive operation.

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 low-complexity tool with a destructive hint and fully described parameters, the description covers the essential operation and the key exception. It could mention that the collection must exist or that the operation is irreversible, but these are minor gaps given the schema and annotation coverage.

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 are already well documented. The description reiterates that deletion is by name and that default '_id_' is protected, which is behavioral rather than adding significant new parameter semantics. No extra guidance is needed 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 tool's action: 'Hapus index berdasarkan nama' (delete index by name). It identifies both the verb and the resource, and differentiates from sibling tools like drop_collection and drop_database by specifying it targets indexes. The added note about the protected '_id_' index further clarifies scope.

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

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

The description implies the tool is for dropping indexes rather than collections or databases, which is enough given the sibling names. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention consequences or prerequisites like collection existence.

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 annotation readOnlyHint=true already establishes that this is a read operation. The description adds useful behavioral context about filtering, projection, sorting, and pagination, but it does not disclose additional behavioral traits such as default limits, return format, or how the database is selected. There is no contradiction with 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, well-structured sentence that front-loads the primary action and then lists the optional capabilities. There is no redundant wording, and every part of the sentence contributes meaning.

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-only query tool with 100% schema coverage and no output schema, the description is largely complete: it identifies the resource and the optional behaviors an agent needs to know. It could be slightly more complete by noting that it returns multiple documents and by giving explicit usage guidance relative to sibling tools, but the combination of description and schema is sufficient for basic correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters in detail. The description mentions filter, projection, sort, and pagination, which reinforces the schema but adds little beyond it. The baseline of 3 is appropriate because the schema carries the semantic load.

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

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

The description states a specific verb and resource ('Cari dokumen dalam koleksi') and enumerates the key features: optional filter, field projection, sort, and pagination. It is clear about what the tool does, though it does not explicitly differentiate it from siblings like find_one or aggregate.

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

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

Usage is implied: this tool searches documents in a collection with optional filtering, projection, sorting, and pagination. However, it does not explicitly state when to use find versus find_one, get_by_id, count, or aggregate, nor does it mention exclusions or alternative selection criteria.

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 readOnlyHint annotation already tells the agent this is a safe read operation, and the description's 'Ambil' is consistent with that. The description adds the 'pertama' (first) qualifier, which is a useful behavioral trait, but it does not clarify what defines 'first' (e.g., natural order) or what happens when no document matches.

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 with no filler, front-loading the core action and object. It is as concise as possible while still conveying the primary function.

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 tool with full schema coverage, the description is adequate but not complete: it omits ordering semantics, return value/null behavior, and any hint about which sibling tools to prefer. Given there is no output schema, a bit more context would improve agent confidence.

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 all four parameters with detailed descriptions (100% coverage), so the schema carries the burden of parameter semantics. The description itself adds no parameter-specific detail beyond what the schema already provides.

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

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

The description uses a specific verb 'Ambil' and a specific resource 'SATU dokumen pertama yang cocok dengan filter,' clearly indicating it retrieves a single matching document. This distinguishes it from sibling find (which would return multiple documents) and get_by_id (which targets by ID), though it does not explicitly name those alternatives.

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 such as find or get_by_id. The intended use case of retrieving one document is implied, but no exclusions, conditions, or alternative tool names are mentioned.

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 annotation declares readOnlyHint=true, so the safety profile is covered. The description adds meaningful behavioral detail by disclosing that 24-character hex strings are automatically converted to ObjectId, which is a non-obvious behavior an agent needs to know.

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

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

Two tight sentences deliver the core purpose and the critical conversion behavior without wasted words. The most decision-relevant information is front-loaded.

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-by-id tool with readOnlyHint and a fully described schema, the description is nearly complete. The main gap is that it does not state what happens when no document matches, such as returning null, an empty result, or an error.

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 structured documentation already explains all parameters. The description adds only the ObjectId conversion nuance for the id parameter; it does not meaningfully elaborate on collection or database semantics 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 that the tool retrieves one document by its _id, and the auto-conversion detail sharpens the scope. However, it does not explicitly differentiate get_by_id from find_one, which could also be used for _id-based lookups.

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 such as find_one or find. The description explains a conversion behavior but gives no context about exclusions, fallback recommendations, or scenarios where another tool would be more appropriate.

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

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

No annotations are present, so the description carries the full burden. It only restates the basic write operation and gives no detail about behavior beyond insertion, such as atomicity, error handling, duplicate behavior, or return values.

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, focused sentence communicates the core purpose without unnecessary words. The bulk aspect is front-loaded and the sentence is easy to parse.

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

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

For a simple bulk insert tool, the core action is clear and schema covers parameters. However, with no annotations and no output schema, the description omits usage guidance and behavioral expectations, leaving an agent without enough context to predict side effects or return behavior.

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 input schema already documents all three parameters. The tool description adds no additional parameter-level meaning, which matches 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 states a specific action ('insert many documents at once') and a clear target resource ('collection'). The word 'BANYAK' differentiates this from the sibling insert_one, making the tool's bulk purpose immediately obvious.

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

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

The phrase 'BANYAK dokumen sekaligus' implies this tool is for bulk insertion, but it does not explicitly state when to prefer this over insert_one or mention any exclusions. Guidance is implied rather than directly provided.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a key behavioral detail: the operation returns the _id of the created document. It does not mention side effects, failure modes, or id-generation specifics, but for a straightforward insert operation the core behavior is reasonably covered.

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 front-loaded, concise sentence with no filler. It emphasizes the singleton nature of the operation and states the return value, earning its place without 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?

For a simple single-insert tool, the description plus schema covers the main operation and return value. However, with no annotations and no output schema, it leaves out potential edge cases like non-optional document semantics and fails to route the agent toward insert_many for multiple documents. It is adequate but not rich.

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%, and the schema already explains database, document, and collection parameters, including an example document. The description itself adds no parameter-specific information, 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 states a specific verb ('Sisipkan'), a resource ('SATU dokumen baru ke dalam koleksi'), and the cardinality 'SATU', which clearly distinguishes it from the sibling insert_many. An agent can immediately tell what this tool does and how it differs from batch insertion.

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 word 'SATU' implies usage for a single document, giving some contextual guidance. However, the description does not explicitly say when to use this tool versus insert_many, nor does it state any exclusions or batch-handling alternatives. The usage guidance is only implied, not explicit.

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

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

The annotations already mark the tool readOnlyHint=true, and the description's 'Daftar' (list) is consistent with that read-only behavior, so there is no contradiction. Beyond that, the description adds no extra behavioral context such as output format, ordering, or effect of omitting database, but this is not a high-risk operation.

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

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

The description is a single, front-loaded sentence with no filler or repeated annotation content. Every word contributes to identifying the action and scope.

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

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

For a simple read-only listing operation with one optional parameter fully described in the schema, the description is nearly complete. It lacks an explicit statement of the return shape, but the resource and scope are clear.

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%: the only parameter, database, is documented as the target database name and optional if MONGODB_DB is set. The tool description itself adds no parameter meaning, but the schema already carries the necessary semantic load, matching 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, 'Daftar semua koleksi di dalam sebuah database,' clearly states the operation (list) and the resource (all collections in a database), so an agent can tell this from tools like list_databases. It does not explicitly name or contrast a sibling, and it relies on the tool name and object wording for 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?

No guidance is given about when to choose this tool over siblings such as list_databases, collection_stats, or db_stats, and no exclusions or prerequisites are stated. The only contextual hint is in the parameter schema about the optional database name, which is not tool-selection guidance.

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

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

The readOnlyHint annotation already covers the read-only safety profile, and the description does not contradict it. The added 'beserta ukurannya' provides useful context about the result content, but there is no mention of ordering, size units, or output format. This is acceptable for a simple read-only listing tool.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning: it states the action, the resource, and the included detail about sizes.

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

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

For a zero-parameter, read-only listing operation, the description is sufficiently complete. It names the resource and the result content (sizes). Exact output format or size units are not specified, but these are minor gaps for a tool this simple.

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 zero properties, so there are no parameters to document. Since 0 params gets a baseline of 4, the description does not need to add parameter semantics. Nothing is missing here.

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 'Daftar' (list) and an unambiguous resource, 'semua database' (all databases), and adds the detail 'beserta ukurannya' (with sizes). This makes the tool's purpose immediately clear and distinguishes it from the sibling list_collections, which targets collections rather than databases.

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 specifies the scope ('semua database yang tersedia') but does not explicitly state when to use this tool versus alternatives like list_collections or server_info. Usage is implied by the clear purpose, but no direct comparison or exclusion is provided.

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

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

The readOnlyHint annotation already signals that this is a safe read operation. The description adds no behavioral detail beyond the tool's purpose—no mention of return format, pagination, or any side effects. With annotations covering safety, the description still fails to enrich the agent's understanding of what to expect.

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 front-loads the core action. It is efficient and to the point, though it could include a bit more context without losing brevity.

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 list tool, the description is minimally adequate. It states the action and the required resource (collection). However, it omits any indication of the return structure or whether indexes are returned in any particular order. Given the tool's simplicity and the readOnlyHint, this is acceptable but not thorough.

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

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

The schema already documents both parameters (database optional, collection required) with clear descriptions. The tool description does not add any semantic meaning beyond what the schema provides, 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 states a specific verb and resource: 'List all indexes on a collection.' It is clear and directly reflects the tool name. It does not explicitly differentiate from sibling tools like list_collections or list_databases, but the focus on 'indexes' makes 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 no guidance on when to use this tool versus alternatives. It does not mention any context, exclusions, or prerequisites. An agent receives no help in deciding between this and other list tools.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It only indicates a rename operation, implying mutation, but says nothing about what happens if the new name already exists, how dropTarget behaves, whether indexes or data are preserved, or what failure modes exist.

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 with no filler and the core action is front-loaded. It earns a slightly above-average score because it is compact, though its brevity partly reflects the lack of substantive detail.

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 mutating tool with four parameters, no annotations, and no output schema, a one-line description is incomplete. It omits operational context such as the effect of dropTarget, the optional database parameter's behavior, and what result or error the agent should expect.

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

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

The input schema already documents all four parameters with descriptions, so schema coverage is 100%. The description adds no extra meaning beyond the schema, matching the baseline where the schema carries the parameter documentation 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 uses a specific verb ('Mengganti nama' = rename) and a clear resource ('koleksi' = collection), making the operation intelligible. The rename verb is distinct enough from the create/drop/list sibling tools, though it does not elaborate on scope or side effects.

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 gives no guidance on when to use this tool versus alternatives such as create_collection, drop_collection, or update operations. There are no prerequisites, conditions, or exclusion criteria, so the agent must infer usage entirely from the tool name and sibling list.

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

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

With no annotations, the description carries the burden and does state the core destructive behavior: it replaces the entire contents of an existing document. However, it does not disclose what happens when no document matches, which document is chosen if multiple match, or the default no-upsert behavior, so transparency is only partial.

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 no filler, front-loading the verb and object. It is appropriately concise, though it provides no structured guidance or examples beyond the bare definition.

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 mutating tool with no annotations and no output schema, the description is too thin. It omits key context such as no-match behavior, upsert implications, multi-match selection, and how it differs from update_one, leaving an agent under-informed for reliable invocation.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the critical '$' operator restriction on replacement. The tool description itself adds no parameter-level meaning beyond the schema, matching 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 clearly states a specific verb ('Ganti' / replace), a specific resource ('satu dokumen yang cocok dengan filter'), and the full-replacement scope ('seluruh isi'). It is distinguishable from sibling update_one because it emphasizes replacing the entire document, though it does not explicitly name the sibling.

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 gives no guidance on when to use replace_one versus update_one, insert_one, or delete_one. It does not state exclusions, prerequisites, or conditions like 'use update_one for partial updates.' The usage context must be inferred from the tool's semantics.

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 readOnlyHint annotation already signals safety, and the description adds useful behavioral context by stating that the tool checks connectivity and returns server metadata. It also implies a failure mode by framing the purpose as verifying the connection, which goes beyond the bare annotation.

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 short, purposeful sentences. It front-loads the core action and return information, then adds the practical usage note. No filler or repetition.

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

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

For a zero-parameter, read-only tool, the description covers what it does, what it returns (version, host, replication status), and when to call it. There is no output schema, but the description sufficiently states the expected information, so nothing critical is missing.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The description appropriately focuses on the tool's behavior rather than inputs. Baseline 4 applies for no-parameter tools.

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

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

The description names a specific verb and resource: 'Cek koneksi dan ambil informasi server MongoDB' (check connection and get MongoDB server info). It also lists concrete returned fields (version, host, replication status), clearly distinguishing it from the collection- and document-level sibling tools.

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

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

The description gives an explicit use case: 'Gunakan ini untuk memastikan koneksi berjalan' (use this to ensure the connection is running). It provides clear context for when to call the tool, though it does not spell out when not to use it or name alternatives.

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 only states the tool updates all matching documents but does not mention potential side effects, atomicity, limits, permission requirements, or return value. Given the destructive potential of a bulk update, this is insufficient 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 that immediately states the verb and resource. It has no unnecessary words and is front-loaded. However, its extreme brevity borders on under-specification, though for pure conciseness it earns a 4.

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 5 parameters (including complex object types), no output schema, and no annotations, the description is insufficient. It lacks guidance on risks, expected behavior, or return format. An agent would not have enough contextual information to safely invoke this bulk update 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 descriptions cover all five parameters (100% coverage), including clear examples for filter and update objects. The description adds no additional 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 clearly states the tool updates ALL documents matching a filter, using an update operator. The word 'SEMUA' explicitly differentiates it from update_one and replace_one, making the core purpose unambiguous. However, it does not mention any limitations or nuances, so it stops short of a 5.

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

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 update_one or replace_one. The description does not mention typical scenarios, prerequisites, or exclusions, leaving an agent to infer usage solely from the name and schema. This is a significant gap for a bulk operation that could affect many records.

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 discloses the key side effect (updates one document, not all) and the operator-based mutation style. However, it does not describe behavior when no document matches, upsert implications, or the return 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?

A single, front-loaded sentence with no filler. Every word contributes the operation, cardinality, and update mode. Unnecessary repetition is absent.

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 mutation tool with no annotations and no output schema, the description conveys the core operation economically, and the schema fills in parameter details. The missing return-value and no-match context is a moderate gap, but an agent still has enough to call it 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 input schema already has 100% description coverage, including detailed examples for filter and update, upsert defaults, and database fallback. The description itself adds no parameter-level meaning, 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?

States clearly that it updates the FIRST document matching the filter, using an update operator. The word 'PERTAMA' distinguishes it from update_many, and 'menggunakan operator update' separates it from replace_one.

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

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

The phrase 'DOKUMEN PERTAMA yang cocok dengan filter' gives clear context: use when only the first matching document should be changed. It does not explicitly mention when to prefer update_many or replace_one, so it lacks explicit exclusions.

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