EDS MCP Server

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

With no annotations, the description carries the full burden and does so thoroughly: it explains the audit/diff/record cycle, status outcomes (ok/degraded/broken), webhook payload safety ('only public audit data, never secrets'), auth requirement (EDS_DA_TOKEN), and the division of labor between server and caller.

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

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

The description is compact yet information-dense. Every sentence adds a distinct piece of needed context (schedule, diff, status, history, webhook, safety, server vs. client role, auth, shared options). It is front-loaded with the core purpose and does not waste words.

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

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

For a tool with no output schema and complex scheduled behavior, the description covers the essential operational contract: what it does, what it records, how status crossing works, what the webhook payload contains, prerequisites, and relation to sibling tools. An agent has enough to decide whether to invoke it and how to configure 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 coverage is 100%, so the baseline is 3. The description adds meaningful parameter context by linking `webhook` to the alert flow ('get pinged when the status crosses `alertOn`') and by warning about payload confidentiality. It also groups audit options under 'Same audit options as eds_audit_site', providing cross-tool semantic continuity.

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

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

The description opens with a specific verb-resource pair ('Watch a site on a schedule') and clearly explains the diff-and-status-report mechanism. It distinguishes itself from siblings by positioning as the 'automate it' primitive and referencing shared history with eds_audit_snapshot/eds_audit_trend and same options as eds_audit_site.

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

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

The description gives clear when-to-use context ('This is the 'automate it' primitive: the SERVER does the check + alert; you supply the schedule'). It implies alternatives through 'Same audit options as eds_audit_site', but does not explicitly name a one-off alternative tool or state 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?

Since no annotations are provided, the description carries the full burden. It explicitly states 'Read-only' and describes the output (prioritized findings with fixes), which covers the key behavioral aspects. It does not mention auth or rate limits, but for a read-only audit tool, this is sufficient.

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

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

The description is two sentences, front-loaded with the primary purpose, then output details and read-only note. No redundant information, every sentence adds value.

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 tool with one parameter and no output schema, the description is complete: it explains what the tool does, what it checks, what it returns, and its read-only nature. It covers all necessary context.

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

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

The schema covers the only parameter 'path' with a clear description, and the tool description does not add extra meaning beyond that. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description clearly states the tool audits a single page for SEO and accessibility issues, listing common checks. It distinguishes from sibling tools like eds_audit_site by focusing on a single page.

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

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

The phrase 'single page' implies usage for one page at a time, distinguishing it from site-wide audits. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusion 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?

No annotations are provided, so the description carries the full burden. It discloses 'Read-only', the always-present Navigator footer credit, and the self-contained nature of the report. It does not mention potential performance implications of running a full site audit, but the read-only declaration is a key safety trait.

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

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

Three sentences, front-loaded with the core purpose, then branding details, then a reference to the sibling tool and safety trait. Every sentence provides essential information without redundancy.

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

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

The description enumerates the report contents (letterhead, summary, scores, issues, PDF button), which compensates for the lack of an output schema. It references eds_audit_site for audit options. Minor gaps exist, such as the exact return format (HTML string vs file), but overall it is sufficiently complete for a complex 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 coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining how brand and executiveSummary affect the output (white-labeling the letterhead, prominent client-facing summary) and that audit parameters match eds_audit_site. This connects parameter use to real-world report behavior.

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

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

The description clearly states the tool runs a site audit and returns a client-ready HTML report, listing specific report components (letterhead, executive summary, health scores, prioritized issues, PDF button). It distinguishes itself from siblings by emphasizing the report output and white-labeling, and explicitly references eds_audit_site for audit options.

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 says 'Same audit options as eds_audit_site', which directly relates this tool to a sibling and implies when to use it (when a client-ready HTML report is needed rather than raw audit data). It does not explicitly exclude alternatives like eds_audit_page, but the context is clear enough.

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

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

With no annotations provided, the description carries the transparency burden. It explicitly discloses read-only behavior ('Read-only; safe to run anytime') and explains the conditional nature of performance/404 checks (when a domain is supplied). It does not detail output format or rate limits, but the core behavioral traits are clearly stated.

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

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

The description is three sentences with no filler. The first sentence is information-dense, the second is a concise safety note, and the third gives actionable usage guidance. 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?

Given no output schema and no annotations, the description adequately explains the tool's scope, conditional behavior, and workflow. It could mention the shape of the prioritized list or the effect of maxPages, but overall it provides enough context for an agent to select and invoke the tool appropriately.

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

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

The input schema already provides 100% coverage with descriptions for all five parameters. The description adds some context by linking 'domain' to real-user data and 'subtree' to pathPrefix, but this largely repeats schema information, keeping it at the baseline.

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

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

The description uses specific verbs ('sweep', 'return a prioritized list') and clearly identifies the resource (whole site or subtree). It enumerates the dimensions covered (SEO, accessibility, freshness, sitemap, performance, 404s) and distinguishes itself from page-level audit tools like eds_audit_page.

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 states it is read-only and safe to run anytime, and suggests pairing with write tools to fix findings. However, it references 'eds_da_*' tools, which appear to be source-management tools rather than the actual fix tools (eds_fix_*) in the sibling list, providing potentially misleading guidance.

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

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

With no annotations provided, the description fully carries the transparency burden. It discloses that the tool writes to a private history sheet, requires EDS_DA_TOKEN, supports dryRun preview, publish flag, same-day row updates, and returns the score plus change. This is rich behavioral disclosure beyond 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?

The description is dense with useful details but remains well-structured and front-loaded with the core purpose. It covers return format, behavior, prerequisites, and related tools without redundancy. Slightly long but each sentence adds value.

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

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

Given the tool's complexity (8 params, no output schema, no annotations), the description is highly complete. It explains the recording mechanism, return values, same-day behavior, dryRun/publish options, authentication requirement, and relationships with sibling tools. No critical missing context for an agent to 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?

