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

No annotations are supplied, so the description carries the entire behavioral burden, yet it discloses nothing beyond the bare action. It does not say whether a token or session is issued, how failed credentials are reported, or whether repeated failed attempts are throttled. The presence of an output schema removes the need to describe return values, but the security-sensitive behavior of an auth operation remains undisclosed.

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, and the core action leads. It is efficient, though its brevity edges toward under-specification rather than optimal density.

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

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

The input schema is fully documented and an output schema exists, so the essential contract is discoverable. However, with no annotations and no behavioral content, the definition leaves a security-critical auth tool's side effects and failure modes unexplained, which is a meaningful gap for this complexity level.

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 all three parameters are already documented, including the collection default of '_superusers' and the custom-collection case. The phrase 'user or superuser' loosely maps to the collection parameter but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Authenticate a user or superuser') plus the credential mechanisms (email and password). It distinguishes the two subject types (user vs superuser), but does not differentiate itself from related siblings such as get_auth_store, which an agent could plausibly confuse with authentication.

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 only: the description makes clear this is the way to authenticate, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives like get_auth_store or of what to do after authenticating.

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 supplied, so the description bears the full behavioral burden, and it does not disclose the most important traits: whether the batch is atomic or allows partial success, what happens to remaining operations when one fails, whether there is a maximum request count, or whether authentication is required. It does add the existence of upsert semantics, which is real value beyond the name, but for an unannotated multi-mutation tool the critical failure semantics are absent.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity is partly the cause of the missing behavioral detail rather than a virtue in itself.

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

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

An output schema exists, so return values need not be described. However, for a batch mutation tool with zero annotations, the description should at minimum cover atomicity/partial-failure behavior and any size limits — the two things an agent must know before assembling a batch. Those omissions leave it materially incomplete for the tool's complexity.

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

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

Schema description coverage is 100%, and the schema's example enumerates the method/url/body shape with concrete POST, PATCH, and DELETE cases, so the description need not repeat it. The description adds nothing about the requests array beyond what the schema already conveys, so 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?

The description states a specific verb set (create/update/upsert/delete) and scope (multiple operations in one request), which distinguishes it from the single-record siblings like create_record and update_record. It also introduces 'upsert', which no sibling offers. It stops short of naming the siblings it replaces, so it lands 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?

'In one request' hints at the efficiency motivation for batching, but there is no explicit guidance on when to choose batch_records over repeated calls to create_record/update_record/delete_record. Nothing is said about batch size limits, ordering guarantees, or whether mixed operation types in a single call are advisable.

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 supplied, so the description carries the full behavioral burden and falls well short. It does not say that creation is a persistent, schema-altering mutation, what permissions are needed, whether it fails on duplicate names, or what errors surface for invalid rule expressions. Only the schema's 'must be unique' note partially covers failure 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?

A single short, front-loaded sentence with no filler or redundancy. It could carry more substance without bloat, but nothing in it is wasted.

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

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

An output schema exists, so return values need not be explained, but this is a nine-parameter schema-mutating operation with zero annotations and the description gives no permission, failure, or side-effect context. An agent would need to infer too much before calling it safely.

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 all nine parameters, including the None-vs-empty-string rule semantics, are already documented in the schema. The description only echoes 'fields and API rules', adding no meaning beyond that, so the 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?

States a specific verb and resource (create a new collection) plus the two main content areas (fields and API rules), so an agent knows exactly what operation this performs. It does not differentiate from sibling update_collection or delete_collection beyond the implicit 'new', but the verb 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?

No explicit guidance about when to use this versus update_collection, no prerequisites (e.g. auth level required to define API rules), and no note about what to do if the collection already exists. Only the word 'new' hints at the create-vs-update distinction.

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 supplied, the description carries the full burden for a mutation tool and discloses almost nothing: no permission or auth requirements, no validation/failure behavior, no statement about whether fields not present in `body` get defaults, and no confirmation of what is returned. The only behavioral signal is the implicit fact that it writes, which is a significant gap for a create 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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though its terseness borders on under-specification rather than being genuinely well-structured guidance.

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

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

