Skip to main content
Glama

Find a songwriter by name

find_songwriter
Read-only

Use when the user names a songwriter or composer and wants to know who they are, which person a name belongs to, or every registration of that writer. Returns the persons the name could be: each with a person ID, the names and IPI name numbers they are registered under, how many works, and a person_url to cite. Pairs listed under possibly_the_same_person were held apart and are not merged; why says why. Candidates are this lookup's own grouping, made afresh for the name, and can differ from the stored person that get_songwriter and the person page describe: a candidate can include records with no IPI name number that the stored person lists apart, and two candidates can carry the same person_id when this lookup keeps apart records the stored person joined. Each record's person_id is the stored person it belongs to, or null; person_records is how many records that person holds, and records_not_in_this_answer how many of them this candidate does not, because they sit in another candidate or outside this lookup. For a person's registrations as they stand, call get_songwriter. A candidate's works counts every record in it, records held apart from the person included; the person's own count is get_songwriter's works.total. Registrations are under legal names: a writer known by a professional or stage name may not be found by it. If the writer you expect is not among the candidates, or song_match.match is none, try their legal name. truncated means more registrations matched than one answer groups: a fuller name narrows it. Give a song title they wrote, when known, to say which of several namesakes wrote it. A one-word name is not searched: ask for the full name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe songwriter's full name, as registered or as commonly written
songNoOptional: the title of a song they wrote

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With readOnlyHint=true already covering safety, the description goes well beyond annotations: it explains that candidates are a fresh grouping that can differ from the stored person, that person_id may be null, what person_records and records_not_in_this_answer mean, what truncated signals, and that only legal names are searched. This is unusually rich behavioral context.

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?

It is front-loaded with a clear 'Use when' clause, but the body is a dense ~350-word wall for a 2-parameter tool, and sentences such as the records_not_in_this_answer explanation are convoluted. The content largely earns its place, but the phrasing could be tightened substantially.

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?

There is no output schema, so the description must carry the return-value burden, and it does: it enumerates the fields of each candidate, the pairing structure, the null case, and the truncation flag. Combined with the fallback guidance, an agent has everything needed to call and interpret the tool.

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 100% so the baseline is 3, but the description adds genuine meaning: the optional song title is framed as a namesake disambiguator, and the name parameter gains a soft constraint ('a one-word name is not searched: ask for the full name') plus the legal-name caveat that the schema does not convey.

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?

The description gives a specific verb+resource (find/group candidate persons for a named songwriter) and spells out exactly what is returned: person ID, registered names and IPI numbers, works counts, and a person_url. It also explicitly differentiates itself from the sibling get_songwriter, so an agent can route without opening a 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?

It states the trigger ('when the user names a songwriter or composer and wants to know who they are'), names the alternative and its condition ('For a person's registrations as they stand, call get_songwriter'), and gives fallbacks (try the legal name, supply a song title to disambiguate namesakes, a one-word name is not searched). Nothing is left 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