The schema provides 100% coverage with descriptions for all 8 parameters. The description adds minimal extra parameter meaning, only mentioning that 'Same audit options as eds_audit_site' implies consistent behavior. This meets the baseline for high schema coverage without additional nuance.

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

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

The description clearly states the tool's purpose: "Run the site audit and RECORD its scores to a history sheet" with a specific resource (Document Authoring content). It distinguishes from siblings by emphasizing the recording aspect and mentions eds_audit_trend for trend viewing, making its role unique.

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

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

The description provides usage context: it explains the history recording, pairing with eds_audit_trend, and notes "Same audit options as eds_audit_site" to indicate similarity. While it doesn't explicitly state when not to use it, the purpose is clear enough for an agent to infer when this tool 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?

With no annotations provided, the description carries the full burden. It explicitly states 'Read-only', requires EDS_DA_TOKEN, explains the output format and content, and notes its dependency on the history sheet. This is comprehensive disclosure of auth, safety, and operational 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?

Two sentences packed with essential information: purpose, output details, data source, format option, auth requirement, and safety. No filler or redundancy; 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?

Despite having no output schema and no annotations, the description covers the tool's main behavior: what it returns, what it depends on, its auth requirements, and its read-only nature. For a simple read-only tool with two optional parameters, this is complete enough for an agent 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%, so the parameters are already well-described. The description adds minimal new meaning beyond the schema—'Pass format:'text' for a short plain-text summary' essentially repeats the schema's enum description. No extra insight is provided for historyPath beyond the schema's default value. 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 ('Show') and resource ('site health OVER TIME from the recorded snapshots'), clearly distinguishing it from siblings like eds_audit_report (current report) and eds_audit_snapshot (writes snapshots). It also details the output (HTML trend view with SVG sparkline and per-dimension movement), making the purpose unambiguous.

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

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

The description clarifies that it reads the history sheet written by eds_audit_snapshot, implying it should be used after snapshots exist. It also gives usage options (format:'text' for a summary). While it doesn't explicitly name alternative tools to avoid, the context is clear enough for an agent to choose this tool for trend analysis over time.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the operation is reversible, returns a single undo object, writes in a batch, requires a token, and supports dryRun and publish modes. It does not mention potential failure modes or rate limits, but the key behavioral traits are well disclosed.

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

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

The description is a single, dense paragraph with no redundant phrases. Each sentence contributes essential information: purpose, input structure, batch behavior, rollback mechanism, modes, token requirement, and pairing suggestion. It is front-loaded with the primary function and efficiently covers all critical aspects.

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

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

Given the tool's complexity (batch metadata update with rollback, dryRun/publish modes, auth token), the description covers all critical aspects: what it does, how to use it, undo capability, preview/publish behavior, token necessity, and integration with the audit workflow. The undo object is explicitly mentioned, addressing the lack of an output schema. It is sufficiently complete for an agent to invoke appropriately.

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

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

