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

With no annotations, the description carries the full burden and does useful work: it discloses the completed-state payload (outputManifest, coverUrl, time-limited download URLs) and a polling cadence. It does not describe non-completed states, failure/error behavior, or how long the job typically takes, so some lifecycle context 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?

Three tight sentences with zero filler; the purpose leads and the polling guidance closes. 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?

There is no output schema, so the description must characterize returns, and it does explain what appears on completion. It leaves the pending/failed response shape and retry semantics unspecified, which is a modest gap for a no-output-schema 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% and the jobId description already ties it back to teneo_generate_book. The description adds no format or sourcing detail for the parameter beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Check a book generation job') and is clearly the polling companion to teneo_generate_book. An agent can distinguish it from the generation and evaluation siblings without opening the schema.

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

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

Gives explicit operational guidance ('Poll every ~30-60s'), which is exactly the context needed for a status-checking tool. It does not name alternatives or state when not to call it, but with no competing status sibling that omission is minor.

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 disclose the informational domains it returns (auth, credits/pricing, field shapes, output shape), which hints at a read-only discovery operation. It does not state that the call is free, side-effect-free, or how large the response is, leaving the safety profile to inference.

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

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

Two short sentences, front-loaded with the value proposition and ending with the routing cue. Every clause enumerates distinct content the agent will receive; nothing is wasted.

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

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

For a zero-parameter, no-annotation discovery tool with no output schema, the description tells the agent what information it will obtain and when to call it, which is enough to act. It could be slightly stronger by noting the return is static documentation rather than generated 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?

The schema has zero parameters, so there is nothing to mis-document and the baseline of 4 applies. The description correctly implies no input is needed to retrieve the capability overview.

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 ('Discover') and enumerates exactly what the tool covers: auth, pricing (credits), request fields, workflow, use cases, and output shape. This clearly separates it from siblings like teneo_generate_book or teneo_research_niche, which perform work rather than describe capability, though it never says outright that it returns static documentation.

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?

'Call this first if unsure' gives explicit, actionable routing guidance for an agent entering this tool family. It lacks a when-not-to-use clause (e.g., skip it once you know the workflow), so it stops short of the top band.

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 hints that the book must already exist ('existing generated book'), but omits whether the operation is read-only or mutating, what forceRestart and evaluationMode do, whether it is long-running, and any auth or rate-limit context.

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

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

One front-loaded sentence with no filler; the action and target are immediately clear. It is arguably too terse for the tool's complexity, but the sentence itself is structurally efficient.

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

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

Given four parameters, an enum, no annotations, no output schema, and 0% schema coverage, the one-sentence description leaves critical invocation context missing. It states the basic action but not return behavior, mode differences, or restart semantics.

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 0% for all four parameters, and the description adds no meaning for fullBookId, forceRestart, evaluationMode, or rewriteVersion. With no compensation for the coverage gap, an agent must guess from parameter names alone.

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

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

States a specific verb ('Run a Teneo evaluation') and resource ('existing generated book'), which separates it from generation and research siblings like teneo_generate_book and teneo_research_niche. However, it does not name a sibling alternative or explain what a Teneo evaluation actually covers, so it stops short of a 5.

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

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

Provides no when-to-use guidance, no prerequisites, and no exclusions. It never mentions related siblings such as teneo_book_status or explains when evaluation is preferable to other steps.

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 so: it discloses asynchronous execution, an immediate jobId return, an expected ~45 min completion, the required polling step, and that the operation is charged in credits to the funded account. The schema separately surfaces idempotency for retry-safety.

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

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

Three tight sentences, front-loaded with the core action and deliverables, then the async/billing mechanics, then the usage boundary. Every clause earns its place with no filler.

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

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

For an async tool with no output schema or annotations, it covers the essential workflow: what it returns, how long it takes, the next step, and cost model. It could say a bit more about the three undocumented parameters, but an agent has enough 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 description coverage is 63%, so several params (author_name, output_formats, number_of_chapters) are undocumented in both places. The description names the overall input concept ('topic/spec') but adds no per-parameter semantics, making it a minimum-viable baseline rather than compensating for the 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?