An output schema exists, so return values need not be explained, and the input schema is fully documented, which covers the mechanical parts. However, for a mutation tool with zero annotations and several sibling write tools, the description omits error behavior, prerequisites, and sibling routing, leaving the definition adequate but incomplete.

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

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

Schema description coverage is 100%, so `body`, `collection`, `expand`, and `fields` are already documented in the schema, including the key-value example for `body`. The description adds no additional meaning about how `body` must match collection fields or how `expand`/`fields` interact with the response, so the 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?

The description states a specific verb and resource ("Create a new record in a collection"), which distinguishes it from read-oriented siblings like get_record or list_records. It does not differentiate from update_record or batch_records, so an agent must infer that this creates exactly one record while batch_records handles multiples.

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 when-to-use guidance at all, no mention of when to prefer batch_records for multiple records, and no note that update_record should be used for existing records. The agent is left to infer selection from the tool name alone.

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

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

No annotations are supplied, so the description carries the full burden of disclosure for a destructive operation, yet it says nothing about irreversibility, whether contained records are cascade-deleted, required permissions, or idempotency. Only the bare fact of deletion is conveyed.

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 or redundancy. It is efficient, though its brevity contributes to the gaps in behavioral disclosure rather than being a strength on its own.

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

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

Although an output schema exists so return values need not be described, this is a destructive tool with no annotations and the description omits the consequences of deletion (records inside the collection, recoverability) that an agent needs before invoking it.

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

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

Schema description coverage is 100% for the single parameter, so the schema already explains that it accepts an ID or name. The description merely restates that duality and adds no format, resolution-order, or validation detail.

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

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

The description uses a specific verb and resource ("Delete a collection") and states that the target may be given by name or ID, so the action is unambiguous. It does not explicitly differentiate itself from siblings such as delete_record, but the resource noun makes the distinction inferable.

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

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

There is no guidance on when to use this versus alternatives like delete_record or update_collection, and no mention of prerequisites, confirmation steps, or conditions under which deletion should be avoided. The agent must infer all usage context from the name alone.

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

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

"Delete" communicates that the operation is destructive, but no annotations are provided to establish its safety profile. The description does not disclose whether deletion is permanent or soft, whether related data is affected, what permissions are required, or how missing records are handled.

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 single sentence is front-loaded, direct, and contains no filler. Its brevity leaves behavioral gaps, but those are assessed under the other dimensions rather than being wordiness or structural problems.

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 operation with fully described inputs and an output schema, the description is sufficient to identify the basic invocation without needing to explain return values. However, the absence of annotations makes the missing deletion semantics and side-effect information meaningful gaps for a destructive tool.

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

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

Schema description coverage is 100%, so the structured fields already document both required parameters and establish the baseline score. The description reinforces the role of record_id but adds no further meaning about collection identifiers, ID formats, or how the two parameters relate.

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, resource, and targeting method: deleting a record by ID. It is distinguishable from delete_collection and update_record by its wording, but it does not explicitly differentiate itself from 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 phrase "by ID" gives minimal implicit context for when to use it, but there are no prerequisites, exclusions, or alternative-tool recommendations. It does not explain when batch_records or delete_collection 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?

With no annotations, the description carries the full burden. It does disclose that the return payload contains an active token and stored sessions, which is valuable sensitivity context, but it says nothing about whether the call is read-only, what happens when unauthenticated, or any permission requirements.

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

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

Two short sentences, front-loaded with the purpose. The "Returns:" block duplicates the existing output schema and is partly redundant, though it is brief enough not to be wasteful.

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

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

An output schema exists, so the return-value sentence is not strictly needed, and for a zero-parameter getter the description is close to sufficient. It still leaves the unauthenticated-state behavior and safety profile unstated, which matters for a tool that surfaces tokens.

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

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