The schema already covers 100% of parameters with descriptions, giving a baseline of 3. The description adds value by explaining the intended workflow (audit first, supply values, use dryRun, then publish) and clarifies the role of the pages parameter ('the agent supplies each page's values after auditing'). This helps the agent understand what data to pass and in what order.

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

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

The description clearly states the tool's purpose: 'Fix SEO/social metadata across MANY pages in one reversible operation.' It uses a specific verb and resource, and differentiates from sibling tools by emphasizing the bulk aspect, single undo object, and rollback via eds_da_rollback. It also mentions pairing with eds_audit_site, further clarifying its niche.

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

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

Provides clear usage context: it's for fixing metadata on many pages, requires EDS_DA_TOKEN, and is meant to be paired with eds_audit_site to fix findings. It explains the dryRun and publish modes and mentions that the agent supplies values after auditing. While it doesn't explicitly say when not to use it, the 'MANY pages' and 'bulk' language implicitly excludes one-off fixes, which are better handled by eds_fix_metadata.

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

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

No annotations are provided, so the description carries the burden. It discloses the async nature, immediate job handle return, and the need to poll, which is the core behavioral trait. However, it does not mention any side effects, permissions, or whether the preview is read-only, leaving some ambiguity.

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

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

The description is two sentences, front-loaded with the primary action, and includes only essential information: the job nature, return handle, polling instruction, and typical use cases. No wasted words.

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

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

The tool is straightforward for an async batch operation, and the description explains the job flow and gives a polling reference. It does not describe output format, but since no output schema exists and the return is just a job handle, the description covers what an agent needs to know to proceed.

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?

All parameters are fully described in the input schema (100% coverage), so the description adds little beyond what is already structured. It reinforces the batch context but does not clarify parameter formats, making the schema's descriptions sufficient.

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

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

The description clearly states the tool starts an asynchronous bulk preview job over many pages, which is distinct from the sibling tools eds_preview_page (single) and eds_bulk_publish (publishing). It also mentions returning a job handle and polling for progress, adding specific operational detail.

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

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

The description gives clear use cases ('section updates or content migrations') and implies the async job flow (poll ed_get_job_status), but it does not explicitly state when NOT to use this tool versus eds_preview_page or eds_bulk_publish.

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

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

With no annotations, the description carries the burden. It discloses the asynchronous behavior, immediate return of a job handle, and the need to poll for progress. It does not cover failure modes or permissions, but the core workflow is well explained.

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 no filler: the first states purpose and scale, the second conveys the async workflow and follow-up action.

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

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

The tool is an async job starter with two well-documented params. The description explains the immediate return and polling mechanism, making the workflow clear. It lacks details on edge cases, but that's covered by the job status tool referenced.

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

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

The schema already provides descriptions for both parameters, including an example for paths and default behavior for forceUpdate. The description adds no further parameter semantics, so baseline 3 applies.

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

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

The description clearly states the action ('Start an asynchronous bulk publish job'), the scope ('from preview to the live production domain over many pages'), and distinguishes it from single-publish siblings like eds_publish_page by emphasizing bulk.

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 indicates this is for publishing 'many pages in one call' and provides a follow-up instruction to poll eds_get_job_status, but it does not explicitly mention when not to use it or name alternative tools for single-page publishes.

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

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

The description adds the authentication requirement (EDS_DA_TOKEN) and specifies the source must be an 'authored source document,' providing some behavioral context. However, it does not disclose whether the destination will be overwritten, how conflicts are handled, or what the tool returns. With no annotations, these omissions leave notable gaps.

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

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

The description is a single sentence of 14 words, front-loaded with the core operation and quickly noting the auth requirement. No unnecessary words.

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

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

For a two-parameter copy tool, the description covers the basics and the auth prerequisite. However, the lack of an output schema and annotations means the description should also address expected outcomes or failure modes (e.g., destination exists). This is missing, so completeness is adequate but not exhaustive.

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

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

The input schema provides clear descriptions for both parameters ('Source DA document path' and 'Destination DA document path'), giving 100% coverage. The description does not add additional semantics beyond this, such as path format or restrictions, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action (copy), the resource (authored source document), and the destination (another path in Document Authoring). It implicitly distinguishes from sibling tools like eds_da_move_source by specifying copy rather than move.

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 using this tool when a copy is needed, but it does not explicitly mention alternatives such as eds_da_move_source for relocating or eds_da_put_source for creating. No when-not-to-use 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?

No annotations are provided, so the description carries the full burden. It discloses the destructive action and auth requirement, but omits whether the deletion is permanent, cascades to versions, or can be undone. For a destructive operation, this leaves significant behavioral uncertainty.

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 concise sentences front-load the purpose and token requirement with no redundant details. Every word earns its place, making it highly 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?

The tool is simple with one parameter and no output schema, and the description covers the core action and token need. However, it lacks information about return values, error conditions, or post-deletion effects, which is a gap for a destructive operation with no annotations.

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

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

The schema fully describes the single 'path' parameter with 100% coverage, and the description adds context by specifying 'from Document Authoring.' With full schema coverage, the description contributes minimal additional parameter semantics, so the baseline 3 is appropriate.

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

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

The description uses the specific verb 'Delete' and names the resource 'authored source document from Document Authoring,' clearly distinguishing it from sibling operations like get, put, copy, and move. It leaves no ambiguity about the tool's function.

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 states a prerequisite (Requires EDS_DA_TOKEN) but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. It implies usage (when you need to delete a source document), but offers no exclusions or alternative recommendations.

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

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

With no annotations, the description carries the burden of disclosing behavior. It mentions the recursive fetch, that it returns all sources together, and the required token. It implies a read-only operation with the phrase 'clone read', but does not explicitly state that it has no side effects or describe error/truncation behavior beyond what the schema covers.

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

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

The description is two sentences long, front-loaded with the action ('Bulk-export'), and each sentence adds essential information: the recursive behavior and the comparison to per-page gets. No fluff or repetition.

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

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

For a tool with two parameters and no output schema, the description covers the core behavior (recursive export, path, return of sources, token requirement) and provides usage context. It could elaborate on what 'sources' means or potential errors, but given the simplicity and helper schema, it is reasonably complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little semantic value beyond the schema: it rephrases the path as 'under a path' but does not explain maxFiles or output format beyond what the schema already provides. It does not hurt, but does not significantly elevate.

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

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

The description clearly states the tool's purpose with a specific verb ('Bulk-export'), the resource ('Document Authoring subtree'), and behavior ('recursively fetch every document under a path and return all their sources together'). It also distinguishes itself from the sibling tool eds_da_get_source by noting this is for many pages at once vs. one get per page.

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

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

The description explicitly positions the tool as the efficient alternative for operating on many pages at once, directly comparing it to 'one get per page' and naming the requirement of EDS_DA_TOKEN. This gives clear when-to-use context and a contrast with 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?

With no annotations, the description carries the full burden. It discloses the auth requirement ('Requires EDS_DA_TOKEN') and clarifies the raw-source nature, but it does not describe response format, error behavior, or whether the operation is safely read-only (though 'Get' implies so). This is 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?

Two sentences with no redundant wording. The key verb, resource, and distinguishing context are front-loaded. The token requirement is a necessary disclosure. 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 simple one-parameter tool with no output schema and no annotations, the description covers the core purpose, auth, and a key distinction from rendered output. It lacks details on the exact response format or potential errors, but the tool's simplicity and the clear 'get source' intent make this largely 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?

The schema already provides 100% coverage for the single 'path' parameter, including the '.html' assumption behavior. The description adds no further parameter-specific meaning beyond reinforcing that the path refers to a DA document, so it stays at baseline.

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

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

The description clearly states a specific verb+resource: 'Get the raw authored source (typically HTML) of a Document Authoring document.' It distinguishes this from rendered/previewed output, which differentiates it from sibling tools like eds_preview_page or eds_get_page.

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 when to use this tool by noting it returns 'the source of truth, not the rendered/previewed output,' signaling it is the choice for raw source access. It mentions the token requirement but does not explicitly name alternative tools or when not to use it, so it falls 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?

The description discloses the authentication requirement (EDS_DA_TOKEN), which is useful because no annotations are provided. However, it does not mention the read-only nature, response format, or any potential side effects, leaving the agent to infer from the tool name.

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

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

The description is a single, front-loaded sentence that directly states the action and requirement. No redundant words or repetition.

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

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

Given the tool's low complexity (one parameter), the description is largely sufficient for selection and invocation. It provides the purpose and auth requirement, though it could mention what the version history response contains since there is no output schema.

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

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

The schema fully describes the single 'path' parameter, and the description does not add any additional semantics. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description states the specific action ('Get') and resource ('version history of a Document Authoring source document'). This clearly distinguishes it from sibling tools like eds_da_get_source, which retrieves the actual source content.

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 intended use is implied: call this when you need the version history of a DA document. However, there is no explicit guidance on when not to use it or how it compares to alternatives like eds_da_get_source.

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

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

No annotations are provided, so the description must carry the full burden. It adds the token requirement but does not disclose whether listing is recursive, what the response format is, or any error handling. The word 'List' implies read-only, but other behavioral aspects are absent.

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

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

The description is two sentences, both informative and directly actionable. It is front-loaded with the purpose and includes essential authentication context, with zero wasted words.

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

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

The tool is simple with one optional parameter, and the input semantics are clear. However, there is no output schema, so the description should explain the return value; it does not. Also, whether the listing includes subfolders recursively is ambiguous. Adequate but with gaps.

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

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

The schema description for the single 'path' parameter is complete (100% coverage), including an example and default behavior. The description's mention of 'under a path' adds little beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'List', the resource 'authored source documents and folders', and the context 'in Document Authoring (DA) under a path'. This distinguishes it from sibling tools like eds_list_pages, which pertains to published pages, and other DA 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?

Provides clear context: lists under a path, with optional path parameter and root default. It also mentions the required token. However, it does not explicitly direct when to use this tool over alternatives, nor does it state exclusions, but the context is strong enough for a focused list tool.

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

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

With no annotations provided, the description carries the full burden. It mentions the token requirement but does not disclose side effects such as whether the source is removed, what happens if the destination already exists, or if the operation is reversible. The verb 'move' implies side effects but lacks explicit detail.

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

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

The description is two sentences, front-loaded with the primary purpose and followed by the required token. It is concise with no fluff, every sentence contributes directly to understanding the tool.

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

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

For a simple two-parameter move operation, the description provides purpose and auth but omits critical behavioral context such as conflict handling, return values, or failure modes. Given the lack of output schema and annotations, the description leaves some gaps, but the core invocation is adequately covered.

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 both parameters described clearly ('Source DA document path' and 'Destination DA document path'). The description adds no additional parameter-level meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb 'Move (rename)' with a clear resource ('authored source document') and scope ('to another path in Document Authoring'). It distinguishes from sibling tools like copy, delete, and put by indicating relocation rather than duplication or creation.

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

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

No explicit guidance on when to use this tool versus alternatives like eds_da_copy_source or eds_da_delete_source. The auth token requirement is a prerequisite, not a usage guideline, and the description does not mention when a move is preferred over copy or delete.

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

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

With no annotations, the description carries the full burden and does well: discloses the bulk nature, dryRun as no-write preview, withUndo as reversible, return of an undo object, and auth token requirement. Missing details on partial failures and response format, but core safety and reversibility are covered.

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

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

Three sentences, front-loaded with the primary purpose. Every sentence adds value: bulk operation, dryRun recommendation, withUndo behavior, and auth requirement. 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 complex write tool with no output schema, the description covers key invocation aspects (documents, dryRun, withUndo, token). Lacks details on response shape or error/partial-failure behavior, but is sufficient for an agent to select and call it correctly in most 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 baseline is 3. The description adds meaningful context beyond the schema by explaining dryRun as a safe preview and withUndo as enabling rollback via eds_da_rollback, which adds practical semantics.

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

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

The description states a specific verb and resource: 'Bulk-push many edited Document Authoring documents back in one call.' It clearly distinguishes from siblings (e.g., eds_da_put_source for single source, eds_bulk_publish) by explicitly focusing on bulk push of edited DA documents.

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

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

Provides clear guidance on using dryRun first as a safe preview and withUndo for reversibility, plus the token requirement. However, it does not explicitly contrast with alternative tools (e.g., when to use eds_da_put_source instead).

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

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

The description discloses the authentication requirement (EDS_DA_TOKEN) and the upsert semantics, but does not elaborate on side effects such as overwriting existing content, directory creation, or response behavior. With no annotations, the description carries the burden but only partially fulfills it.

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

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

The description is a single sentence that front-loads the action (Create or update) and resource (authored source). Every word earns its place; no unnecessary detail or repetition.

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

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

For a simple write tool with three parameters, the description adequately conveys the core purpose and required authentication. It lacks return value or error expectations, but the absence of an output schema makes this a minor gap; overall the tool context is reasonably 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?

The input schema already provides descriptions for all three parameters (path, content, contentType) with 100% coverage. The description adds no extra meaning beyond the schema's existing parameter descriptions, so baseline 3 is appropriate.

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

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

The description clearly states a specific verb 'Create or update (upsert)' and a specific resource 'the authored source of a Document Authoring document'. This clearly distinguishes it from sibling tools like eds_da_get_source and eds_da_delete_source.

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 for writing a DA document source, but does not explicitly state when to use it instead of alternative tools or exclude any conditions. There is no mention of when not to use it or when a sibling tool would be more appropriate.

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

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

No annotations are provided, so the description carries the burden. It explicitly states the behavioral effect: 'restores overwritten documents and deletes newly-created ones.' It also notes the authentication requirement (EDS_DA_TOKEN). It does not cover every edge case (e.g., errors, partial failures), but it discloses the core behavior transparently.

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

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

The description is two sentences, front-loaded with the purpose, and contains no redundancy. Every sentence adds valuable information: what it does, what the input is, and the auth requirement. It is efficiently structured.

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

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

Given the single nested parameter and no output schema, the description covers the essential aspects: what the tool does, what to pass, where to get it, and the auth requirement. It does not describe the return value, but without an output schema, that omission is acceptable. Overall, it is complete enough for an agent to use correctly.

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

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

The schema describes the structure of the undo object with 100% coverage, but the description adds critical semantic context by specifying that the undo object must be the exact one returned by a withUndo push. This provenance information is not present in the schema and is essential for correct usage.

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

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

The description clearly states its purpose: 'Undo a previous eds_da_push.' It uses a specific verb and resource, and distinguishes itself from other tools by referencing the push operation. It also specifies the required input context, making it 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?

It gives clear guidance on when to use: only to undo a previous push that used withUndo, and requires passing the exact undo object. It does not explicitly mention alternatives, but the usage context is well-defined and sufficient for an agent to decide when to invoke 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?

With no annotations provided, the description carries the full burden. It discloses that the operation is reversible via eds_da_rollback, that everything is pushed in a single batch, that dryRun previews without writing, and that publish:true makes it live. It also notes the EDS_DA_TOKEN requirement. These go beyond basic parameter info and set clear expectations for the agent.

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

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

The description is comprehensive yet succinct. It front-loads the core purpose, then explains the workflow, safety, and prerequisites. Each sentence adds value—no redundant or vague phrasing. The length is justified by the tool's complexity and the need to convey safety features.

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

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

Given the tool's complexity (multiple parameter types, batch behavior, publish vs dryRun), the description is complete. It covers the expected input, the reversible nature, and prerequisites. There is no output schema, but the description sufficiently explains what happens during dryRun vs publish, so the agent can anticipate 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?

Although the schema already describes each parameter (100% coverage), the description enriches them with usage context: metadata fixes are per-page, redirects use { source, destination }, and values must come from findings. It clarifies the semantic difference between dryRun and publish, and that metadata only changes provided fields. This adds meaning beyond the raw schema.

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

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

The description clearly states the action: 'Fix what the audit found — across metadata AND redirects — in ONE reversible operation.' It identifies the resource (audit findings) and distinguishes itself from sibling tools like eds_fix_metadata and eds_fix_redirect by combining both. The workflow ('audit → you supply values → one safe, reversible apply') further clarifies 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?

Explicitly specifies when to use: 'After eds_audit_site/eds_audit_report, findings that carry a `fix` are repairable here.' It states that the tool does not invent copy, implying the user must provide values from findings. It also contrasts with alternative tools and explains the dryRun and publish parameters as part of the safe workflow.

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, so description carries full burden. Clearly discloses that it writes to Document Authoring source, uses safe-writes (dry-run + undo), requires EDS_DA_TOKEN, and that publish:true makes changes live. Also mentions idempotency and that only provided fields are changed. No contradictions.

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 concise sentences that front-load the purpose and mechanism. Every sentence carries unique info: what it does, safety features, and publish nuance. No padding.

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

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

Given 5 params, nested object, no output schema, and no annotations, the description covers purpose, mechanism (safe-writes), auth requirement, publish behavior, and idempotency. It's comprehensive and doesn't leave critical unknowns like reversibility or how to preview.

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 has 100% coverage (all params described). The description adds context by tying dryRun/withUndo to 'safe-writes path', explains the publish flag meaning, and clarifies the agent's role in supplying values. It adds value beyond schema without redundancy.

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

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

The description clearly states the verb (fix), the object (SEO/social metadata), and the mechanism (Document Authoring source). It differentiates from siblings like eds_get_metadata (read-only) and eds_bulk_fix_metadata (bulk) by specifying it edits the page's Metadata block idempotently.

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

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

Provides clear context: when to use (to fix metadata), how to use (dryRun first, publish to go live, withUndo for reversibility), and notes EDS_DA_TOKEN requirement. However, it doesn't explicitly contrast with eds_bulk_fix_metadata or eds_get_metadata, but the tool's scope is implied by its name.

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

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

With no annotations provided, the description carries the full burden. It discloses idempotency ('updates a rule for an existing source, never duplicates'), the safe-writes path with dry-run and undo, the publish behavior ('publish:true publishes the sheet so redirects go live'), and the token requirement ('Requires EDS_DA_TOKEN'). This is thorough and gives the agent a clear behavioral model.

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

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

The description is dense but every sentence serves a purpose: purpose, rule format, idempotency, safe-writes/publish, token, and pairing. It is front-loaded with the main verb and resource, then efficiently delivers all critical operational details without fluff.

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

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

Given no annotations and no output schema, this description compensates fully. It covers prerequisites, safe-write behavior, live publication, and integration with eds_audit_site. The only minor omission is explicit mention of maxItems (500) and the undo mechanism's exact nature, but the schema already documents maxItems and the safe-writes mention suffices for an agent.

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 value by explaining the redirects array can contain 'one or many' rules, gives concrete examples of source/destination formats, and clarifies the idempotent update behavior. It also ties the publish parameter to actual publication, which the schema already hints at but the description contextualizes.

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

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

The description clearly states the tool's purpose: 'Fix broken links (404s) by adding redirect rules to the site's redirects sheet — the EDS mechanism that serves 301 redirects.' It names a specific verb ('Fix'), resource ('redirects sheet'), and mechanism ('301 redirects'), distinguishing it from read-only siblings like eds_get_redirects.

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

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

The description provides clear usage context: it pairs with eds_audit_site to identify 404s and recommends 'dry-run + undo' via the safe-writes path. It doesn't explicitly say when not to use the tool or name alternatives, but the pairing and dry-run guidance offer strong situational cues.

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 provided, so description carries full burden. It discloses the report includes hit counts and referrer sources, but does not state whether the operation is read-only, or address authorization, rate limits, or side effects.

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?

Single sentence of 15 words, front-loaded with key information. No redundant 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?

Given the tool's simplicity (2 params, no output schema), the description is adequate for basic understanding. It could mention output format or contrast with siblings, but overall covers the main purpose and content.

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 clear descriptions for both parameters. The description adds 'including hit counts and referrer sources' but does not enhance parameter meaning beyond the schema.

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

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

The description clearly states the tool retrieves a report of 404 errors with hit counts and referrer sources, using a specific verb ('Get') and resource. It distinguishes from siblings like eds_get_logs or eds_get_redirects by focusing specifically on 404 errors.

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. The name and description imply it's for 404 error reports, but no alternatives or exclusions are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It implies a read operation via 'List' but does not disclose any behavioral traits such as authentication requirements, rate limits, or whether the tool is read-only. More detail is needed.

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

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

The description is a single sentence of 13 words, front-loaded with the purpose. Every word earns its place, and there is no redundancy.

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

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

For a simple list tool with no parameters and no output schema, the description provides the essential information: what is listed (API keys) and the included fields (roles, creation dates). It is sufficient for a low-complexity tool, though it omits any mention of authentication or scope.

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

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

There are 0 parameters, so the baseline is 4. The description adds meaning about the output (roles and creation dates), but since there are no parameters, it cannot add parameter semantics. The schema coverage is trivially 100%.

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

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

The description clearly states the tool lists API keys for the EDS site, including roles and creation dates. It uses a specific verb ('List') and resource ('API keys'), distinguishing it from sibling tools that focus on other resources like logs, config, or pages.

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

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

The purpose is clear and distinct from siblings, so an agent can infer when to use it. However, there is no explicit guidance on when not to use it or alternatives, but the context is straightforward.

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

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

The description indicates a read operation, which is sufficient given no annotations, but it lacks details on authentication requirements, rate limits, or potential side effects. The mention of specific config elements adds some transparency.

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

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

A single, front-loaded sentence that efficiently communicates the tool's purpose without unnecessary words.

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

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

While the description covers the purpose and key config elements, it lacks details on the return format or structure, which would be helpful since there is no output schema.

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

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

The input schema has zero parameters, so the description does not need to add parameter information. Baseline for 0 parameters is 4, and the description correctly explains what the tool retrieves.

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

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

The description clearly states the tool reads site configuration from the EDS config endpoint and lists examples (fstab, headers, redirects), making the purpose specific and distinct from sibling tools like eds_get_redirects or eds_get_metadata.

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

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

No guidance is provided on when to use this tool versus alternatives like eds_get_redirects or eds_get_sitemap. The description only states what it does, with no context for selection.

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

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

With no annotations, the description carries full behavioral disclosure burden. It mentions the data source but does not disclose read-only nature, authentication needs, rate limits, error handling, or effects of the query.

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?

Single sentence, front-loaded with action, no wasted words. Efficient and clear.

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

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

For a simple two-parameter tool with no output schema or annotations, the description covers the basics (what, where) but lacks return format details or error handling. Adequate but not thorough.

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

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

Schema description coverage is 100%, so both parameters (domain, days) are already documented in the schema. The description adds no extra meaning beyond what the schema provides, meeting the baseline for high coverage.

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

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

The description specifies the verb 'Get' and resource 'Core Web Vitals' with explicit metrics (LCP, CLS, INP, TTFB) and source (RUM data pipeline). It clearly distinguishes from sibling tools like eds_get_404s or eds_get_logs.

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 vs alternatives. The description only states what it does, lacking context on prerequisites, typical use cases, or when not to use 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?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It indicates a read operation but does not mention data freshness, pagination, authentication needs, or potential side effects. The behavior is partially transparent but insufficient.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core purpose and key output details without extraneous 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?

Despite having no output schema, the description mentions three specific data fields (views, clicks, conversion rates). However, it lacks detail on the structure of the results (e.g., per experiment or aggregated) and does not clarify behavior for multiple experiments or missing data. 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 coverage is 100% with basic parameter descriptions. The description adds context about output fields (views, clicks, conversion rates) but does not elaborate on the parameters themselves, only restating their purpose. This meets the baseline but adds limited semantic value.

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 specifies the verb 'Get', the resource 'A/B experiment results for an EDS site', and includes specific data fields (variant views, clicks, conversion rates). It differentiates from sibling tools that deal with pages, redirects, or logs.

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

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

The description implies the tool is for retrieving A/B experiment results but provides no explicit guidance on when to use it over alternatives or any exclusions. There is no mention of prerequisite calls or comparison with similar tools.

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

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

No annotations are provided, so the description must convey behavior. It discloses that it reports state (created/running/stopped) and processed/failed counts, which is valuable. However, it does not mention potential error cases (e.g., job not found), whether it is read-only, or any side effects, leaving some behavioral gaps.

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

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

The description is two sentences, front-loaded with the core purpose, and every phrase adds value. No filler or redundant information, making it highly effective for quick comprehension.

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

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

Without an output schema, the description rightly includes what the tool reports (state and counts). It is complete enough for a 2-parameter status-check tool, though it could mention error behavior or polling semantics. Overall, it provides sufficient context for an agent to use the tool effectively.

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

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

The input schema already provides 100% coverage with meaningful descriptions for both parameters ('Job name returned by the bulk operation' and 'Job topic returned by the bulk operation'). The description modestly reinforces this by naming the originating tools, but it does not add substantial semantic meaning beyond the schema, hence the baseline score of 3.

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

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

The description uses a specific verb ('Check the progress') and clearly identifies the resource ('an asynchronous bulk job started by eds_bulk_preview or eds_bulk_publish'). It also distinguishes itself from sibling tools by focusing on bulk job status rather than page/config operations, making the purpose unambiguous.

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

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

The description clearly indicates when to use the tool: after starting a bulk job via eds_bulk_preview or eds_bulk_publish. It does not explicitly state when not to use it or name alternative tools, but the context is sufficient for an agent to recognize the appropriate invocation scenario.

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

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

No annotations are provided, so the description must fully inform the agent. It only states the tool 'shows recent preview, publish, and configuration actions', omitting details like whether it's read-only, authentication requirements, rate limits, or whether logs are persistent.

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

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

The description is a single, compact sentence that conveys essential information without fluff. Every word serves a purpose.

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

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

Given the simplicity (one optional parameter, no output schema), the description adequately states the purpose and content type. However, it lacks details on output format, ordering, or project scope, which could be helpful for a complete understanding.

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

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

The input schema covers 100% of parameters with a clear description for 'limit'. The tool description does not add any additional parameter semantics beyond what the schema already provides, meeting the baseline.

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

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

The description clearly states the verb 'Get' and the resource 'project activity log', and specifies the content includes 'recent preview, publish, and configuration actions'. This distinguishes it from sibling tools like eds_get_status or eds_get_cwv.

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 for viewing recent actions but provides no explicit instructions on when to use vs. alternatives, nor any prerequisites or exclusions. No guidance about retrieving logs for specific time ranges or filters.

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 provided, so the description bears full responsibility for behavioral disclosure. It only states it fetches metadata, omitting any details about permissions, rate limits, or response characteristics.

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

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

A single, clear sentence that efficiently conveys the tool's purpose without any wasted words.

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

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

For a parameterless tool with no output schema, the description provides the essential information (fetches metadata sheet with SEO and social meta values). However, it could be improved by noting the format (JSON) or typical use case.

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, and input schema coverage is 100% (trivially). The description adds meaning by specifying the content (SEO and social meta values) beyond the empty schema. Baseline for zero parameters is 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 clearly states the tool fetches a site-wide metadata sheet (metadata.json) containing SEO and social meta values. It uses a specific verb and resource, and is distinct from siblings like eds_get_config or eds_get_page.

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. With many sibling tools available, such as eds_get_config or eds_list_pages, users would benefit from explicit context on when to select this over others.

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

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

No annotations are provided, so the description carries full burden. It states a read operation ('fetch'), but does not disclose what happens if the path is invalid, authorization requirements, or whether there are any side effects. This is adequate but minimal.

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

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

The description is a single concise sentence (14 words) that front-loads the key action. No unnecessary words or redundancy.

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

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

Given the tool's simplicity (one required parameter, no output schema), the description covers the core purpose. However, it omits details about error responses, return format, or usage context, leaving gaps for the agent.

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

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

The input schema already provides a clear description for the 'path' parameter. The tool description adds context about the endpoint ('.plain.html'), which is useful but not parameter-specific. With 100% schema coverage, 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 clearly specifies the verb ('Fetch'), resource ('rendered HTML content of an EDS page'), and method ('via the .plain.html endpoint'). It effectively distinguishes this tool from siblings like eds_list_pages or eds_get_metadata, which serve different purposes.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., eds_get_metadata for non-HTML content). The purpose is implied but the agent must infer usage context from the name and description 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?

