pSEO Engine

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

Annotations already include readOnlyHint=false, idempotentHint=false, but the description adds critical context: it is ASYNCHRONOUS, returns a jobId, records findings, and costs 30c per call. It also explicitly limits scope to reporting only, which is beyond the annotations and informs the agent's expectations.

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

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

Three sentences with no redundancy. The first sentence front-loads the action and scope, the second gives the async pattern and follow-up step, and the third clarifies reporting-only and cost. 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 an async tool with an output schema, the description covers what it does, the defect types it finds, the async pattern and polling target, cost, and non-fixing behavior. Nothing essential is missing for correct invocation.

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

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

Schema coverage is 100% and the projectId parameter description is already extremely detailed (explaining what it is, how to get it, and that it's not a slug or name). The tool description adds no parameter-specific information, so a baseline of 3 is appropriate since schema does the heavy lifting.

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

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

States a specific verb (scans all generated pages) and resource (all generated pages), listing concrete defect types (broken text, unfilled placeholders, truncated copy, missing images). Clearly distinguishes from siblings like seo_content_generate and seo_publish by focusing on auditing and explicitly stating it only reports problems.

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 instructs to poll seo_job_status after receiving a jobId, giving a clear follow-up pattern. Clarifies that it does not fix issues, so the agent knows not to expect repairs. Does not explicitly state when to avoid using it or compare to alternative audit tools, but the async usage pattern is well defined.

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

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

Annotations only declare readOnlyHint=false and idempotentHint=false, leaving behavioral disclosure to the description. The description adds critical facts: cost ('spends real AI budget per generated page', 'Costs 75c per call'), asynchronous return ('Returns a jobId immediately'), and the lifecycle ('NOT live until approved and published'). No contradiction with annotations.

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

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

Each sentence carries operational value: async marker, queue scope, cost, prerequisite, return contract, and final status. The cost is mentioned twice in different units (per page vs per call), which is mild redundancy but not harmful. Well structured and front-loaded.

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

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

For a queue-starting, cost-bearing, asynchronous mutation, the description covers all required context: what it does, prerequisite check, return contract, follow-up polling, and resulting page status. The output schema exists to document the jobId shape, and the description explicitly references it. 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 covers the sole parameter at 100% and explains it in detail (cuid, not slug/display name, call seo_project_list if missing). The main description adds no additional parameter semantics beyond the schema, so the baseline 3 applies as the schema carries the full burden.

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

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

The description states a specific verb ('starts'), resource ('content-generation queue'), and scope ('every PENDING row in the project'). The leading 'ASYNCHRONOUS' and the mention of 'jobId' differentiate it from synchronous tools, and the sibling 'start' tools (seo_audit_start, seo_research_start) are clearly distinct by naming the generation queue.

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 explicit prerequisites: 'Requires the project to be configured (check readyToGenerate via seo_project_get first)' and describes the follow-up: 'poll seo_job_status'. This tells the agent when it is safe to call and what to do after, but it does not explicitly name alternatives when the project is not configured or when only a subset of rows is desired. Clear context without an explicit exclusion.

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

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description's additional details about being FREE and the refusal behavior when re-calling start during RUNNING add genuine context beyond the structured fields. It does not contradict any annotation. A 4 reflects that it is highly transparent but doesn't describe every edge case.

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: the return value, the polling guidance, and the cost/refusal warning. Each sentence earns its place, the most important information is front-loaded, and there is zero 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 status-check tool, the description covers return fields, polling cadence, a critical guardrail, and cost. The output schema exists to document the response format. Nothing an agent needs to call it correctly is missing.

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

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

The input schema provides a thorough description of projectId, including format, examples, and guidance to call seo_project_list if needed. Since schema coverage is 100%, the description itself adds no additional parameter semantics. Baseline 3 is appropriate because the schema carries the full burden.

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

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

The description clearly states the verb 'Returns' and the specific resource 'the most recent background job for a project', then enumerates the returned fields (type, status, progress counters, last log line). It implicitly distinguishes itself from sibling start tools (seo_audit_start, seo_content_generate, etc.) by describing a polling operation rather than a job initiation.

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 tells the agent when to use this tool ('Poll this every few seconds after any tool that starts a job') and provides a critical negative instruction ('Do NOT re-call the start tool while status is RUNNING'). It also clarifies the consequence (refusal), leaving no ambiguity about the correct invocation pattern.

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 key behaviors beyond the annotations: keys are stored encrypted and can never be read back, only replaced or cleared; tokens bill the caller's provider account (BYOK); and the call is free. These are substantive behavioral traits that the annotations (readOnlyHint, idempotentHint, destructiveHint) do not capture.

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—three sentences—and front-loads the core purpose before layering billing, key recommendation, and security context. Each sentence adds a distinct piece of information with minimal filler, though the 'FREE' note is slightly redundant with the BYOK billing point.

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

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

With seven parameters, an output schema, and these annotations, the description still covers the essential context: purpose, recommended key type, optional Perplexity key, encryption/no-read-back, and cost. It omits error/edge-case behavior, but the rich input/output schemas cover remaining details, making this adequate for an agent to call correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds high-level context (BYOK, encrypted storage, what the keys power) but does not detail individual parameter semantics beyond the schema. Those details are already well covered in the input schema, so no additional credit is warranted.

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 ('Stores') and a precise resource (the AI provider key that a project's generation, audits, and research run on), and the title makes the connect-or-replace function explicit. The optional Perplexity key adds a second distinct purpose (citation-bearing visibility checks), which clearly separates it from the sibling action tools.

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

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

The description gives actionable usage context: it recommends a Google Gemini API key, notes the free tier needs no card, and specifies when the optional Perplexity key is needed (citation-bearing AI visibility checks). It does not explicitly name alternatives or state when not to use it, but the purpose is so distinct from the siblings that the context is clear.

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

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

Annotations only say readOnlyHint=false, idempotentHint=false, destructiveHint=false, leaving the safety profile mostly inferred. The description adds genuinely valuable behavior beyond that: the project is 'created EMPTY' and still needs a data source and content spec before seo_content_generate runs, the agent should fetch readinessNote afterward, and 'FREE — this call costs nothing' discloses billing behavior the annotations never cover. No contradiction with annotations.

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

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

Four sentences, each earning its place: what it does, when to call it, what state it leaves the project in and the follow-up step, and cost. The core purpose is front-loaded in the first clause, and no sentence repeats schema or annotation content. Dense but not bloated.

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

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

For a 7-parameter creation tool with a 100%-documented schema list hubs and an output schema present, the description covers the non-obvious operational context: empty-list trigger, projectId dependency of sibling tools, empty creation state, readinessNote follow-up, and cost. An agent has everything needed to decide whether and how to invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. All seven parameters already carry rich descriptions in the schema (e.g., 'BYOK: the AI provider key... stored encrypted'). The description adds context about the projectId output and empty-state lifecycle but does not enhance meaning of any individual parameter, which is acceptable given the schema bears that burden.

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

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

States a specific verb and resource ('Creates a new programmatic-SEO project') and names the concrete outcome ('returns its projectId'). The sentence 'every other tool needs a projectId and a new account has none' differentiates it from the sibling toolset by positioning it as the entry-point creation operation. No ambiguity with nearby siblings like seo_project_connect_ai or seo_project_get.

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

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

Gives an explicit trigger condition: 'Call this when seo_project_list comes back empty.' It also explains the rationale ('every other tool needs a projectId') and prescribes the follow-up sequence ('call seo_project_get afterwards and read readinessNote'). It stops short of an explicit when-not-to-use statement or naming alternatives, but the context is clear enough for an agent to route correctly.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't repeat those. It adds new behavioral context: the readiness criteria (needs both a field mapping and a content spec) and the cost ('FREE — this call costs nothing'). No contradiction with annotations.

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

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

Two sentences, zero filler. The primary purpose is front-loaded, followed by a usage directive, then the cost note. Every word earns its place; there is no redundancy with the schema.

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

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

The tool is a simple read-only getter with a single parameter and an output schema. The description covers purpose, when to call it, and cost. There is nothing an agent needs to invoke it correctly that is missing.

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

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

Schema coverage is 100% and the parameter already has a rich description (cuid format, exact source from seo_project_list, and explicit disambiguation from slug/name). The tool description adds no additional parameter guidance, so it stays at the 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?

States a specific verb ('Returns'), a clear resource ('one project's settings') and an explicit condition ('whether it is configured enough to generate content'). It also names the sibling it is not (seo_content_generate) and explains why the readiness check matters, so an agent can instantly distinguish it from related tools.

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

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

Explicitly instructs when to use the tool: 'Use this before seo_content_generate to avoid starting a run that will immediately fail.' This gives a concrete workflow position and a decision rule. It also notes the call is free, which is a practical selection factor.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description rightly does not repeat it. It adds genuine extra context: the cost behavior ('FREE — this call costs nothing') and the scope constraint that ids are account-specific and cannot be guessed. No contradiction with annotations.

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

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

Three sentences, each earning its place: purpose+output, usage-ordering rule, and cost note. The core purpose is front-loaded in the first sentence. The 'FREE' note is a minor addition but is genuinely useful behavioral information rather than padding.

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

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

For a parameterless list tool with a full output schema and safety annotations, the description covers everything an agent needs: what is returned, that it must be called first, that ids come from here, and that it costs nothing. Nothing material is missing.

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

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

The tool has zero parameters, so the baseline is 4 and there is nothing to document beyond it. The description does mention the output fields (id, name, slug, custom domain, page count), which adds value for interpreting the result even though it is arguably output-schema territory.

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

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

States a specific verb ('Lists') and resource ('every programmatic-SEO project this API key can act on'), plus enumerates the returned fields (id, name, slug, custom domain, page count). The scope qualifier 'can act on' and the collection semantics clearly distinguish it from seo_project_get (single project) and seo_project_create (creation) among siblings.

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

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

Provides explicit, imperative routing: 'Call this FIRST in any session — every other tool needs a projectId from here.' It also states the negative case — ids cannot be guessed or carried over from another account — which tells the agent why this tool is mandatory rather than optional. This is exemplary usage guidance.

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

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

Annotations indicate this is a write operation (readOnlyHint=false), non-destructive, idempotent, and open-world. The description adds critical behavioral details beyond these: the call is synchronous, costs 15c per call, skips GENERATED drafts due to a human approval gate, and reports skip counts. No contradiction with annotations.

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

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

The description is compact yet information-dense. It front-loads the synchronous nature, then covers the key behavior (status filtering), the rationale, the response interpretation, and the cost. Every sentence adds value 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?

Given the presence of an output schema, the description does not need to explain return values. It covers all essential context for an agent to call the tool correctly: the status gate, the skip behavior, cost, and diagnostic guidance. No significant gaps for a single-parameter tool with a well-documented 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 already provides 100% coverage of the single parameter (projectId), including its exact source (seo_project_list) and the caution against using slug/display name. The description does not add additional meaning about the parameter itself, 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 function: publishing approved pages ('takes approved pages live'). It distinguishes itself from content generation by explicitly noting that GENERATED drafts are skipped, which differentiates it from sibling seo_content_generate. The verb 'takes' is slightly informal but the resource and action are unambiguous.

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

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

The description provides explicit conditions for use: only rows in REVIEWED status are published, and GENERATED drafts are skipped. It also explains how to interpret the response (if publishedCount is 0 and skippedNeedsReview is high, approval is needed first). This gives clear guidance on when to call the tool and what to expect.

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

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

The description goes well beyond the annotations by disclosing that the tool returns immediately with a jobId but keywords do not yet exist, spends real AI budget, costs 750c, fails when another run is in progress, and has human/trial account restrictions. These behavioral traits are not implied by readOnlyHint, openWorldHint, idempotentHint, or destructiveHint.

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 longer than average but every sentence carries operational weight: async behavior, budget, polling, immediate return semantics, concurrency failure, trial account rules, and cost. It is front-loaded with the most critical fact ('ASYNCHRONOUS') and proceeds logically from invocation to completion behavior to edge cases.

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

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

For an async, cost-incurring start-tool with an output schema, the description covers everything needed to call it correctly: polling workflow, jobId return, non-existence of results on return, failure modes, retry guidance, and cost. The existing output schema and annotations cover the remaining structured details.

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 description itself does not add parameter-specific semantics, but schema description coverage is 100% and the schema already provides rich detail: examples, exact source instructions like 'exactly as returned by seo_project_list', and numeric constraints. Baseline 3 is appropriate because the description does not need to compensate for schema gaps.

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 'ASYNCHRONOUS' and states a specific action and resource: 'Starts a keyword-research run that mines and qualifies keywords into PENDING rows.' This clearly distinguishes it from async siblings like seo_audit_start and seo_content_generate by naming the resource type and its output state.

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

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

It gives explicit operational guidance: 'call it once and then poll seo_job_status until status is COMPLETED.' It also warns against retrying by telling the agent to 'stop and report instead of retrying' on card_required, and documents the in-progress failure condition.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive; the description adds the cost of 3c per call, which is not present in the annotations, and clarifies that content bodies are excluded. It also explains status semantics and the risk sort behavior, all beyond structured fields. No contradiction with annotations.

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

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

The description is three sentences, front-loads the core function, and each sentence adds distinct value – outcome, status semantics, exclusion of content, the risk-sort workflow, and cost. No filler or repetition; structure is 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?

For a read-only listing tool with an output schema and full parameter descriptions, the description is remarkably complete: it covers cost, status domain, sort behavior, and what is not returned. It even gives a practical review workflow. No important operational aspect an agent needs is left unexplained.

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 four parameters are already described in the schema (100% coverage), so the baseline is 3. The description adds meaning by interpreting the status enum values ('PENDING (no content yet), GENERATING, GENERATED (draft)...') and by explaining the purpose of sort:'risk' as a review queue. This goes beyond the schema's bare enum listing.

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 'Returns a page of rows (individual generated pages) with slug, target keyword and status', naming the specific resource and output fields. It further distinguishes itself from an export by saying 'Content bodies are NOT included — this is a listing, not an export.' This clearly differentiates it from sibling tools like seo_content_generate or seo_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 gives concrete guidance for its main niche: 'Use sort:''risk'' to get the review queue ordered by risk score... so a human reviews the riskiest pages before bulk-approving the safe ones.' It also states what it does not do ('not an export'), but it never names a specific alternative tool for content export or other actions, so the routing is clear but not exhaustive.

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