Biohacking Kompakt

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?

Although the annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, the description adds substantial behavioral context: regulated topics deliberately omit dosage and community links, unknown ids return similar existing ids, and the BK score axes require careful interpretation. This goes well beyond what the annotations alone provide.

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 long but every section earns its place: the full deliverable list, the nuanced BK-score clarification, the regulated-topic behavior, the easily-confused field distinction, and the error handling. It is well-structured and front-loaded with the core purpose before diving into details.

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

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

For a complex topic-retrieval tool, this description is remarkably complete. It covers return structure, field semantics, regulatory edge cases, error behavior, examples, and exclusions. The output schema exists, but the description still adds meaning by explaining relationships between fields and how to phrase results for regulated substances.

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 covers all three parameters with descriptions, so the baseline is 3. The description adds meaningful extra semantics: concrete id examples, the disambiguation purpose of 'view', and the intended use of markdown vs json response_format. This lifts it above the baseline but does not radically expand parameter knowledge.

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

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

The description clearly states the verb 'Liefert' and the resource 'Themen-Eintrag von biohackingkompakt.de', enumerating exactly what content is included. It also differentiates itself from the sibling tool bk_list_scores by explicitly saying it is not for listing 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?

The description provides concrete usage scenarios with examples ('Erklaer mir Kreatin mit euren Quellen') and an explicit when-not-to-use case with the correct alternative ('Nicht benutzen fuer: eine Liste... -> bk_list_scores'). This gives the agent clear routing guidance without ambiguity.

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?

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 mark this as read-only and idempotent, and the description adds substantial behavioral context: the score measures knowledge state, not substance; sicherheit means 'well studied', not 'harmless'; anwendung is not an efficacy proof. This goes well beyond the structured 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 long but well-structured, with purpose, axis semantics, arguments, returns, and examples clearly separated. It is somewhat redundant with the input and output schemas, but the axis explanations and examples justify the 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 tool with 10 optional parameters and an output schema, the description is complete: it explains all relevant filters, sorting options, pagination, response format, and the meaning of the score axes. The examples further clarify how to use the tool for common questions.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the meaning of the score axes and by mapping example questions to specific parameter combinations like min_evidenz=7 and richtung='positiv'. This helps an agent choose parameter values correctly.

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

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

The description clearly states the tool lists Themen filtered by BK-Score, with a specific verb and resource. It conveys the unique value proposition but does not explicitly differentiate from sibling tools like bk_search_topics or 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?

The description provides concrete use-case questions and example filter combinations, giving clear context for when to use the tool. It does not explicitly state when not to use it or name alternative tools.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint=false), the description discloses a key behavioral invariant: 'Noch nicht erschienene Folgen werden nie ausgegeben' and the default behavior of returning newest episodes without a query. These details are not implied by the annotations and meaningfully shape invocation and interpretation of 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?

The description is well-structured with Args, Returns, and Beispiele sections, and the primary action is front-loaded. However, it includes some redundant background about the podcast's production (KI-Stimmen, redaktionell verantwortet) and repeats schema parameter descriptions, so it is slightly less concise than it could be.

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 search tool with five optional parameters, full schema descriptions, and an output schema, the description covers invocation behavior, examples, return shape, and explicit routing to a sibling tool. Nothing an agent needs to select and call this tool 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 all parameters; the description's Args section largely duplicates this. It adds only marginal context through examples, such as mapping 'Gibt es eine Folge ueber Kreatin?' to query='Kreatin', but no new parameter-level semantics 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 action and resource: 'Sucht in den veroeffentlichten Folgen des Podcasts Biohacking Kompakt', clearly identifying it as a search tool over podcast episodes. It also explicitly differentiates from a sibling by stating 'Nicht benutzen fuer: den Sachstand zu einem Thema (dafuer 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?

Provides explicit usage context: without a query it returns the newest episodes, and gives three representative examples mapping natural-language requests to parameters. It also states when not to use the tool and names the alternative (bk_get_topic), satisfying the when/when-not/alternatives criterion.

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

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

The annotations already establish a safe, read-only, idempotent operation, and the description adds valuable behavior: it searches names, aliases, tags, and descriptions; ignores umlauts and spelling variations; returns short summaries with BK-Score; and exposes pagination via has_more and next_offset. This goes well beyond what annotations alone provide and contains no contradictions.

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

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

The description is well structured and front-loaded: a clear scope statement, followed by result expectations, a compact Args summary, return shape, and practical examples. The explicit 'Nicht benutzen fuer' line is efficient and earns its place; nothing in the text is wasted or redundant enough to hurt.

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 search tool with rich schema annotations and an output schema, this description is fully sufficient. It covers what is searched, matching behavior, result format, pagination, usage examples, and the correct follow-up sibling tool. No critical information an agent would need to invoke or interpret the tool 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 adds genuinely useful meaning through concrete examples like 'Kreatin' and 'Abnehmen, bereich=experimental', clarifying how to translate user intent into query parameters. It also summarizes the purpose of offset, limit, and response_format in a way that supports selection, though much of the Args list duplicates the schema.

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

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

The description clearly states the tool's function: searching all topics on biohackingkompakt.de across named categories, matching against names, aliases, tags, and descriptions. It also explicitly differentiates itself from the sibling bk_search_podcast and tells the agent to use bk_get_topic for full entries, making its purpose and boundaries unambiguous.

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

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

The description provides concrete usage examples, including natural-language queries mapped to parameters, and an explicit exclusion: 'Nicht benutzen fuer: eine Podcastfolge finden (dafuer bk_search_podcast)'. It also instructs the agent to follow up with bk_get_topic when complete entries are needed, which is strong routing guidance.

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