Skip to main content
Glama

find_song_synergies

Find every Disney Lorcana character that can sing a given song by cost or Singer keyword, with optional ink-color filters and owned-copy counts for deck building.

Instructions

Find every Character that can sing a given song — the tool for building or checking a Singer/song combo (e.g. the Amber/Steel Steelsong package), not for general card search (use search_cards for that).

A character can sing a song if its printed ink cost meets the song's cost outright, OR it has a "Singer X" keyword with X meeting the song's cost — Singer lets a cheap character punch above its actual cost for singing purposes only (see the Steelsong package: Amber Singers unlocking expensive Steel songs for free). Provide either song_name (resolved the same fuzzy way as resolve_card, so "beauty and beast" or a slight typo still works) or a raw cost threshold — exactly one is required; passing neither, or both, returns an error message instead of guessing.

Results are grouped: Singer-keyword characters first (the actual "discount" picks — highest Singer value, then cheapest actual cost), followed by characters that simply cost enough to sing it outright, cheapest first. This only tells you who can sing — it doesn't check whether that character is otherwise good (stats, other abilities) or whether you own enough copies to make the combo consistent unless you pass collection_csv, in which case each result is annotated with owned quantity so you can see the combo's real consistency at a glance.

Args: song_name: Name of a Song card, e.g. "Be Our Guest". Fuzzy-matched. cost: Raw song cost threshold to use instead of song_name, e.g. 5. colors: Optional comma-separated ink color(s) to restrict characters to, e.g. "Amber,Steel". collection_csv: Optional path to an enriched collection CSV — when given, each character is flagged with how many copies you own. limit: Max characters to list (default 50, capped at 200).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
costNo
limitNo
colorsNo
song_nameNo
collection_csvNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.7

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it explains the Singer-keyword eligibility rule, result grouping/ordering, fuzzy name resolution, the error path for zero-or-two arguments, the limit cap, and the explicit limitation that it does not evaluate stats or combo consistency unless collection_csv is passed.

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 purpose and the sibling contrast, and every sentence carries information. The parenthetical asides (Steelsong example, typo note) add length but also real value, so it is slightly verbose rather than padded.

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 read-only lookup tool with an output schema already documenting return shape, the description supplies everything else an agent needs: eligibility logic, argument exclusivity, ordering, and the ownership caveat.

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 0%, so the description must compensate, and it largely does: it defines song_name (fuzzy), cost as a raw threshold, colors as comma-separated inks with an example, collection_csv's path/effect, and limit's default and 200 cap. Only the cost default sentinel (-1) is left unexplained.

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

Purpose5/5

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

States a specific verb+resource ('Find every Character that can sing a given song') and immediately names the sibling it is not, routing general card search to `search_cards`. An agent can distinguish it from `search_cards`/`filter_collection` without opening any schema.

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

Usage Guidelines5/5

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

Explicitly frames the use case (building/checking a Singer/song combo) and the anti-case (general card search → `search_cards`). It also states the mutual-exclusion rule: exactly one of song_name or cost, with an error otherwise.

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