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

Annotations only carry readOnlyHint=false/destructiveHint=false, so the description must carry the rest and does: validation refusal with the allow-list named in the error, collision-free DynamicPlaceholderId assignment, template-driven parameter writing, force bypassing validation, and the return of the placeholder path for nested builds. It even flags the silent-breakage cases.

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 primary action and sibling contrast, then layers in behavior. Every sentence carries signal, though the final guide pointer and the parameter-adjacent details make it long enough to be dense on first read.

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 14-parameter mutation tool with no output schema, the description covers validation behavior, override path, return value semantics (placeholder path for the child call), and the resource to consult for the tricky nested/dynamic cases. Nothing an agent needs to invoke 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 the baseline is 3, but the description contributes behavior beyond field-level docs: force skips the settings check yet still requires the rendering item to exist, and dynamicPlaceholderId overrides the scanned max+1 with a warning about silent merging. These are consequences of parameter values, not just restatements.

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 ('Adds a rendering to a placeholder on a page') and immediately contrasts it with the sibling presentation-add-rendering, explaining why this tool is the one to use for composition. The scope (single rendering into a placeholder, one call per nesting level) 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?

Explicitly names the alternative (presentation-add-rendering writes whatever it is told), gives the force=true migration/repair exception, and points to guide://compose-page for ordering of the composition tools. When-to-use and when-to-override are both 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 declare non-read-only and non-destructive, and the description adds meaningful behavior beyond them: subtree copying is the default, deepCopy=false narrows it to the single item, and the copy adopts Sitecore's 'Copy of ...' naming unless overridden. It omits anything about naming collisions or what the new item is named in the response, but the scope disclosure is solid.

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 purpose and then constraints, with no padding or duplicated schema content.

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

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

Covers source, destination, subtree scope, naming default, and database default — enough to invoke correctly for a 7-parameter tool with no output schema. It could say whether the new item's identifier is returned, but that is a minor gap given no output schema exists.

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 the mutual-exclusivity contract between id/path and targetParentId/targetParentPath that the schema only implies with 'Supply this or ...'. It restates deepCopy's default, which is already in the schema, so it does not go far beyond the baseline.

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

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

States a specific verb ('Copies') and resource ('a Sitecore item to another parent') plus the API surface used, which cleanly separates it from authoring-move-item, authoring-create-item, and common-new-item-clone 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 the invocation contract explicitly: exactly one of id or path for the source and exactly one of targetParentId or targetParentPath for the destination. It does not, however, state when to prefer copy over move-item or create-item, nor name an alternative, so the routing guidance is incomplete.

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 and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context (returns the created item, parent must be a GUID) but says nothing about auth requirements, failure modes, or what happens when the item already 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?

Two dense sentences, front-loaded with what the tool does and immediately followed by the key non-obvious constraint and the pointer to the helper tool. 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 create tool with no output schema, the description covers the action, the return value, and the GUID constraint on parent. It stops short of describing error behavior or versioning/language interactions, but the essentials for a correct call 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 description coverage is 100%, with detailed guidance for all six parameters including name character restrictions and template ID format. The description adds the parent-GUID constraint but otherwise defers to the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Creates a Sitecore item from a template') and the API channel ('Authoring and Management API') and return behavior. Beyond that, it distinguishes itself from item-service-create-item by naming authoring-get-item as the path-resolution helper.

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 concrete prerequisite: parent must be a GUID, and routes the agent to authoring-get-item to resolve a path first. It does not explicitly contrast with item-service-create-item, which is a plausible alternative for item creation.

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 and destructiveHint=false, so the agent already knows this is a non-destructive write; the description adds useful context by naming the Authoring and Management API surface and the GUID-only parent constraint. It does not disclose failure behavior, name-conflict handling, or reversibility, which matters for a mutation tool.

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

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

Three sentences, front-loaded with the core purpose and followed by two compact constraints. No filler, and the most important information (what it creates) comes first.

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 an 8-parameter tool that builds nested sections and fields, the description covers purpose, parent constraint, and field-type naming but says nothing about what the call returns or how partial failures in nested sections are reported, and there is no output schema to compensate. Annotations cover the safety profile, so this is adequate rather than rich.

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

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

Schema description coverage is 100%, so every parameter, section, and field property is already documented inline. The description's notes about the GUID parent and Sitecore field-type names largely restate what the schema already says ('A path is not accepted — resolve it with authoring-get-item'). Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Creates a Sitecore data template, with its sections and fields, in one call'), which cleanly separates it from generic item creation like authoring-create-item. It never explicitly names the nearest sibling, authoring-update-item-template, so sibling routing is left to inference.

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 create verb and by the prerequisite that the parent GUID be resolved via authoring-get-item, which usefully points at a sibling. However, there is no explicit when-to-use versus authoring-update-item-template, and no stated exclusions or preconditions beyond the GUID requirement.

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. The description adds materially more: the default recycle-bin behavior with restorability, the irreversibility of permanently=true, and the cascade deletion of descendants — exactly the behavioral context 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 tight sentences, front-loaded with the core action, then the default/permanent distinction, then the cascade warning and targeting constraint. 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 destructive mutation with no output schema, the description covers reversibility, cascade scope, and argument selection. It omits auth/permission requirements and failure behavior (e.g. locked or published items), which leaves a modest gap but nothing an agent would likely get catastrophically wrong.

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 parameters are already documented; baseline would be 3. The description adds a real constraint the schema does not enforce — 'Supply exactly one of id or path' — which is genuinely useful selection logic beyond the per-field 'supply this or path' text.

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 ('Deletes a Sitecore item') and names the API surface it operates over. It does not differentiate itself from the sibling item-service-delete-item, so an agent scanning both cannot tell which is preferred 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?

The description implies usage (single-item deletion, choose id or path) but never states when to prefer this tool over item-service-delete-item, nor any prerequisite such as required permissions or item-lock state. Usage is implied rather than guided.

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 readOnlyHint=true already covering the safety profile, the description adds meaningful behavioral context beyond annotations: it discloses that reads hit the authoring/master database so unpublished content is visible, which is a genuine semantic trait. It does not mention auth requirements or rate limits, but the added visibility nuance is substantive.

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 tightly packed sentences, front-loaded with the core purpose, then the distinguishing database behavior, then the input constraint. No filler; every sentence carries information.

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

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

For a 7-parameter read tool with no output schema, the description covers purpose, return contents, and database semantics, and all parameters are fully documented in the schema. It is complete enough to invoke correctly, with only minor room to say more about defaulting behavior or error cases.

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 a real constraint not enforced by the schema: 'Supply exactly one of id or path'. That mutual-exclusivity rule genuinely supplements the per-parameter 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?

States a specific verb and resource ('Reads a Sitecore item by ID or path') and describes the return payload (identity, template, field values). It also differentiates from siblings by noting it reads the authoring database 'unlike the Edge query tools', letting an agent distinguish it 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?

Clear context for when to use it: reads the authoring database so unpublished content is visible, contrasted against the Edge query tools. It stops short of naming specific sibling alternatives (e.g. item-service-get-item, authoring-get-media-item) or stating explicit when-not-to-use conditions, so it is strong but not fully 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 only provide readOnlyHint=true, so the description carries the rest. It discloses what is returned (sections and field definitions with name, type, source), a non-obvious cross-tool contract (itemTemplateSectionId on read maps to templateSectionId on write), and the exactly-one-of constraint on templateId/path. That is well beyond annotation coverage.

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

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

Four sentences, each carrying a distinct load: purpose, usage routing, ID mapping contract, and parameter constraint. Front-loaded with the verb and resource, and no sentence is redundant with the schema.

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

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

For a read-only, 3-parameter template fetch with no output schema, the description covers what an agent needs: when to call it, what comes back, how the returned IDs are consumed downstream, and the templateId/path exclusivity rule. Nothing essential 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; the description nevertheless adds the cross-field constraint 'supply exactly one of templateId or path' that the schema only hints at in individual property descriptions. It does not add format details beyond the schema, but the either-or rule is genuinely useful semantic content.

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 ('Reads') and resource ('Sitecore data template'), plus the transport ('Authoring and Management API') and the concrete payload (sections and field definitions). An agent can distinguish this from siblings like authoring-get-item or common-get-item-template 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?

