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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, closed-world), and the description adds meaningful non-obvious context beyond them: the analysis is queued asynchronously and 'may invoke the configured LLM,' signaling latency/cost implications. It does not state whether repeated calls duplicate work, a minor 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?

Two tightly written sentences: the action is front-loaded, followed immediately by the required follow-up step. No filler or redundancy.

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

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

With an output schema present, return values needn't be explained; the description still conveys the async queue-and-poll model and the LLM dependency. Sufficient for correct invocation, though it could clarify whether re-invocation is idempotent.

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 per the rubric this is the baseline 4. There is no parameter surface for the description to describe or compensate for.

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 ('Queue schema analysis') and resource ('relationship pattern suggestions') for a defined scope ('the current project'). It is clearly distinguishable from listRelationshipPatterns, which it explicitly designates for a different purpose (inspecting status/suggestions).

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?

Names the companion tool and the follow-up action ('Poll listRelationshipPatterns to inspect completion status'). This gives clear context on where this tool sits in the workflow, though it stops short of explicit when-not-to-use or prerequisite conditions.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write. The description adds some behavioral context by stating that the pattern is applied and that the user should review inferred fields first. It does not disclose failure modes, authorization needs, or what happens to the underlying schema or data when the pattern is applied, so it adds only modest value beyond 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 two tight sentences with no wasted words. It front-loads the core action and then appends the critical precondition. Every clause earns its place and follows a logical order.

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. The one parameter is fully documented in the schema, annotations cover the safety profile, and the description covers the core action plus the required review workflow. It is missing only a note on error behavior or how it relates to sibling actions like ignore/delete, so it is not quite flawless.

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 single 'id' parameter is fully described in the schema as the ID of the suggested relationship pattern to approve. The description does not add any format, constraint, or semantic detail beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Approve and apply a suggested relationship pattern.' It also names listRelationshipPatterns as the prerequisite, which helps distinguish it from the read-only listing tool. However, it does not explicitly differentiate itself from close siblings like ignoreRelationshipPattern or deleteRelationshipPattern, so it falls 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?

It gives a clear, actionable precondition: 'Call listRelationshipPatterns first so the user can review the inferred source, target, direction, type, mode, and confidence.' This tells the agent exactly when and in what sequence to use the tool. It does not mention when not to use it or compare it against alternative pattern actions such as ignoring or deleting.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this mutates local state without being destructive. The description adds the useful pre-existence constraint and the findRecords prerequisite, but says nothing about duplicate-edge behavior, idempotency, permission requirements, or transaction semantics despite a transactionId parameter.

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: the first states the action, the second states the precondition and the remedy. The critical constraint is front-loaded 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?

An output schema exists, so return values need no explanation, and the 7-parameter surface is fully described in the schema. The remaining gap is minor: the description says 'directed or bidirectional' while the enum also offers 'incoming', leaving the direction semantics slightly under-explained for an edge-creation 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 schema already documents sourceId, targetId/targetIds, direction, properties and transactionId; the baseline is 3. The description only reinforces the targetId/targetIds pre-existence requirement and adds nothing about direction values or property restrictions beyond what the schema states.

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

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

The description gives a specific verb and resource — 'Create a directed or bidirectional relationship between records' — so the agent immediately knows this is an edge-creation operation. It does not, however, explicitly distinguish itself from the inverse sibling detachRelation or the read-only findRelationships, so it falls 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?

It states a concrete precondition (sourceId and targetId/targetIds must already exist) and routes the agent to findRecords for resolution, which is genuine when-to-use guidance. It stops short of when-not-to-use, e.g. that detachRelation removes edges or that records must pre-exist rather than be auto-created, so it is clear but not exhaustive.

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 only declare safety hints (not read-only, not destructive); the description adds the substantive behavior an agent needs: how append vs rewrite treat existing unspecified fields and that mergeBy presence triggers upsert. It does not cover partial-failure or atomicity behavior despite the transactionId parameter existing.

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?

Three tight sentences, bulk scope front-loaded, then options semantics, then the label-casing caveat. 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?

Output schema exists so return values need no explanation, and annotations cover the safety profile; the description covers the upsert model well. Gaps remain around batch size limits, error/partial-success semantics, and the purpose of transactionId.

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 baseline is 3; the description goes slightly beyond by linking mergeStrategy/mergeBy to the upsert activation mechanism and clarifying the semantic effect of 'append'. It ignores transactionId and skipEmptyValues, which the schema handles alone.

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 ('Insert multiple records'), plus the key scope constraint ('of the same label in one call') that distinguishes it from the singular createRecord 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?

