Classical music discovery: 656 composers (women & lesser-known), concerts in Belgium, CD reviews.
Scored across 5 tools
The composer tools (chercher_compositeurs vs fiche_compositeur) follow a clear search-then-detail pattern, and the concert tools (chercher_concerts vs prochains_concerts) differ by scope (general agenda vs composer-specific). However, the two concert tools share enough surface that an agent might occasionally pick the wrong one despite the descriptions.
All names use snake_case, but the verb pattern is inconsistent: chercher_compositeurs and chercher_concerts start with an infinitive verb, while disques_crescendo, fiche_compositeur, and prochains_concerts are noun phrases. The set is readable but lacks a predictable naming template.
Five tools is well within the ideal 3–15 range and each tool covers a distinct facet (composer search, composer detail, recordings, general concerts, composer concerts). No tool feels redundant or out of scope.
The surface covers composer discovery, deep profiles, recordings, and both general and composer-specific concert listings—a coherent lifecycle for a music magazine. Minor gaps remain, such as no general article search and no independent recording browse, but these are workaround-able via existing tools.
Recherche dans les 656 compositrices et compositeurs de Pauline (Crescendo Magazine), du Moyen Âge à la création contemporaine, avec une attention particulière aux compositrices, aux scènes belges et aux talents méconnus. Tous les critères sont facultatifs et combinables. Renvoie nom, dates, nationalité, période, notoriété et adresse de la fiche.
| Name | Required | Description | Default |
|---|---|---|---|
| texte | No | Mots à chercher dans le nom, la biographie et les œuvres (ex. « Ysaÿe », « quatuor », « orgue », « Liège ») | |
| limite | No | ||
| periode | No | ||
| notoriete | No | Niveau de notoriété auprès du grand public | |
| nationalite | No | Nationalité au féminin, en français (ex. « Belge », « Française », « Italienne ») | |
| compositrices | No | true : uniquement des compositrices |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description goes beyond that by disclosing the corpus size and provenance (656 entries, Crescendo Magazine), the temporal span, the editorial emphasis on women/Belgian/under-recognized composers, and the fields returned since no output schema exists.
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?
Two sentences, zero waste: the first front-loads the what/scope, the second the invocation rule, and the third the return shape. Dense but every clause carries information an agent needs.
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 6-parameter, all-optional search with no output schema, the description compensates by enumerating the returned fields (name, dates, nationality, period, notoriety, record URL) and stating the corpus scope. It could still say more about how 'texte' searches across name/biography/works, which is left to the schema alone.
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 67% and the description adds only a collective statement that all criteria are optional and combinable, not per-parameter meaning. It does not clarify 'limite', 'periode' beyond the self-describing enum, or how 'texte' interacts with the other filters, so it sits at the baseline for partial coverage.
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 (Recherche) and resource (compositeurs) and scopes it precisely: a corpus of 656 composers from Pauline/Crescendo Magazine, Medieval to contemporary, with emphasis on women composers and Belgian scenes. It is clearly a search tool, but it never names the sibling fiche_compositeur to distinguish lookup-by-detail from search.
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?
"Tous les critères sont facultatifs et combinables" tells the agent filters can be combined freely, which is useful invocation context. However, it gives no when-to-use vs alternatives guidance and no exclusions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche dans l'Agenda Crescendo : plus de 2 000 concerts de musique classique à venir en Belgique et dans l'Eurorégion (Hauts-de-France, Metz, Luxembourg, Maastricht, Aix-la-Chapelle). Tous les critères sont facultatifs et combinables (ex. « que joue Flagey en novembre », « opéra à Liège ce mois-ci », « Brussels Cello Festival »). Renvoie date, heure, titre, salle, ville, lien vers la page du concert et billetterie.
| Name | Required | Description | Default |
|---|---|---|---|
| pays | No | ||
| salle | No | Nom de la salle (ex. « Flagey », « Bozar », « Monnaie », « deSingel ») | |
| texte | No | Mots à chercher dans le titre, le programme, les compositeurs et les interprètes (ex. « Beethoven », « violoncelle », « Vox Luminis ») | |
| ville | No | Ville (ex. « Bruxelles », « Liège », « Lille », « Gand ») | |
| limite | No | ||
| date_fin | No | Date de fin AAAA-MM-JJ (incluse) | |
| festival | No | Nom du festival (ex. « Ars Musica », « Brussels Cello Festival ») | |
| categorie | No | ||
| date_debut | No | Date de début AAAA-MM-JJ (par défaut : aujourd'hui) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real context beyond annotations: the corpus size ("plus de 2 000 concerts"), geographic coverage, and the returned fields (date, heure, titre, salle, ville, lien, billetterie). It does not discuss pagination behavior or how the limite cap interacts with result volume, which keeps 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?
Three sentences, front-loaded with the resource and scope, then the flexibility of the criteria, then the return shape. Dense but every sentence carries information. Slightly crowded by the long parenthetical list of regions.
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 correctly compensates by enumerating the returned fields (date, heure, titre, salle, ville, liens). It also explains that all 9 parameters are optional and combinable, matching the 0-required schema. Minor gaps remain around result limits and ordering, but nothing essential to a correct call 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 67%, so most parameters are self-documented. The description's examples implicitly illustrate combinable filters (salle + date, categorie + ville + date, festival name), which adds some meaning beyond the schema. But the two enum parameters (pays, categorie) and the limite cap get no elaboration in the description, so it only marginally compensates for the coverage gap.
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 ("Recherche dans l'Agenda Crescendo") plus a concrete scope: 2000+ classical concerts in Belgium and the Eurorégion. This clearly separates it from chercher_compositeurs, disques_crescendo and fiche_compositeur. However, it never contrasts itself with prochains_concerts, which is the most closely overlapping sibling, so sibling differentiation is incomplete.
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 line "Tous les critères sont facultatifs et combinables" with three worked example queries ("que joue Flagey en novembre", "opéra à Liège ce mois-ci") gives useful implied guidance on how to combine filters. But there is no explicit when-to-use vs when-not, and the near-identical sibling prochains_concerts is never mentioned as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enregistrements de ce compositeur chroniqués par la rédaction de Crescendo Magazine (Phono.Crescendo), distinctions Joker et Millésime en tête, avec le lien vers chaque critique.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | ||
| compositeur | Yes | Nom ou identifiant Pauline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true); the description adds genuine context beyond them by disclosing result ordering (Joker and Millésime distinctions surfaced first) and that each entry includes a link to its review.
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?
A single dense sentence with no filler; the resource (recordings reviewed by Crescendo) is front-loaded, followed by ordering and content details. Slightly packed, but every clause earns its place.
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?
No output schema exists, and the description usefully sketches what comes back (ranked reviews with links). For a two-parameter read-only tool this is nearly sufficient; only the undocumented 'limite' parameter keeps it from being fully complete.
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 50%: 'compositeur' is documented ('Nom ou identifiant Pauline') but 'limite' has no description anywhere. The description references the composer concept but says nothing about the limit parameter, so it does not compensate for the coverage gap.
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+resource: recordings of a composer reviewed by Crescendo Magazine, including Joker/Millésime distinctions and review links. An agent can tell it returns disc reviews, but the description never contrasts it with siblings like fiche_compositeur, leaving the differentiation to be inferred.
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 implies a composer must be supplied ('Enregistrements de ce compositeur'), but gives no explicit when-to-use, when-not-to-use, or alternative tool. With three siblings, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fiche complète d'un compositeur ou d'une compositrice de Pauline : biographie rédigée par Crescendo Magazine, œuvres clés, œuvre pour commencer l'écoute, cote d'accessibilité, liens (fiche Pauline, articles Crescendo, écoute).
| Name | Required | Description | Default |
|---|---|---|---|
| compositeur | Yes | Nom (ex. « Louise Farrenc », « Haendel ») ou identifiant Pauline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds genuinely useful context by enumerating the returned profile sections, which matters because there is no output schema to describe the payload. It omits failure behavior (e.g. unknown composer) but is otherwise strong.
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?
A single front-loaded sentence that opens with the core purpose and then lists the payload contents without filler. The enumeration is dense but every item conveys what the caller will receive.
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 one-parameter, read-only lookup with a fully documented schema and no output schema, the description's enumeration of return contents largely covers what an agent needs. Only the relationship to the search sibling and error/not-found behavior are left implicit.
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%, and the single parameter already documents that it accepts a name or a Pauline identifier, with examples. The description adds no syntax, matching, or disambiguation detail beyond the schema, so the baseline of 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 names a precise resource — a complete profile of a Pauline composer — and enumerates exactly what the profile contains (biography, key works, accessibility rating, links), which is far more specific than the title alone. It does not, however, explicitly contrast itself with the sibling chercher_compositeurs, so an agent must infer that this is the detail-fetch counterpart to the search tool.
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?
There is no statement of when to use this tool versus the siblings. It never tells the agent to resolve a name via chercher_compositeurs first, nor when a profile lookup is appropriate rather than a concert or record query. Usage must be inferred entirely from the name and the listed contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prochains concerts en Belgique et dans l'Eurorégion (Lille, Aix-la-Chapelle, Luxembourg…) qui programment ce compositeur, d'après l'Agenda Crescendo. Renvoie date, titre, salle, ville et lien.
| Name | Required | Description | Default |
|---|---|---|---|
| compositeur | Yes | Nom ou identifiant Pauline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint) and the external-source nature (openWorldHint), so the description's job is supplementary. It adds real value by naming the source (Agenda Crescendo) and enumerating returned fields (date, titre, salle, ville, lien), which tells the agent what to expect from an otherwise opaque open-world read.
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?
Two compact sentences, front-loaded with the resource and its scope, followed by the return payload. Every clause earns its place 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?
With no output schema, the description carries the return-value burden and discharges it by listing the fields, and it discloses the data source and geographic limitation. For a single-parameter read-only lookup this is nearly complete; only the parameter format ambiguity remains.
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 single 'compositeur' parameter is already documented. The description adds nothing about accepted formats (name vs. Pauline identifier), 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?
States a specific verb-and-resource pair (list upcoming concerts that program a given composer) plus a clear geographic scope (Belgique/Eurorégion) and names the data source (Agenda Crescendo). It does not explicitly contrast itself with siblings like fiche_compositeur or disques_crescendo, but the resource type is distinct enough that an agent can separate them.
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?
Usage is implied rather than stated: the geographic scoping implicitly tells the agent this tool will not return concerts outside Belgium/Eurorégion, but there is no explicit 'use this when / use X instead' routing against the three sibling tools. Adequate but leaves the agent to infer the boundary.
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.
chercher_concerts1 field changedInput schema / properties / pays / enumPrevious value: -[
- "BE",
- "FR",
- "LU",
- "NL"
-]New value: +[
+ "BE",
+ "FR",
+ "LU",
+ "NL",
+ "DE"
+]chercher_concertschercher_compositeursdisques_crescendofiche_compositeurprochains_concertsRepertoire & program archive for classical vocalists. Match works from posters, save, search.
Agenda and ticketing for Toots Jazz Club, Brussels: browse concerts, check seats, reserve tickets.
Live-concert discovery: 44,000+ upcoming concerts worldwide by city, artist, genre or festival.
Catalogue, work pages, news and orchestras of the Ravel Edition, revised editions of Ravel's works
Add one secure layer between your agents and this server.
