Find the songwriter behind a name or IPI name number, under every spelling and number.
Scored across 4 tools
Each tool targets a distinct input and purpose: check_writers handles bulk IPI lookups, songwriter_by_ipi handles a single IPI, find_songwriter searches by name, and get_songwriter retrieves by person ID. The boundaries are clear despite some conceptual overlap between IPI-based tools.
Three tools follow a verb_noun pattern (check_writers, find_songwriter, get_songwriter), while songwriter_by_ipi uses a noun_by_attribute pattern. This is a minor deviation but remains readable and predictable.
Four tools are well-scoped for a songwriter/IPI lookup server. Each tool earns its place by covering a distinct entry point: name, IPI, person ID, and bulk IPI lookup.
The core lookup workflows are covered, but there are minor gaps: no dedicated work/title search, and get_songwriter returns only up to 25 works with the rest deferred to an external person page. These gaps are workable for identity resolution but limit full catalogue exploration.
Use when the user has several IPI name numbers, such as the writers on a song, a catalogue or a registration file, and wants to know who each one is, or whether some of a writer's works sit under another spelling or number. Up to 50 numbers per call. For each: the person holding it, their registered names, works in total and on their main number, works_elsewhere (registered only under another spelling or number), and a person_url.
| Name | Required | Description | Default |
|---|---|---|---|
| ipi_name_numbers | Yes | Up to 50 IPI name numbers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful behavioral detail: the 50-number batch limit and the exact return fields, including what works_elsewhere means. It does not explain error handling or the conflict with the schema's maxItems of 100, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is front-loaded with the use case, followed by the limit and return fields in a compact sequence. Every sentence adds actionable information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only batch lookup with no output schema, the description enumerates the key return fields and clarifies works_elsewhere, which is valuable. However, the 'Up to 50 numbers per call' statement conflicts with the schema's maxItems of 100 and no explanation is given, leaving a small completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single ipi_name_numbers parameter. The description repeats the 50-number limit and gives input-context examples, but adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a batch lookup of songwriters by IPI name number and what each result contains. The plural 'several IPI name numbers' and 'Up to 50 numbers per call' distinguish it from singular siblings like get_songwriter and find_songwriter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool: when the user has several IPI name numbers, such as writers on a song, catalogue, or registration file. It does not name when not to use it or explicitly route single-number cases to a sibling, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The songwriter's full name, as registered or as commonly written | |
| song | No | Optional: the title of a song they wrote |
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.
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.
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.
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.
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.
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.
Use when you have a Songlinks person ID (SLP-XXXX-XXXX-X), from find_songwriter or a person page, and the user wants that writer's details: the registrations grouped into the person, records listed apart as possibly the same person, and their first works. Each record says how it was joined: main marks the record the ID was issued on, and rule is the evidence: same_ipi (another of the person's records carries the same IPI name number), ipi (it carries the person's own number), model (judged the same writer from works, co-writers and publishers in common; score is how sure), corroborated (confirmed by an independent source) or verdict (decided by a person). At most 25 works are listed; works.total is the full count and the person page lists the rest. works.ordered_by is recordings when the list starts with the most-recorded works, and coded when it is in catalogue-code order: then it is a sample, not the writer's best-known songs.
| Name | Required | Description | Default |
|---|---|---|---|
| person_id | Yes | A Songlinks person ID, SLP-XXXX-XXXX-X |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint already covering the safety profile, the description adds real behavioral content: the 25-work listing cap with works.total holding the full count, and the meaning of works.ordered_by=coded being a sample rather than best-known songs. It stops short of auth, rate-limit, or error behavior, so it earns a 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The usage condition and ID format are front-loaded, so an agent gets the trigger immediately. The remaining text is dense and run-on, with nested clauses and backticked tokens packed into two long sentences, but almost every clause carries information the agent needs given the absent output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carries the full burden of describing returns, and it does so thoroughly, including the join-rule vocabulary (main, same_ipi, ipi, model with score, corroborated, verdict) and the listing-cap semantics. Combined with full parameter coverage, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is a single parameter whose format (SLP-XXXX-XXXX-X) is already documented in the schema. The description restates the same format without adding syntax, validation, or edge-case meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: use it when you hold a Songlinks person ID and want that writer's details, then enumerates what comes back (registrations, records, first works). It implicitly routes from find_songwriter but never explicitly contrasts itself with songwriter_by_ipi or check_writers, so sibling differentiation is only partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit precondition and ID source: a Songlinks person ID (SLP-XXXX-XXXX-X) obtained from find_songwriter or a person page. It does not state when *not* to use it or which sibling to prefer when the user has an IPI instead of a person ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user has an IPI name number (up to 11 digits, often written without its leading zeros) and wants to know which songwriter holds it. Returns the person or persons holding the number, each with a person ID and person_url; use get_songwriter for one person's details. none means no person here holds it: it may be a publisher's number, or one whose registrations have not been grouped.
| Name | Required | Description | Default |
|---|---|---|---|
| ipi_name_number | Yes | One IPI name number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered by structured data. The description adds genuinely non-obvious behavior: it can return multiple persons, each carries person_id and person_url, and `none` is a meaningful signal (publisher number or ungrouped registrations) rather than an error. It stops short of describing error/rate-limit behavior, but the not-found semantics are the important detail here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the trigger condition, then return shape, then the not-found case. Every clause carries information; nothing restates the title or the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies the return shape (person(s) with person_id and person_url), the null-result semantics, and cross-tool routing. For a single-parameter lookup tool with a readOnly annotation, nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 format guidance the schema lacks: 'up to 11 digits, often written without its leading zeros'. That directly informs how an agent should normalize the value before calling, which the generic schema description 'One IPI name number' does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('find a songwriter by IPI name number') and explicitly scopes the input to an IPI name number. It also distinguishes itself from the sibling get_songwriter, so an agent can choose between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use when the user has an IPI name number ... and wants to know which songwriter holds it' gives an explicit trigger condition. It goes further by naming the alternative ('use get_songwriter for one person's details') and by explaining the `none` outcome, so both the happy path and the fallback routing are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_writersfind_songwriterget_songwritersongwriter_by_ipiCheck a catalogue against The MLC, look up a song's writers, publishers and ISWC, validate CWR files
Find engineers and scientists from papers, open source and patents. Each result links its sources.
Search, analyze, and discover commercially released music using sonic intelligence.
Free ISRC lookup and public titles for Reels, TikTok, Shorts, and X links.
Add one secure layer between your agents and this server.