Explains the conditional that switches it into upsert mode (set mergeStrategy and mergeBy) and routes the agent to findLabels for correct label casing. It lacks explicit when-not guidance (e.g., use createRecord for single 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds genuinely new context beyond that: it stresses irreversibility, high-impact potential, and a mandatory preview+confirmation protocol. It stops short of noting limits, partial-failure behavior, or how transactionId affects atomicity.

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?

Three sentences, zero padding, and the irreversibility warning is placed ahead of the procedural requirement so the agent registers risk before workflow. Every clause earns its place.

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 no explanation. For a destructive bulk mutation the description covers the critical unknowns (irreversibility, required confirmation). Minor gaps remain around atomicity/limits, but nothing an agent needs to invoke it safely 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?

Schema description coverage is 100%, so all three parameters (where, labels, transactionId) are already documented. The description only indirectly hints at where/labels via the findRecords parity requirement and adds nothing about transactionId, 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+resource ('Delete all records') plus the scope qualifier ('matching a query'), which distinguishes it from the single-record siblings deleteRecord/deleteRecordById. The impact framing in the same sentence aids selection immediately.

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?

Gives an explicit prerequisite workflow: call findRecords with the same labels+where to preview, then obtain explicit user confirmation before invoking. This is a named alternative plus the condition that selects it, leaving nothing to inference.

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

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

With annotations only declaring readOnly=false, destructive=false, openWorld=false, the description supplies the behavior that actually matters: managed indexes asynchronously embed every existing value and keep new values embedded on write, the index has a status lifecycle ending in "ready", and external indexes require the client to push vectors. This is exactly the beyond-annotation context an agent needs for a long-running, stateful 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?

Three tight sentences, front-loaded with the purpose, then mode semantics, then the post-creation workflow. No filler and no repetition of schema text.

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 multi-mode, asynchronous creation tool with an output schema available, the description covers the creation semantics, the two operating modes, the readiness signal, and the downstream query tool. Nothing an agent needs to invoke and then correctly follow up 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains the sourceType dichotomy (managed vs external), that dimensions matter primarily for external indexes, and that vectors for external indexes arrive via upsertEmbeddingVectors. That workflow context goes beyond the field-level descriptions.

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

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

The first sentence states a specific verb and resource ('Create a new embedding index policy for a string property'), and the rest of the description anchors it against the sibling tools it pairs with (getEmbeddingIndexStats, vectorSearch, upsertEmbeddingVectors). An agent can distinguish this from createTextIndex/textSearch by the explicit vector-embedding framing.

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

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

It clearly explains when each mode applies ('For managed indexes (default)... For external indexes (sourceType: "external"), the client supplies vectors via upsertEmbeddingVectors') and gives the follow-on workflow (wait for status "ready", then use vectorSearch). It never states when not to use this tool or prerequisites like model configuration, so it stops short of full when/when-not guidance.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds real behavioral context beyond that: that mergeStrategy+mergeBy together enable upsert and that labels must match findLabels casing. It stops short of stating what happens on a label/record conflict when upsert is not enabled (duplicate vs. error).

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?

Three short sentences, each earning its place: the core action first, then the label prerequisite, then the upsert control. No redundancy and 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?

With an output schema present, return values need not be explained, and annotations carry the safety profile, so the description covers the mutation-specific essentials (label source, upsert semantics). The remaining gap is conflict behavior when upsert is not enabled.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the label casing requirement (schema only says 'Label for the record') and the fact that mergeStrategy and mergeBy must be set together to trigger upsert. This is a genuine supplement over the structured fields.

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

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

The description opens with a specific verb+resource ('Create a new record'), which is clear and distinct from read-oriented siblings like findRecords/getRecord. It does not, however, differentiate itself from the closely related write siblings setRecord, updateRecord, or bulkCreateRecords, leaving that ambiguity for the agent to resolve.

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

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

It gives one actionable prerequisite ('Use the exact label casing returned by findLabels') and explains the upsert toggle, which is useful cross-tool guidance. But it never states when to choose createRecord over setRecord/updateRecord/bulkCreateRecords, so tool-selection guidance is only implied.

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

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

Annotations declare this is a write (readOnlyHint=false) but non-destructive, so the remaining burden is light. The description adds real behavioral value beyond that: the index is built online and passes through a status lifecycle ("ready") before it is queryable, which the agent must know before expecting search results.

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

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

Two dense sentences with zero filler; the core declaration semantics are front-loaded and the lifecycle/query follow-up is packed into the second sentence with useful parenthetical pointers.

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, return values need not be explained, and the description covers creation scope, async build status, and the tools that consume the index. It omits edge cases such as duplicate-name behavior or the default insertion path shaping the "all" name.

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%, documenting name defaulting, the "*" property wildcard, and the consistency enum, so the baseline is 3. The description restates the "*" wildcard but adds no syntax, naming, or consistency tradeoff 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?

Names a specific verb ("Declare"), a precise resource ("keyword (BM25) text index"), and its exact scope ("one property of a label, or every string of it"). The BM25/keyword framing distinguishes it from the embedding-index sibling without opening a schema.

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

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

Gives a clear operational sequence: the index is built online, its status becomes "ready" (checked via listTextIndexes), then it is queried with textSearch or as the text leg of vectorSearch. It lacks an explicit alternative clause (e.g., when to prefer createEmbeddingIndex instead).

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is known; the description adds real value beyond that by disclosing irreversibility and the collateral effect of removing all stored embedding vectors, plus a confirmation requirement. It does not cover permissions, rate limits, or failure modes, keeping it below a 5.

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?

Four short sentences, zero filler, with the destructive action and its scope front-loaded before the prerequisite and confirmation 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 no explanation; the description covers the destructive consequence, irreversibility, confirmation requirement, and ID acquisition path. Minor omissions such as required permissions or post-delete side effects on related indexes keep it from being fully exhaustive.

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 indexId parameter, so the schema already carries the parameter documentation; the description's 'by its ID' and the findEmbeddingIndexes hint add modest routing value but no format or type 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 plus resource ('Delete an embedding index policy by its ID') and adds the secondary effect of stripping stored embedding vectors, which distinguishes it from sibling tools like deleteTextIndex and deleteRecord. An agent can identify the target and scope without opening the schema.

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

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

Gives a clear prerequisite path ('Use findEmbeddingIndexes to get the indexId') and a mandatory safety step ('Confirm with the user before calling'). It does not state when this tool is not appropriate or name a delete alternative, but the context and gating condition are unambiguous.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable behavioral context: 'Permanently delete' and 'Irreversible' reinforce the severity, and the explicit instruction to confirm with the user is a key operational requirement beyond annotations. It does not cover permissions or error behavior, but for a simple destructive tool this is substantial.

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

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

The description is three short sentences, front-loaded with the core action, followed by irreversibility and a confirmation directive. Every sentence earns its place with no redundancy.

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

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

Given the tool's simplicity (one required parameter, output schema exists), the description covers the essential aspects: what it does, that it is irreversible, and that user confirmation is needed. It could mention potential dependencies (e.g., property must exist) or error cases, but overall it is sufficient for an agent to invoke 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?

Schema coverage is 100%, so the single parameter propertyId is fully documented in the schema. The description adds no additional meaning about the parameter (e.g., format or constraints), so the baseline score of 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb (delete) and resource (property) with precise scope ('all its values from every record that has it'). It clearly distinguishes from siblings like deleteRecord or deleteTextIndex by focusing on properties, so an agent can identify the right tool without ambiguity.

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

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

The description provides a clear usage condition: 'Confirm with the user before calling.' It also implies irreversibility, which guides caution. However, it does not explicitly name alternative tools or when not to use this one, leaving some inference to the agent.

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

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

Annotations already declare destructiveHint=true, so the safety profile is known, but the description adds genuinely non-redundant context: the operation is irreversible and should be confirmed with the user. It omits any permission/auth requirements or what the returned payload confirms about the deletion.

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?

Four short sentences, front-loaded with the action, then risk, then the pre-call protocol. Every sentence carries a distinct instruction and none is padding.

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 no explanation, and the description covers the risk and the workflow. It could still say whether the delete is idempotent or what error means (record missing), but the essentials for correct invocation are 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?

Schema coverage is 100%, so both recordId and the optional transactionId are already documented in the schema. The description adds nothing about the transactional parameter (e.g. atomicity semantics), 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?

Specific verb+resource ('Delete a single record') with an explicit scope qualifier ('single') that separates it from bulkDeleteRecords. It does not, however, distinguish itself from the very similarly named sibling deleteRecordById, leaving some ambiguity about which single-record delete to pick.

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?

Gives concrete operating guidance: confirm with the user before calling, and preview with findRecords first. This is real when/how-to-use context. It stops short of stating when NOT to use this tool or when a sibling delete is preferable.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is partly covered; the description reinforces this with 'Irreversible' and adds a human-confirmation requirement, which is real behavioral context. It says nothing about what happens on failure, partial deletion, or how transactionId affects atomicity.

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?

Three short sentences, front-loaded with the core action, then the irreversibility warning and confirmation requirement, then the alternative. Every sentence carries distinct information with no padding.

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 annotations covering the safety profile, an output schema handling return values, and 100% schema coverage on parameters, the description supplies everything else an agent needs: destructive scope, confirmation obligation, and a preview path.

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 schema, and the description adds no format or usage detail for transactionId. 'By ID' merely restates the recordId parameter, 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 gives a specific verb and resource with scope ('Delete a single record by ID'), which distinguishes it from bulkDeleteRecords and bulkDeleteRecords-like siblings. However, it does not differentiate from the sibling deleteRecord, leaving the agent unsure which single-delete tool to pick.

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

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

It states a precondition ('Always confirm with the user before calling') and points to an alternative for inspection ('Use getRecord to preview the record if needed'). It stops short of explicit when-not guidance or clarifying the split with deleteRecord.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is partly carried by structured data. The description goes beyond that by flagging the operation as irreversible, requiring user confirmation, and disclosing the cascade behavior when deleteExisting is true — exactly the kind of 'what gets destroyed' detail that annotations cannot express.

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?

Four short sentences, each carrying distinct information: action, reversibility, confirmation requirement, and cascade semantics. The most important constraint (irreversible) is front-loaded immediately after the action.

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. For a destructive mutation with annotations covering the safety hints, the description supplies the remaining decision-critical context: irreversibility, the confirmation requirement, and the side effect of the optional parameter.

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 schema. The description's restatement of the deleteExisting cascade ('relationships previously materialized by this pattern are also removed') is essentially a duplicate of the schema text and adds no new syntax, default, or edge-case 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?

The first sentence states a specific verb (Delete) and a specific resource (saved relationship pattern), which cleanly separates it from the many sibling deletion tools (deleteRecord, deleteProperty, deleteTextIndex) that target different resources. An agent can identify the target of this tool without opening the schema.

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

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

The description supplies one operational directive ('Confirm with the user before calling') but gives no guidance on when this tool is appropriate versus siblings like ignoreRelationshipPattern or listRelationshipPatterns, nor any prerequisites. Usage is implied by the verb rather than explicitly framed.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds value beyond that by explicitly labeling the operation 'Irreversible' and requiring user confirmation, which is exactly the kind of consequence detail annotations cannot express.

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?

Three short sentences with the action front-loaded, the irreversibility stated second, and the confirmation requirement last. Every sentence earns its place with 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?

An output schema exists so return values need no explanation, and the annotations plus the description together cover the destructive nature, irreversibility, and the confirmation requirement. An agent has everything needed to invoke this 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?

Schema coverage is 100% and the single parameter is fully documented, including the source of valid names ('from listTextIndexes'). The description's 'by name' adds no meaning 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?

States a specific verb (Drop) and resource (text index) with the identifying parameter (by name). It is unambiguously distinct from the sibling listTextIndexes and createTextIndex, so an agent can pick it without opening a schema.

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

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

Provides a prerequisite directive ('Confirm with the user before calling'), which is genuine usage guidance. However, it never states when this tool should be chosen over alternatives or what conditions make deletion appropriate versus, say, recreating an index.

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?

Adds two behavioral facts not carried by the annotations: the tool is unavailable inside a transaction, and omitting relationType widens the destructive blast radius to every relation type. That meaningfully supplements destructiveHint=true. It stops short of saying what happens when no matching relationship exists (error vs silent no-op) or any authorization requirement.

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?

Three tight sentences: operation first, then the two parameter-driven behaviors, then the prerequisite inspection step. Every sentence carries distinct information with no restatement of the tool name.

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, return values need no explanation, and the description covers the destructive scope, transaction restriction, and verification workflow. A no-match/error behavior note would make it complete for a destructive mutation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra credit by explaining the interaction semantics of relationType omission and direction='bidirectional' rather than just restating the field docs. It does not mention the targetId/targetIds deprecation trade-off handled in 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+resource ('Remove the relationships between a record and target records') with the scope of what a relation is. Clear enough to separate from attachRelation, though it never names attachRelation as the inverse operation — it only routes to findRelationships.

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?

Gives explicit pre-call guidance: use findRelationships to inspect and confirm the correct type/direction before detaching. It also states the selection conditions for the optional params (omit relationType = all types, bidirectional = both ways). Missing only an explicit 'do not use this when you meant to move/update a relation' exclusion.

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

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

Annotations already declare readOnly=true/destructive=false, and an output schema covers the return value, so the description adds the non-obvious behavior: a downloadable CSV artifact is produced rather than data returned inline, and it carries an explicit consent gate. It does not mention size/limit or performance characteristics of large exports, keeping it from a 5.

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?

Three sentences, each earning its place, with the gating condition front-loaded ahead of the alternative and the prerequisite. No filler or restatement of the name.

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 4-parameter export tool with full schema coverage, complete annotations, and an output schema, the description fills the remaining gaps agents need: when it is appropriate, what it replaces, and what to do first. Nothing required for correct invocation 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?

Schema coverage is 100%, so all four parameters (limit, where, labels, orderBy) are already documented by the schema, which sets the baseline at 3. The description adds a useful cross-tool equivalence ('accepts the same labels/where/orderBy filters as findRecords') and a hint on sourcing field names, but says nothing about limit or filter syntax beyond that.

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 (export), resource (matching records) and concrete output artifact (a CSV file), which distinguishes it from findRecords and other read tools. An agent knows exactly what the call produces without opening a schema.

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

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

Gives both the when ('only when the user explicitly asks to export/download CSV') and the when-not with a named alternative ('for normal reading... use findRecords instead'), plus a prerequisite ('call findProperties first' before building a where filter). Nothing is left to inference.

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

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds useful behavioral detail beyond that: the enumerable status lifecycle values (pending|indexing|ready|error) and the intended dedupe-check usage pattern.

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

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

Two sentences, front-loaded with the core action and followed by the field list and the pre-flight check. No redundant or filler text.

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?

A zero-parameter read tool with full annotation coverage and an output schema; the description supplies everything an agent needs to decide when to call it and what it will see, without duplicating return-value documentation.

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 argument semantics to explain; baseline 4 applies. The mention of label+propertyName refers to index attributes referenced elsewhere, not to inputs 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?

States a specific verb and resource ('List all embedding index policies configured for the current project') and enumerates the returned fields, which clearly separates it from createEmbeddingIndex/deleteEmbeddingIndex/getEmbeddingIndexStats. It never names a sibling explicitly, so differentiation is inferable 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?

Gives an explicit call condition: 'Call this before creating a new index to check if one already exists for the same label+propertyName.' That is actionable pre-flight guidance, though it offers no when-not-to-use or alternative tool routing.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower. The description adds real behavioral context: `where` filters Records rather than label metadata, names are case-sensitive and must be reused verbatim, and the returned name+count shape. The return-shape note is partly redundant given the output schema, keeping it at a 4.

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?

Front-loads the most important warning (the getSchemaMarkdown conflict) before the mechanics. It is dense but long, and the trailing label-matching heuristic ('exact match > starts-with > substring...') is procedural advice that slightly exceeds what's needed to invoke the 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?

For a read-only listing tool with full schema coverage and an output schema, nothing an agent needs to call it correctly is missing: routing, no-arg behavior, `where` scope, and case-sensitive name handling are all 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?

Schema coverage is 100%, so the 3 baseline is met by the schema alone. The description goes further by clarifying the critical scoping semantics of `where` (record-scoped, not label metadata) and confirming the no-arg case, which the schema's 'Record-scoped filter' line only partly conveys.

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 (list/filter) and resource (record types / labels), and explicitly names the sibling getSchemaMarkdown as the tool NOT to substitute for. An agent can tell it apart from getSchemaMarkdown and findProperties without opening the schema.

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

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

Gives an explicit when-not ('do NOT call findLabels as a substitute for getSchemaMarkdown'), two concrete when-to-call conditions (label counts after record-scoped predicates, or when getSchemaMarkdown wasn't called), and the no-arg behavior. Routing is unambiguous.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds real behavioral context beyond that: it returns only the first match and recommends a small limit, tying the tool to a resolve-then-filter workflow. It doesn't say what happens on zero matches, which the output schema presumably covers.

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?

Three sentences, each load-bearing: purpose, invocation pattern, and alternative-selection rule. Scoping constraint and the recommended call shape are front-loaded with 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?

For a 2-param read tool with an output schema, the description covers purpose, usage, invocation and the sibling trade-off. The only gap is edge-case behavior such as a missing match returning null, which the output schema likely documents.

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

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

Schema coverage is 100%, so the baseline is 3, but the description supplies a concrete example of the where object syntax ({ <nameField>: { $contains: "..." } }) that the generic schema description does not convey. That is genuine added meaning over the structured field.

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 with scope: 'Return the first record matching the query'. It explicitly differentiates from the sibling findRecords ('exactly one representative match rather than a full list'), so an agent can select between them without opening schemas.

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?

Names the concrete use case (entity resolution probes), the alternative (findRecords) and the condition that selects it. It even prescribes the invocation shape — where with $contains plus a small limit — to resolve a name to an ID before relationship filtering.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. Beyond that, the description discloses the exact shape of returned property objects (id, name, type, recordsCount), clarifies that `where` applies to Records rather than property metadata, and maps post-call branches. This adds substantial behavioral context beyond the annotations.

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

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

The description is front-loaded with purpose, then imperative usage, then return structure, then a next-step decision tree. Every sentence earns its place and directly helps an agent act, despite the length.

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 exists, so return-value details are redundant but harmless. The description is mostly complete for a discovery tool, but the mention of a `labels` parameter absent from the schema is a gap that could confuse invocation. Otherwise it covers usage, return shape, and next steps thoroughly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some meaning (e.g., how the `name` field should be used in where/orderBy/groupBy), but it also references a `labels: ["LABEL_NAME"]` filter that does not exist in the input schema, which could mislead an agent. It does not add enough beyond the schema to justify a higher 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?

States a specific verb and resource: 'Discover the field names, types, and IDs available on a record label.' It explicitly distinguishes itself from query tools (findRecords) and value tools (propertyValues) by directing the agent to use it first before any query. An agent can identify the tool's role without opening the schema.

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

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

Provides an explicit imperative ('Always call this before using field names in any query — never guess or invent field names'), names the alternative next steps (propertyValues, findRecords), and gives a conditional decision tree based on field type. Nothing about when/when-not is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds value by naming the concrete metadata fields returned, though it omits behavior for an unknown/invalid propertyId (error vs empty result).

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

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

Two sentences, no waste. The purpose and returned fields come first, followed by the usage condition and sibling handoff.

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 further, and the description covers purpose and usage well. Minor gap: no mention of not-found/error behavior for an invalid propertyId.

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

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

With a single parameter at 100% schema description coverage, the schema already documents propertyId. The description reinforces that lookup is by ID but adds no format or validation details beyond the schema, 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?

States a specific verb (Fetch) and resource (metadata of a single property by ID) and enumerates the returned fields (name, type, label, recordsCount). This clearly distinguishes it from sibling list/search tools like findProperties and propertyValues.

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?

Explicitly says when to use it: when you already have a propertyId and need to re-confirm type or cardinality before calling propertyValues. It names the downstream alternative and the condition that selects this tool.

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

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

Annotations already cover the safety profile (readOnly, non-destructive), and the description goes well beyond it: documents the response shape { data, total }, the metric-vs-listing distinction, the limit-with-select hazard, label/traversal scoping semantics, and the groupBy alias restriction. These are non-obvious behavioral traps an agent could not infer from annotations or schema.

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?

Front-loaded with purpose and the routing decision, then organized into INTENT/RESPONSE/HARD RULES blocks that are easy to scan. Slightly bloated by the synonym list ('find records, search records, list records, retrieve matching records, filter records') and some overlap between the description's response shape and the existing output schema.

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

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

For a 7-parameter query tool with nested objects, rich annotations, and an output schema, the description covers everything needed to call it correctly — intent routing, prerequisite spec lookup, response shape, and five failure-mode rules. Nothing material is left to inference.

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 baseline is 3, but the description adds cross-parameter rules the schema cannot express: never set limit when select is present, labels contain root records only with related labels nested via $alias, and groupBy rejects alias-only values. It stops short of 5 because much of the per-parameter operator detail merely points back to getSearchQuerySpec.

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 ('Primary read/query/list/search tool for records') and enumerates the query intents it serves. It explicitly names the sibling it is not (exportRecords) and the prerequisite sibling (getSearchQuerySpec), so an agent can route without opening a schema.

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

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

Explicit when-to-use rules: use this rather than exportRecords unless the user explicitly asks for CSV/export/download, and call getSearchQuerySpec before building date/metric/groupBy/traversal/vector queries. Also gives intent-based routing (metrics request → select + groupBy) with a negative instruction ('NEVER fetch raw records to count/sum manually').

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds real behavioral context beyond that: where applies to relationship edges while source/target scope endpoint records, and the no-select/groupBy limitation. It stops short of describing result shape or pagination semantics, hence a 4 rather than 5.

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 operation is front-loaded ('Discover and traverse relationships between records') before the two scenarios, and each clause carries actionable content rather than filler. It is dense and slightly long but no sentence is redundant.

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 description is not obligated to explain return values, and the schema covers all six parameters. What remains — when to use this versus findRecords, how to chain it for multi-hop traversal, and the select/groupBy exclusion — is precisely what the structured fields cannot express, and it is all 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?

Schema description coverage is 100% with defaults on skip/limit, so the structured fields already carry most semantics. The description still adds value by disambiguating the edge-level 'where' from the endpoint-level source.where/target.where and by showing how source.where is used with a sample record ID in practice, which the schema does not convey.

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+resource ('Discover and traverse relationships between records') and immediately frames the two modes of operation. It also names the sibling it is not (findRecords) so an agent can separate this from the analytics/query tools without opening a schema.

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

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

Explicitly enumerates two scenarios (multi-hop path discovery and edge filtering), gives the procedure for the first (fetch a sample ID, filter source.where/target.where, repeat, then build a nested findRecords clause), and states a negative constraint: no select/groupBy, use findRecords for metrics. This is explicit when/when-not/alternative guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the tool throws on zero matches and on multiple matches, which is the key distinction an agent must know before calling it. It does not cover return shape, but an output schema exists.

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?

Three sentences with no filler, front-loaded with the core behavior and the throw semantics, then the use case, then the alternative. Every sentence earns its place.

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 two-parameter read lookup with an output schema, annotations, and a 100%-covered input schema, nothing an agent needs is missing. The distinctive error behavior and the sibling routing are both spelled out.

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 both parameters (where, labels) are documented in the schema, so the baseline is 3. The description mentions example key types (email, code, slug) for uniqueness but adds no syntax or format detail for the where/labels parameters themselves.

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 single unique record) plus the exact scope constraint: it throws when zero or more than one record matches. It is immediately distinguishable from findRecords, findOneRecord, and getRecord by that all-or-nothing semantics.

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?

Explicitly says when to use it (unique-key lookups like email, code, slug where exactly one result is expected) and names the alternative with the condition that selects it: use findOneRecord when only the first match is wanted and duplicates are acceptable. Both the when and the when-not are covered.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral meaning beyond that: the operation is a non-destructive progress probe whose readiness semantics depend on comparing two returned counters.

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

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

Two sentences: the first defines the return payload, the second defines the usage trigger. Nothing is wasted and 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?

An output schema exists, so return values need no elaboration, and the description still supplies the interpretive rule (indexedRecords === totalRecords means ready) that a raw output schema could not convey. Nothing needed to call this correctly 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?

Schema coverage is 100% and the schema itself documents indexId, including that an ID or name from findEmbeddingIndexes is accepted. The description adds no parameter-level detail, so this is the baseline case where the schema does the work.

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

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

States a specific verb+resource ('Return indexing statistics for an embedding index') and even names the two returned fields, totalRecords and indexedRecords. This separates it cleanly from siblings like findEmbeddingIndexes, createEmbeddingIndex, and deleteEmbeddingIndex.

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?

Gives explicit context: use it to monitor backfill progress after creating an index, with the concrete readiness condition indexedRecords === totalRecords. It does not name when-not to use it or point to an alternative tool for other index questions, so it falls just short of 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that this is a fallback path for clients lacking Prompts API support, which is genuinely useful context, but it says nothing about the size, format, or contents of the returned prompt.

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 with no waste. The action is front-loaded and the condition follows immediately, which is exactly the right ordering for a simple retrieval 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 an output schema present, the description needn't explain return values, and the purpose plus fallback condition are covered. Adequate for a zero-parameter read tool, though it could note what the prompt is intended to help build (query construction).

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 the baseline is 4. The empty schema matches the description, which correctly implies no arguments are needed to retrieve the system prompt.

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 RushDB system prompt.' An agent immediately knows this is a prompt-retrieval tool, distinct from the data-focused siblings. It lacks any explicit differentiation from sibling tools, but the purpose itself 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?

Provides an explicit conditional: 'Use this if your MCP client does not support the Prompts API.' This is clear when-to-use guidance that implies the alternative delivery path, though it doesn't state whether there are any other conditions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral fact that this expects a pre-existing ID from a prior lookup, implying it is not a search entry point. It says nothing about failure behavior for unknown IDs, and the output schema covers the return shape.

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 with zero filler, and the core action is front-loaded before the usage condition. Every sentence earns its place.

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 trivial single-parameter lookup with full schema coverage, an output schema, and safety annotations, the description supplies everything an agent needs: what it fetches, and when the ID precondition holds. Nothing material 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?

With one parameter at 100% schema coverage, the schema already documents recordId as 'ID of the record to retrieve.' The description's 'by its ID' simply restates this, adding no format or sourcing detail beyond the schema. Baseline 3 is appropriate when the schema does the work.

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

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

States a specific verb and resource: 'Fetch a single record by its ID.' The word 'single' and 'by its ID' distinguish it from search-style siblings like findRecords and findOneRecord. It does not explicitly name getRecordsByIds, the closest sibling for plural ID lookup, so full sibling differentiation is missing.

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?

Gives an explicit precondition: 'Use when you already have the ID from a previous findRecords or findOneRecord call.' It names the two sibling tools that produce the ID, which is actionable routing guidance. It stops short of stating when to prefer this over getRecordsByIds for multiple IDs, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the meaningful behavioral trait that retrieval is batched into a single round trip, but says nothing about missing IDs, ordering of results, or limits on array size.

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

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

Two sentences, no filler, and the core capability is front-loaded before the workflow hint. Every clause carries information an agent can 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?

An output schema exists, so return values need not be explained, and the description supplies the batch semantics and upstream chaining the agent needs. It is slightly thin on edge-case behavior (unknown/duplicate IDs) but nothing essential to correct invocation 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?

Only one parameter (recordIds) and schema coverage is 100%, so the schema already documents type and meaning. The description adds no format, size-limit, or ordering guidance beyond what the schema states, making the baseline 3 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?

States a specific verb ('Fetch'), resource ('records'), batch scope ('multiple ... in one call') and the query that produces the inputs. The batch wording implicitly separates it from the single-record sibling getRecord, though it never names that sibling explicitly.

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?

Gives explicit sequencing guidance — 'Use after collecting IDs from a findRecords query' — which tells the agent when in a workflow to reach for this tool. It stops short of an exclusion ('use getRecord for a single ID'), so it is clear context rather than full when/when-not routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds beyond annotations by explaining the 1-hour schema cache, the force=true bypass behavior, and that non-empty vectorIndexes means a property is queryable with aiSemanticSearch. It does not add auth or rate-limit context, but for a read-only schema introspection tool the added cache and semantic-query behavior are substantial.

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

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

The description is front-loaded and structured, starting with what the tool returns and then giving usage guidance. However, a large middle portion exhaustively describes output fields even though an output schema exists, and the force behavior is repeated from the input schema. This is information-dense but not optimally 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 description gives enough context for an agent to select and invoke the tool: it explains the JSON vs Markdown distinction, the drill-down use case with propertyValues, and the cache-bypass option. Because an output schema exists, it need not explain return values, and the input schema covers the labels parameter. The main minor gap is that label scoping is not mentioned in the description itself.

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 repeats the force parameter's cache-bypass meaning but adds no new semantics for force or for the labels scoping parameter. The baseline of 3 is appropriate when the schema already does the heavy lifting.

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

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

The first sentence states a specific verb and resource: 'Returns the same graph schema as getSchemaMarkdown but as structured JSON.' It distinguishes this tool from its closest sibling, getSchemaMarkdown, by format and token cost, and it names another related tool, propertyValues.

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

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

It explicitly says when to use this tool: 'Use this when you need property `id` values to pass to propertyValues for deeper drill-down.' It also states when to prefer the alternative: 'For initial schema orientation, getSchemaMarkdown uses fewer tokens.' This is clear routing guidance with no inference required.

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

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

Annotations already cover the safety profile (readOnlyHint/non-destructive), and the description adds genuinely new behavior: the 1-hour schema cache and how force bypasses it, plus the semantics of the Semantic Search column. This is strong added context; the only minor gap is not stating output size/truncation behavior for very large schemas.

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 imperative 'STEP 0 — call this ONCE...' is front-loaded and the dense middle enumerates exactly what the return contains. It is long, but nearly every clause carries information (cache, semantic column, replacement of three calls); minor trimming of the output-format detail would tighten it.

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 discovery tool returning a large structured payload, the description explains scope, invocation timing, caching, and how to interpret the Semantic Search column, and it routes the agent to the follow-up (findRecords). Nothing needed to call it correctly 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?

Schema coverage is 100%, so both parameters (force, labels) are already fully documented in the schema, and the description's statements about them largely restate that. 'Leave empty to get all labels' adds a small clarification, but this is the baseline case where the schema does the heavy lifting.

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

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

States a specific verb+resource: returns the complete graph schema as compact Markdown, enumerating exactly what is included (labels with counts, properties with types/ranges, relationships with direction). It explicitly differentiates from sibling discovery tools by declaring it replaces findLabels + findProperties + findRelationships.

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?

Explicit 'STEP 0 — call this ONCE at the start of every conversation before constructing any query' gives unambiguous when-to-use. It also names the alternative discovery calls it supersedes and states the sequencing relative to findRecords, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile of this static documentation retrieval is covered. The description reinforces this by framing the tool as a source-of-truth reference rather than an action, but adds no further behavioral detail (no caching, versioning, or size caveats), which is acceptable for a pure read of a spec document.

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?

Front-loaded with the one-line purpose before the coverage enumeration, and the call-to-action is last, which is a sound structure. The coverage list is long and dense, but each item describes a distinct capability of the spec document, so it largely earns its place rather than being 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?

With an output schema present, the description need not explain return values, and with zero params there is no parameter gap to close. Annotations cover safety, and the description fully covers scope, trigger conditions, and content so an agent knows exactly when and why to invoke it.

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

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

The tool takes zero parameters (empty schema, 100% coverage trivially), so there is nothing for the description to disambiguate. The baseline of 4 applies: no parameter explanation is required and none is missing.

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: returns the RushDB SearchQuery specification as a reference document, and enumerates the coverage areas precisely. It is clear what the tool does, but it does not differentiate itself from similarly reference-oriented siblings such as getQueryBuilderPrompt or getSchemaMarkdown, so an agent cannot tell from the description alone which of those to prefer.

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?

Gives an explicit trigger ('CALL THIS before building any findRecords query that involves dates, metrics, groupBy, relationship traversal, or vector search') and a directive against guessing syntax. It ties usage to the concrete sibling tool (findRecords) whose queries this spec serves.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the setup-helper context but does not disclose what the help consists of, whether it modifies client configuration, or any auth/rate-limit considerations.

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

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

The description is a single front-loaded sentence with no redundant details. It is appropriately sized for a zero-parameter helper 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?

Given the simple zero-parameter helper nature, read-only annotations, and an output schema covering return values, the description is nearly complete. It could more explicitly state the setup context, but no critical invocation information 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?

With zero parameters and 100% schema description coverage, there is no parameter meaning for the description to clarify. The baseline of 4 applies because the tool takes no 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?

The description names a specific resource and outcome: adding the RushDB MCP server to the user's MCP client. It is clearly distinct from all sibling data-management tools, though 'help' is less precise than a concrete verb and partly restates the tool 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 implies the tool is used when a user needs to connect an MCP client to RushDB, but it does not explicitly state when to use it versus alternatives or list any prerequisites. Usage is inferred rather than specified.

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 it as a non-read, non-destructive, non-open-world operation, so safety is covered. The description adds meaningful semantics beyond that: the pattern is dismissed rather than applied, and the user should review it first. It doesn't clarify whether an ignored pattern is persisted or removed, which is the one remaining ambiguity against deleteRelationshipPattern.

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, the action front-loaded and the prerequisite second; nothing is redundant or padded.

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 a full output schema present, return values need no explanation, and the single-parameter schema is complete. The description supplies purpose and workflow context; only the ignore-versus-delete distinction is missing for full completeness.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented in the schema. The description adds no syntax, format, or sourcing detail beyond what the schema already 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 ('Ignore a suggested relationship pattern') and clarifies the effect with 'without applying it', which distinguishes it from approveRelationshipPattern. It does not explicitly name that sibling or deleteRelationshipPattern, so the differentiation is implied rather than spelled out.

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

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

It gives a sequencing prerequisite ('Call listRelationshipPatterns first so the user can review the inferred pattern'), which is useful workflow context. However, it never states when to choose ignore versus approveRelationshipPattern or deleteRelationshipPattern, leaving the core selection decision to inference from the tool names.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that results include suggestions with lifecycle status, schema relationship summaries and the latest analysis status, plus project scoping, though pagination and result limits are unmentioned.

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?

Three sentences, front-loaded with the purpose, and each earns its place. The return-content sentence partially duplicates the output schema, which slightly dilutes efficiency.

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 parameterless, read-only list tool with an output schema, the description covers purpose, workflow placement and returned content adequately. Nothing essential for calling it correctly is missing, though ordering or freshness of the analysis status could be clarified.

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 has zero parameters, so the baseline is 4; there is nothing for the description to disambiguate, and it correctly implies the call is scoped implicitly to the current project.

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?

Specific verb+resource ('List inferred relationship patterns for the current project'), with the scope of the listing named and clearly separable from the sibling mutation tools approve/ignore/deleteRelationshipPattern and the analyzeRelationshipPatterns trigger.

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?

'Use this before approving, ignoring, or deleting a relationship pattern' gives an explicit workflow trigger that maps onto the sibling tools. It states when to use it but does not name the alternatives directly or describe when the tool is unnecessary.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the agent knows this is a safe, local read. The description adds the semantics of the returned 'property' field ('*' = every string of the record), which is genuinely useful context, but it says nothing about scope limits, empty-project behavior, or pagination beyond the annotations.

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

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

One front-loaded sentence with the resource named first and the returned fields list trailing, no filler or restatement of the tool name. Every clause earns its place.

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 tool with annotations and a full output schema, the description covers purpose, scope, and key field semantics. It leaves only minor gaps such as whether the result is paginated or what an empty index list looks like.

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 the schema requires no param documentation and the baseline is 4. The description uses the space to clarify a returned field's wildcard semantics rather than parameters, which is a reasonable use of the budget but not a full 5.

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 (List) and a precisely qualified resource (the project's keyword/BM25 text indexes), which naturally separates it from the embedding-index siblings (findEmbeddingIndexes, getEmbeddingIndexStats). It also enumerates the returned fields, so an agent knows exactly what it gets back without opening the output schema.

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

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

There are no parameters and the intent (enumerate the project's text indexes) is implied by the verb, but the description never states when to reach for this tool versus createTextIndex, deleteTextIndex, textSearch, or the embedding-index listers. No conditions or exclusions are given, so usage is only inferred.

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

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

Annotations already declare readOnly/non-destructive/non-openWorld, and the description adds real value beyond them by disclosing the conditional return shape by property type ({min,max} vs. distinct-value list) and noting that aggregation is unnecessary. It does not mention pagination interaction with skip/limit beyond what the schema says.

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?

Front-loaded with the core purpose, then structured bullets for the type-dependent behavior and an ordered workflow. Slightly verbose, but each sentence carries actionable information with 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?

With annotations, a full output schema, and 100% schema coverage, the remaining gaps are covered by the description's type-branching and workflow guidance. An agent can select and invoke this tool correctly from the definition alone.

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. The description adds only the provenance of propertyId (the id from findProperties), which is useful but minimal; baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb (get statistics / distinct values) and resource (a specific property), and crucially explains that behavior branches by property type. This distinguishes it clearly from findProperties, whose id it consumes.

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?

Gives explicit when-to-use branching: number/datetime for range/min/max/spread questions with a note that no aggregation is needed, string/boolean for canonicalizing filter values. It also spells out a 3-step workflow (findLabels → findProperties → this tool) for range questions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: deprecation status and the hard prerequisite that the property must have an embedding index created first. It does not discuss result ranking or index-type behavior, but the schema covers those.

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?

Four short sentences, with the most decision-relevant fact (deprecation) front-loaded, followed by what it does, then the two routing alternatives. 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 an output schema exists, return values need no explanation, and with 100% schema coverage the 13 parameters are self-documenting. The description supplies exactly what structured fields cannot: deprecation, the indexing prerequisite, and sibling routing.

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% across all 13 parameters, including enums for mode, sourceType, and similarityFunction, so the schema already carries the parameter semantics. The description only reinforces propertyName's indexing prerequisite; 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?

States a specific verb and resource ('direct vector similarity search over records') plus the precondition that propertyName must be indexed with createEmbeddingIndex. It explicitly distinguishes itself from vectorSearch (the preferred replacement) and smartSearch, so an agent can route without opening any schema.

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

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

Gives explicit when-not-to-use guidance: it is deprecated, new integrations should use vectorSearch, and natural-language schema-aware querying should use smartSearch. This is a complete routing decision with 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?

Annotations already declare destructiveHint=true, and the description earns credit for specifying exactly what is destroyed — any existing field not present in data. That is real context beyond the flag. It stops short of covering auth requirements, whether the set is transactional (transactionId exists in schema), or failure behavior, which keeps it from a 5.

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

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

Two sentences, zero filler, with the destructive consequence front-loaded before the alternative-tool guidance. Every clause carries information an agent needs.

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 destructive mutation with annotations and a defined output schema, the description covers the safety-relevant behavior and the sibling routing decision. It does not touch the atomicity implied by the optional transactionId parameter, a minor remaining 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 coverage is 100%, so the schema documents all four parameters and the baseline is 3. The description adds meaning the schema does not: that the data object is a full replacement rather than a merge target, which is the key semantic for the primary parameter.

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 (replace ALL fields of a record) and immediately scopes the behavior with the consequence. It explicitly distinguishes itself from the sibling updateRecord, so an agent can route correctly without opening either schema.

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

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

Names the alternative tool (updateRecord) and the exact condition that selects it: partial/merge updates that preserve unspecified fields. This is a complete when-to-use / when-not-to-use rule with no inference required.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the tool both executes the query and returns the generated SearchQuery, which is useful, but it discloses no LLM-nondeterminism, schema-fetching, or failure-mode context for a tool that generates queries from free text.

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?

Three sentences, front-loaded with the core action, then illustrative examples, then the routing rule. Each sentence 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?

An output schema exists, so return-value detail is not required in the description, and the description still summarizes the return shape. Combined with 100% parameter coverage and full annotations, an agent has everything needed to call this 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?

Schema coverage is 100% and both parameters are documented in the schema, so baseline 3 applies. The description mentions reliance on 'the project schema' but adds no syntax, format, or intent detail for prompt or currentQuery beyond what the schema already says.

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 chain (convert, execute, return) over a specific resource (natural-language question → RushDB SearchQuery) and names what it returns. It is clearly distinguishable from the semanticSearch and vectorSearch siblings without opening any schema.

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

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

Gives an explicit when-to-use trigger ('user-facing questions such as "Who are piloting Falcon?"') and an explicit alternative with the condition that selects it ('For direct vector similarity over an embedding index, use vectorSearch instead'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavior the structured fields don't: results are returned best-first with a __score field, `total` reflects the full match count rather than the returned page, and matching is done over a text index with the pre-ranking filter scope. Sorting/return semantics are disclosed, though pagination behavior is left to the schema.

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 dense sentences with no filler: the first gives mechanism, ordering, filter scope, and the meaning of `total`; the second is a compact operator reference. Information is front-loaded and every clause carries distinct 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?

With an output schema present and 100% parameter description coverage, the description need not restate return shapes, and it still adds ranking/count semantics. The only real gap is that it does not tell the agent how this interacts with the other search tools or how skip/limit behave across the `total` count, which an agent choosing among many search siblings would benefit from.

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

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

Schema coverage is 100%, so the parameter baseline is 3, but the description goes beyond the schema by explaining query operators (any vs all under allTerms, quoted phrases, '-' exclusion, '+' requirement) that the schema only gestures at as 'Keywords to match'. It also clarifies the interaction of `labels` and `where` as the pre-ranking selection scope.

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 ('Keyword (BM25) search over a text index') and the ranking semantics ('best first (__score)'), which cleanly separates it from semanticSearch/vectorSearch by mechanism. It does not name those siblings or smartSearch explicitly, so an agent must infer the contrast from the word 'Keyword'/'BM25' rather than being told.

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 by the mechanism – lexical/BM25 matching is what this tool is for – and the query syntax hints at when the advanced options apply. However, there is no explicit when-to-use, when-not-to-use, or named alternative (semanticSearch, smartSearch) to route the agent among the several search tools listed as siblings.

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=false, destructiveHint=false and openWorldHint=false, and the description is consistent with that by explaining the merge/preserve behavior that justifies non-destructiveness. It adds genuinely useful context beyond the annotations (what survives the call), but says nothing about the transactionId atomic-update semantics, permission requirements, or failure behavior, so it falls short of a 5.

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

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

Two sentences, both front-loaded: the core semantics first, then the alternative and prerequisite. Every clause carries information an agent needs; nothing is redundant with the name, title, or schema.

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

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

For a mutation tool with an output schema already present, the description covers the essentials: what it mutates, what is preserved, the sibling alternative, and the prerequisite for the required recordId. Return values need not be described since the output schema exists, so nothing an agent needs to call this correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning to the `data` parameter by defining it as a partial patch where absent fields are preserved — a semantic the schema's 'updated (partial) record data' only gestures at. It also motivates `recordId` by describing how to obtain it. It does not clarify `label` or `transactionId`, keeping it below 5.

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 precise verb+resource ('Partially update a record') and immediately qualifies the semantics with 'only fields present in data are changed; all other existing fields are preserved.' It explicitly distinguishes itself from the sibling setRecord, so an agent can route without opening either schema.

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

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

Names the alternative tool and the exact condition that selects it ('Use setRecord instead if you want to replace all fields'), and supplies a prerequisite workflow ('Requires recordId: retrieve it first with findRecords or getRecord if not already known'). Both when-to-use and how-to-prepare are covered explicitly.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds meaningful behavioral context beyond annotations: the external-index restriction, the exact dimension requirement, and the recommended post-write verification step. It does not specify what happens when a recordId already exists, but the upsert name and non-destructive annotation make this reasonably inferable.

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 four tight sentences, front-loaded with the core action and then proceeding through constraints and post-write verification. Every sentence contributes useful information without 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?

With 100% schema coverage, an output schema, and annotations, the description supplies enough additional context for correct invocation: external-only, dimension matching, and the follow-up stats check. It does not cover edge cases such as duplicate record IDs or failure behavior, but those are lower-priority given the structured support.

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

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

Schema coverage is 100%, so the schema already documents both parameters, including the vector length matching index dimensions. The description adds a slightly more precise version of that constraint and notes vectors are pre-computed, but it does not add substantial meaning beyond the schema for indexId or items.

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: write pre-computed embedding vectors to an external vector index. It also distinguishes itself from sibling tools by naming the external index constraint and the follow-up getEmbeddingIndexStats call.

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

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

It gives clear context for use: only valid for indexes with sourceType 'external', and it recommends calling getEmbeddingIndexStats afterward to verify indexing status. It does not explicitly name alternative tools such as vectorSearch or createEmbeddingIndex, but the usage scenario and constraint are clear.

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

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

Annotations already declare readOnlyHint=true/openWorldHint=false, so safety is covered; the description adds real context beyond that — results are ranked by similarity with a __score, `where` triggers prefilter mode, hybrid fusion runs both legs over the same filtered records, and the tool fails without a ready index. Missing details on failure modes or performance characteristics.

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?

Four sentences, front-loaded with the core action and scope before moving to the managed/external branching and the prerequisite. Dense but each sentence carries information; only the prerequisite could arguably be hoisted earlier.

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 19-parameter read tool with an output schema, the description covers the two invocation paths, the index prerequisite, and the prefilter/hybrid behavior an agent needs to choose arguments. Since the output schema carries return values, the only real gap is the absence of guidance against the neighboring search 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%, so the schema already documents all 19 parameters including the query/queryVector mutual exclusivity and the managed/external sourceType. The description restates the managed-vs-external choice and the prefilter role of `where`, adding modest framing value but no parameter meaning the schema lacks — 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: 'Perform direct vector similarity search over records whose propertyName has been indexed'. The word 'direct' and the createEmbeddingIndex reference hint at how it differs from higher-level siblings like semanticSearch or smartSearch, but it never names those siblings, so the differentiation is inferential rather than explicit.

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?

Gives clear conditional guidance: use free-text `query` for managed indexes, `queryVector` for external indexes, and states the prerequisite that an embedding index must be in 'ready' status for the label+propertyName. It does not name alternative tools (semanticSearch, smartSearch, textSearch) or say when NOT to use this, so it stops short of full routing guidance.

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