musette-mcp
Server Details
AI soigneur for cyclists: Strava ride to an Ien-Vitse-validated nutrition plan + orderable box.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.6/5.
Most tools have clearly distinct purposes: plan calculation, product assembly, ordering, recovery advice, event search, and info. Some overlap exists between bereken_voedingsplan and stel_musette_samen (both calculate plans), but descriptions clarify that the latter also assembles products and gives an order link, reducing ambiguity.
Tool names mix Dutch and English (e.g., 'bereken_voedingsplan' vs 'fetch'), and patterns vary: some are verb_noun (bestel_musette), one is a phrase (stel_musette_samen), and some are single words (ping, search). This inconsistency can confuse an agent.
With 9 tools, the server covers the core functionality of a cycling nutrition planning and ordering service without being overwhelming. Each tool serves a distinct role in the workflow, from event lookup to recovery advice, making the set well-scoped.
The tool surface covers the main use cases: plan calculation for custom rides or events, product assembly with ordering, and recovery advice. Missing features like order history or product management are not critical for the primary purpose, so only minor gaps.
Available Tools
9 toolsbereken_voedingsplanAInspect
Berekent het Ien-Vitse-gevalideerde wielren-voedingsplan voor één rit: koolhydraten per uur, totaal, hydratatie, een timing-/voedingsschema, productverdeling (drank/gel/reep) en veiligheidsadvies. Geef minimaal de afstand (afstand_km) óf de duur (duur_minuten). Hoe meer context (hoogtemeters, intensiteit, temperatuur), hoe nauwkeuriger het plan.
| Name | Required | Description | Default |
|---|---|---|---|
| binnen | No | Indoor/hometrainer (meer zweetverlies) | |
| geslacht | No | Voor FTP-schatting wanneer alleen vermogen bekend is | |
| afstand_km | No | Ritafstand in km (alternatief voor duur_minuten) | |
| intensiteit | No | Inspanningsniveau van de rit | |
| darmgetraind | No | Kan de renner >75 g/uur verdragen? | |
| duur_minuten | No | Geschatte rijduur in minuten (nauwkeuriger dan afstand) | |
| hoogtemeters | No | Totale klim in meters | |
| ftp_percentage | No | Exact % van FTP (overschrijft 'intensiteit') | |
| gem_snelheid_kmh | No | Gemiddelde snelheid, voor duurschatting uit afstand | |
| temperatuur_celsius | No | Verwachte buitentemperatuur |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Er zijn geen annotaties, dus de beschrijving draagt de volledige last. Hoewel wordt vermeld dat het plan 'Ien-Vitse-gevalideerd' is en veiligheidsadvies bevat, ontbreken details over neveneffecten (geen mutaties), authenticatievereisten, of datalimieten. De tool is waarschijnlijk read-only, maar dat wordt niet expliciet gesteld.
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?
De beschrijving is één alinea van ~50 woorden, front-loaded met de functie en vervolgens de vereisten en output. Efficiënt en zonder overbodige informatie. Het had iets compacter gekund, maar is duidelijk.
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?
Gezien de complexiteit (10 parameters, geen output schema, geen annotaties) is de beschrijving redelijk compleet, maar mist details over het outputformaat (JSON/tekst?) en hoe het plan wordt gepresenteerd. De lijst met componenten helpt, maar specifiekere verwachtingen over de returnwaarde ontbreken.
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?
De schemabeschrijvingen dekken alle 10 parameters volledig (100%), dus baseline is 3. De beschrijving voegt waarde toe door de minimale vereiste (afstand of duur) en het voordeel van meer context te benadrukken, wat niet uit het schema alleen blijkt.
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?
Het doel is duidelijk: het berekenen van een Ien-Vitse-gevalideerd voedingsplan voor één wielerrit. De beschrijving somt specifieke uitvoercomponenten op (koolhydraten per uur, totaal, hydratatie, etc.) en onderscheidt zich impliciet van sibling tools zoals bestel_musette of herstel_voeding.
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?
De beschrijving geeft expliciet aan dat minimaal afstand_km of duur_minuten moet worden opgegeven, en moedigt aan om meer context te geven voor nauwkeurigheid. Er wordt echter niet aangegeven wanneer de tool niet gebruikt moet worden of wat de alternatieven zijn bij sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bestel_musetteAInspect
LAATSTE stap van de bestelling — gebruik deze tool PAS nadat de gebruiker het voedingsplan én de samengestelde musette met de prijs heeft gezien en bevestigt te willen bestellen. Werkwijze: toon EERST het plan (bereken_voedingsplan) en de musette met producten + totaalprijs (stel_musette_samen). Vraag PAS daarna, als de gebruiker wil afrekenen, om e-mailadres en bezorgadres (voornaam, achternaam, straat + huisnummer, postcode, plaats, land). Deze tool berekent het plan opnieuw, stelt dezelfde musette samen en maakt een directe Stripe-betaallink met winkelwagen + bezorgadres al ingevuld — één klik om af te rekenen. Gebruik dezelfde rit-gegevens als bereken_voedingsplan. Alleen Nederland en België. Voor alleen een overzicht zonder afrekenen: gebruik 'stel_musette_samen'.
| Name | Required | Description | Default |
|---|---|---|---|
| land | No | Land: NL of BE (standaard NL) | |
| Yes | E-mailadres voor de bevestiging | ||
| binnen | No | Indoor/hometrainer (meer zweetverlies) | |
| plaats | Yes | Woonplaats | |
| geslacht | No | Voor FTP-schatting wanneer alleen vermogen bekend is | |
| postcode | Yes | Postcode | |
| voornaam | Yes | Voornaam van de ontvanger | |
| achternaam | Yes | Achternaam van de ontvanger | |
| afstand_km | No | Ritafstand in km (alternatief voor duur_minuten) | |
| intensiteit | No | Inspanningsniveau van de rit | |
| darmgetraind | No | Kan de renner >75 g/uur verdragen? | |
| duur_minuten | No | Geschatte rijduur in minuten (nauwkeuriger dan afstand) | |
| hoogtemeters | No | Totale klim in meters | |
| merk_voorkeur | No | Merkvoorkeur voor de producten (standaard: amacx) | |
| ftp_percentage | No | Exact % van FTP (overschrijft 'intensiteit') | |
| gem_snelheid_kmh | No | Gemiddelde snelheid, voor duurschatting uit afstand | |
| straat_huisnummer | Yes | Straat + huisnummer, bv. 'Weesperstraat 107' | |
| temperatuur_celsius | No | Verwachte buitentemperatuur |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's actions: recalculating plan, composing musette, and generating a Stripe payment link. It mentions geographic restriction (NL/BE) and reuse of ride data. Lacks details on idempotency or duplicate prevention, but sufficient for a payment tool.
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 structured in a logical order (workflow, then details). While slightly verbose, every sentence adds necessary context. Efficient for the complexity involved.
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 18 parameters, no output schema, and multiple sibling tools, the description provides sufficient context: prerequisite steps, required address inputs, and the Stripe link output. It explains the tool's role in the broader ordering process comprehensively.
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. The description adds context by grouping required address fields and noting reuse of ride parameters from 'bereken_voedingsplan'. However, it does not elaborate on each parameter beyond what the schema already provides in Dutch.
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 this tool as the final ordering step, specifying that it creates a Stripe payment link after the user confirms. It distinguishes itself from the sibling 'stel_musette_samen' which is for overview only.
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?
Explicitly states when to use (after user has seen plan and musette and confirmed) and when not to use (for overview alone, use 'stel_musette_samen'). Provides a clear workflow sequence with prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchAInspect
Haalt het volledige Musette-voedingsplan op voor een zoekresultaat-id uit 'search': koolhydraten per uur, timing-/voedingsschema, hydratatie, veiligheidsadvies én een kant-en-klare musette met directe bestel-link. Gevalideerd door Ien Vitse (sportdiëtist, ex-Jumbo-Visma).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Het id uit een 'search'-resultaat |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return content comprehensively (carbs, timing, hydration, safety advice, order link) and mentions validation by a dietitian. It implies a read operation with no side effects, which is transparent.
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 a single, front-loaded sentence that immediately states the primary action. It is slightly long but contains no redundancy; every clause provides useful information.
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 no output schema and a single required parameter, the description fully explains what the tool does and what it returns. It covers the parameter's origin and the return contents, leaving no ambiguity for a fetch operation.
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% with a description that the 'id' is from a 'search' result. The description adds value by reinforcing that the id originates from 'search', slightly enriching the schema. Baseline 3 is elevated due to the contextual linkage.
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 the tool fetches a full Musette nutrition plan for a search result ID, listing specific contents (carbs per hour, timing, hydration, safety advice, musette with order link). It is distinguished from siblings like 'search' (which retrieves IDs) and 'bestel_musette' (ordering).
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 indicates the tool should be used after a 'search' result ID is available, providing clear context. It does not explicitly state when not to use it or mention alternatives, but the linkage to 'search' is sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
herstel_voedingAInspect
Geeft het Ien-gevalideerde HERSTEL-advies ná een rit: hoeveel koolhydraten en eiwit in welk venster (0–30 min, 30–120 min, 2–24 u), hydratatie (150% van het zweetverlies) en praktische voorbeelden. Pas dit toe op een net voltooide rit — voed het met de echte rit-gegevens (duur of afstand, intensiteit, hoogtemeters, temperatuur). Geef 'gewicht_kg' voor concrete grammen. Let op: dit is advies; herstel-producten zijn nog niet los te bestellen.
| Name | Required | Description | Default |
|---|---|---|---|
| binnen | No | Indoor/hometrainer (meer zweetverlies) | |
| geslacht | No | Voor FTP-schatting wanneer alleen vermogen bekend is | |
| afstand_km | No | Ritafstand in km (alternatief voor duur_minuten) | |
| gewicht_kg | No | Lichaamsgewicht in kg — voor concrete grammen i.p.v. per-kilo-richtlijnen | |
| intensiteit | No | Inspanningsniveau van de rit | |
| darmgetraind | No | Kan de renner >75 g/uur verdragen? | |
| duur_minuten | No | Geschatte rijduur in minuten (nauwkeuriger dan afstand) | |
| hoogtemeters | No | Totale klim in meters | |
| ftp_percentage | No | Exact % van FTP (overschrijft 'intensiteit') | |
| gem_snelheid_kmh | No | Gemiddelde snelheid, voor duurschatting uit afstand | |
| temperatuur_celsius | No | Verwachte buitentemperatuur |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool gives advice only, not ordering capabilities, and covers specific recovery windows and hydration formulas. It doesn't mention authorization or side effects, but the behavioral context is sufficient for a computation tool.
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 concise with three sentences, front-loading the main purpose and then providing usage instructions and a note. Every sentence adds value, with no wasted words.
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 11 parameters, no output schema, and no annotations, the description explains the input well and outlines the output (carbs/protein windows, hydration). It lacks explicit details on the output format or structure, which would aid complete understanding, but it is adequate for agent 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?
The description adds meaning beyond the 100% schema coverage by explaining how parameters like 'gewicht_kg' yield concrete gram amounts, and how 'binnen' affects sweat loss. It clarifies the role of intensity, elevation, and temperature, and that duration or distance can be used, which the schema alone doesn't convey in the tool's context.
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 the tool's purpose: it provides Ien-validated recovery advice after a ride, detailing carbohydrate and protein intake windows, hydration guidelines, and examples. It differentiates from siblings like 'bereken_voedingsplan' by focusing specifically on post-ride recovery, using verbs like 'Geeft' and 'Pas dit toe'.
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 tells the agent to apply the tool to a just-completed ride with real ride data, specifying parameters like duration/distance, intensity, elevation, and temperature. It also mentions to provide 'weight_kg' for concrete grams. However, it lacks explicit exclusions or alternatives, such as when not to use this tool versus 'bereken_voedingsplan'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
musette_infoAInspect
Vertelt wat Musette is en wat de De Soigneur MCP straks kan: een wielren-voedingsplan gevalideerd door WorldTour-soigneur Ien Vitse, omgezet in een kant-en-klare musette met één-klik-bestelling. Gebruik dit om de gebruiker uit te leggen wat er mogelijk is.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently states that the tool provides informational content without side effects. While it could explicitly note that it is read-only, the nature is clearly non-destructive.
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 two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence earns its place, providing both what the tool does and how to use it.
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 has no parameters and no output schema, the description is complete enough to understand its function. It explains the informational output ('vertelt wat Musette is en wat de MCP kan') and when to use it. However, it does not specify the return format, which could be helpful.
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?
The tool has zero parameters, so schema coverage is 100%. The description adds meaning beyond the empty schema by explaining the tool's purpose and usage. It effectively compensates for the lack of parameter details.
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 the tool's purpose: explaining what Musette is and what the De Soigneur MCP can do. It uses a specific verb ('vertelt') and resource ('Musette'), and distinguishes from sibling tools that compute plans, order, or fetch data.
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 provides a clear usage guideline: 'Gebruik dit om de gebruiker uit te leggen wat er mogelijk is.' It implicitly suggests when to use (for introducing the MCP) but does not explicitly mention when not to use or alternatives. However, given the tool's simplicity, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pingAInspect
Controleert of de Musette MCP-server bereikbaar is. Geeft 'pong' + serverinfo terug.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses return value ('pong + serverinfo'), which is adequate for a simple ping. No mention of errors or timeouts, but acceptable for this tool.
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 short sentences with no fluff, front-loaded with purpose. Every word 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?
Given no parameters, no output schema, and a simple purpose, the description is complete enough. It explains input (none) and output (pong + serverinfo). No missing aspects.
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 has zero parameters with 100% coverage, so baseline is 4. Description adds no parameter info, but 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?
Description clearly states the tool checks server reachability and returns 'pong + serverinfo', distinguishing it from siblings like 'fetch' which likely performs HTTP requests. Verb 'controleert' (checks) and resource 'Musette MCP-server' are specific.
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 implies usage for verifying connectivity, but does not explicitly state when not to use or mention alternatives. However, for a simple ping tool with no parameters, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Doorzoekt Musette naar een wieler-voedingsplan. Geef een evenement/toertocht-naam (bv. 'La Marmotte') óf een ritbeschrijving (bv. '120 km 2000 hm tempo'). Geeft per match een voedingsplan-document terug dat je met 'fetch' ophaalt. Gebruik dit bij vragen over wielervoeding, koolhydraten per uur, of bevoorrading voor een rit of evenement.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Evenementnaam of ritbeschrijving (afstand + hoogtemeters + intensiteit) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool returns a document reference to be fetched with 'fetch', not the full plan. With no annotations, this is valuable 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?
Three concise sentences with front-loaded purpose, each sentence adding value: purpose, input, output and use cases.
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?
Adequately covers the tool's functionality given its simplicity. Missing details on result format or limits, but reference to 'fetch' suffices.
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%, but the description adds practical context on input format (e.g., '120 km 2000 hm tempo'), enhancing understanding beyond 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 clearly states it searches Musette for a cycling nutrition plan, specifies input type (event name or ride description), and distinguishes from siblings by focusing on cycling nutrition queries.
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?
Explicit guidance on when to use (cycling nutrition, carbs per hour, provisioning) and what input to provide (event name or ride description). Implicitly contrasts with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
stel_musette_samenAInspect
Zet een rit om in een kant-en-klare musette: berekent het Ien-gevalideerde plan, kiest concrete producten + aantallen (Amacx/Maurten) en geeft een directe bestel-link naar musette.cc met de winkelwagen al gevuld. Gebruik dezelfde rit-gegevens als bereken_voedingsplan.
| Name | Required | Description | Default |
|---|---|---|---|
| binnen | No | Indoor/hometrainer (meer zweetverlies) | |
| geslacht | No | Voor FTP-schatting wanneer alleen vermogen bekend is | |
| afstand_km | No | Ritafstand in km (alternatief voor duur_minuten) | |
| intensiteit | No | Inspanningsniveau van de rit | |
| darmgetraind | No | Kan de renner >75 g/uur verdragen? | |
| duur_minuten | No | Geschatte rijduur in minuten (nauwkeuriger dan afstand) | |
| hoogtemeters | No | Totale klim in meters | |
| merk_voorkeur | No | Merkvoorkeur voor de producten (standaard: amacx) | |
| ftp_percentage | No | Exact % van FTP (overschrijft 'intensiteit') | |
| gem_snelheid_kmh | No | Gemiddelde snelheid, voor duurschatting uit afstand | |
| temperatuur_celsius | No | Verwachte buitentemperatuur |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the actions (calculate, choose products, give link) but does not disclose whether any side effects occur (e.g., placing an order or saving a cart). The return value is implied (a link) but not explicitly stated. The phrase 'directe bestel-link' could be interpreted as a direct order link, but it's unclear if clicking it would immediately place an order.
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 a single long sentence that conveys the essential information. It could be broken into two for better readability, but it is not overly verbose. It is front-loaded with the main action and key details.
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 explains the main functionality but lacks details about the output format (e.g., whether it returns a link, the plan, or both). Since there is no output schema, the description should be more explicit about what the agent receives after invocation. The reference to 'Ien-gevalideerd' adds specialized context but is vague.
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 input schema already explains all 11 parameters well. The description adds no additional parameter context beyond referencing 'dezelfde rit-gegevens' as the sibling tool. With full coverage, the baseline is 3, and the description does not elevate it further.
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 that the tool converts a ride into a musette by calculating an Ien-validated plan, selecting specific products (Amacx/Maurten) with quantities, and providing a direct order link. This distinguishes it from siblings like 'bereken_voedingsplan' which likely only calculates the plan.
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 mentions using the same ride data as 'bereken_voedingsplan', implying a use case after that sibling. However, it does not explicitly state when to use this tool versus alternatives like 'bestel_musette' or 'bereken_voedingsplan' alone. The guidance is implicit rather than clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zoek_evenementAInspect
Zoekt een wielerevenement of toertocht op naam op en geeft datum, locatie en de beschikbare afstanden (km + hoogtemeters) terug. Gebruik dit als de gebruiker een evenement noemt, en voed daarna bereken_voedingsplan / stel_musette_samen met de gekozen afstand en hoogtemeters.
| Name | Required | Description | Default |
|---|---|---|---|
| naam | Yes | Naam van het evenement, bv. 'Amstel Gold Race' of 'La Marmotte' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states functionality. It does not disclose behavioral traits such as read-only nature, rate limits, or auth requirements. The usage guidance implies a safe operation, but transparency is minimal.
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 two concise sentences, front-loaded with the main purpose, followed by explicit usage guidance. No superfluous text.
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 simple single-parameter tool and no output schema, the description adequately explains the return data (date, location, distances) and provides usage context. The chaining instruction adds completeness.
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% with a clear description for the single parameter 'naam'. The tool description adds no extra semantics beyond the schema, so baseline score of 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 uses specific verbs ('zoekt' = searches) and a clear resource ('wielerevenement of toertocht'), and explicitly states what data is returned (date, location, distances). It distinguishes itself from sibling tools like 'search' by focusing on cycling events and providing chaining instructions.
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 explicitly states when to use this tool ('als de gebruiker een evenement noemt') and how to chain it with subsequent tools ('bereken_voedingsplan / stel_musette_samen'), providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!