Mike Fluff

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

Goes well beyond the annotations (which only give readOnly=false, destructive=false, openWorld=true, idempotent=false). The description discloses the full side-effect chain (calendar event, confirmation email with invite, Mike alerted, lead recorded), the OAuth scope 'mikefluff:booking' plus the 401-with-sign-in failure mode, rate limits (3/hour per caller, 2 upcoming per email), and the cancel/reschedule link. This is unusually rich behavioral context for a mutation tool.

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

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

Front-loaded with 'SIDE EFFECT:' so the most consequential fact lands first, and nearly every clause carries distinct operational information (effects, auth, limits, cancel path). It is one dense block rather than scannable chunks, but very little is padding.

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

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

For a 7-parameter, non-idempotent, open-world write tool with no output schema, the description covers the prerequisites (explicit user intent, valid slot), authentication, side effects, limits, and how the user can undo the booking. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns more: it explains that name/email default to the signed-in INITE ID account when omitted, constrains slot to exact get_booking_slots values, and gives real meaning to the topic enum (diagnostic, automation, compliance, architect-mode) that the schema only labels 'What the call is about'. Only locale and timeZone get no extra detail from the prose.

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

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

States a specific verb and resource with concrete scope: 'books a real 30-minute video call in Mike Fluff's calendar'. It also distinguishes itself from the get_booking_slots sibling by declaring that slot values must come from that tool, so an agent can route correctly 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?

Explicit gate: 'Only call this when the user has explicitly asked to book and chosen the time.' It names the upstream dependency for valid slot values and enumerates the four topical variants, covering when-to-use and what to confirm before calling.

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?

Far exceeds the annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). It discloses the OAuth scope required, the HTTP 401 unauthenticated path, wallet auto-charge vs. one-time link vs. card/PIX fallback, agent self-purchase via x402 wallet, and the money-spend side effect up front.

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?

Long but front-loaded: the critical 'SIDE EFFECT, MAY SPEND MONEY' warning leads, and each subsequent sentence carries distinct behavioral information (auth, payment paths, agent flow) rather than filler. Slightly dense but no wasted sentences.

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

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

With no output schema, the description fully carries the return-behavior burden: it explains the payment link, the pay-now vs. recurring options, the already-owned message, and the agent wallet flow. 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?

Schema description coverage is 100%, so the schema already documents book, email, and locale, including the locale's currency implication. The description adds little parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