Explicitly names two prerequisite scenarios: call before authoring-create-item to learn accepted fields, and before authoring-update-item-template to retrieve section/field IDs. This is exactly the 'when to use' routing an agent needs, with named alternatives rather than vague context.

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

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

readOnlyHint=true already establishes this as a safe read. The description adds useful behavior beyond the annotation: the returned fields and the mutual-exclusion rule ('exactly one of jobName or handle'). Missing details like error behavior when neither/both are supplied, but the added context exceeds the annotation baseline.

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: purpose, usage context, and the parameter constraint, front-loaded and free of filler. Every sentence carries distinct information.

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

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

For a two-parameter read-only lookup with no output schema, the description covers what it does, why you'd call it, what it returns, and how to disambiguate the inputs. Nothing needed to invoke it correctly is absent.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real value by stating the exactly-one-of constraint between jobName and handle — the schema lists both as optional with no such rule — so it earns above baseline.

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

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

States a specific verb (Reads), a precise resource (one Sitecore background job), the transport (Authoring and Management API), and the lookup keys (name or handle). It also declares what the return contains (state, progress, messages), which is enough to distinguish it from the sibling list-style tools like authoring-list-jobs.

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 use-case: 'This is how you find out whether an index rebuild or other queued operation finished.' That tells the agent when to reach for it. It does not name alternatives (e.g. authoring-list-jobs) or say when not to use it, so it stops short of a 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?

readOnlyHint=true already establishes the safety profile, and the description adds real value on top by enumerating the returned fields, which substitutes for the missing output schema. It does not mention authorization scope, paging, or behavior when the id/path is absent from the requested database.

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: capability, then use cases, then the id/path constraint last. Front-loaded purpose and zero 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 read-only lookup with no output schema, the description covers purpose, when to call it, and the key argument constraint, so an agent can invoke it correctly. Minor gaps remain around default database/language behavior and what happens when the item is not found.

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 the mutual-exclusivity rule 'Supply exactly one of id or path', which the per-property text ('Supply this or path') does not state as strictly. It adds nothing about database/language, which the schema already covers.

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 ('Reads a media item') plus the returned fields (identity, mime type, size, URL), which implicitly separates it from media-download (bytes) and generic authoring-get-item. It never names a competing sibling explicitly, so an agent facing authoring-get-item vs authoring-get-media-item must still infer the boundary from the word 'media'.

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 two concrete scenarios — 'after authoring-upload-media to get the ID an image field value needs' and 'check what is already in the media library' — and names the sibling it follows. It stops short of an explicit when-not or an alternative-tool routing rule.

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?

readOnlyHint=true already declares the safe-read profile, so the description only needs to add context. It does add the API surface and the configuration content returned, but says nothing about permissions required, caching, or error behavior on unknown names.

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, front-loaded with what is read and followed by the routing hint. Every clause 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?

For a single-parameter read tool with annotations covering safety and no output schema, the description is nearly self-sufficient: it says what is read and how to find the name. Only minor gaps (auth/permission context) remain.

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 sole parameter siteName is already documented with an example ('website'). The description's 'by name' adds nothing 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 ('Reads') and resource ('one site's configuration by name') and enumerates the fields returned (paths, database, language, device, editing switches). It clearly distinguishes itself from the sibling authoring-list-sites and other get-* tools.

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

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

Explicitly names the alternative and the condition that selects it: use authoring-list-sites first when the site name is unknown. It doesn't address other nearby options (get-site-information, list-sites) or when-not-to-use cases, so not a full 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?

Goes well beyond the annotations by disclosing that the document is syntax-checked before sending, that it reads/writes the authoring databases (unpublished content visible, mutations immediate), and that the API forbids subscriptions and GET. These are operationally important traits an agent cannot derive from the destructiveHint/openWorldHint flags alone.

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

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

Front-loads the core purpose and return format, then layers contrast, routing, and transport constraints. Every sentence contributes, though the closing transport remark ('which this tool does for you') is mildly chatty.

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 generic pass-through GraphQL executor with no output schema, the description covers the return format, safety implications, sibling preference, and transport constraints. An agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100% and both parameters carry concrete examples, so the schema does the heavy lifting. The description adds no syntax or format guidance for 'query'/'variables' beyond what is already documented, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ('Executes any query or mutation against the Sitecore Authoring and Management GraphQL API') and the return format ('returns the data as JSON'). It explicitly contrasts with the Edge endpoint and routes to typed authoring-* siblings, so an agent can identify it 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 preference rule ('Prefer a typed authoring-* tool when one covers the operation; use this for the rest of the schema') and names authoring-introspect-schema for the SDL. When-to-use and the fallback role are both stated, nothing 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 only declare readOnlyHint=true; the description goes well beyond that, disclosing the return shape (127 queries/mutations, one line each), a measured size for full: true (117,188 characters on a live CM), that type expands to include referenced input/enum types so one call suffices, and that search returns names/summaries rather than definitions. This is exactly the extra operational context annotations cannot carry.

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 tool's scope and mode-selection guidance, and every sentence carries usable information (sizes, examples, sibling disambiguation). It is dense and long, with example operation names clustered in one sentence, but nothing is wasted.

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

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

For an introspection tool with no output schema, the description fully characterizes return values (index lines, search summaries, full SDL with measured size) and the expansion behavior of type. An agent has everything needed to choose a mode and interpret results.

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 operational meaning: it explains the interaction between full and includeDescriptions ('combine with includeDescriptions:false to cut it substantially'), what type actually returns for an operation, and why search results are lightweight. It reinforces rather than merely repeats 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 (explores) and resource (the Sitecore Authoring and Management GraphQL schema), enumerates the domains it covers (items, templates, media, sites, search, publishing, jobs, indexing, workflow, security, identity), and explicitly rules out the Edge schema by naming the introspection-graphql-* sibling. An agent can distinguish this from all other introspection/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?

Gives concrete when-to-use guidance per mode: no arguments for the operation index, type for one operation, search for keyword lookup, full for the whole SDL. It also states the broader purpose ('Most of this schema has no typed authoring-* tool, so this is how you find the rest') and names the alternative to avoid ('Not the Edge schema — that is introspection-graphql-*').

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 so the safety profile is known. The description adds genuinely useful behavior beyond that: the full wildcard matching semantics and the fact that omitting jobName returns everything, which is the key invocation nuance for this tool.

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

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

Three tight sentences, front-loaded with the core action, then wildcard rules, then use case. Every sentence carries information; nothing 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?

No output schema, but the description is adequate for correct invocation: action, parameter behavior, and intent are all covered. It does not mention pagination via 'first' or the shape of returned jobs, a minor gap for a list endpoint.

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 would be 3, but the description goes beyond the schema's terse example by spelling out all four wildcard forms ('*', 'myjob*', '*myjob', '*myjob*') and the omit-to-list-all behavior, directly disambiguating the most error-prone 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 ('Lists Sitecore background jobs') plus the API surface (Authoring and Management API). The list-vs-get contrast with the sibling authoring-get-job is implied by 'Lists' but never made explicit, so it stops short of full sibling differentiation.

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

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

Gives two concrete situations for use: finding out what the instance is busy with, and locating a job whose exact name is unknown. Clear context, but no explicit alternative (e.g. authoring-get-job) or when-not-to-use 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?

readOnlyHint=true already telegraphs a safe read, so the bar is lower, and the description adds real behavioral context: the returned field set and that system sites (shell, admin, login) are filtered out by default. This is more than the annotation conveys. It does not cover pagination or result size, keeping it 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, front-loaded with the core action and followed by the workflow rationale. It is dense but each sentence carries information (returned fields, why it matters, system-site filtering). Slightly long but 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?

