Biohacking Kompakt

Themen nach BK-Score filtern

bk_list_scores

Read-onlyIdempotent

Listet Themen nach ihrer Bewertung im BK-Score - dem Kern von Biohacking Kompakt. Damit lassen sich Fragen beantworten wie "Was ist wirklich gut belegt?", "Wo ist der Hype groesser als die Evidenz?" oder "Welche Peptide sind am Menschen ueberhaupt nicht untersucht?".

Der Score hat fuenf Achsen (jeweils 0-10) und bewertet den WISSENSSTAND, nicht die Substanz:

evidenz: wie viel und wie gut am Menschen untersucht. Sagt NICHT, ob es wirkt - dafuer ist richtung da.
richtung: wohin die vorhandene Evidenz zeigt (positiv, gemischt, negativ, offen).
sicherheit: wie gut die Sicherheitslage untersucht ist. Hoch heisst "gut untersucht", NICHT "harmlos".
anwendung: wie lange und breit angewendet. Kein Wirksamkeitsbeleg - Aderlass haette hier eine 10.
hype: der Hype-Abstand. 10 = die Werbung deckt sich mit den Daten, niedrig = die Werbung ist den Daten weit voraus. Niedrig ist also das Warnsignal, nicht hoch.

Args:

view, label, richtung, min_evidenz, max_evidenz, min_hype, max_hype: Filter (alle optional)
sortierung ('evidenz_ab' | 'evidenz_auf' | 'hype_ab' | 'hype_auf' (groesster Abstand zuerst) | 'name')
limit (1-100, Standard 25), offset, response_format

Returns: { total, count, offset, items: [{ id, view, name, label, evidenz, richtung, sicherheit, anwendung, hype, url }], has_more, next_offset }

Beispiele:

"Was ist gut belegt und wirkt?" -> min_evidenz=7, richtung="positiv"
"Wo ist der Hype groesser als die Evidenz?" -> max_hype=3, sortierung="hype_auf"

Input Schema

Name	Required	Description	Default
`view`	No	Auf einen Bereich einschraenken
`label`	No	Score-Label als Textfilter, z. B. 'Gut belegt', 'Hype', 'Nicht am Menschen'
`limit`	No	Hoechstzahl der Ergebnisse (1-100)
`offset`	No	Wie viele Ergebnisse uebersprungen werden
`max_hype`	No	Hoechstwert des Hype-Abstands (niedrig = Werbung weit vor den Daten)
`min_hype`	No	Mindestwert des Hype-Abstands (hoch = Werbung deckt sich mit den Daten)
`richtung`	No	Wohin die vorhandene Human-Evidenz zeigt
`sortierung`	No	Reihenfolge der Ergebnisse	evidenz_ab
`max_evidenz`	No	Hoechstwert der Human-Evidenz-Achse
`min_evidenz`	No	Mindestwert der Human-Evidenz-Achse
`response_format`	No	Ausgabeformat: 'markdown' zum Lesen, 'json' zum Weiterverarbeiten	markdown

Output Schema

Name	Required	Description
`count`	Yes	Zahl der Eintraege in dieser Antwort
`items`	Yes
`total`	Yes	Gesamtzahl der Treffer
`offset`	Yes	Wie viele uebersprungen wurden
`has_more`	Yes	Ob es weitere Treffer gibt
`next_offset`	No	offset fuer die naechste Seite

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 16, 2026

addedInput schema / properties / max_hype

Added value: +{
+  "description": "Hoechstwert des Hype-Abstands (niedrig = Werbung weit vor den Daten)",
+  "maximum": 10,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / min_hype / description

Previous value: -"Mindestwert der Hype-Achse"New value: +"Mindestwert des Hype-Abstands (hoch = Werbung deckt sich mit den Daten)"

changedInput schema / properties / sortierung / enum

Previous value: -[
-  "evidenz_ab",
-  "evidenz_auf",
-  "hype_ab",
-  "name"
-]New value: +[
+  "evidenz_ab",
+  "evidenz_auf",
+  "hype_ab",
+  "hype_auf",
+  "name"
+]

First observedSep 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the description is free to add meaningful domain context instead. It does so extensively: each axis measures the WISSENSSTAND not the substance, 'evidenz' does not say whether something works, high 'sicherheit' means well-studied not harmless, and a low hype value is the warning signal rather than a high one. These are exactly the misinterpretations an agent would otherwise make.

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

Conciseness4/5

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

Front-loaded with the tool's role, then a clearly bulleted axis glossary and example mappings, which is appropriate structure for inherently counterintuitive semantics. It loses a point for restating the full Args list and Returns object even though the schema covers parameters at 100% and an output schema exists, making those sections partly redundant.

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

Completeness5/5

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

For an 11-parameter filter tool with enums and an output schema, the description supplies everything an agent needs: the meaning and direction of every filterable axis, sort-order semantics, pagination behavior, and intent-to-parameter examples. No material gap remains for correct invocation.

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

Parameters5/5

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

Schema coverage is 100%, but the description still adds substantial meaning beyond it by defining the semantics and direction of each score axis and clarifying that 'hype_auf' sorts by largest gap first. It also supplies worked parameter combinations that the schema cannot express on its own.

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

Purpose4/5

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

States a specific verb and resource ('Listet Themen nach ihrer Bewertung im BK-Score') and scopes it to the five score axes, immediately establishing what the tool returns. It does not explicitly distinguish itself from siblings like bk_search_topics or bk_get_topic, though the axis-based filtering implicitly sets it apart.

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

Usage Guidelines4/5

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

Provides concrete when-to-use contexts by mapping real questions to parameter values ('Was ist gut belegt und wirkt?' -> min_evidenz=7, richtung='positiv'; 'Wo ist der Hype groesser als die Evidenz?' -> max_hype=3, sortierung='hype_auf'). It never names an alternative tool or a when-not-to-use condition, so routing against siblings is still left to inference.

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

All Biohacking Kompakt tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.