Opens with a specific verb and resource ('buys a Mike Fluff Press book') and immediately flags the side effect. The scope (the signed-in person's account) is stated, so an agent can distinguish this from buy_course and the read-oriented siblings without inspecting schemas.

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

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

Ends with an explicit invocation condition: 'Only call when the user has asked to buy this book,' and notes that owning the book already produces a different result. It does not name the nearest alternative (buy_course) for routing, 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?

Far exceeds the annotations, which only say non-read-only/open-world/non-idempotent. The description discloses the OAuth scope 'mikefluff:purchase', the 401-without-token behavior and that the client signs the person in, the three distinct payment paths, the returned x402Url and the wallet pay tool, and the money-spending side effect. This is the operational detail an agent needs before committing a purchase.

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

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

Front-loaded with the most important fact ('SIDE EFFECT, MAY SPEND MONEY'), and the parentheticals are dense rather than padded. It runs long as a single paragraph though, and the payment-path detail could be split for scannability, which keeps it just short of a 5.

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

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

For a 4-param mutation tool with no output schema and an open-world, money-spending operation, the description covers auth, entitlements, id sourcing, payment fallbacks, and the post-purchase reading path. Nothing material for a correct call is left unstated.

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

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

Schema coverage is 100% and every property already carries a description with enums and examples, so the schema does the heavy lifting. The description only restates where ids come from ('Get chapter ids from list_books'), which duplicates the schema's own wording rather than adding format, range, or default semantics. 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?

Opens with an unambiguous verb+resource ('buys one paid chapter of a Mike Fluff Press book, on its own') and immediately separates it from buy_book by scoping to a single chapter. The phrase 'on its own' plus the sibling name buy_book lets an agent distinguish the two purchase tools without opening either schema.

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

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

Explicitly states the trigger ('Only call when the user has asked to buy this chapter') and a when-not condition ('Owning the book already includes every chapter'), plus where to get ids (list_books). It even routes reading to the sibling get_chapter_preview, which is exactly the alternative an agent might otherwise confuse with a purchase.

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

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

Goes well beyond the annotations: discloses that nothing is charged until the user pays on the hosted page, that the link works without signing in, that access is emailed post-payment, and that OAuth scope 'mikefluff:purchase' is needed to attach the course to an account. This is exactly the kind of side-effect/auth detail annotations cannot carry.

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

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

Front-loads 'SIDE EFFECT:' so the mutation is visible immediately, and every sentence carries unique information. It is dense and runs long as one paragraph, but no sentence is filler.

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

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

With no output schema, the description still specifies what is returned (payment link plus locale price) and what happens afterward, so an agent has everything needed to call and hand off 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% (baseline 3), but the description adds real meaning: email omission falls back to the signed-in account, locale determines currency, and the human-readable course names are mapped to their slugs.

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

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

States a specific verb+resource ('opens a checkout for one of Mike Fluff's paid courses'), names the side effect of lead creation, and enumerates the exact course keys/slugs so it is distinguishable from siblings like buy_book.

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

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

Explicit gating condition ('Only call when the user has asked to buy and given the email'), an explicit alternative path (omit email to use the signed-in account), and an explicit prohibition ('Give the user the payment link; do not try to pay').

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/idempotent/non-destructive/closed-world, and the description still adds real behavioral context: the text is not stored, the exact tiers returned, the hard-ban gate, and the language and length limits. That is substantial disclosure beyond the structured fields.

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

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

Front-loads the purpose before the output details, and every clause carries information. It is long and parenthetical, but the length is justified by enumerating the return shape 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?

With no output schema, the description carries the burden of describing returns and does so fully: verdict tiers, gate result, and per-hit fields. An agent knows what it gets back and what inputs are valid.

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

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

Schema description coverage is 100% and the schema already documents both params including the enum. The description's 'English and Russian only' and 'up to 20000 characters' simply restate the enum and maxLength rather than adding syntax or format meaning.

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 ('run the writer linter ... on a text') and spells out the concrete output artifacts (density verdict, pass/fail gate, per-hit line/column/category). It is unmistakably distinct from every sibling, which are all book/call/answer 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?

Gives clear conditions for use: English and Russian only, up to 20000 characters, judges the text rather than the author. It does not name an alternative tool or an explicit when-not-to-use, but with no relevant sibling there is nothing to route against.

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/idempotentHint/destructiveHint=false, so the description's 'Read-only' is largely redundant. It does add real value by disclosing the response composition (sections, FAQ, cited chapters/experiments, related answers, canonical URLs), which no output schema provides.

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 leads with the action and resource, then lists the returned content. No filler 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?

With no output schema, the description compensates by describing the return shape in detail, and it supplies the usage context and prerequisite source for the id. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so both parameters (id, locale) are already fully documented with pattern, length, and enum. The description adds no extra semantics about id format or locale behavior; 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 ('Fetch one published answer by its id') and enumerates the payload (direct answer, sections, FAQ, chapters, experiments, related answers, canonical URLs), which clearly distinguishes it from search_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?

Explicitly names the alternative and the selecting condition: 'Use after search_answers when the lead answer is not enough.' The id source is also given ('from search_answers'), so an agent knows how to obtain the required argument.

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/idempotentHint/destructiveHint=false, so safety is covered structurally. The description adds real context beyond them: slot granularity (30 minutes), the UTC/ISO 8601 encoding of results, and the hard contract that returned values must be passed verbatim to book_call.

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

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

Three compact sentences, each earning its place: what it returns, how the output is formatted, how to use it downstream. The essential 'what' is front-loaded with no filler.

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

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

No output schema exists, but the description compensates by specifying the result format (ISO 8601 UTC start times) and the downstream consumption contract. Combined with the fully documented input schema and safety annotations, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so days, from, and locale are already documented with defaults and bounds in the schema. The description adds nothing parameter-specific beyond confirming the return format, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the open 30-minute slots for a free video call with Mike Fluff') and even scopes the subject matter (business diagnosis, AI automation, compliance, Architect Mode). An agent can immediately distinguish this from book_call or any other sibling.

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

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

Explicit sequencing guidance: 'Use before book_call; pass one of these exact values as its "slot"' tells the agent when to call and how the result feeds the next tool — unusually strong routing. It lacks an explicit when-not condition (e.g., skip if a slot is already known), so it falls just short of 5.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavior those hints cannot express: content is conditionally truncated to roughly a fifth for non-owners, ownership of the book or a purchased chapter unlocks the whole text, and the paid price is surfaced in the preview response. This is exactly the kind of conditional-output disclosure an agent needs before calling.

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 tightly packed sentences, front-loaded with the outcome and followed by the branching rules; nothing is padding. The trailing 'Read-only.' restates what the annotations already say and is the one line that does not earn 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?

With no output schema, the description carries the return-value burden and does so: full text for free/owned chapters, public lead-in plus standalone price otherwise. Combined with the schema-covered inputs, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so the three parameters are already documented by the schema; the description adds the sourcing hint that book slugs and chapter ids come from list_books. Minor confusion: 'the call carries its token' implies a token input that does not appear in the schema, leaving the agent to guess how entitlement is transmitted.

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?

Starts with a specific verb+resource ('Return the text of one chapter') and immediately scopes it by entitlement (free = full, paid = lead-in unless owned). It names the related siblings list_books and buy_chapter, so an agent can tell what this tool is and is not 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 clear context for when the full text comes back versus a truncated lead-in, and routes the agent to list_books for slugs and chapter ids and to buy_chapter for ownership. It stops short of an explicit 'do not use this for X' exclusion, but the entitlement conditions effectively define the branch points.

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/idempotentHint/openWorldHint, so the trailing 'Read-only' is largely redundant. However, with no output schema the description usefully discloses the shape of the response, including that the table of contents marks which chapters are free to read.

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: the payload is front-loaded, followed by usage routing and a safety tag. No filler, and the most decision-relevant information comes first.

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

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

For a single-parameter read tool with no output schema, the description covers what is returned, when to call it, and its read-only nature. Nothing an agent needs to select or invoke it correctly is missing.

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

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

Schema coverage is 100% and the single locale parameter is fully documented with its enum in the schema, so the baseline is 3. The description adds nothing about locale or how it affects the result.

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

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

States a specific verb and resource (list the books) and enumerates exactly what is returned: title, subtitle, synopsis, status, canonical page URL and TOC. It scopes the corpus to Mike Fluff Press, which separates it from course/answer siblings without opening a schema.

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

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

Gives concrete when-to-use cases (answering 'what has Mike Fluff written', and calling it before get_chapter_preview), naming a sibling in sequence. No explicit exclusions or 'when not to use', 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description reinforces this with 'Read-only: nothing is stored or mailed.' It goes further by disclosing the two-phase questionnaire workflow and that the cost estimate is derived only from the user's own answers, which is meaningful behavior beyond the annotations.

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

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

The description is a single dense paragraph, but it is front-loaded with the identity of the diagnostic followed by the call procedure. Nearly every clause carries information, with only mild redundancy between the output description and the schema's own answers note.

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

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

With no output schema, the description carries the return-value burden and does so: named condition, severity, cost estimate, and recommended next step with URL. Combined with the explicit two-call flow and the nested answers format, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: answers={} returns the questionnaire rather than a result, and the value is questionId→optionId with an array for multiple-choice questions. It also notes that locale controls the language of the result.

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

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

The description names a specific resource (the mikefluff.com ten-question business diagnostic) and states exactly what it returns: one of five named operational conditions, a severity, a cost estimate, and a next-step URL. It is unmistakably distinct from siblings like book_call, get_answer, or list_books.

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 an explicit operating procedure: call with answers={} to fetch the questionnaire (question ids, option ids, conditionals), ask the user, then call again with {questionId: optionId}. That is clear when-to-use guidance, though it does not name any alternative tool or a when-not-to-use 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 declare readOnlyHint, idempotentHint, openWorldHint=false, so the safety profile is covered; the description reinforces it with "Read-only." More usefully, it discloses the result cap ("up to 8 hits") and the exact return fields including a quotable 40-60 word lead answer, which is real behavioral detail absent from any structured field.

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

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

Purpose and routing instruction are front-loaded, and the return-value sentence earns its place since there is no output schema. The parenthetical example questions add length but also make the topical scope concrete, so the size is justifiable rather than padded.

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

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

With no output schema, the description compensates by describing the hit count and each returned field, and it covers the activation condition and read-only nature. Nothing an agent needs to select or call this tool is missing.

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

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

Schema description coverage is 100% (query is described as a question or keywords in any of four languages; locale is enumerated with a default), so the schema carries the parameter burden. The description adds only topical scope, not format or syntax guidance beyond what the schema already says.

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

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

States a specific verb (search) plus the exact resource (Mike Fluff Press answers and book experiments) and even scopes the topical domain with concrete example queries. The agent can distinguish this from get_answer (single lookup) and check_text without opening either schema.

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

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

"Use this first whenever the user asks a factual question these books cover" gives a clear triggering condition and a routing priority, which is strong guidance. It stops short of naming the alternative sibling (get_answer) or stating when not to use it, so it is not a full when/when-not treatment.

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