There is no output schema, so the description correctly compensates by naming the returned fields and the relationships they enable (root item ID scopes authoring-search; root path anchors item paths). It also documents the system-site filtering behavior. Nothing essential for calling 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?

With 100% schema description coverage on the single parameter, the schema already documents includeSystemSites and its default. The description restates the same hiding behavior ('System sites... are hidden unless includeSystemSites is set'), so it adds little beyond the structured field. 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 ('Lists the sites configured on the Sitecore instance') and enumerates the returned fields (root path, start path, root item ID). It differentiates itself by naming the Authoring and Management API, but it does not explicitly distinguish itself from close siblings like list-sites or get-site-information. Clear purpose, missing sibling disambiguation.

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 strong positive guidance: 'Usually the first call when working on an instance you have not seen,' and explains exactly how the outputs feed authoring-search subtree scoping and item paths. It stops short of stating when not to use it or naming the sibling alternative, so it is not fully explicit about the alternative.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds genuinely useful behavior beyond that: descendants move along with the item and all links survive. It does not mention permissions or failure behavior, but this is solid added context.

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

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

Three tightly written sentences, front-loaded with what the tool does, then the rationale, then the parameter constraint. 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?

For a mutating, non-destructive move with no output schema and fully covered params, the description supplies the mutation behavior, the key side effect (descendants/links), and the exclusivity rule. It stops short of noting permissions or error conditions, but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the individual parameters are already documented and the baseline is 3. The description adds a cross-parameter constraint the schema cannot express: supply exactly one of id/path and exactly one of targetParentId/targetParentPath, which is real semantic value for correct invocation.

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 (moves) and resource (a Sitecore item to another parent) and adds scope (descendants travel with it). It is clearly distinguishable from siblings like authoring-copy-item, authoring-delete-item and authoring-update-item.

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 states when to prefer this tool: 'prefer this over delete-and-recreate, which breaks them.' It gives both a recommended condition and a rejected alternative with the reason, so the agent can route correctly without 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 only declare readOnlyHint=true; the description adds substantial context beyond that by enumerating the state values, disclosing isDone/isFailed and the processed-item count, and instructing polling until isDone. This meaningfully enriches the behavioral picture for a read 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 compact sentences with zero waste; the purpose is front-loaded, then return values, then the polling instruction in priority 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?

With no output schema, the description compensates by naming the key return fields (state, isDone, isFailed, processed count) and the polling completion condition. Combined with readOnlyHint, an agent has everything needed to call and use it correctly.

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

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

Schema coverage is 100% and the schema itself fully documents publishingOperationId, including the format example and the semicolon-suffix caveat. The description adds no further parameter meaning, 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 (Reads) plus resource (status of a publish) and ties it to the exact sibling that produces the operation, authoring-publish-item. An agent can distinguish it from the publish/queue tools in the sibling list 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 clear context (use after authoring-publish-item queues a publish) and explicit behavioral guidance ('Poll this until isDone before treating published content as live'). It does not mention alternative status mechanisms such as authoring-get-job, but the when-to-use case 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 only declare readOnlyHint=false and destructiveHint=false; the description goes much further by disclosing that the operation is asynchronous, returns as soon as the job is queued, and requires polling to know when content is actually live. That's exactly the behavioral context an agent needs and cannot get from structured fields.

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

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

Three tight sentences, each earning its place: the action, the async caveat with the follow-up tool named, and the platform-specific target plus the one-of constraint. Front-loaded with the core behavior.

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 9-parameter mutation tool with no output schema, the description covers the gaps that matter: return value (operationId), async semantics, the follow-up call, platform-specific target values, and the root-item mutual exclusion. 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?

Schema coverage is 100%, so baseline is 3, but the description adds non-obvious semantics: the mutual exclusion of rootItemIds vs rootItemPaths, and the trap that targetDatabases takes the database name ('experienceedge') not the publishing target item name ('Edge', which is rejected). Those details materially reduce invocation errors.

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 ('Queues a publish'), resource ('one or more items'), and channel ('Authoring and Management API'), plus the return value (operationId). This clearly separates it from siblings like common-publish-item or authoring-publishing-status.

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 operational guidance: poll authoring-publishing-status with the operationId before reporting content is live, and supply exactly one of rootItemIds/rootItemPaths. It also names the correct target per platform. It does not, however, contrast itself against the sibling common-publish-item, so an agent still has to infer which publish tool to choose.

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?

Goes well beyond the annotations by disclosing cost ('expensive'), the side effect that search results are incomplete while it runs, and the asynchronous job model ('returns the jobs it queued'). Annotations only cover the read/destructive flags, so this added operational context is genuinely valuable.

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 action and its result, followed by the cost caveat and the follow-up calls. No filler; each sentence supports a distinct decision the agent must make.

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?

No output schema exists, and the description compensates by stating what is returned (job names) and how to consume it (poll with authoring-get-job). Combined with the value-discovery hint and cost warning, nothing needed to invoke this tool 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% with an example value, so the baseline is 3. The description adds real value by telling the agent how to discover valid index names via the GraphQL indexes query, which is not derivable from the schema.

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

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

States a specific verb and resource ('Starts a rebuild of one or more Sitecore search indexes') plus the API surface and the returned artifact (queued jobs). It does not, however, differentiate itself from the similarly named sibling indexing-rebuild-search-index, which an agent could easily confuse with this tool.

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 when-not condition ('prefer it only when the index is actually stale') and routes follow-up work explicitly to authoring-get-job and authoring-graphql. It stops short of naming an alternative rebuild/indexing tool, so the sibling ambiguity is left for the agent to resolve.

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 readOnly=false and destructive=false; the description adds real behavioral context by explaining that the item keeps its ID (so links survive) while its path and URL-derived name change. This helps the agent reason about side effects beyond the flat annotation hints.

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, none wasted; the core action is front-loaded and the consequence follows. Structure is clean and skimmable.

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 no output schema, the description covers the critical rename semantics and the id/path constraint, while annotations carry the safety profile. Missing only secondary details like permission requirements, which are minor here.

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 id, path, newName, and database are already documented. The description adds the mutual-exclusivity rule for id/path, which reinforces rather than exceeds the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Renames a Sitecore item') and clarifies the outcome that distinguishes it from sibling mutations: the ID is preserved while the path and derived URL change. It does not explicitly name move/copy/update alternatives, but the semantic framing makes the distinction clear.

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 concrete usage rule ('Supply exactly one of id or path'), which is genuinely actionable. However, it offers no guidance on when to choose rename over siblings like authoring-move-item or authoring-update-item, leaving the selection context 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 only declare readOnlyHint=true, so the description carries the rest and does so well: default index, default 10-result page size, pagination via pageSize/pageIndex, relevance vs sortField ordering, and the important caveat that index values are lowercase unpunctuated IDs and that _path results return identity fields rather than field values. This is real behavioral context beyond the safety hint.

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

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

Purpose is front-loaded in the first clause, and each subsequent sentence adds distinct operational value (operator semantics, useful fields, ID format, page size, subtree tradeoff). Dense but no filler or 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 no output schema, the description must carry return-value context; it does so at a high level (matching items, 10 results by default, identity fields vs field values) but never describes the result shape or total-count/paging metadata. For a search tool with eight parameters this is close to complete, with 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 baseline is 3, but the description adds meaning the schema lacks: the usable system fields ('_name', '_fullpath', '_path', '_template', '_templatename'), the brace/dash-free ancestor-ID syntax for '_path', and the exact ID format example. It does not explain criteriaType behavior or boost in prose, leaving some schema-documented semantics untouched.

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 ('Searches a Sitecore index over the Authoring and Management API and returns matching items') and immediately distinguishes itself from nearby tools by describing criteria semantics and index-backed behavior. An agent can tell it apart from item-service-search-items and item-service-get-item-descendants 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?