With no annotations, the description carries the full burden. It discloses that the operation is a non-destructive fetch and parse, and specifies the returned fields. However, it omits potential issues like authentication requirements or what happens if the spreadsheet is missing.

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 concise sentences with no wasted words. Structure is front-loaded with the action and follows with output details.

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

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

For a parameterless fetch tool, the description fully covers what the tool does and returns. No output schema exists, but the description specifies the fields, making it sufficiently 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?

The tool has zero parameters, so the description just needs to explain the function. It effectively does so by detailing what is fetched and returned, adding meaning beyond the empty 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?

Description clearly states the tool fetches and parses the site redirects spreadsheet, returning all redirect rules with source, destination, and type. It uniquely identifies its resource and output, distinguishing it from siblings like eds_get_404s or eds_get_sitemap.

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 use when redirect rules are needed, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling tools.

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

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

The description discloses the read-only nature (fetch and parse) and the return value. However, it lacks details on error handling, rate limits, or behavior if the sitemap is missing. Since no annotations are provided, the description carries the full burden but is minimally adequate.

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

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

The description is a single, well-structured sentence that immediately conveys the action and result. No extraneous information, front-loaded with the verb.

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

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

Given the simplicity (no parameters, no output schema), the description covers the core functionality. It could mention potential issues (e.g., missing sitemap) but is sufficient for the tool's straightforward nature.

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?

