Biohacking Kompakt

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world). The description adds substantive interpretive context the annotations cannot: the axes measure knowledge state rather than substance, that high human evidence with direction 'negative' is not 'bad', and the meaning of the hype-distance scale. That is real added value beyond 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?

Purpose and examples are front-loaded, and the axis/hype-distance semantics are compactly explained in two short sentences. It is slightly dense in the closing lines but every sentence carries information an agent needs to interpret the result.

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

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

An output schema exists, yet the description still previews the returned fields and the side-by-side table, and explains how to read the axes. Combined with full schema coverage and annotations, nothing an agent needs to call or interpret 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%, so the schema already documents both ids and response_format (including the markdown/json enum). The description only restates the id source and duplicates the schema example, adding little beyond it – baseline 3 is appropriate.

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

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

States a specific verb (side-by-side comparison) and resource (two to four BK-score topics), and enumerates the concrete output (label, all axes, direction, reasoning, link, comparison table). It also names the sibling scenario it is not for (editorial comparison pages → bk_search_inhalte), so an agent can route correctly without opening other 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?

Explicitly routes the editorially-written comparison case to bk_search_inhalte with art='vergleich', and implies ids are sourced from bk_search_topics. This is clear conditional guidance, though it stops short of a fully explicit 'use this when / not when' framing.

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 and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond them: the target range is only present 'wo die Seite einen nennt', high/low values are hedged as what they 'KÖNNEN' mean, and it instructs the agent to always note that the range on the user's own lab report applies.

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

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

Purpose is front-loaded, then a compact example, then a short Args block. The return-field list is dense but earns its place since it defines scope. Slightly long for the value delivered, but no filler 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 an output schema present, return values need not be described, and the safety annotations cover the write/read profile. The description supplies the remaining decision-relevant context (what a marker lookup yields, the interpretation caveat), leaving only pagination/error behavior unaddressed, which is minor for a single-entity getter.

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 and the schema already documents both parameters and the enum. The description still adds value by linking 'id' to its provenance ('Marker-id aus bk_search_blutwerte') and confirming names are accepted, which helps an agent construct the call without a prior lookup.

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 ('Liefert einen Marker der Blutwerte-Seite vollständig') and enumerates exactly what comes back: Bedeutung, Referenzbereich, Zielbereich, hohe/niedrige Werte, Hebel, Störfaktoren, Podcastfolge. This distinguishes it from the sibling search tool bk_search_blutwerte without the agent needing to open 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 a concrete usage pattern ('Typische Frage: Mein ApoB ist 110 - was heißt das? -> id=apob, dann gegen referenz und optimal einordnen') and implies the id originates from bk_search_blutwerte. It never states when NOT to use this tool or names a competing sibling explicitly, so it falls short of a full when/when-not/alternatives statement.

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 establish readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond that: thema can be null when no topic is assigned, and if the episode does not exist or is not yet published, the response tells which episode numbers exist.

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 and well organized into Args, Returns, and Fehlerfaelle. The core behavior is front-loaded and every sentence contributes useful 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?

For a single-episode getter, the description covers the input, the full return shape, the conditional null topic, and the invalid-number error behavior. Combined with the output schema and annotations, an agent has everything needed to call the 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?

The input schema already documents both parameters with types, enums, defaults, and descriptions, so schema coverage is 100%. The description's Args section mostly restates this and adds no meaning beyond the structured 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 first sentence states a concrete action ('Liefert eine einzelne Folge') with an exact resource: the 'Biohacking Kompakt' podcast. The nr argument makes clear this is a by-number retrieval, which distinguishes it from the sibling search tool bk_search_podcast.

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 use case is inferable: fetch a single known episode by number. However, the description never explicitly says when to prefer this over bk_search_podcast or bk_get_topic, nor does it provide any 'when not to use' guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond them: numbers are computed live from the current inventory and may diverge from the published 2026 report (Stand 15.10.2026, 494 Mittel), and it notes that report is separately available as page/PDF/CSV under report/2026. That is a meaningful caveat an agent must not misreport.

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 metric scope are front-loaded in the first sentence, and the subsequent sentences (example questions, published-report caveat) each carry information an agent needs. The opening sentence is long and list-heavy, but nothing is padding.

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

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