The tool takes zero parameters, so there is no parameter meaning to add and the baseline applies. The description correctly does not invent inputs.

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

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

States a specific verb and resource ("Return the current authentication state") and its scope, which distinguishes it from the sibling auth_with_password by implying a read of existing state rather than a login action. It never names that sibling explicitly, so the differentiation is inferential rather than stated.

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 when-to-use or when-not-to-use guidance is given, and the obvious alternative (auth_with_password) is not mentioned. An agent must guess whether this tool is for checking login status versus initiating authentication.

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 supplied, so the description carries the full burden of behavioral disclosure. "Get" implies a read, but the description says nothing about read-only guarantees, what happens when the name/ID does not exist, or any permission requirements for private collections.

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 with the resource and its lookups front-loaded and no filler. It is efficient, though the brevity comes at the cost of the missing behavior and selection guidance noted above.

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

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

An output schema exists and there is only one well-documented parameter, so return values and inputs are covered elsewhere. However, with zero annotations the description should still establish that this is a safe read and what a missing collection looks like; that gap keeps it at minimum-viable.

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

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

Schema description coverage is 100%, and the schema already says the parameter accepts "The collection ID or name." The description's "by name or ID" repeats that rather than adding format, precedence, or edge-case meaning such as what happens if a name collides with an ID.

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

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

States a specific verb ("Get") and a specific resource ("collection schema"), keyed by name or ID. It is distinguishable from list_collections and get_record, though it never explicitly contrasts itself with the other read tools like list_collections or get_auth_store.

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 when-to-use or when-not-to-use guidance and no named alternative. An agent must infer that this is the single-collection lookup versus list_collections for enumeration, entirely from the tool's name and the 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?

No annotations are supplied, so the description carries the full burden. 'Get' implies a read, but it says nothing about error behavior for missing records, whether expand/fields change payload size or trigger extra fetches, or permission requirements — meaningful gaps for an unannotated tool.

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

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

A single short sentence with zero wasted wording and the core action front-loaded. Brevity is appropriate, though it borders on under-specification rather than elegant concision.

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

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

An output schema exists, so return values needn't be explained, and the input schema fully documents the parameters. However, with no annotations and no usage or error context, a retrieval tool on a large sibling set deserves more than one sentence.

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 all four parameters, including expand and fields, are already documented in the schema. The description adds no additional meaning beyond that 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?

States a specific verb ('Get') and resource ('a single record') scoped by ID, which is clear enough to distinguish from list_records at a glance. It does not explicitly name or contrast with siblings, and omits that a collection scope is required, so it falls short of full differentiation.

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

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

There is no guidance on when to use this versus list_records, batch_records, or get_collection, and no mention of prerequisites such as needing a valid collection. The agent must infer the use case purely from the name.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that filtering, sorting and pagination are optional, but says nothing about whether the listing is admin-scoped, whether it returns only accessible collections, or what the defaults are — all relevant for a PocketBase collections endpoint.

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 the resource first and capabilities second; nothing is redundant. It is arguably too terse for the behavioral gaps it leaves, but there is no wasted wording.

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 output schema covers return values and the input schema covers all four optional parameters, so the mechanical calling information is complete. What is missing relative to a collections-listing tool is the permission/auth context and any statement of listing scope.

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 page, per_page, sort and filter are already fully documented with defaults and examples. The description only echoes the parameter categories at a high level and adds no syntax or constraint detail 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?

States a specific verb and resource ("List all collections") and names the three supported operations. It is distinguishable from get_collection (singular retrieval) by the word "all", though it never explicitly contrasts itself with that 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?

There is no when-to-use guidance, no mention of when to prefer get_collection, and no prerequisites such as required auth scope. The agent must infer usage entirely from the tool name and the word "optional".

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

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

