Skip to main content
Glama

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: wie stark beworben.

Args:

  • view, label, richtung, min_evidenz, max_evidenz, min_hype: Filter (alle optional)

  • sortierung ('evidenz_ab' | 'evidenz_auf' | 'hype_ab' | '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?" -> min_hype=7, max_evidenz=3, sortierung="hype_ab"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoAuf einen Bereich einschraenken
labelNoScore-Label als Textfilter, z. B. 'Gut belegt', 'Hype', 'Nicht am Menschen'
limitNoHoechstzahl der Ergebnisse (1-100)
offsetNoWie viele Ergebnisse uebersprungen werden
min_hypeNoMindestwert der Hype-Achse
richtungNoWohin die vorhandene Human-Evidenz zeigt
sortierungNoReihenfolge der Ergebnisseevidenz_ab
max_evidenzNoHoechstwert der Human-Evidenz-Achse
min_evidenzNoMindestwert der Human-Evidenz-Achse
response_formatNoAusgabeformat: 'markdown' zum Lesen, 'json' zum Weiterverarbeitenmarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesZahl der Eintraege in dieser Antwort
itemsYes
totalYesGesamtzahl der Treffer
offsetYesWie viele uebersprungen wurden
has_moreYesOb es weitere Treffer gibt
next_offsetNooffset fuer die naechste Seite

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.