There are no parameters, and the schema coverage is 100%. The description does not need to add parameter information, meeting the baseline expectation for zero-parameter tools.

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

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

The description clearly states the tool fetches and parses the site sitemap.xml and returns URLs with last-modified dates. It distinguishes from sibling tools that focus on individual pages or other resources.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites or context for using the sitemap fetch.

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?

Describes a read operation without side effects, but lacks disclosure of any potential restrictions, rate limits, or authentication needs. Since no annotations are provided, the description bears full burden and is minimally adequate.

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?

Single sentence, front-loaded with essential information, no extraneous words. Highly 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 simple tool with one parameter and no output schema, the description sufficiently covers what the tool returns. However, it does not explain the meaning of 'preview, live, code-bus' status, which may be domain-specific but not critical.

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 one parameter described; the description adds little beyond what the parameter description already provides ('Resource path to check status for'). Baseline at 3.

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

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

Description clearly states verb 'Get', the resource 'preview, live, and code-bus status for an EDS resource', and includes specifics (URLs and modification timestamps). It distinguishes from sibling tools that focus on other actions like bulk preview or publishing.

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?

Implies usage when status information is needed, but no explicit guidance on when to use this tool vs alternatives among siblings (e.g., eds_get_page for page content). No exclusions or context provided.

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

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

