mcp-imslp

Read the editions of a work

list_work_files

Read-onlyIdempotent

Discover all editions of a classical work on IMSLP—scores, parts, and recordings—paginated and filterable by section. Clarifies copyright per jurisdiction so you know what is usable.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server