Explicitly routes one case: use a '_path' criterion to read a whole subtree in one query, versus item-service-get-item-descendants which makes one request per node, and it names the tradeoff (identity fields, index not database). It does not cover when to prefer the other search siblings (item-service-search-items, indexing-find-item) or any when-not conditions, so it falls 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.

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds the partial-update guarantee ('only the fields named are touched'), which usefully bounds the blast radius, but it says nothing about versioning/concurrency, permissions required, or whether writes are published. Reset semantics are already documented in 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?

Three sentences, front-loaded with purpose, then behavior, then the input constraint. Every sentence carries distinct information and nothing is 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?

For a 6-parameter mutation tool with a fully documented schema and annotations covering the safety profile, the description covers purpose, mutation scope, reset, and the id/path rule. It omits version-conflict/concurrency behavior and permission requirements, which keeps it short of complete.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description adds real value by stating the id/path relationship as a strict XOR ('exactly one'), which the per-field schema text ('Supply this or path') leaves ambiguous. It repeats the reset behavior that the schema already documents, so it is not a 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+resource ('Sets field values on an existing Sitecore item') and the transport layer (Authoring and Management API), which unambiguously separates it from siblings like authoring-create-item, authoring-delete-item, or authoring-copy-item. It does not explicitly name or differentiate against any sibling, so it lands just below the top mark.

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 partial-update use case ('Only the fields named are touched') and states a hard input rule ('Supply exactly one of id or path'), but it never says when to choose this tool over overlapping siblings such as item-service-edit-item or authoring-update-item-template. Usage is inferable rather than directed.

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 readOnlyHint=false and destructiveHint=false; the description goes well beyond them by disclosing that deleteMissingFields deletes every absent section and field plus their stored content, and that the default is off. It also explains the ID-only matching rule and the rejection behavior, which the annotations cannot convey.

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 create-vs-update rule, then the ID-matching constraint, then the destructive-flag warning. Every sentence carries operational information; nothing is padding 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 9-parameter mutation tool with no output schema and only two thin annotations, the description covers the highest-risk behaviors (deletion, ID matching, rejection). It stops short of noting permission requirements or the effect of baseTemplates replacement, but those are minor relative to what it does cover.

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 on top: it explains that templateSectionId/templateFieldId are the only match keys and are mandatory when targeting an existing section, and it warns what deleteMissingFields=true actually does. Minor gaps remain (database, language, baseTemplates) that only the schema covers.

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 ('Updates a Sitecore data template over the Authoring and Management API') and immediately distinguishes itself from siblings like authoring-create-item-template and authoring-get-item-template by explaining create-vs-update semantics. 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?

Gives explicit routing instructions: read the template first via authoring-get-item-template, pass templateSectionId to add a field to an existing section, and pass templateFieldId to update rather than create. It also names the failure mode (rejection for creating a duplicate section name), which is precisely the when-not guidance an agent needs.

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/openWorldHint=true, so the description earns credit by adding non-obvious mechanics: the two-step pre-signed-URL-then-POST flow, the HTTP-transport refusal of filePath unless MEDIA_LOCAL_FILE_ROOT confines it, and the returned media item. It stops short of describing overwrite failure/rollback semantics, which matter for a destructive tool.

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

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

Front-loaded with the core action and flow, then alternatives and the sibling distinction. Four sentences are dense but each carries information; 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 an 11-parameter destructive mutation with no output schema, the description covers the mechanism, the source-selection decision, the return value, and the sibling alternative. The main gap is auth/permission prerequisites and what happens on partial failure, but overall it is complete enough 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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly, including the itemPath extension rule and the source/exclusivity constraint. The description's 'exactly one of sourceUrl, filePath, or content' mirrors what the schema already says, adding reinforcement rather than new meaning — 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 ('Uploads a file into the Sitecore media library over the Authoring and Management API') and names the sibling it differs from ('Needs no SPE Remoting, unlike media-upload'). An agent can distinguish it from media-upload and authoring-create-item 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?

Gives explicit selection guidance for the three source modes ('use this to import from a live site' for sourceUrl; filePath is local to the MCP server machine; content is base64 for small files) and routes away from media-upload. It does not explicitly state when not to use the tool, so it falls short of a full 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 declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds real context by explaining the version is derived from an existing language version (implying field-copy semantics), but it omits behavioral details like what ifExist=OverwriteLatest does or that recurse touches children. Adequate but not rich.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though arguably too terse for a 12-parameter tool and offers no structure to anchor the enum-based options.

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 12 parameters, two undocumented enums (ifExist, ifNoSourceVersion), no output schema, and no required fields, the description is thin for the tool's complexity. The schema carries most of the load, but behavior around version overwrite/skip and recursive processing is left unaddressed.

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 83%, so the schema already documents id, path, full, fields, recurse, database, language, targetLanguage, and doNotCopyFields. The description only clarifies the source/target language relationship and leaves enums like ifExist and ifNoSourceVersion (which have no schema description) unexplained. 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 (creates a version) and resource (item), plus the scoping qualifier 'in a new language based on an existing language version'. It implicitly distinguishes itself from the sibling common-remove-item-version, but never names or contrasts an alternative 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?

The description says what the tool does but gives no when-to-use guidance, no prerequisites (e.g. source language must have a version), and no alternatives such as authoring-update-item or item-service-edit-item. Usage must be inferred entirely from the name.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the description need not restate safety, but it still leaves key behavior unexplained: whether the clone link is severed permanently, whether the conversion is reversible, and what permissions are required. No contradiction with annotations, but no added behavioral context either.

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

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

A single tight sentence with no filler and a front-loaded verb. It is efficient, though the brevity comes at the cost of the missing context noted elsewhere.

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?

Schema coverage is full and annotations exist, so the structured fields carry most of the load, and there is no output schema to explain. Still, the description does not address the notable `recurse` branch-wide effect or the irreversible-looking nature of the conversion, which an agent should know before invoking a 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 description coverage is 100%, so the schema already documents all seven parameters. The description adds no parameter-level meaning beyond the schema, which is the baseline 3 case.

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 (converts) and resource (an item from a clone), and the outcome (fully independent item) is unambiguous. It does not explicitly contrast itself with the adjacent clone tools (common-new-item-clone, common-get-item-clone), so it stops short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no routing to siblings such as common-new-item-clone. The agent must infer usage entirely from the one-line purpose.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered, but the description adds nothing beyond that — no note on what an archive result contains, expected size, or whether a database/name is required despite zero required params.

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

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

A single short sentence with no filler and the resource front-loaded. It is efficient, though its brevity edges toward under-specification rather than crisp conciseness.

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

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

For a read tool with a fully documented schema this is thin: it omits the distinction from common-get-archive-item, doesn't say what is returned, and gives no guidance on the absence of required parameters. An agent could call it, but not confidently over its siblings.

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

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

Schema description coverage is 100%; the schema itself fully documents full (diagnostics/unprojected graph), name, and database. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

"Gets Sitecore database archives" states a clear verb and resource, so the basic purpose is legible. However, it does not differentiate from the near-identical sibling common-get-archive-item, leaving the agent to infer the scope difference between an archive and an item within an archive.

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 contains no when-to-use guidance, no prerequisites, and no routing to alternatives. With siblings like common-get-archive-item and common-restore-archive-item present, an agent gets no signal about which to pick.

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 readOnlyHint=true already covering the safety profile, the bar is lower and the description clears it: it adds the ordering semantic ('100 most recently archived entries') and discloses that the response carries the archive's total entry count, neither of which appears in the schema. It does not state permission requirements, which is the main remaining 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 with the paging default front-loaded and the return payload appended compactly. Every clause carries information; nothing 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?