No annotations are provided, so the description must carry the burden. It only mentions pagination, but does not disclose behavioral traits like default ordering, side effects, authentication requirements, or rate limits. It is minimal.

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

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

The description is a single, efficient sentence that is front-loaded and contains no unnecessary words.

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

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

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is reasonably complete. It could mention default ordering or that it returns all pages if no limit, but is adequate for a straightforward listing 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 coverage is 100% with descriptions for limit and offset. The description adds 'with pagination support' which contextualizes but does not add significant new semantics beyond the schema. Baseline 3.

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

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

The description clearly states it lists pages from the site query index with pagination support, using a specific verb and resource. It distinguishes from siblings like eds_get_page (single page) and eds_search_pages (search).

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 when you need to list pages with pagination, but it does not explicitly state when to use this tool vs alternatives (e.g., eds_search_pages) or any 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 provided, and description only mentions atomic operation. Missing details on error handling, prerequisites (e.g., page must exist in draft), permissions, or side effects (e.g., cache invalidation).

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 brief sentences with no redundancy, front-loading the key action and use case.

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 tool combining two operations without output schema, description lacks information on return value, success/failure indication, and preconditions. Incomplete for an AI to use reliably.

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 parameter description 'Page path to preview and publish (e.g., /about)'. Tool description adds context that path is for a page, but no additional semantic details beyond 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?