An output schema exists, so return-shape explanation is rightly omitted. For a read-only aggregation tool the description covers scope, available category slices, and the live-vs-published discrepancy, leaving little an agent needs uncertain.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, enum values and defaults; baseline is 3. The description adds only a small amount beyond it, notably that the examples are the best-studied ones first ("die am besten untersuchten zuerst"), which is genuine but limited added 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 resource (die Kennzahlen des Biohacking-Reports von biohackingkompakt.de) and what is computed (live aus dem aktuellen Bestand), then enumerates the exact metric labels (gut belegt, mit Einschränkungen belegt, dünn belegt, nie am Menschen untersucht, weit vor der Evidenz beworben) and the five Bereiche. That level of specificity makes it unmistakable as an aggregate-statistics tool rather than a per-topic getter like bk_get_topic.

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 example questions it answers ("Wie viel im Biohacking ist überhaupt belegt?", "Wie steht es um Peptide insgesamt?"), which tells the agent when to reach for it. It does not name an alternative tool or state when not to use it, so it stops short of full routing guidance.

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

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

Annotations already cover read-only, idempotent, open-world, and non-destructive safety. The description adds a non-obvious data caveat: deliberately missing application, dosage, and experience sections for regulated topics, plus section-wise delivery.

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 purpose and uses Args/Returns structure. The Args and Returns blocks duplicate the schema and output schema somewhat, but the text remains compact and organized.

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 page fetch with full annotations, an output schema, and 100% schema coverage, the description supplies key usage context, a return-shape preview, and the regulated-topic omission. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so baseline is 3. The description adds useful meaning for slug ('wie ihn bk_search_inhalte liefert', usually topic id) and abschnitt (matching part of the heading), beyond the schema examples.

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 ('Liefert') and resource ('vollstaendigen Text einer Seite von biohackingkompakt.de') and lists supported page types. However it does not explicitly contrast itself with get siblings such as bk_get_topic or bk_get_podcast_episode, so sibling differentiation is incomplete.

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 says the typical sequence is after bk_search_inhalte to read a find in context. No when-not guidance or alternative get tools are named.

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, so safety is covered. The description adds non-obvious context: the evidence-level encoding (2/1/0) that qualifies every link and the caveat that a link is a mechanism rather than proven efficacy. It could still say more about result size or pagination, so not a full 5.

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

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

Front-loads the resource, then a clean three-bullet breakdown of modes, then the evidence-scale note. The opening sentence enumerates many pathway names, which is somewhat verbose but serves as scope illustration rather than 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?

An output schema exists, so return formatting need not be explained. Combined with the mode semantics, evidence-level legend, and sibling cross-reference, an agent has everything needed to choose and 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 coverage is 100%, so the baseline is 3. The description earns extra credit by mapping each parameter to a distinct behavioral mode (id = pathway view, thema_id = inverted topic view, absence = list), which is semantic meaning beyond the schema's field descriptions.

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

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

Stated as a specific verb+resource ('Signalwege-Atlas abfragen') and explains the three distinct retrieval modes, so an agent knows exactly what the tool returns in each case. It also names the adjacent tool bk_get_topic that supplies the effect data this tool deliberately omits.

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 enumerates when to use each mode: no argument for a full list, id for one pathway with its topics, thema_id for the reverse lookup. It also draws the boundary against bk_get_topic by clarifying that links are mechanisms, not demonstrated human effects.

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, openWorldHint, idempotentHint, destructiveHint=false. The description adds a useful caveat that the score axes mean something different from their names, and clarifies that no arguments are needed except possibly response_format. 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 short sentences, front-loaded with purpose, then usage trigger, then args/returns. 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?

For a simple read-only retrieval tool, it provides the content scope, the trigger, the argument expectations, and the return type. It also includes an important interpretation warning. There is no output schema, but the description covers what the agent needs.

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 0 parameters and 100% coverage, so baseline is 4. The description explicitly notes 'Args: keine (ausser response_format)', clarifying that no tool-specific parameters are expected, which is useful for agents.

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: it delivers the official citation guidelines (llms.txt) from Biohacking Kompakt, and details the content (BK score meaning, misunderstood axes, classification). This clearly differentiates it from sibling tools like podcast/topic search or score lists.

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 trigger: call once before first citing content. It doesn't name alternatives, but no sibling tool serves this purpose, so the context is clear. It lacks explicit 'when not to use', but that's acceptable for a unique 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?