For a read-only, paginated listing tool with no output schema, the description supplies the essentials: ordering, default page size, and that a total count is returned (matching the schema's reference to 'Total'). Only the absence of any note on permissions or what an individual entry contains keeps it from being fully complete.

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

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

Schema coverage is 100%, so the schema already documents first, skip, full and their defaults, making the description's restatement of the 100-entry default largely redundant. It adds no meaning for the less obvious parameters (itemId, identity), whose schema text reads as if copied from a different operation.

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 — 'Gets a page of the items found in the specified archive' — plus the secondary payload (total entry count), which clearly separates it from the item-listing siblings. It stops short of naming a specific sibling (e.g. common-get-archive, which lists archives rather than their entries), so an agent must infer the boundary rather than read it.

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 implicitly tells the agent how to page ('Returns the 100 most recently archived entries unless first/skip say otherwise'), which is real usage guidance for the paging parameters. But there is no explicit when-to-use/when-not statement and no routing to common-get-archive or common-restore-archive-item, leaving the sibling choice 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?

readOnlyHint=true already covers the safety profile, so the description earns credit for adding real behavior: exact literal matching versus wildcard matching, and the square-bracket gotcha in cache names that would otherwise cause silent mismatches. It never states auth or rate-limit behavior, so it is not 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, all load-bearing: purpose and return fields first, then the default behavior, then the matching rules. Zero filler, front-loaded, no repetition of the schema.

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

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

For a 2-param, no-required, read-only tool with no output schema, the description covers what is returned (size and occupancy), the default scope, and the tricky matching semantics. It leaves the 'full' projection caveat entirely to the schema, which is acceptable but a minor gap given the schema already flags it as diagnostics-only.

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% (baseline 3), and the description adds meaning beyond the schema by warning that names contain square brackets and are matched literally when passed verbatim, versus '*'/'?' for patterns. This disambiguates the most error-prone parameter for the agent.

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 ('Gets information about Sitecore caches') plus what the payload contains ('size and occupancy'). No sibling tool targets caches, so there is no ambiguity to resolve against the ~90 item/security siblings.

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?

'Omit name to return every cache' gives a clear conditional for the default/no-arg case, and the wildcard guidance tells the agent how to widen a query. It stops short of explicit when-not/alternative routing, but no real alternative exists among 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 only declare readOnlyHint=true. The description says nothing about what information is returned, whether 'full' has performance implications (the schema hints at 100,000+ chars but the description never warns about it), or what happens when name is omitted (schema covers this, description does not). Given annotations carry only the safety bit, the description adds almost nothing.

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

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

A single short sentence, front-loaded and with no filler. It is concise, though arguably too terse for the breadth of the common- tool family.

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 no annotations beyond readOnlyHint and no output schema, the description bears the burden of explaining what a 'database' object contains, whether name defaults to all databases (only in schema), and what 'full' returns. It covers none of this, leaving the agent to infer behavior entirely from parameter descriptions.

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 are well documented within the schema itself (including the 'master'/'core'/'web' examples and the diagnostics warning for 'full'). Description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

States a clear verb+resource (get info about Sitecore databases), but provides no differentiation from the many other 'get' siblings in the common- family (e.g. common-get-cache, common-get-item-clone). An agent can't tell from the description whether this returns connection strings, size, status, or names.

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

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

No when-to-use, when-not-to, or alternative guidance. With dozens of sibling get- tools, the absence of any routing information is a real gap.

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, so the safety profile is covered. The description adds nothing beyond that: it does not explain what a 'clone' represents, what is returned per item, or how it interacts with the related new/convert clone tools.

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

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

A single front-loaded sentence with no filler or redundancy. It is appropriately sized, though its brevity borders on under-specification rather than tightness.

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 tool with a fully documented schema and no output schema, the description is minimally adequate. It nonetheless omits the nature of a clone and any return-shape context, which would matter given the multiple clone-related siblings.

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 five parameters (id, path, full, fields, database) are already well documented in the schema, including the id-or-path rule and the full-vs-fields interaction. The description adds no parameter meaning beyond that, which is the expected baseline when the schema carries the load.

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

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

States a specific verb ('Returns') and resource ('all the clones for the specified item'), so the agent understands the read operation. However, it does not distinguish itself from the closely related siblings common-new-item-clone and common-convert-from-item-clone, leaving the clone-family boundary to be inferred.

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 offers no when-to-use guidance, prerequisites, or reference to alternatives. With sibling clone tools (new/convert) present, an agent gets no help choosing between them.

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

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

The readOnlyHint annotation already establishes this as a safe read, lowering the bar, but the description adds little beyond restating the returnType options that already exist in the schema. It says nothing about id-vs-path resolution, wildcard name matching, database defaults, or language analysis that would help an agent predict behavior.

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

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

A single short sentence that is front-loaded with the verb and resource. It is efficient, though the phrasing "as either names or fields or template fields" is slightly redundant with the returnType enum.

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 tool with no output schema and no annotations beyond readOnlyHint, the description is too thin. It omits the id/path requirement, wildcard semantics, database resolution, and the language parameter, leaving significant behavioral gaps that the schema descriptions only partially cover.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters thoroughly (id/path mutual exclusivity, wildcard support, database default, returnType enum). The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description names a verb ("Gets") and resource ("item fields"), and hints at three output modes (names, fields, template fields). However, "as either names or fields or template fields" is awkward and does not distinguish this tool from siblings like common-get-item-template or item-service-get-item, leaving the agent to guess its specific role.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the many sibling get-item tools (common-get-item-template, authoring-get-item, item-service-get-item). The agent must infer selection from the name alone.

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

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

readOnlyHint=true already declares the safety profile, so the description does not need to restate that this is a safe read. It adds a mild scope hint ('where it is used throughout the system') but says nothing about permissions, cost, or how the 'full' diagnostic mode behaves, leaving meaningful gaps given the annotations carry only safety.

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

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

A single, front-loaded sentence with the verb first and the scope clarification second. No wasted text, though the trailing clause slightly overlaps with the word 'references'.

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 tool with a fully documented schema and no output schema, the core information is present. The notable omission is any differentiation from the closely related referrer tools, which is exactly the context an agent needs to choose 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 description coverage is 100%, with id/path, full, fields, version, database, and language all documented in the schema itself. The description adds no additional meaning beyond that baseline, so a 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 ('Gets') and resource ('item references for a Sitecore item') and clarifies intent with 'showing where it is used throughout the system'. However, it does not distinguish itself from the near-identical sibling common-get-item-referrer, leaving the agent unable to tell the two apart from the description alone.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives such as common-get-item-referrer or common-update-item-referrer. The usage is only implied by the verb, and the choice of id vs path is left entirely to the schema.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered by structured data. Beyond that the description adds nothing: no mention of what a "referrer" result looks like, whether results are paginated or bounded, or performance characteristics, despite there being no output schema to carry that burden.

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

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

A single front-loaded sentence is efficient in size, but half of it ("showing which items reference it") is redundant with the first half, so the sentence does not fully earn its 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?

For a 7-parameter tool with no output schema and no required parameters, the description is too thin: it does not describe the shape or scope of returned referrers, nor clarify the id/path resolution behavior that the schema hints at. An agent has little beyond the schema 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 description coverage is 100%, so the schema fully documents all 7 parameters (id/path mutual exclusion, full being diagnostics-only, fields, version, database, language). The description adds no parameter 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 ("Gets") and resource ("items referring to a Sitecore item"), so the core action is clear. However, it fails to distinguish itself from the very similarly named sibling common-get-item-reference, and the trailing clause "showing which items reference it" merely restates the verb phrase.

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

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

No guidance on when to use this tool versus alternatives. The near-identical sibling common-get-item-reference creates real ambiguity that the description does nothing to resolve, and no prerequisites or conditions are stated.

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

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

Annotations declare readOnlyHint=true, and 'Gets' is consistent with that safety profile. The description adds little beyond the annotation: it does not explain return format, the implications of the 'full' diagnostics flag, or any auth/rate-limit considerations. With annotations covering safety, a 3 is appropriate.

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

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

The single sentence is front-loaded and free of filler, making it easy to parse. It is perhaps too terse to structure any caveats, but it avoids verbosity entirely.

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

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

The tool has five parameters and no output schema, so the description could help by summarizing what 'template information' includes (e.g., fields, base templates) or noting the id/path requirement. However, 100% schema coverage already documents the parameters and the read-only annotation covers safety, leaving the description minimally adequate.

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 already documents all five parameters, including the id/path mutual exclusivity and the 'full' diagnostics caveat. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb ('Gets') and resource ('template information for a Sitecore item'), making the operation clear. However, it does not distinguish this tool from the similar sibling authoring-get-item-template, 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?

No guidance is given on when to use this tool versus alternatives such as authoring-get-item-template or common-set-item-template. The description offers only the core action with no context, conditions, or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds no behavioral context beyond the purpose statement: nothing about ordering of entries, pagination, whether history is complete, or how the optional identity/language filters affect 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?

A single front-loaded sentence with zero waste, but it is arguably undersized for a 5-parameter tool, leaving no room for routing or behavioral notes.

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 five optional parameters, no output schema, and only a readOnlyHint annotation, the description is only minimally adequate. It does not explain defaults (e.g., master database), what a workflow history entry contains, or how filtering interacts, though the schema descriptions carry the per-parameter load.

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 every parameter (id, path, database, identity, language) is already documented in the schema, including the id/path exclusivity and the identity wildcard support. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb (gets) and resource (workflow history entries for a specified item), which is meaningfully distinct from siblings like common-new-item-workflow-event and common-invoke-workflow. However, it does not explicitly name or contrast with those siblings, leaving the agent to infer the boundary.

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

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

There is no when-to-use guidance, no mention of when a history lookup is appropriate versus invoking a workflow or creating a new event, and no prerequisites stated. The agent must infer usage entirely from the one-line purpose.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that — every job is returned with no filtering, and State/IsDone are the fields to inspect — but says nothing about return shape details, result size, or paging, and there is no output schema to compensate.

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 with the core capability front-loaded, followed by the practical hint on which fields to read. No filler, though the 'takes no arguments' phrasing is imprecise given the schema's 'full' flag.

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 no output schema, the description carries some burden for describing returns; it names State, IsDone and progress, which is a start, but omits job identity fields (e.g. name/id) an agent would need to identify 'the one you want'. It is adequate but incomplete for a discovery 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 single 'full' parameter is fully documented as a diagnostics-only option in the schema itself. The description adds a mild tension by asserting the tool 'takes no arguments', which slightly undersells the one parameter that exists, but adds no new semantic 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?

The description states a specific verb and resource ('Gets the current Sitecore jobs with their state and progress'), so an agent immediately knows what is returned. It does not, however, differentiate itself from the close siblings 'authoring-get-job' and 'authoring-list-jobs', leaving the agent to guess which job-retrieval 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 gives implied usage guidance by telling the agent to 'read State and IsDone to find the one you want', which suggests this is a discovery tool rather than a targeted fetch. It offers no explicit when-to-use/when-not-to-use framing versus 'authoring-get-job' or 'authoring-list-jobs', so the routing decision 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 only state readOnlyHint=false and destructiveHint=false. The description adds nothing about behavior: it does not say the item's workflow state advances, that comments are recorded in history (only the schema hints at this), what permissions are needed, or whether the action is reversible. For a state-mutating tool this is a real 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?

One short, front-loaded sentence with no waste, which is good. But it is terse to the point of under-specification rather than genuinely efficient.

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 a 6-parameter mutation tool with no output schema and only minimal annotations, the description should explain what the workflow action does to the item and any preconditions. It leaves the agent without enough context to invoke it confidently.

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 six parameters (id/path mutual exclusion, comments, database, language, commandName) are already documented in the schema. The description contributes no additional parameter meaning; 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?

It names a verb ('Executes') and a resource ('workflow action for a Sitecore item'), so the general operation is clear. However, 'workflow action' is never defined (state transition? command invocation?), and the description offers no differentiation from siblings like common-new-item-workflow-event or common-get-item-workflow-event.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites such as the item being in a workflow state, and no indication of what happens on failure. The agent must infer everything from the name.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered. The description adds nothing beyond the operation itself: it doesn't explain Sitecore clone semantics (a clone stays linked to its original and inherits changes), what content is duplicated, or how 'recurse' alters scope. For a mutation tool with meaningful side effects, this is thin.

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

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

A single efficient sentence with no filler, and the verb is front-loaded. It is arguably too terse rather than padded, so conciseness is not the problem.

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 8-parameter mutation tool with no output schema and no annotations explaining clone behavior. The description omits the critical Sitecore distinction that a clone is a live-linked reference rather than a detached copy, and says nothing about destination/name validation or recursion — gaps an agent cannot recover from the schema 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 all eight parameters are already documented in the schema (id/path, recurse, fields, database, destination). The description adds no syntax, defaults, or interaction detail beyond what the schema provides, 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 clear verb+resource ('Creates a new item clone') and identifies the source ('based on the item provided'). However, it does not differentiate itself from closely related siblings such as common-get-item-clone or common-convert-from-item-clone, leaving the agent to infer which clone-related 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?

No when-to-use or when-not-to-use guidance is given, and no alternative tools are named. The presence of common-get-item-clone and common-convert-from-item-clone in the sibling list makes this omission notable — the definition never explains how 'new clone' differs from those.

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

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

Annotations state readOnlyHint=false and destructiveHint=false, so the agent knows this writes data without destroying it. However, the description adds no behavioral context beyond that: it doesn't say whether an entry is appended (history is usually additive), whether it requires the item to be in a workflow, or what happens if the item has no workflow state. With annotations covering only the safety profile, this mutation tool leaves a meaningful disclosure gap.

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

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

A single front-loaded sentence with no waste. It's efficient, though it could have used a second clause to distinguish itself from the state-changing sibling without harming brevity.

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

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

For a seven-parameter workflow-mutating tool with no output schema, the description is under-specified. It omits when the tool should be preferred, what workflow constraints apply, and any behavioral contract (appending vs. replacing history), leaving the agent to infer too much.

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 seven parameters (id, path, text, database, language, newState, oldState) are already fully documented in the schema, including default behavior for database and state fallbacks. The description adds no parameter meaning beyond this, which is appropriate given 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?

The description clearly states a specific verb (Creates) and resource (a new entry in the workflow history for a Sitecore item), differentiating it from the sibling common-get-item-workflow-event, which retrieves rather than creates. It does not, however, explicitly reference the direct alternative common-invoke-workflow, which also modifies workflow state.

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

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

There is no guidance on when to use this tool versus a state-changing alternative like common-invoke-workflow, nor any mention of prerequisites such as item lock state, workflow membership, or permissions. The description only implies usage from its name and sibling set.

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 readOnlyHint=false and destructiveHint=false; the description adds genuinely new context by explaining that on SitecoreAI publishing goes to Edge on Sitecore's cloud servers and silently fails to have a target on a local dev CM. That is meaningful behavioral information beyond the structured fields. It stops short of covering permissions, async/job behavior, or failure modes, so it is not 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, with the core action front-loaded and the environment caveat second, so nothing is buried. The second sentence is somewhat long and dash-laden, but every clause carries information an agent needs, so it 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 12-parameter mutation tool with no output schema, the description covers the environment caveat but says nothing about what the call returns (e.g., whether a job id comes back when asJob is set), nor does it differentiate from the near-duplicate publishing sibling. It is adequate but has clear gaps given the tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents all 12 parameters (id/path, target, publishMode, asJob, etc.), which sets the baseline at 3. The description's Edge/cloud remark indirectly illuminates the 'target' parameter (the default 'web' database does not exist on SitecoreAI), but it adds no syntax or parameter-level guidance 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?

The description uses a specific verb+resource ('Publishes a Sitecore item'), so the core action is unambiguous. However, the sibling list contains a near-identical tool, 'authoring-publish-item', and the description does nothing to distinguish the two, leaving the agent unable to choose between them from the text alone.

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 useful environmental condition ('works on deployed environments but a local development CM has no publishing target'), which is an implicit when-not. But it offers no positive when-to-use guidance and no routing to alternatives such as authoring-publish-item or authoring-publishing-status, so the sibling-selection problem is left open.

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 and destructiveHint=true, so the safety profile is covered. The description adds one genuinely useful bit beyond that: 'permanently', which clarifies the removal is irreversible. It says nothing about required permissions, whether a version/clone remains, or the response.

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

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

One short sentence with the destructive action front-loaded and no wasted words. It is efficient, though so terse for a four-parameter destructive operation that the brevity shades into under-specification.

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 tool with no output schema and annotation-covered safety, the description is minimally adequate. It leaves open whether the operation targets a single itemId or every item in the archive, and what identity and database actually constrain, which an agent needs in order to call it correctly.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including archive, database, and identity. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies; notably it implies a bulk 'items' scope while itemId is an optional single-item parameter, but it never resolves 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 and resource ('Removes items permanently from the specified archive'), which is clearly distinct from the sibling common-restore-archive-item and common-get-archive-item. It does not, however, explicitly name those siblings or explain the plural-vs-single-item scope, so it stops short of full differentiation.

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

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

There is no when-to-use guidance, no prerequisite (e.g. item must already be archived), and no mention of the inverse operation common-restore-archive-item that an agent should consider instead when the goal is reversible. The agent must infer the context entirely.

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 and destructiveHint=true, so the safety profile is covered. The description adds nothing beyond them — it does not disclose that removal is irreversible, what happens when the last version is removed, that recursion can affect descendants, or that archive vs recycle bin behavior differs. Purely a restatement of 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?

A single front-loaded sentence with zero waste. It is efficient but so thin that it arguably under-specifies rather than optimizes 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?

For an 8-parameter destructive mutation with recursive and wildcard behavior and no output schema, the description omits the consequences an agent needs: irreversibility, recursive impact on children, and archive-vs-recycle-bin retention. Complete parameter data lives in the schema, but the behavioral context is absent.

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 8 parameters (id/path, archive, recurse, version globbing, database, language, maxRecentVersions) are already documented in the schema. The description adds no parameter-level meaning, 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 ('Removes a version of a Sitecore item'), which clearly distinguishes it from item-level deletion siblings like authoring-delete-item or item-service-delete-item. It does not, however, mention its inverse sibling common-add-item-version or otherwise differentiate itself from them.

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

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

No guidance on when to use this versus alternatives, no preconditions, and no exclusions. The description only restates the operation and gives no routing information for an agent choosing among the many removal/deletion tools.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a write. The description contributes nothing further — it does not explain what an existing field value is replaced with, whether the change is reversible, or whether a publish is required, which is the most important missing behavioral context for a destructive mutation.

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

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

A single short sentence with no wasted words, and the resource is front-loaded. The terseness is appropriate in form even though it leaves substance unaddressed.

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, zero-required-parameter mutation with no output schema, the description should explain what reset semantics are and what the agent risks losing. It omits all of this, leaving the most consequential aspects of the operation undocumented.

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 five parameters are already documented in the schema. The phrase "names, fields or template fields" loosely maps to the name/includeStandardFields parameters but adds no syntax, wildcard behavior, or id-vs-path resolution detail 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 names a specific verb ("resets") and resource ("item fields"), so the domain is identifiable. However, "reset" is ambiguous — it does not say whether fields revert to template/standard defaults, are cleared, or are recomputed, and there is no differentiation from siblings like common-set-item-template or common-get-item-field.

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

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

There is no statement of when this tool should be used, what preconditions apply, or which sibling covers the task instead. The agent must infer usage entirely from the name.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds only the target (the application pool); it says nothing about downtime, dropped in-flight requests, required permissions, or scope of impact across the instance — the details that actually matter for a destructive restart.

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

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

A single short sentence with the scope front-loaded and zero filler. It is efficient, though arguably terse to the point of under-specification rather than 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?

For a destructive, instance-wide restart with no parameters and no output schema, the description omits the operational facts an agent needs — that this disrupts the running application, whether it can be safely called at any time, and what state it returns to. The annotations flag destructiveness but nothing explains the consequence.

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 nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter-level information 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 ('Restarts') and a specific resource ('the Sitecore Application pool'), so the agent knows exactly what the tool affects. No sibling tool performs a restart, so there is no realistic confusion to disambiguate, but the description also doesn't explicitly differentiate itself from the common-* administrative family.

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

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

There is no guidance about when this should be invoked — no preconditions (e.g., after config or cache changes), no exclusions, and no mention of alternatives. The agent must guess the operational context in which restarting the application pool is appropriate.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly covered, and the description is consistent with them. The description adds the useful fact that items go back to the original database, but omits whether the archive entry is consumed, whether existing items are overwritten, or any permission requirements for a mutation tool.

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

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

A single front-loaded sentence with no filler. It is appropriately sized, though the plural 'items' is mildly ambiguous given the singular itemId parameter.

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 four-parameter mutation tool with no output schema and no annotations covering side effects beyond readOnly/destructive, the description leaves gaps: what happens to the archive copy, whether the caller must supply archive plus database plus itemId together, and what the result is. Adequate but incomplete.

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

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

Schema description coverage is 100%, so itemId, archive, database, and identity are already documented in the schema. The description only says 'specified archive' and 'original database', adding no syntax or constraint detail beyond what the schema provides.

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

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

States a specific verb and resource: restores archived items back to the original database from a named archive. An agent can understand the core operation, but the description doesn't distinguish it explicitly from adjacent siblings such as common-remove-archive-item or common-get-archive-item.

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

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

There is no guidance on when to use this versus common-get-archive-item, common-remove-archive-item, or common-new-item-clone, and no mention of prerequisites such as the item first being in the archive. Usage is only implied by the verb.

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 flag readOnlyHint=false and destructiveHint=true, and the description goes beyond that by spelling out the concrete consequence of removal: fields are stripped from every derived item along with their values. This is genuinely useful blast-radius context. It stops short of describing the add-side effects or any permission requirements, so not 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 tight sentences with no filler, and the destructive consequence is front-loaded immediately after the core action. 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 mutation tool with full schema coverage, annotations carrying the safety profile, and no output schema, the definition is nearly complete: purpose plus the key destructive side effect. Only the add-side behavior and any id/path resolution nuance are left unstated.

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 every parameter (id, path, action, database, template) is already documented in the schema. The description adds no format, resolution, or defaulting detail beyond that, so the baseline 3 applies.

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

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

States a specific verb pair (adds/removes) and a precise resource (a base template on a template item), so the operation is unambiguous. It does not, however, distinguish itself from nearby siblings like common-test-base-template or common-set-item-template, which the agent must sort out on its own.

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

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

There is no when-to-use guidance and no mention of alternatives such as common-test-base-template (to check) or common-set-item-template (a different template operation). The action enum implies the add/remove branch, but the description never says when to choose this tool over its 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 and destructiveHint=false, so the agent knows this is a non-destructive mutation, but the description adds nothing beyond that structured signal. It doesn't say what actually changes when a template is assigned, whether existing field values are affected, or whether the operation requires the item id/path plus a resolvable template.

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

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

A single short sentence with no wasted words and no burying of key information. However, it is concise by omission rather than by discipline, so it earns only a middling score for structure.

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

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

This is a mutation tool with a nested object parameter (fieldsToCopy), no output schema, and no annotations explaining consequences, yet the description says nothing about effects or edge cases. For an operation whose whole point is swapping an item's template and remapping fields, that is a significant 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?

With 100% schema description coverage across all five parameters — including the id/path alternative and the fieldsToCopy old-to-new field mapping — the schema already carries the parameter burden. The description contributes no additional parameter meaning, 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?

"Sets the item template" restates the tool name almost verbatim, giving no more information than the identifier already did. It does not distinguish this from close siblings like common-set-base-template, common-get-item-template, authoring-update-item-template, or authoring-create-item-template, so an agent cannot tell which one to reach for.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The sibling common-set-base-template in particular covers a closely related operation, and the description gives the agent nothing to choose between them.

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

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

The readOnlyHint=true annotation already establishes that this is a safe, non-mutating read. The description adds the 'inherits from' predicate semantics, which clarifies the nature of the check, but it omits behavior such as default database resolution or that the result is a boolean.

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

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

A single efficient sentence with no redundant or wasted wording. It is front-loaded and easy to parse, though it is arguably too sparse to earn a 5.

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

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

For a simple read-only boolean check with fully documented params it is close to sufficient, but with no output schema the description should indicate the return shape (a boolean inheritance result) and does not. Response format and default behavior are left unstated.

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 id, path, database, and template with their fallback logic. The description adds no parameter detail beyond what the schema provides, so the baseline 3 applies.

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

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

The description states a specific verb ('Checks') and resource ('inherits from the specified template'), making the predicate nature of the tool unambiguous. It is distinguishable from siblings like common-set-base-template and common-get-item-template by its boolean-test framing, though it does not explicitly name an alternative.

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

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

There is no guidance on when to use this versus related siblings such as common-get-item-template, common-set-item-template, or common-set-base-template. The single sentence gives no context, prerequisites, or exclusions.

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

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

No annotations cover the relink/remove semantics, so the description must carry that burden, and it does state that links are updated or removed. But it omits whether this is reversible, what happens to the items whose links are changed, and whether it is destructive (annotations claim destructiveHint=false, yet removing links is arguably destructive); the behavior claim is thin relative to the mutation's impact.

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

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

A single sentence that is both under-specified and grammatically broken ('a new provided in the -NewTarget'). It is short but not because it is tight; important decision context is missing.

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 relinking/mutation tool with six parameters, no output schema, and no annotations describing side effects, the description is inadequate. It never explains the mutual exclusivity of id/path, the role of database/language, or the effect on the referencing items, leaving an agent short of what it needs 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 description coverage is 100%, so each parameter is already documented, including the supply-this-or-that relationship for id/path and the newTarget/removeLink meanings. The description adds only a pointer to newTarget and link removal, no syntax or format details 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 the verb (updates) and the resource (references to the specified item), and mentions the two operating modes via -NewTarget or removal. However, it does not differentiate itself from the sibling common-get-item-referrer, and the description is grammatically garbled ('point to a new provided in the -NewTarget'), which reduces clarity.

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

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

No explicit when-to-use guidance. It never states how it differs from common-get-item-referrer (read vs write) or when to pick newTarget versus removeLink. The two modes are mentioned but not framed as alternatives the caller must choose between.

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, so the safe read nature is covered. The description adds meaningful behavioral context beyond that by specifying that secrets (passwords, GraphQL API key, authorization header) are redacted, which is important for an agent to know when interpreting output. It does not describe auth requirements or output format, so it falls just 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 and free of redundancy. The first sentence states the core action; the second adds the security-relevant detail about redaction. 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 zero-parameter, read-only diagnostic tool with no output schema, the description gives an agent everything needed: what is printed and the important caveat that secrets are redacted. No additional context is required to invoke it correctly or interpret the response safely.

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

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

The tool has zero parameters, so there are no parameter semantics to document. Per the rubric, a zero-parameter tool receives a baseline of 4.

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 ("Prints") and resource ("configuration of the Sitecore MCP server") with no ambiguity. No sibling tool covers server configuration, so an agent can immediately distinguish it from all other tools in the list.

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 for diagnostics or when the current server configuration needs inspection, but the description does not state when to use this tool instead of alternatives or mention any prerequisites. No explicit when/when-not guidance is provided.

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

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

Annotations only declare a non-readonly, non-destructive write, so the description carries most of the behavioral load and does so well: it discloses the layout-reference return form for page-local, the item-ID return for shared, and the failure mode ('fails naming every candidate it tried when none resolves, rather than guessing'). Permissions/auth requirements are not addressed, 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 front-loaded sentences that lead with the core action before drilling into placement semantics. Dense but each clause carries information; only the slightly long placement sentence risks over-explanation.

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 9-parameter, zero-required creation tool with no output schema, the description supplies the missing return-value semantics and error behavior. It leaves minor gaps around authentication/permissions, but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains placement's effect on path and return value and confirms that 'fields' are set on the new item. The name-defaulting convention is described in both places but the description reinforces it coherently.

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: it 'creates the datasource item for a component', and grounds it in the rendering's Datasource Template and Location. This clearly distinguishes it from generic item creators like authoring-create-item and item-service-create-item.

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 two placement modes and when each applies ('lives and dies with the page' vs 'reused across pages'), which is genuine when-to-use guidance. It stops short of naming alternative sibling tools for other creation scenarios, so it is clear context without explicit 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?

Despite readOnlyHint covering the safety profile, the description adds substantial behavioral context: the two-tier resolution order (site-level then global fallback), which item answered via settingsItemPath, dynamic-placeholder leaf matching against wildcard keys, and how unresolved control IDs and Found=false are surfaced. This is far beyond what annotations provide.

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 purpose and pre-call guidance are front-loaded, then resolution order and edge cases follow. It is dense and every sentence carries information (resolution order, dynamic placeholders, Unresolved, Found=false), though the length pushes against ideal conciseness.

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

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

With no output schema, the description carries the burden of explaining returns and does so thoroughly — settingsItemPath, Unresolved, and Found=false are all defined with their implications. Nothing material for correct invocation or interpretation 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: it explains the bare-key vs full-runtime-path forms of placeholderPath and the leaf-segment matching, and clarifies the project parameter's precedence and fallback. It stops short of detailing path/pageId/database/language interactions 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 concrete verb and resource — 'Lists the renderings a placeholder allows on a given page' — and immediately grounds it in the placeholder settings items that govern it. An agent can distinguish this from sibling tools like add-rendering-to-placeholder and presentation-get-placeholder-setting 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-to-use context: 'Call this before adding a rendering,' with a concrete consequence ('a placeholder that forbids a component will still accept it silently'). It routes the agent into the add-rendering workflow well, though it doesn't name a specific sibling as an alternative or state when not to call it.

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 read safety, and the description goes further by disclosing the exact result envelope (Matched/Returned/Truncated/Root/SiteName/Pages), the truncation contract, and the semantic rule that decides membership (presentation presence, not template naming). It stops short of noting permissions or ordering, but this is far more than the annotations supply.

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 one-line purpose, then the return shape, then the inclusion rule. Three tight sentences with no filler, though the inclusion clause is somewhat long for the value it carries.

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?

There is no output schema, so the description correctly supplies the return structure and truncation semantics itself, plus the definition of what qualifies as a page. For a read-only listing tool, an agent has everything needed to invoke and interpret it.

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

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

Schema description coverage is 100%, so the schema already fully documents path, siteName, limit, database, and rootPath; the description adds nothing about them. Baseline 3 is correct when the schema does all the work.

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

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

States a specific verb and resource ('Lists the pages of a site') and sharpens it with an inclusion rule that separates a real page from a template-naming guess. It does not, however, name or contrast itself with the obvious sibling search-site-pages, so differentiation is left to inference.

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

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

No explicit when-to-use or when-not-to-use guidance is given. With search-site-pages and list-sites among siblings, an agent gets no signal about which to pick for a filtered search versus a full enumeration.

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, so safety is covered. The description adds real behavioral context the annotations cannot: progressive disclosure, the ~510KB corpus size, the 129-command index shape, and that search returns names/summaries rather than full pages. It stops short of describing pagination or error behavior, so 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?

Purpose is front-loaded and every sentence carries information about call sequencing or return shape. It is dense and slightly long, but nothing is padding; a marginally tighter phrasing would reach 5.

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 no output schema, the description must describe returns, and it does: index of 129 commands with one-line summaries, full pages with syntax/parameters/examples, and search results as names and summaries. That is sufficient for an agent to call the tool correctly at each stage.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that calling with NO arguments returns an index, a cross-parameter usage workflow the schema cannot express, and reinforces what 'search' returns versus full pages. This adds genuine meaning over the field 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?

States a specific resource (Sitecore PowerShell Extensions command reference) and its concrete purpose (writing run-powershell-script scripts), which cleanly separates it from the run-powershell-script execution sibling. An agent can tell exactly what this returns 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.