Skip to main content
Glama

Find game guides and articles

search_guides
Read-onlyIdempotent

Find published FoolFish Games guides and articles by topic. Optional game slug matches the primary game only; linked recommendations are not counted as walkthroughs.

Input Schema

NameRequiredDescriptionDefault
gameNoOptional public game slug, e.g. fish-sudoku-idle.
limitNo
queryNoWords from the game title, genre or gameplay, e.g. sudoku, idle, rngdle, size it up.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that only *published* guides are returned and that a game slug matches the primary game only (recommendations excluded) — real behavioral context. It says nothing about result ordering, the default/max limit behavior, or pagination, so it stays at a 3.

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

Conciseness5/5

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

Two tight sentences, zero filler, with the core purpose front-loaded and the filter caveat second. Every clause earns its 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 read-only search tool with no output schema, the description covers purpose and the key filter semantics but omits what a result contains, ordering, and the meaning/behavior of the default limit of 8 — details an agent cannot recover since no output schema exists. Adequate but with clear gaps.

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 67% (game and query documented, limit not). The description adds genuine meaning beyond the schema by clarifying that the `game` slug matches only the primary game and not linked recommendations, which changes expected recall. It adds nothing for `limit`, keeping it below 5.

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 ("Find published FoolFish Games guides and articles") plus the scoping dimension ("by topic"), which is enough to separate it from get_guide (fetch one) and search_games (a different resource). It does not explicitly name or differentiate from its siblings, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is implied: reach for this when you want guides/articles by topic, with game as an optional narrowing filter. However, it never says when NOT to use it or points to search_games / get_guide as alternatives, leaving the routing decision to inference.

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.

Resources