Description clearly states the tool previews and publishes a page atomically, and distinguishes from siblings like eds_preview_page and eds_publish_page by combining both operations into one.

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

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

The description says 'the most common EDS workflow,' implying primary use case, but does not explicitly state when to avoid this tool or use alternatives like eds_preview_page or eds_publish_page individually.

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

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

With no annotations, the description must disclose behavioral traits. It indicates a write operation ('trigger preview') but does not mention side effects, prerequisites, rate limits, or return values. The description is minimal but not misleading.

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 conveys the purpose and effect. It is front-loaded with the action. However, it could be restructured to emphasize when to use it. Very concise but lacks some detail.

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

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

The tool is simple (one required parameter, no output schema). The description covers the core action adequately. Missing details like error handling or success confirmation, but it is minimally complete for a straightforward task.

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 parameter 'path' is described in the schema (path relative to site root). The description repeats this link to the preview domain but adds no new semantics beyond the schema.

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

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

The description uses a specific verb ('Trigger preview') and resource ('EDS page'), and the domain pattern '*.aem.page' clarifies the scope. It distinguishes this tool from siblings like 'eds_bulk_preview' (multiple pages) and 'eds_preview_and_publish' (preview+ publish).

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 for triggering preview on a single page but does not explicitly state when to use this tool versus alternatives (e.g., bulk preview or preview-and-publish). No exclusions or conditions are mentioned.

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

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