With no annotations, the description carries the full behavioral burden, and it only discloses that pagination exists. It does not state that this is a read-only operation, whether collection access rules or auth apply, how results are ordered by default, or the cost implications of the total-count query that skip_total hints at. An output schema exists, so return-value explanation is not required.

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, and the core capability set appears immediately. It is efficient, though the brevity borders on under-specification for an eight-parameter tool.

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

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

With 100% schema coverage and an output schema, the structural load is already carried elsewhere, so the short description is not fatal. However, for an eight-parameter list tool with no annotations, it says nothing about access control, default ordering, or the performance tradeoff behind skip_total, leaving gaps an agent would want filled.

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

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

Schema coverage is 100%, so all eight parameters, including the PocketBase filter syntax, sort expression format, expand, fields, and skip_total, are already documented in the schema. The description's 'filtering, sorting, and pagination' merely summarizes a subset of those parameters and adds no semantics beyond the schema, so the 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?

The sentence gives a specific verb ('List') and resource ('records in a collection') and names the three capabilities (filtering, sorting, pagination), which is enough to distinguish it from get_record and create_record. It stops short of explicitly contrasting with siblings like list_collections, so it is clear but not fully differentiated.

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?

Enumeration is implicitly the use case, but there is no explicit 'use this when...' statement, no mention of when to prefer get_record for a single item, and no prerequisites such as collection permissions or auth requirements. The agent must infer the routing from the tool name.

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 supplied, so the description carries the full disclosure burden, and it discloses almost nothing: not that passing 'fields' or 'indexes' replaces existing definitions, not the '__unset__' semantics for rules, not permission requirements, and not whether the change is reversible. For a 9-parameter mutation tool this is a significant gap.

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 short sentence, front-loaded with the verb and resource, with no filler. Its brevity is efficient but borders on under-specification for a mutation tool with nine parameters.

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

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

With an output schema present the return value need not be explained, but a mutation tool with no annotations and destructive replacement semantics (fields, indexes, rules) needs more than one sentence. The description leaves permission requirements and the overwrite behavior unstated, relying entirely on the schema.

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

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

Schema description coverage is 100%, so all nine parameters, including the '__unset__' sentinel and the empty-string/public rule convention, are already documented in the schema. The description adds only the high-level grouping 'schema or rules' and omits renaming, so it does not exceed 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?

States a specific verb and resource ('Update a collection') plus the broad scope of what can change ('schema or rules'). It is distinguishable from record-level siblings (update_record) and from create_collection/delete_collection by name and verb. It stops short of naming siblings explicitly or noting that renaming is also possible, so it is clear but not fully differentiating.

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

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

There is no guidance on when to use this versus alternatives such as create_collection or delete_collection, and no prerequisites (admin/auth requirements, whether the collection must be empty or existing). The agent must infer usage entirely from the tool name.

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 supplied, so the description carries the full behavioral burden. "Update" implies a mutation, but the description does not disclose partial-update behavior, missing-record semantics, permissions, or other safety context.

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

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

The single sentence is short, readable, and front-loaded, with no structural clutter. However, its brevity provides almost no value beyond the tool name, making it under-specified rather than usefully concise.

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

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

The rich input schema and presence of an output schema reduce what the description must explain, but this remains an unannotated mutation with five parameters and a nested body. A minimal restatement is not complete enough; it should at least clarify partial updates and routing versus related record tools.

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

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

Schema description coverage is 100%, including the important partial-update semantics of `body` and the response-shaping options `expand` and `fields`. The description adds no parameter meaning, so the high schema coverage supports the baseline score.

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

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

The description identifies an update to an existing record, but it simply verbalizes `update_record` without adding scope or distinguishing it from siblings such as `update_collection` or `create_record`. This makes it largely tautological rather than informative.

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

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

There is no explicit when-to-use or when-not-to-use guidance, prerequisite, or alternative. The word "existing" only weakly implies that creation requires another tool; `create_record` is never named.

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