Annotations already declare this as a safe, read-only, idempotent, open-world read, so the safety profile is covered. The description adds useful context – the changelog nature of the data and that every entry carries a verifiable source – but the only operational detail (default limit 10) is essentially restated from the schema, and nothing is said about ordering or pagination behaviour.

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 prose is tight and front-loaded: what the changelog is, then the kinds of entries, then example queries. The trailing Args block partly duplicates fields already in the schema, which is minor waste but does not obscure the core message.

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 an output schema present, return values need no explanation, and all seven parameters are optional, so the agent needs only purpose and filtering semantics – both supplied. Enumerating the change categories plus example queries makes this comfortably callable, with only sibling-routing left implicit.

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 71%, so several parameters are documented structurally (typ enum, seit pattern, response_format, thema_id). The description adds one genuine clarification – query searches 'Titel und Text' – but otherwise mostly restates the schema's own limits and defaults for limit/offset, whose schema entries carry no description text.

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

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

The description states a specific resource (the content changelog of biohackingkompakt.de) and enumerates exactly what kind of entries it contains – new peer-reviewed studies, retractions, failed approvals, case law, own corrections – each with a verifiable source. That is far more specific than a tautology. It never names a sibling (e.g. bk_search_inhalte) that an agent might confuse it with, so it stops short of full differentiation.

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

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

Two concrete example questions ('Was ist neu bei Retatrutid?', 'Welche Bewertungen wurden zuletzt korrigiert?') give an agent clear context for when this tool is the right choice. However, no explicit when-not condition or named alternative (such as bk_search_inhalte or bk_search_studien) is provided, leaving overlap resolution 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?

Beyond the readOnly/idempotent annotations, the description discloses that the list excludes promotional reports, that total reflects the filtered list, and that promotional reports appear as ads on the website. It also flags the epistemic limitation that a report is a single observation, not a proof.

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 main behavior is front-loaded and followed by two purposeful caveats, then structured Args and Returns sections. The Args block is somewhat redundant with the schema, but it is compact and does not waste 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?

The definition is complete for this listing tool: it states the content, filtering behavior, pagination fields, and return item shape, and it names the relevant sibling tool for efficacy. The 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 input schema already describes all five parameters at 100% coverage, so the description's Args section does not add much semantic value. It repeats optionality and defaults without adding new meaning beyond what the schema provides.

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

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

The description opens with a specific verb and resource ('Listet die Erfahrungsberichte von biohackingkompakt.de') and defines the list's content (Selbstversuche, recherchierte Berichte, Dauer, Dosierung, Fazit). It differentiates this listing from the efficacy-oriented BK-Score tool by explicitly stating that a report is only a single observation and not proof.

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 explicit guidance not to treat Erfahrungsberichte as evidence of efficacy and points to bk_get_topic for the BK-Score. It also explains the list is filtered to exclude partner-program/rabattcode reports and that total refers to this filtered list, so an agent knows how to interpret results.

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, so the safety profile is covered. The description adds genuine behavioral context beyond that: the content is orientation, not diagnosis ('sie ordnet ein, sie befundet nicht'), and it describes what each thema mode returns. It does not discuss pagination or result size, so not a full 5.

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

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

Reasonably long but front-loaded: purpose first, then the mode branches, then the alternative tool and the disclaimer. Every sentence carries information (markers, mode meanings, routing, caveat) rather than filler; slightly dense with the long marker list.

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

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

An output schema exists, so return values need not be explained, and the description covers purpose, all parameter semantics, mode routing, the sibling alternative, and the non-diagnostic caveat. Nothing an agent needs to call this 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%, making 3 the baseline, but the description adds meaning over the schema: it maps the opaque enum slugs (entzuendung, naehrstoffe) to readable Baustellen, gives query examples ('ApoB', 'Insulin', 'Eisen'), and clarifies what nur_einsteiger and the thema modes select.

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 (Durchsucht) plus resource (Blutwerte-Seite des Longevity-Panels) and enumerates the concrete content returned (Marker mit Referenzbereich, Einheit, Baustelle). It also explicitly names the sibling used for the single-marker case (bk_get_blutwert), so an agent can distinguish it without opening either schema.

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

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

Gives explicit when-to-use branches: no query → overview, thema='panels' → Laborpakete, thema='regeln' → Messrhythmus/Vorbereitung, and routes single-marker deep-dives to bk_get_blutwert. This is the kind of routing an agent needs, with no alternatives left to inference.

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

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