States a specific verb (Generate) and resource (COMPLETE, publish-ready non-fiction book) and enumerates the deliverables (manuscript + cover + PDF/EPUB/DOCX). It distinguishes itself from siblings by naming teneo_book_status as the follow-up and explicitly excluding fiction/short answers.

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

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

Gives explicit when-to-use (finished book/manuscript, KDP-ready files) and when-not (not a short answer, not fiction), and routes the agent to teneo_book_status for polling. Nothing is left to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses a real behavioral trait the schema cannot express: the call charges the account cover-generation credits. However, it says nothing about whether generation is synchronous, how long it takes, whether the provider choice changes cost or quality, or what happens on failure.

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

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

Two short sentences, front-loaded with the action and followed by the cost caveat; nothing is padded. The phrasing 'only' is slightly ambiguous but costs almost no length.

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

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

For a six-parameter generative tool with no annotations, no output schema, and no parameter documentation, this description is far too thin. The billing note is the one genuinely helpful addition; an agent still lacks any basis for choosing a provider or supplying mood/style/theme values.

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 0% across six parameters (mood, style, theme, title, author, provider), and the description adds no meaning for any of them. The enum on 'provider' is completely unexplained, and the required 'title' is not distinguished from the optional descriptive fields.

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

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

States a specific verb and resource ('Generate a book cover'), which is unambiguous on its own. The trailing 'only' weakly signals it does not generate anything beyond the cover, hinting at a boundary with the sibling teneo_generate_book, but the sibling is never named and the contrast is left implicit.

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

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

There is no guidance on when to pick this over teneo_generate_book or teneo_generate_outline, nor any prerequisites or ordering advice. The word 'only' gestures at scope but does not tell the agent what condition should route it here.

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 usefully discloses scope — this is a lightweight, candidate-producing operation that skips the full book pipeline — but says nothing about whether the outline is persisted, what permissions are needed, or what the output looks like. Partial behavioral context only.

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

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

A single tight sentence with the core action front-loaded and the differentiator clause at the end. Efficient, though arguably too sparse given the missing behavioral and parameter 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?

For a 4-parameter generation tool with no annotations and no output schema, the description is minimally adequate. It explains what is produced at a high level but not what a 'candidate outline' contains or how it is returned, leaving the agent to guess about the result.

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 75%, near the high-coverage baseline, so the schema already documents title, description, target_audience, and chapter count. The description adds no parameter-level detail (e.g., constraints on number_of_chapters or how the four inputs shape the outline), so it neither compensates for the gap nor adds 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?

States a specific verb ('Generate') and resource ('an outline candidate for a nonfiction book'), and differentiates itself from the sibling teneo_generate_book by clarifying it works 'without running the full book pipeline.' This gives an agent enough to distinguish it from the full-book generator, though it doesn't contrast with other siblings like teneo_research_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?

Usage is implied rather than stated: an agent can infer it should use this when it wants an outline but not a full book. However, no alternatives are named explicitly and no when-not conditions are given, leaving selection to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Start a ... job' weakly implies an async, long-running operation, but nothing is said about whether results are returned immediately, how long it takes, whether runs can be duplicated or cancelled, or what permissions are 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 single sentence is front-loaded with the verb and resource and contains no filler. However, it is so terse that 'conciseness' shades into under-specification rather than efficient structure.

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

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

With no output schema, no annotations, and four undocumented parameters, the one-line description is not sufficient for an agent to invoke this tool confidently. It would need at least parameter meaning and the async/job lifecycle spelled out.

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

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

Schema coverage is 0% for four parameters. The description maps 'topic' to the seed topic but leaves 'count' (1-50), 'audience', and 'category' completely undefined in both schema and prose, so it fails to compensate for the coverage gap.

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

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

The description names a specific verb ('Start') and resource ('niche research job') plus the trigger input ('seed topic'), which is enough to distinguish it from the book-generation siblings. It stops short of explicitly contrasting itself with any sibling tool, so it does not reach a 5.

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

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

There is no guidance on when to use this versus the book-oriented siblings (outline, cover, evaluate) or on what to do after starting the job. The word 'Start' implies an asynchronous job, but no follow-up tool (e.g. a status check) is named.

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