The description indicates a state change from preview to live but does not disclose any side effects, permissions required, rate limits, or reversibility. With no annotations, the description should carry the full behavioral burden but falls short.

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

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

The description is a single sentence that conveys the essential information without any wasted words. It is well-structured for quick comprehension.

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

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

Given the tool's simplicity (1 param, no output schema), the description is minimally adequate. However, it lacks context about the preview-to-live flow and potential overwriting, which would help an agent decide to use this 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 coverage is 100% with a clear description of the 'path' parameter and an example. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the action (publish), the resource (EDS page), and the target domain (*.aem.live). It distinguishes this tool from siblings like eds_preview_page and eds_unpublish_page.

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

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

No guidance is provided on when to use this tool, prerequisites (e.g., page must be in preview), or when to choose alternatives like eds_preview_and_publish or eds_bulk_publish.

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

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

With no annotations provided, the description carries full burden. It communicates that the tool purges cache and triggers a fresh fetch, but does not disclose potential side effects (e.g., temporary performance impact) or authentication requirements. The behavior is minimally described.

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

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

The description is a single, well-formed sentence that starts with the action verb and includes the purpose immediately. No extraneous words or redundant 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the core functionality and parameter meaning adequately. It could mention that the purging is immediate or irreversible, but the lack is not severe.

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

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

Schema description coverage is 100% for the single 'path' parameter, and the tool description mentions 'EDS page path' as context. The baseline 3 is appropriate since the description adds little beyond what the schema already provides (the example '/about').

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 'Purge' and clearly identifies the resource as 'CDN cache for an EDS page path'. It is distinct from sibling tools like eds_publish_page or eds_preview_page, which deal with content staging rather than cache invalidation.

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 when stale cache is an issue, but does not explicitly state when to use or not use this tool versus alternatives. It lacks prerequisites or exclusions, which would improve guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that the search operates on a 'site query index' and covers specific fields, but does not explain read-only nature, result ordering, error conditions, or pagination behavior (though limit/offset exist in schema). This is 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?

The description is a single, front-loaded sentence that states the action, target, and search scope without unnecessary words. It is highly concise and easy to parse.

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

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

Given the moderate complexity (3 parameters, no output schema), the description is sufficient to understand the core function but does not describe the return format or result structure. It implies the result is a list of pages but omits details like fields, sort order, or how matches are ranked.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it merely echoes the fields searched, which are already documented in the query parameter. No additional semantics for limit/offset are provided.

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 ('Search'), identifies the resource ('pages'), and clearly distinguishes the scope ('across titles, descriptions, and paths in the site query index'). This makes it distinct from sibling tools like eds_list_pages, which likely lists all pages without a keyword filter.

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 for keyword-based search but does not explicitly state when to prefer it over alternatives like eds_list_pages or eds_get_page. No exclusions or alternative recommendations are provided, so the guidance is limited to the implied 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?

No annotations are provided, so the description must fully convey behavioral traits. It accurately states the primary consequence (page becomes non-public), but does not disclose potential side effects like whether the page is deleted from the system, if it remains as a draft, or if special permissions are required. Basic transparency is achieved.

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

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

The description is two concise sentences with no redundant information. It is front-loaded with the core action and its consequence.

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

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

Given the tool's simplicity (single required parameter, no output schema), the description adequately covers the essential information. However, it could be more complete by clarifying whether the page remains in a draft state or is permanently removed from the system.

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

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

The input schema has 100% coverage for the single parameter 'path', including an example. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's specific action ('Remove an EDS page from the live production site') and the effect ('no longer be publicly accessible'), using a precise verb and resource. It is easily distinguishable from sibling tools like eds_publish_page or eds_preview_page.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as unpublishing versus deleting a page, or prerequisites like needing the page to be previously published. It lacks explicit context or exclusions.

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