Skip to main content
Glama

Pick a costume

pick_costume
Read-onlyIdempotent

Ranks Halloween costume ideas from a fixed catalog of 169 against the supplied audience, interests, vibe, effort level, and owned materials, and returns the top 3 matches. Each pick includes a why-line explaining the match, a thumbnail image, a link to its full build page, and the estimated time and effort. Owned items boost ranking: ideas whose materials are covered by the supplied owned items rank higher. Interest is the strongest ranking signal: ideas matching the stated interest outrank others.

Input Schema

NameRequiredDescriptionDefault
vibeNoVibe: 'funny', 'scary' (or 'spooky'), 'cute' (or 'sweet'), 'chill' (or 'low-key').
effortNoEffort: 'easy'/'last-minute'/'couch-level', 'crafty'/'medium', or 'all-out'/'ambitious'.
who_forYesWho the costume is for: e.g. 'toddler', '3-year-old', 'kid', 'adult', 'couple', 'family', 'group of 5'.
interestNoOptional but powerful: what the wearer is into, e.g. 'dinosaurs', 'animals', 'princesses', 'superheroes', 'video games', 'tv characters', 'food', 'sports'. This is the strongest ranking signal: ideas matching the interest win.
group_sizeNoOptional: how many people need costumes (for family/group picks).
owned_itemsNoOptional: things the user already owns, e.g. ['bedsheet'], ['cardboard', 'tape']. Ideas buildable from owned items rank higher.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, and the description adds real behavior beyond that: the catalog is fixed at 169, output is capped at top 3, and ranking weights (interest strongest, owned items boost). It does not discuss tie-breaking or what happens when nothing matches well.

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 ranking action and output count, then the return payload, then ranking rules. Slightly repetitive in restating the interest signal that the schema also states, but no filler.

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

Completeness4/5

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

No output schema exists, so the description correctly spells out the return payload (why-line, thumbnail, build-page link, time/effort estimate). For a 6-parameter read-only recommender this is nearly complete, missing only behavior on empty or poor matches.

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?

Schema coverage is 100% and the schema already documents every parameter including that interest is 'the strongest ranking signal'. The description restates that weighting and adds that owned items raise rank, so it adds modest meaning but largely mirrors the schema.

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 and resource ('ranks Halloween costume ideas from a fixed catalog of 169') plus the exact output shape (top 3 matches). An agent can tell this apart from get_build_guide and search_by_owning purely from this sentence.

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?

The description implies the use case (ranking candidate costumes from audience/interests/vibe/effort/materials), but never states when to choose this over search_by_owning or get_build_guide, nor any exclusions. The mention of a 'link to its full build page' only hints at the get_build_guide handoff.

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.