Skip to main content
Glama

Find poems

find_poems
Read-onlyIdempotent

Search the library. For a situation or a wish ("I just lost my dad", "a poem to thank my mother", "something calm for a ten-year-old", "an easy first poem to learn by heart"), set what the reader needs first: need, or occasion and recipient for a poem to send, audience, easy_to_memorise, easy_to_read. Narrow it with one mood or 1–3 tags from library_guide in the poem language, and max_lines for a short poem. Words in query are looked for in the title and text and in what the poem is about, so "grief father" finds poems of a father's death. For a poem or line the user remembers, put its words in query. Returns up to 10 poems, the best fit first, with the poet, the number of lines, the opening lines (a poem of 1 to 3 lines whole), one sentence on what the poem feels like (use it to choose, it is not the poet's words) and the link. need, occasion, recipient, easy_to_memorise, easy_to_read and audience cover English, Russian and Belarusian poems. Give at least one filter. When nothing fits, or the user wants a deeper search by mood or situation, give them the Smart Search link from the result: a page of the site where they describe it in their own words.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_poems"
  }
}

Input Schema

NameRequiredDescriptionDefault
moodNoOne library mood: sad, anxious, angry, contemplative, inspiring, romantic, dreamy or joyful, or its name in the poem language from library_guide.
needNoWhat the reader wants the poem to do for them: comfort (consoling words for someone who suffers), calm (stillness, a gentle pace), hope (ends more hopeful than it begins), energy (courage, action), release (a good cry), perspective (troubles set against something larger), feel_understood (a painful feeling put into words and left as it is), smile (funny or playful) or tenderness (love toward someone). Only poems that clearly do it come back, the best fit first.
tagsNoTags from library_guide in the poem language, for example ["grief", "father"]. A poem matches any of them.
limitNo
queryNoWords in any order, looked for in the title, the text and what the poem is about. Every word must appear. Poems with all of them in the title come first. When no poem has them all, poems with any of them come back and the result says so.
authorNoThe poet's name or part of it, for example "Dickinson".
audienceNochildren (up to 12), teens or anyone. Leaves out poems not suited to that age. With this or any of need, occasion, recipient, easy_to_memorise and easy_to_read, explicit poems are left out.
languageNoLanguage of the poems, an ISO 639-1 code: en, ru, be, de, fr, es, it, pl, nl, sv, da, nb or uk.
occasionNoFor a poem to send someone as a personal message: greeting (good morning, good night, thinking of you), romance, thanks, celebration (birthday, wedding, newborn, graduation), holiday, support (illness, hard times, before a challenge), condolence, apology, farewell, blessing or friendship. Only poems that read as a message in the sender's own words come back.
max_linesNoOnly poems of at most this many lines.
recipientNoWho the poem is sent to: partner, friend, parent, child or anyone. Poems for that person come first, then poems that suit anyone.
easy_to_readNoOnly poems in plain language a teenager follows on first reading.
easy_to_memoriseNoOnly poems easy to learn by heart (steady rhythm and rhyme, not long), the easiest first. For a first poem to learn.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover read-only, idempotent, closed-world safety, so the description adds the parts annotations cannot: a 10-poem cap, best-fit ordering, the exact returned fields, the warning that the mood sentence is not the poet's words, and the recall-relaxation behavior when no poem matches all query words. It also discloses a policy not in the schema descriptions — that explicit poems are dropped when age/need/occasion filters are used.

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 and dense, with almost every sentence carrying operational content, but it is a single unbroken block of ~220 words in which the filter list and return fields are recited twice in slightly different form. Sub-grouping (filters / query / returns / fallback) would cost nothing and improve scanability.

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?

With 13 optional parameters, no output schema and a non-obvious search model, the definition supplies what is missing elsewhere: how filters combine, what comes back, ordering, cross-language coverage of the semantic filters, and an escalation path. Nothing an agent needs to call this correctly is absent.

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?

At 92% schema coverage the schema already carries most parameter meaning, but the description adds the intent mapping the schema cannot: need vs occasion+recipient as two different entry paths, tags taken from library_guide in the poem language, and max_lines as the lever for a short poem. It does not explain limit or language beyond what the schema already states.

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?

"Search the library" plus the concrete user-situation examples ("I just lost my dad", "something calm for a ten-year-old") make it unmistakable that this is a discovery/search tool over a poem corpus. It never explicitly contrasts itself with get_poem or get_collection, though the line about putting remembered words in query implicitly separates it from a fetch-by-id tool.

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?

It gives explicit when-to-use guidance with worked examples, tells the agent to set need first or occasion+recipient for a sendable poem, mandates at least one filter, and even covers the failure case: route the user to the Smart Search link when nothing fits or a deeper mood-based search is wanted. That is when/when-not plus a fallback, not just context.

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