Skip to main content
Glama

Good Turn Studio (all tools)

Scroll the Lore: Search the curated readings, best match first

lore_search_readings
Read-onlyIdempotent

Scroll the Lore. Search the curated readings, best match first. Greek and Norse myth: daily readings explained line by line, plans, search, and the whole Theogony, Iliad, Odyssey and Poetic Edda read a passage at a time

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesWords or a name to search for, for example Loki or Persephone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered structurally. The description adds only 'best match first' (relevance ordering) and does not disclose result count, pagination, or matching behavior — modest added value against an already-strong annotation set.

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

Conciseness3/5

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

The core statement is front-loaded, but the definition opens with a tagline that duplicates the title and then trails into a comma-heavy inventory of texts and generic terms ('plans, search'). It is readable but not tight; several clauses do not earn their place.

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

Completeness3/5

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

For a one-parameter read-only search with an annotated safety profile and a fully documented parameter, the description is adequate — it establishes the corpus and ranking behavior. It stops short of describing what a result looks like or whether results are limited/paginated, which for a tool with no output schema is a real but minor gap.

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

Parameters3/5

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

With a single parameter at 100% schema description coverage ('Words or a name to search for, for example Loki or Persephone'), the schema fully carries parameter semantics. The description adds nothing beyond scope of the corpus, so the baseline 3 applies.

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 — 'Search the curated readings' — and the scope (Greek and Norse myth, Theogony/Iliad/Odyssey/Poetic Edda) distinguishes it from the lore_get_* and lore_list_* siblings. The leading tagline 'Scroll the Lore' and the title restatement add noise, but the operational purpose is unambiguous.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not guidance and no routing to alternatives such as lore_list_readings (browse) or lore_get_reading (read one passage). 'Best match first' describes ranking output, not when to choose this tool over its siblings, so usage must be inferred purely from the word 'search'.

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.