Annotations already cover read-only, idempotent, non-destructive and open-world behavior, so the bar is lower. The description adds genuinely useful non-obvious context: stopwords are ignored, each hit returns page/section/excerpt only, and regulated topics deliberately omit application/dosage/experience sections, which prevents the agent from misreading thin results.

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

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

Front-loaded with purpose, then when-to-use with examples, then return shape, follow-up tool, and a caveat – a sensible priority order. The long parenthetical enumeration of page types and five example queries make it longer than strictly necessary, but nearly every sentence carries actionable information.

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

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

For a 5-parameter search tool with full schema coverage and an output schema, this covers what the agent needs: scope, query construction, filtering, hit granularity, the companion retrieval tool, and the regulated-content caveat. Nothing material is left for the agent to infer.

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 a 3 is the baseline and the schema already documents all five parameters. The description adds real meaning beyond it by noting that Füllwörter are ignored in the query (relevant to how an agent phrases searches) and glosses the art enum values, though it repeats limit/default values already in the schema.

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

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

States a specific verb (Volltextsuche) and resource (ALLE Seiten von biohackingkompakt.de) and enumerates the covered content types (Themenseiten, Tipps, Vergleiche, Fragen & Beschwerden, Glossar, Podcast-Folgen). The scope word 'ALLE' implicitly distinguishes it from the narrower siblings bk_search_blutwerte, bk_search_studien, bk_search_podcast and bk_search_topics.

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

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

Gives a clear when-to-use rule ('konkrete Fragen im Wortlaut, deren Antwort im Fliesstext steht') backed by five sample queries, and names the follow-up tool bk_get_seite for retrieving full sections/pages. What it lacks is an explicit exclusion routing the agent to the specialized sibling searches (Blutwerte, Studien, Podcast) when those are the better fit.

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 safe-read profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful behavior: unpublished episodes are never returned and an empty query yields the newest episodes, which is scope behavior not encoded in annotations. It stops short of describing pagination edge cases beyond the return shape.

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 purpose, then defaults, then args, returns, and examples in a clean layered structure. The Args block largely restates the schema descriptions, which is mild redundancy, but the examples and exclusion line earn their space.

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

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

An output schema exists, so the return values need not be explained, yet the description still sketches them usefully. Combined with the exclusion note and examples, an agent has enough to call and route this tool correctly; only deep pagination semantics are left implicit.

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 cross-tool meaning by tying thema_id to bk_search_topics and clarifying that query matches the title specifically, plus the natural-language examples map queries to parameters. Marginal but real value over the schema.

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

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

States a specific verb and resource ('Sucht in den veroeffentlichten Folgen des Podcasts Biohacking Kompakt') and distinguishes itself from siblings by naming bk_get_podcast_episode-like granularity and explicitly excluding bk_get_topic use cases. An agent can immediately tell this is an episode-search tool.

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

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

Explicitly states the no-query default (newest episodes), gives three worked examples mapping natural-language questions to parameter settings, and names a concrete exclusion ('Nicht benutzen fuer: den Sachstand zu einem Thema (dafuer bk_get_topic)'). This is routing guidance, not inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so safety is covered structurally. The description adds genuinely useful behavior not in annotations: the default ordering when no query is supplied (by study type, then year descending) and the caveat that Studientyp is an orientation, not a quality grade. However it does not mention rate limits, freshness of 'stand', or pagination semantics 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?

Front-loaded with the core action and scope, then args, return shape, and examples in a scannable structure. The Returns block largely restates the output schema, which is minor redundancy, 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?

For an 8-parameter, zero-required search tool with an output schema and full annotation coverage, the description supplies everything needed: scope, defaults, sort behavior, parameter hints, examples, and an explicit exclusion. 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 description coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: the tip that titles are mostly English ('creatine' findet mehr als 'Kreatin') while topic names are German, and concrete thema_id examples ('kreatin', 'biotin'). This steers parameter choice in ways the schema text does not.

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 ('Durchsucht die Studien-Datenbank von biohackingkompakt.de') and quantifies scope (ca. 2.500 Studien, 400 Behoerden-/Rechtsquellen). It explicitly distinguishes itself from the closest sibling by stating it is not for topic assessment (dafuer bk_get_topic), so an agent can route 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?

Provides four concrete query-to-parameter mappings (thema_id, typ, quellenart) and an explicit exclusion ('Nicht benutzen fuer: die Bewertung eines Themens (dafuer bk_get_topic)'). When-to-use, when-not-to-use, and the alternative are all present.

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