Un servidor MCP para IMSLP, la Petrucci Music Library: obras, partituras y grabaciones de música clásica, catalogadas por los voluntarios que la gestionan. No se necesita ninguna clave de API ni cuenta.
La biblioteca publica sus páginas bajo CC BY-SA 4.0, por lo que todo lo que se muestre desde este servidor atribuye el crédito a IMSLP y enlaza la página de la que procede.
Las lecturas pasan por la API de MediaWiki en /api.php y por el punto de
entrada de listados que IMSLP documenta en su propia página IMSLP:API. El
robots.txt del sitio prohíbe /index.php, /images/, /imglnks/,
/wiki/File:, /works y /library/, y este servidor no construye ninguna
dirección bajo ninguno de ellos: no descarga ningún archivo de partitura y,
en su lugar, devuelve el enlace a la página de la obra.
IMSLP publica Crawl-delay: 2, por lo que las solicitudes se ejecutan de una
en una con al menos dos segundos entre ellas. Ese mínimo se mantiene
independientemente de cómo esté configurado el servidor.
Related MCP server: mcp-ytmusic
Una partitura en IMSLP lleva un estado por jurisdicción, y la biblioteca revisa
Canadá, los Estados Unidos y la Unión Europea. Un archivo puede indicar
Public Domain - Non-PD US: libre en un lugar y protegido en otro. Este
servidor informa del estado tal como se publica, por jurisdicción, y nunca lo
reduce a "dominio público".
Variable | Predeterminado | Qué hace |
| la identidad del proyecto | Da nombre a tu aplicación; se añade la identidad del proyecto para que IMSLP pueda contactar con una persona |
| 2500 | Intervalo entre solicitudes, nunca inferior a 2000 |
| 30000 | Plazo para una solicitud |
| 3 | Intentos tras un fallo transitorio |
| 900000 | Cuánto tiempo permanece una página en memoria |
| 100 | Páginas retenidas a la vez |
|
|
|
MIT, consulta LICENSE. Los datos pertenecen a IMSLP y a sus colaboradores.
Un servidor MCP para IMSLP, la Petrucci Music Library: obras, partituras y grabaciones de música clásica, catalogadas por los voluntarios que la gestionan. Sin clave de API, sin cuenta.
La biblioteca publica sus páginas bajo CC BY-SA 4.0, por lo que todo lo que este servidor devuelve atribuye el crédito a IMSLP y remite a la página de origen.
Las lecturas pasan por la API de MediaWiki /api.php y por el punto de entrada
que IMSLP documenta en su página IMSLP:API. El robots.txt del sitio prohíbe
/index.php, /images/, /imglnks/, /wiki/File:, /works y /library/, y
este servidor no construye ninguna dirección bajo esas rutas: no descarga
ningún archivo de partitura y devuelve el enlace de la página de la obra.
IMSLP publica Crawl-delay: 2, por lo que las solicitudes salen de una en una,
con al menos dos segundos entre ellas, sea cual sea la configuración.
Una partitura lleva en IMSLP un estado por jurisdicción, y la biblioteca
verifica Canadá, los Estados Unidos y la Unión Europea. Un archivo puede ser
Public Domain - Non-PD US: libre aquí y protegido en otro lugar. Este
servidor devuelve el estado tal como se publica, jurisdicción por jurisdicción.
Read the works IMSLP files under a category: a genre, a key, an instrumentation or a period. The library writes these names itself, and get_work hands them back for a work under 'genre_categories': 'Nocturnes', 'For piano', 'Scores featuring the piano', 'B-flat minor'. Pass one of those rather than a name of your own, since a category the library does not hold answers exactly as an empty one does. The 'Category:' prefix may be left out. The library cannot cross two categories, so a question naming both a genre and an instrument is answered by browsing one and reading the other off each work. IMSLP publishes no count of what a category holds, so 'total' is always null; 'has_more' and 'cursor' say whether more rows remain and how to read them. When you show a work to a user, credit IMSLP and link the page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to serve, from 1 to 100. | |
| cursor | No | The 'cursor' a previous answer named, to read on from where it stopped. The library writes it itself, so it is passed back as it was given rather than built. | |
| category | Yes | The category to read, in the library's own wording, for example 'For piano', 'Nocturnes' or 'Category:B-flat minor'. The prefix is added when it is left out. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| total | Yes | Always null: IMSLP publishes no count of what a category holds. |
| cursor | Yes | The cursor to read on from, as the library named it. Null when it named none. |
| source | Yes | |
| license | Yes | |
| results | Yes | |
| category | Yes | The category as it reached the library, prefix included. |
| has_more | Yes | True when the library named a cursor to continue from. |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses non-obvious behaviors: category names are library-controlled, missing categories return results indistinguishable from empty ones, the 'Category:' prefix is optional, cross-category queries are unsupported, 'total' is always null, and 'has_more'/'cursor' govern pagination. It also adds an attribution and linking requirement.
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 description is front-loaded and every sentence carries a distinct, useful fact. It is somewhat dense and longer than strictly necessary for a listing tool, but the extra length is mostly justified by the category, empty-result, and pagination quirks.
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?
Together with the schema and annotations, the description covers what the tool does, where valid category names come from, how to handle missing categories and combinations, what pagination looks like, and how to credit IMSLP. Nothing needed to invoke the tool correctly is left unexplained.
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 real value: category values should come from get_work and may omit the prefix, while cursor should be echoed back from a previous response rather than constructed. The limit parameter gains no extra explanation, which keeps this from a 5.
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 opens with 'Read the works IMSLP files under a category' and enumerates the category kinds (genre, key, instrumentation, period), making the tool’s job unambiguous. It also references get_work and distinguishes browsing a category from searching or fetching a single work.
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 clear guidance to pass category names from get_work rather than inventing them, explains that unknown categories behave like empty ones, and explicitly handles the common multi-category question by advising the agent to browse one category and read the other off each work. It does not explicitly name sibling alternatives like search_works, but the usage context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read what IMSLP holds about a person: the name as its page prints it, the life dates it states, the other names it files them under, the registers holding a record of them, and the addresses it points to off the site. The person is named by the category the library addresses them by, written 'Category:Surname, Forename', which search_people finds. The prefix may be left out. Life dates come back in the wording the page used, since the library writes '1861-1934' on one page and '4 March 1861 — 2 November 1934' on another, and a page holding none says so. This reads the person; list_person_works reads what they wrote. When you show a person to a user, credit IMSLP and link the page.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | The person's category, written 'Category:Surname, Forename', for example 'Category:Satie, Erik'. The prefix is added when it is left out. |
| Name | Required | Description |
|---|---|---|
| name | Yes | The name as the page prints it, which reads forename first. |
| notes | Yes | |
| source | Yes | |
| aliases | Yes | The aliases line as published, separated the same way. |
| license | Yes | |
| category | Yes | The category the library addresses them by. |
| page_url | Yes | |
| life_dates | Yes | The dates beside the name, exactly as published. Null when the page prints none. |
| authorities | Yes | |
| catalogued_as | Yes | The name without the prefix, surname first. |
| external_links | Yes | |
| alternative_names | Yes | The other names and transliterations the library files them under, as the line was published. It separates names with commas and a name written surname first carries one of its own, so the line is not cut into a list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and related annotations covering safety, the description adds valuable behavioral context: date formatting varies by page, missing dates are explicitly reported, the category prefix may be omitted, and the output should credit IMSLP with a link. This goes well beyond what annotations or schema state.
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 description is longer than average, but every sentence contributes: result contents, category format, date-format caveat, sibling distinction, and attribution requirement. It is dense but not padded, though it could be slightly tightened without losing value.
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?
Given the output schema exists, the description sufficiently covers how to invoke the tool, what inputs are expected, the variability of life-date formatting, and even user-facing attribution instructions. Nothing critical for correct usage 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 baseline is 3, but the description enriches the single parameter by explaining the category convention, the optional prefix, and how to obtain the category via search_people. This adds meaningful guidance beyond the schema's own text.
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 specific verb ('Read') and resource ('what IMSLP holds about a person'), enumerating the exact facets returned: name, life dates, aliases, registers, and off-site addresses. It also distinguishes itself from the sibling list_person_works, making the tool's purpose unambiguous.
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 contrasts with list_person_works ('This reads the person; list_person_works reads what they wrote') and directs agents to search_people for finding the category. It does not enumerate every sibling exclusion, but it gives clear context for the main alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one work on IMSLP: its title and alternative titles, the composer, the opus and catalogue numbers, the year it was written and the year it was first published, the dedication, the key, the instrumentation, the style and period, and how many scores and recordings the page holds. Address a work by its page title, written 'Work (Composer)', for example 'Nocturnes, Op.9 (Chopin, Frédéric)', or by the page id. Dates and durations come back in the wording the page used: 'ca.1830' stays 'ca.1830', because a bare year would state a certainty the library declined to state. A facet the page leaves empty comes back null rather than guessed. A work holding a few editions comes back with them, files included. One holding many comes back with 'editions' null and 'editions_truncated' true, and list_work_files pages through them. The copyright of a score is stated per jurisdiction: 'Public Domain - Non-PD US' is free in Canada and the European Union and protected in the United States, so never report a score as public domain without saying where. No score file is downloaded or linked; the work page is what an answer links to. When you show a work to a user, credit IMSLP and link that page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The title of the work's page, written 'Work (Composer)', for example 'Nocturnes, Op.9 (Chopin, Frédéric)'. Pass this or 'pageid', not both. | |
| pageid | No | The page id a search returns. Pass this or 'page', not both. |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| notes | Yes | |
| title | Yes | |
| pageid | Yes | The number IMSLP gives the page. Known when the work was addressed by it, and null when it was addressed by title: a rendered page states its title and nothing else. |
| source | Yes | |
| license | Yes | |
| composer | Yes | |
| editions | Yes | Every edition the page holds, files included. Null when the work holds more of them than one answer carries, and list_work_files then pages through them. |
| language | Yes | |
| page_url | Yes | |
| sections | Yes | The sections of the page, with the number of entries the site counts in each. |
| movements | Yes | |
| dedication | Yes | |
| librettist | Yes | |
| page_title | Yes | |
| authorities | Yes | Records of the work in library catalogues: VIAF, LCCN, WorldCat, BNF, GND. |
| piece_style | Yes | |
| external_links | Yes | |
| composer_period | Yes | |
| instrumentation | Yes | |
| redirected_from | Yes | The title asked for, when it redirected here. |
| average_duration | Yes | |
| composition_year | Yes | As published, for example 'ca.1830'. |
| genre_categories | Yes | |
| alternative_title | Yes | |
| composer_page_url | Yes | |
| copyright_summary | Yes | The terms the scores of this work are published under, one entry per distinct statement, with the number of editions on the page carrying it. Stated whether or not the editions themselves fit in this answer. |
| extra_information | Yes | |
| first_performance | Yes | |
| first_publication | Yes | |
| editions_truncated | Yes | |
| opus_catalogue_number | Yes | |
| internal_catalogue_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds substantial behavior beyond them: dates preserve original wording, empty facets return null, edition truncation is disclosed, copyright is jurisdiction-dependent, and no score files are linked. These are exactly the behavioral nuances an agent needs.
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 description is long but every sentence earns its place, covering addressing, truncation behavior, copyright caveats, and linking policy. It is front-loaded with the core purpose and then layers necessary edge-case behavior, making it well-suited to a nuanced read operation.
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?
Given the tool's complexity, the availability of an output schema, and the annotation set, the description is complete. It tells the agent how to identify a work, what to expect for truncated editions, how to handle copyright statements, and what to link when presenting results. No critical calling guidance 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 description coverage is 100%, so the baseline is 3. The description repeats the page title format and the 'pass this or pageid, not both' rule already present in the schema, adding no new parameter-level meaning. It does not compensate beyond the schema because none is needed.
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 opens with 'Read one work on IMSLP' and enumerates exactly what fields come back, making the verb, resource, and scope explicit. It is clearly distinguished from siblings like search_works and list_work_files, which search or page through files rather than reading a single work.
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?
The description gives concrete addressing instructions ('page title' vs 'page id') and explicitly points to list_work_files when a work has many editions and 'editions_truncated' is true. This provides a clear when-to-use-this vs when-to-use-that signal, including an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the works IMSLP files under a person: what a composer wrote, and also what an editor, an arranger or a performer is credited on. The person is named by the category the library addresses them by, written 'Category:Surname, Forename', which search_people finds. The prefix may be left out. IMSLP publishes no count of what a category holds, so 'total' is always null; 'has_more' and 'cursor' say whether the library held more rows and how to read them. A category the library does not hold answers exactly as an empty one does, so an answer with no rows means one of the two rather than a person without works. When you show a work to a user, credit IMSLP and link the page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to serve, from 1 to 100. | |
| cursor | No | The 'cursor' a previous answer named, to read on from where it stopped. The library writes it itself, so it is passed back as it was given rather than built. | |
| category | Yes | The person's category, written 'Category:Surname, Forename', for example 'Category:Chopin, Frédéric'. The prefix is added when it is left out. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| total | Yes | Always null: IMSLP publishes no count of what a category holds. |
| cursor | Yes | The cursor to read on from, as the library named it. Null when it named none. |
| source | Yes | |
| license | Yes | |
| results | Yes | |
| category | Yes | The category as it reached the library, prefix included. |
| has_more | Yes | True when the library named a cursor to continue from. |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and idempotent, and the description adds valuable edge-case behavior: total is always null because IMSLP publishes no count, has_more/cursor control pagination, and an unknown category returns exactly the same empty response as a known empty one. This materially affects how an agent should interpret results.
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 description is front-loaded with purpose, then covers important edge cases concisely. A small amount of redundancy with the schema (prefix may be omitted) keeps it from being perfectly compact, but every sentence contributes.
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 list tool with an output schema, it explains pagination, the null total, the empty-category ambiguity, and the attribution requirement. An agent has enough behavioral context to call it correctly and interpret results without guessing.
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 schema already documents category, limit, and cursor. The description adds context that category comes from search_people and that cursor relates to has_more, but it largely repeats schema-level detail rather than adding new parameter semantics.
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 opens with a specific verb and resource: 'Read the works IMSLP files under a person', and expands scope to composer/editor/arranger/performer credits. This clearly distinguishes it from siblings like search_works, get_person, and list_work_files.
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 tool is for listing works credited to a person and explains that the person must be addressed by a category, which 'search_people finds'. It gives clear identification context but does not explicitly name exclusions or alternate tools to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the scores and recordings a work on IMSLP holds, edition by edition. An edition is a set of files published under one set of terms: the publisher, the editor and the copyright statement belong to the edition, and its files are the entries under it. A block of recordings carries performers instead, and no copyright statement at all. Address the work by its page title, written 'Work (Composer)', or by its page id, and read it a page at a time with 'limit' and 'offset'. 'editions_on_page' counts the editions the page holds, so it says how far a reading can go. Restrict to one part of the page with 'section', using the names the page itself prints: 'Scores', 'Parts', 'Arrangements and Transcriptions', 'Recordings', 'Full Scores' and others. A restriction matching nothing comes back with the sections the page does hold rather than as a work without scores. The copyright of a score is stated per jurisdiction: 'Public Domain - Non-PD US' is free in Canada and the European Union and protected in the United States, so never report a score as public domain without saying where. No score file is downloaded or linked; the work page is what an answer links to. When you show an edition to a user, credit IMSLP and link that page.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The title of the work's page, written 'Work (Composer)', for example 'Nocturnes, Op.9 (Chopin, Frédéric)'. Pass this or 'pageid', not both. | |
| limit | No | Editions to serve, from 1 to 100. | |
| offset | No | Editions to skip, for reading a work whose page holds many. | |
| pageid | No | The page id a search returns. Pass this or 'page', not both. | |
| section | No | One section of the page, in the wording the page prints: 'Scores', 'Parts', 'Recordings', 'Arrangements and Transcriptions', 'Full Scores', 'Synthesized/MIDI'. Matched without regard to case. Left out, every section is read. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| title | Yes | The work these editions belong to. |
| offset | Yes | |
| pageid | Yes | |
| source | Yes | |
| license | Yes | |
| section | Yes | The restriction this answer was read under. |
| composer | Yes | |
| editions | Yes | |
| has_more | Yes | |
| page_url | Yes | |
| returned | Yes | |
| sections | Yes | The sections of the page, with the number of entries the site counts in each. |
| page_title | Yes | |
| redirected_from | Yes | |
| editions_on_page | Yes | Editions the page holds, counted here rather than published by IMSLP. |
| editions_in_section | Yes | Editions left after the restriction, equal to 'editions_on_page' without one. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already indicate read-only, idempotent, open-world, and non-destructive behavior, the description adds valuable behavioral detail: no score files are downloaded or linked, empty section restrictions return available sections, copyright must be reported by jurisdiction, and attribution is required. This goes well beyond the annotations.
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 description is longer than average but every sentence contributes practical guidance for a tool with five parameters and several edge cases. It is front-loaded with the core purpose, then moves through addressing, pagination, sections, copyright, and attribution in a logical order.
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 tool with this complexity, the description covers all essential calling details: how to identify the work, pagination semantics, section restrictions, empty-result behavior, copyright caveats, and linking requirements. An output schema exists and supplies return structure, so the description does not need to restate return fields.
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 schema already documents each parameter. The description adds real semantic value by defining what an edition is, explaining that editions_on_page bounds pagination, clarifying section value wording, and describing the empty-section fallback. It does not merely repeat the schema.
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 opens with a specific action and resource: reading the scores and recordings a work on IMSLP holds, edition by edition. It clearly distinguishes this from siblings like search_works, get_work, and list_person_works by focusing on editions and files rather than work metadata or person-level listings.
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?
The description gives concrete usage context: address the work by title or page id, paginate with limit and offset, and restrict by section using page-printed names. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the composers, editors, arrangers and performers of IMSLP by name. The library addresses a person by a category, written 'Category:Surname, Forename', and that is what list_person_works and get_person take. A name is written the library's own way, so searching finds it where guessing at the spelling does not. Some rows stand for another category rather than for a person: the library keeps a redirect for a name spelled differently, and 'redirect_to' names the category it leads to. Follow it rather than reading works under the redirect, which holds none. IMSLP publishes no count of what a search matched, so 'total' is always null. When you show a person to a user, credit IMSLP and link the page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to serve, from 1 to 50. | |
| query | Yes | What to look for among the people of the library. Words are matched across the page, not only titles. | |
| offset | No | Rows to skip, using the 'next_offset' a previous answer named. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| query | Yes | The search as it reached the library. |
| total | Yes | Always null: IMSLP publishes no count of what a search matched. |
| offset | Yes | |
| source | Yes | |
| license | Yes | |
| results | Yes | |
| has_more | Yes | True when the library named an offset to continue from. |
| returned | Yes | |
| next_offset | Yes | The offset to read on from, as the library named it. Null when it named none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses meaningful behaviors: redirects appear as rows and should be followed rather than used for works, 'total' is always null because IMSLP provides no count, and attribution to IMSLP is required when displaying results. This significantly helps the agent interpret results.
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 description is front-loaded with the core purpose and each subsequent sentence earns its place by explaining redirects, count behavior, downstream usage, or attribution. It is detailed without becoming wasteful.
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?
The description covers purpose, result interpretation, redirect handling, missing total counts, and how to use the result with sibling tools. With annotations indicating read-only behavior and an output schema present, nothing essential is missing for correct selection and invocation.
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 useful query semantics: names use the library's own spelling, so searching is more reliable than guessing. It also explains the category format relevant to interpreting the query results, giving the agent a better mental model of what it is matching.
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 identifies the resource (people/contributors in IMSLP) and the action (search by name), and distinguishes it from search_works by focusing on person-oriented entities. It also clarifies that results are categories like 'Category:Surname, Forename', which is essential for downstream use.
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?
The description explains why to use this search rather than guessing spellings, and tells the agent that the resulting category is what list_person_works and get_person consume. It does not explicitly contrast with search_works, but the context is clear enough for an agent to select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the works of IMSLP by title, by composer, or by words printed on their pages. Each row names the page of a work, which is how get_work and list_work_files address it: a title is written 'Work (Composer)', and the row splits it into the work and the person it names. IMSLP publishes no count of what a search matched, so 'total' is always null; 'has_more' and 'next_offset' say whether the library held more rows and where to read on from. A snippet is words taken from the page around the match. The library writes its pages in wikitext, so a snippet sometimes shows the name of a file rather than a sentence, and some rows carry none at all. The library titles a work in the language its composer used, so 'Die Zauberflöte' and not 'The Magic Flute', 'Sinfonia' and not 'Symphony'. A title translated into another language finds nothing, or finds only the works written about it: rows that look thin for a famous work are a sign the work sits under its original title, not that the library lacks it. Searching for a person by name finds the works naming them; search_people finds the person. When you show a result to a user, credit IMSLP and link the page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Rows to serve, from 1 to 50. | |
| query | Yes | What to look for in the works of the library. Words are matched across the page, not only titles. | |
| offset | No | Rows to skip, using the 'next_offset' a previous answer named. |
| Name | Required | Description |
|---|---|---|
| limit | Yes | |
| notes | Yes | |
| query | Yes | The search as it reached the library. |
| total | Yes | Always null: IMSLP publishes no count of what a search matched. |
| offset | Yes | |
| source | Yes | |
| license | Yes | |
| results | Yes | |
| has_more | Yes | True when the library named an offset to continue from. |
| returned | Yes | |
| next_offset | Yes | The offset to read on from, as the library named it. Null when it named none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation, and the description adds valuable behavior beyond that: 'total' is always null, snippets may show filenames or be absent, wikitext can affect results, and attribution to IMSLP is required. No contradictions with the annotations.
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 description is long but information-dense, front-loading the core purpose and then adding caveats that materially affect result interpretation. Each paragraph earns its place, though it could be trimmed slightly without losing meaning.
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 search tool with an output schema, the description covers query semantics, title-language pitfalls, pagination fields, snippet behavior, the relationship to sibling tools, and attribution requirements. Nothing essential for correct invocation and interpretation appears to be 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 a baseline of 3 applies, but the description enriches query semantics by explaining that words are matched across the page, not only titles, and that titles are in the composer's original language. It also explains pagination through 'next_offset', adding meaning to the offset parameter beyond the schema's type and default.
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?
States a specific verb and resource: 'Search the works of IMSLP by title, by composer, or by words printed on their pages.' It also differentiates from search_people by explaining that searching a person finds works naming them while 'search_people finds the person,' so an agent can distinguish it from its sibling.
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?
Gives explicit usage context: searches by title, composer, or page text, and warns that translated titles find nothing, pointing users to the original title. It explicitly names the alternative for person lookups ('search_people finds the person'), telling the agent when not to use this tool.
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.
v1.0.0browse_categoryget_personget_worklist_person_workslist_work_filessearch_peoplesearch_worksScored across 7 tools
Each tool targets a clearly distinct resource and action: searching works vs people, fetching a single work/person, listing files, and browsing categories. Even where list_person_works and browse_category both return work lists, the descriptions make the boundary explicit.
All tool names follow a consistent verb_noun snake_case pattern: search_*, get_*, list_*, and browse_category. The pattern makes the intended operation and target predictable across the entire set.
Seven tools is well-scoped for an IMSLP access server, covering search, entity retrieval, file listing, and category browsing without redundancy. Each tool earns its place in the workflow.
The surface covers the full read-oriented workflow: discover works/people, fetch metadata, enumerate editions and files, and browse by category. The explicit choice not to download files or link them is consistent, and no major workflow dead-ends are evident.
The CWI Discovery Engine is the MCP server for the Cumulative Web Inc music catalog — 28 tools for AI agents: catalog search, track/artist/release lookups, semantic and mood-based sync search, Radio 365 live stream data, playlist pitching, sync-brief submission, airplay requests, featured nominations, label info, events, lyrics, press kits, videos, genres, playlists and recommendations. No authentication required. Free.
Search YouTube, read video metadata, and fetch transcripts with language preferences
ScanSing reads printed sheet music. Give Claude a PDF or a photo of a score and it gets back MusicXML, the format MuseScore, Sibelius, Finale and Dorico open. It is the recogniser inside the ScanSing app for choir singers, offered as a connector. Once a score is recognised, Claude can answer questions about it without recognising it again: - what the key, time signature, tempo and length are, and each part's range, clefs and lyrics; - one voice on its own, for example just the alto line of a choir piece; - the score or a part moved to another key, with notes respelled for the new key signature; - a MIDI file, one track per part, to listen to or rehearse with; - a short-lived download link to open the result in a browser or notation app. It handles PDFs up to 40 pages and PNG, JPEG, HEIC, TIFF and WebP images, can recognise selected pages of a long PDF, and can split a songbook into one MusicXML per piece. A file can be given as a web link or a small image; in Claude Code, a file on your computer is sent through a one-time upload link. Recognition spends pages from your ScanSing plan, so it is the only tool that is not read-only. Everything else works on the stored result and is free. The first connection with a new email comes with 20 free pages; paid plans start at $9 a month for 300 pages. Scores and results are deleted about an hour after recognition and are never used for training.
Academic literature search, retrieval, and private library management on top of OpenAlex.
