Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cbr-mcp Wat is het slagingspercentage van rijschool 883?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Een MCP-server met de slagingspercentages en examencijfers van het CBR: per rijschool, per examencentrum, per stad en per provincie. Gratis, zonder account en zonder sleutel.
Het CBR publiceert zijn cijfers per rijschool, als losse momentopname. Wie het andersom wil zien, per examencentrum of per stad, of wie wil weten hoe een cijfer zich over de tijd ontwikkelt, moet dat zelf opbouwen. Dat is precies wat deze server teruggeeft.
Gemaakt en onderhouden door Ribba, de vergelijker voor rijscholen en gratis theorie in Nederland.
Er is geen account en geen sleutel nodig. Elke client hieronder start de server zelf met npx, dus je hoeft niets vooraf te installeren behalve Node 20 of nieuwer.
claude mcp add --scope user cbr -- npx -y @ribba/cbr-mcp--scope user schrijft hem naar ~/.claude.json, waarmee hij in al je projecten werkt en ook beschikbaar is in het Code-tabblad van de desktop-app. Laat je --scope weg, dan geldt hij alleen in de map waar je op dat moment staat. Wil je hem juist met je team delen, gebruik dan --scope project: die schrijft naar .mcp.json in de repo, en dat bestand hoort in versiebeheer.
codex mcp add cbr -- npx -y @ribba/cbr-mcpOf met de hand in ~/.codex/config.toml:
[mcp_servers.cbr]
command = "npx"
args = ["-y", "@ribba/cbr-mcp"]De Codex-CLI, de IDE-extensie en de ChatGPT-desktopapp lezen alle drie datzelfde bestand, dus één keer instellen is genoeg. Zet je het in .codex/config.toml binnen een project, dan geldt het alleen daar.
De chat-app deelt zijn instellingen niet met Claude Code en heeft een eigen bestand:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"cbr": {
"command": "npx",
"args": ["-y", "@ribba/cbr-mcp"]
}
}
}Herstart de app daarna. Heb je hem daar al staan en wil je hem ook in Claude Code, dan neemt claude mcp add-from-claude-desktop hem over.
Dezelfde JSON als hierboven, in het configuratiebestand van je client.
Related MCP server: nl-opendata-mcp
Vraag je client:
Wat is het landelijk slagingspercentage voor het autoexamen?
Komt er een antwoord met cijfers, dan staat de server. Zo niet:
De server staat er niet bij. De meeste clients lezen hun instellingen alleen bij het opstarten. Sluit hem helemaal af en start opnieuw.
npx: command not found of een foutmelding over de Node-versie. Je hebt Node 20 of nieuwer nodig. Controleer met node --version; installeren kan via nodejs.org.
De eerste keer duurt even. npx haalt het pakket dan nog op. Daarna start hij meteen.
Het duurt lang, of je krijgt een foutmelding over een verbinding. Deze server haalt zijn gegevens op bij Ribba, dus hij heeft internet nodig. Zit je achter een bedrijfsproxy of firewall, dan moet die registry.npmjs.org, ribba.nl en de bijbehorende diensten doorlaten.
Nog steeds niets? Start de server met de hand en kijk wat hij zegt: npx -y @ribba/cbr-mcp. Hij wacht dan op invoer, wat betekent dat hij werkt; foutmeldingen komen erbij te staan.
Kom je er niet uit, open een issue of mail team@ribba.nl.
Wat is het landelijk slagingspercentage voor het autoexamen?
Welk examencentrum heeft het hoogste slagingspercentage, en welk het laagste?
Waar zit examencentrum Den Bosch en hoe parkeer ik daar?
Wat zijn de tien beste rijscholen in Rotterdam, gemeten aan eerste examens?
Hoe doet rijschool 883 het ten opzichte van het examencentrum waar hij rijdt?
In welke provincie slaag je het vaakst in één keer?
Naam | Wat het teruggeeft |
| De categorieën waarvoor het CBR cijfers publiceert, met per categorie wat het examen meet. |
| Het landelijk gemiddelde, het aantal rijscholen met cijfers en het totaal aantal examens. |
| Alle 54 CBR-examencentra met hun cijfers, adres en examenaantal. |
| Eén centrum in detail: adres, parkeren, eerste examens en herexamens, en de ranglijst van rijscholen. |
| De best scorende rijscholen, landelijk of binnen één stad of provincie. |
| Het gemiddelde per provincie, of per stad binnen één provincie. |
| De cijfers van één rijschool, met de uitsplitsing per examencentrum. |
| De tijdreeks van wekelijkse metingen voor één rijschool. |
Alles gaat standaard over categorie B, de personenauto. Voor motor, bromfiets, aanhanger, vrachtwagen, bus of tractor geef je categorie mee: AVB, AVD, AM, BE, C, CE, D of T.
Een slagingspercentage is een breuk, en een breuk over weinig examens zegt weinig. Elke uitvoer bevat daarom het aantal examens waarop een percentage rust. De ranglijsten hanteren een drempel: minstens honderd eerste examens voor een landelijke notering, minstens vijfentwintig binnen een stad of examencentrum.
Verder is er niet één slagingspercentage maar drie, en ze meten iets anders:
Eerste examen. Het aandeel kandidaten dat in één keer slaagt. Dit is het cijfer waar het meestal om gaat.
Herexamen. Het aandeel dat bij een tweede of latere poging slaagt.
Gemiddelde van het examencentrum. Wat álle rijscholen op dat centrum halen. Dit is een eerlijker ijkpunt dan het landelijk gemiddelde: het ene centrum is strenger dan het andere, en een school die op een streng centrum rijdt wordt anders onterecht afgestraft.
Eén ding om op te letten bij school_cijfers: het veld slagingspercentage_eerste_examen komt zo uit de CBR-publicatie en neemt de hoogste locatiescore. Voor een rijschool die op meerdere centra examineert valt dat cijfer te hoog uit. Het veld per_examencentrum in dezelfde uitvoer bevat de losse cijfers, en cijfers_over_tijd geeft de naar examenaantal gewogen variant.
De cijfers komen uit de openbare CBR-publicatie per rijschool en worden wekelijks opgehaald. De examencentra worden hier opgeteld uit die publicatie: het CBR levert de uitsplitsing per centrum alleen als bijvangst bij een rijschool.
Twee dingen zijn afgeleid en geen CBR-gegeven. De coördinaten van een examencentrum zijn het zwaartepunt van de rijscholen die er examen doen, want het CBR publiceert geen coördinaten; het adres in dezelfde uitvoer is wél het echte pand. En de tijdreeks in cijfers_over_tijd begint bij de eerste meting van Ribba, niet bij het begin van de rijschool: het CBR publiceert geen historie.
npm install
npm run build
npm testDe tests praten met de echte database, dus je hebt een verbinding nodig. Ze controleren niet alleen dat elk gereedschap antwoordt, maar ook dat de cijfers kloppen: dat totalen optellen, dat ranglijsten aflopend staan, dat drempels en filters echt worden toegepast en dat de links naar ribba.nl de vorm hebben die de site bouwt.
npm install
npm run build
node dist/index.jsDe server praat JSON-RPC over stdin en stdout. Handmatig starten is vooral nuttig om de foutuitvoer te zien; normaal doet je MCP-client dit.
Dezelfde gegevens staan als gewone pagina's op ribba.nl, met grafieken, kaarten en uitleg erbij:
Slagingspercentages per rijschool, stad en provincie
Alle CBR-examencentra met adres, parkeerinformatie en ranglijst
Rijscholen vergelijken op cijfers, prijs en beoordeling
De gids: hoe het examen werkt en wat de cijfers betekenen
Elke rijschool, elk examencentrum en elk gebied in de uitvoer draagt een verwijzing naar de bijbehorende pagina, zodat je een cijfer altijd in zijn context kunt teruglezen.
De code staat onder de MIT-licentie. De examencijfers zijn openbare CBR-gegevens; de bewerking en samenstelling door Ribba staan onder CC BY 4.0. Verwijs bij hergebruik naar https://ribba.nl.
rijschool-mcp voor de rijscholen zelf: adressen, prijzen, beoordelingen en dekkingsgebied.
theorie-mcp voor de theorie: hoofdstukken, verkeersborden, begrippen en wetsartikelen.
Vragen of iets kapot? team@ribba.nl of open een issue.
De tijdreeks van CBR-cijfers voor één rijschool. Het CBR publiceert zelf geen historie: dit is opgebouwd uit wekelijkse metingen door Ribba, dus de reeks begint bij de eerste meting en niet bij het begin van de rijschool. Deze cijfers zijn gewogen naar het aantal examens per locatie.
| Name | Required | Description | Default |
|---|---|---|---|
| categorie | No | Rijbewijscategorie, standaard B (auto). | |
| school_id | Yes | Het Ribba-id van de rijschool. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that the data is not official CBR history but constructed from weekly measurements, that the series starts at the first measurement, and that scores are weighted by the number of exams per location. It does not mention side effects, but this is a read-only retrieval, and the provenance and weighting are 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?
Three sentences, no redundant phrases, well-structured. It efficiently communicates the core function, data source, and weighting without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not specify the format of the time series (e.g., list of points, date range, sorting) or any pagination/limitations. It gives a high-level understanding but lacks operational details needed for a developer to fully anticipate the response. Given the tool's simplicity, it is adequate but not 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 descriptions for both parameters (school_id and categorie) are complete. The tool description adds that the data is for one school and weighted by location, which provides context but does not specifically clarify parameter behavior beyond the schema. Since schema coverage is 100%, a baseline 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 clearly states it provides a time series of CBR exam scores for a single driving school, explains the data provenance (weekly measurements by Ribba), and clarifies weighting by exam count per location, 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?
No explicit guidance on when to use this tool versus alternatives like school_cijfers or landelijke_cijfers. The description notes that the series starts at the first measurement, which implicitly hints at historical analysis, but does not state usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Het gemiddelde slagingspercentage per provincie, of per stad binnen één provincie, met het aantal rijscholen en het aantal examens.
| Name | Required | Description | Default |
|---|---|---|---|
| provincie | No | Laat leeg voor alle provincies. Vul in om de steden binnen die provincie te krijgen. | |
| minimum_rijscholen | No | Toon alleen gebieden met minstens zoveel rijscholen, standaard 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It reveals that the 'provincie' parameter can be left empty to return all provinces, and that 'minimum_rijscholen' defaults to 3. This gives useful behavioral insight beyond a mere static definition.
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, well-formed sentence that efficiently conveys the core functionality and the main output dimensions. It is concise and fits the tool's simple nature without unnecessary elaboration.
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 simplicity and the absence of an output schema, the description provides sufficient context about the grouping logic (province or city) and the included metrics. It does not specify the response format, but that is not required here, making the description adequately complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (provincie and minimum_rijscholen) including their optionality and default behavior. The tool description adds no additional parameter semantics beyond what the schema already covers, so the 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 clearly states that the tool returns average pass rates per province or per city within a province, along with counts of driving schools and exams. This distinctly differentiates it from siblings like 'landelijke_cijfers' (national) and 'school_cijfers' (per school), making its 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?
The description implies use for geographical breakdowns but does not explicitly indicate when to choose this tool over alternatives such as 'ranglijst' or 'cijfers_over_tijd'. No direct comparison or selection guidance is provided, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alle CBR-examencentra met hun slagingspercentage, het aantal examens en het aantal rijscholen dat er rijdt. Gesorteerd op examenaantal. Zonder de ranglijst per centrum; die haal je met examencentrum.
| Name | Required | Description | Default |
|---|---|---|---|
| categorie | No | Rijbewijscategorie, standaard B (auto). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the output contents (all exam centers with specific metrics), sorting by exam count, and explicitly excludes the per-center ranking. It does not explicitly mention read-only nature, but given it's a listing tool, the behavior is reasonably 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 concise, consisting of three short sentences that convey the full purpose without unnecessary detail. It is well-structured and easy to parse.
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 provides sufficient context: what the tool returns, how it is sorted, and what it explicitly excludes (with a pointer to the alternative). It is complete for an agent to know when and how to use it.
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 single parameter 'categorie' is described as 'Rijbewijscategorie, standaard B (auto).' which fully explains its meaning and default value. Schema coverage is 100%, so the description adds no extra info but the schema itself is complete.
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 returns all CBR exam centers with their pass rate, number of exams, and number of driving schools, sorted by exam count. It explicitly differentiates from the sibling 'examencentrum' which provides per-center rankings.
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 says 'Zonder de ranglijst per centrum; die haal je met examencentrum', which indicates when not to use this tool and directs to the alternative for ranking per center. This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alles over één CBR-examencentrum: adres en parkeerinformatie, slagingspercentages voor eerste examens en herexamens, de steden waar de rijscholen vandaan komen, en de ranglijst van rijscholen die er examen doen.
| Name | Required | Description | Default |
|---|---|---|---|
| naam | Yes | Naam of slug van het examencentrum, bijvoorbeeld "Amsterdam" of "den-bosch". | |
| categorie | No | Rijbewijscategorie, standaard B (auto). | |
| ranglijst_limiet | No | Hoeveel rijscholen in de ranglijst, standaard 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention side effects, read-only behavior, output format, or error conditions. While this is likely a safe query operation, the description does not disclose these aspects, placing full burden on itself and failing to convey behavioral expectations beyond the core purpose.
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, well-structured sentence that leads with the core scope and then enumerates the distinct data categories. It is concise, free of redundancy, and easy to parse quickly.
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 lists all major return categories (address, parking, pass rates, origin cities, ranking), giving the agent a solid expectation of the output. However, it omits details about the output structure, pagination, or any limitations. Given no output schema exists, this is a minor gap but not a critical one.
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 itself adds no parameter-specific information, but the input schema descriptions are comprehensive (100% coverage), including defaults, examples, and constraints. As per the baseline, with high schema coverage, a score of 3 is appropriate when the description does not enhance parameter understanding 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 the tool's scope: 'Alles over één CBR-examencentrum' and enumerates specific data categories (address, parking, pass rates for first and retry exams, origin cities, and ranking). This makes it immediately obvious what the tool does and distinguishes it from sibling tools that cover multiple centers or aggregate statistics.
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 a single exam center ('één CBR-examencentrum') and lists the information returned, but it does not explicitly state when to use this tool versus alternatives such as 'examencentra' or 'landelijke_cijfers'. No direct comparison or exclusion criteria are provided, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Het landelijk gemiddelde slagingspercentage, het aantal rijscholen met examencijfers en het totaal aantal afgelegde examens. Het ijkpunt waar je een losse rijschool tegen afzet.
| Name | Required | Description | Default |
|---|---|---|---|
| categorie | No | Rijbewijscategorie, standaard B (auto). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It implicitly describes a read-only query but does not explicitly state non-modifying behavior, side effects, or safety. This is a minor gap for a tool that appears to be a simple data retrieval.
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, two sentences, with no redundancy. It efficiently conveys the returned data points and the tool's role without unnecessary 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?
Given the lack of an output schema, the description adequately lists the expected data fields (percentage, number of schools, number of exams). It does not describe the response format or pagination, but for the tool's simplicity, this is sufficient for an agent to call and interpret results.
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 parameter 'categorie' is described as 'Rijbewijscategorie, standaard B (auto)', adding meaning by indicating the standard value and domain. However, it does not clarify optionality or enumerations, though the description adds some value beyond the property name.
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 provides national statistics (average pass rate, number of schools, total exams) and frames it as a benchmark, distinguishing it from more specific sibling tools. The purpose is immediately understandable.
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 includes a practical hint ('ijkpunt waar je een losse rijschool tegen afzet') implying use for comparison against a single driving school. It does not explicitly mention alternatives or exclusions, but the context strongly suggests when 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.
De rijscholen met het hoogste slagingspercentage, landelijk of binnen één stad of provincie. Alleen scholen met genoeg examens om een percentage op te baseren.
| Name | Required | Description | Default |
|---|---|---|---|
| stad | No | Beperk tot één stad, bijvoorbeeld "Utrecht". | |
| limiet | No | Aantal rijscholen, standaard 25. | |
| provincie | No | Beperk tot één provincie, bijvoorbeeld "Noord-Holland". | |
| minimum_examens | No | Drempel, standaard 100 landelijk en 25 binnen een stad of provincie. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions no side effects, permissions, or data limits. As a query tool, it is likely read-only, but this is not explicitly stated. With no annotations, the description carries the burden but falls short of full transparency.
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, clear sentence that efficiently conveys the tool's purpose and filtering criteria. It is well-structured with no unnecessary 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?
The tool is simple and the description covers the core functionality, but it does not specify the output format (e.g., a list of schools with percentages). Given the low complexity and clear purpose, this minor omission does not significantly hinder understanding, but a brief mention of output would make it 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?
The schema provides clear descriptions with examples and defaults for all four parameters (stad, limiet, provincie, minimum_examens). The description adds no extra semantic information beyond what the schema already covers, so a 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 clearly states the tool returns driving schools with the highest pass percentage, optionally filtered by city or province, and only those with sufficient exams. It distinguishes it from sibling tools by focusing specifically on ranking lists.
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 ranking queries but does not explicitly contrast with alternative tools like school_cijfers or cijfers_per_gebied. No explicit 'use when' or 'use instead' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
De rijbewijscategorieën waarvoor het CBR per rijschool cijfers publiceert, met per categorie wat het examen precies meet. Gebruik de code als parameter bij de andere tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must carry the full transparency burden. It states what the tool lists and that codes are used as parameters, but it does not specify the response format (e.g., array of objects) or any potential limitations. This is sufficient for a simple enumeration tool but lacks detail about behavior.
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 concise sentence that conveys all essential information without extraneous details. It is well-structured, presenting the purpose first and then the usage instruction. No unnecessary words or redundancy.
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 for its context. It explains what the tool provides and how it relates to other tools. There is no missing information that would prevent an agent from understanding or using the tool correctly.
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 there is nothing to describe. According to the rubric, with 100% schema description coverage, the baseline score is 3 even without parameter-specific info in the description. The description does not need to add anything here.
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 (driving license categories) and the scope (categories for which CBR publishes scores per driving school). It also explains that each category includes what the exam measures, making the purpose understandable. However, it does not use an explicit verb like 'returns' or 'lists', so it is slightly less direct.
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 explicit usage guidance by instructing to use the code as a parameter in other tools, which directly connects this tool to its siblings. It implies that this tool is the reference for obtaining category codes before using other tools. It does not explicitly compare with alternatives, but the instruction is clear enough for practical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
De CBR-cijfers van één rijschool: eerste examens, herexamens, het gemiddelde van de examencentra waar hij rijdt, en de uitsplitsing per examencentrum. Zoek op id of op naam.
| Name | Required | Description | Default |
|---|---|---|---|
| naam | No | Naam van de rijschool, als je het id niet hebt. | |
| stad | No | Stad erbij, om een naam die vaker voorkomt te onderscheiden. | |
| school_id | No | Het Ribba-id van de rijschool. |
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 implies a read-only lookup but does not explicitly state side effects, error behavior, or what happens if multiple schools match a name. The description gives no details about return format or limits.
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 no redundant details. It front-loads the main purpose and then briefly explains lookup options, making it easy to parse and understand.
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 simple tool with three optional parameters and no output schema, the description covers the main data points. It does not explicitly state that at least one parameter is required or describe the output structure, but the tool's simplicity makes this acceptable.
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?
All three parameters have meaningful descriptions that go beyond their names: 'naam' is described as the fallback when ID is unknown, 'stad' is for disambiguation, and 'school_id' is identified as a Ribba ID. However, the interaction between parameters (e.g., precedence if both name and ID are provided) is not addressed.
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 returns exam scores for one driving school, including first exams, re-exams, averages per exam center, and a breakdown by center. It also specifies that lookup is by ID or name, 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?
The description explains how to search (by ID or name) but does not explicitly mention when to choose this tool over its siblings (e.g., landelijke_cijfers, cijfers_per_gebied). The scope 'één rijschool' implies a single school, but no direct comparison or conditions are given.
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. Dates show when Glama detected each change.
v0.1.0cijfers_over_tijdcijfers_per_gebiedexamencentraexamencentrumlandelijke_cijfersranglijstrijbewijscategorieenschool_cijfersEach tool targets a distinct scope (national, area, school, time series, centers, categories, ranking), but several names share the 'cijfers' suffix and could be confused at a glance. The singular/plural center pair is clear, and the scope qualifiers help differentiate the statistics tools.
Tool names consistently use Dutch snake_case and follow a mostly predictable pattern: plural for collections, singular for detail, and scope-qualified 'cijfers' for statistics. The pattern is not verb-based, but it is internally consistent and readable.
Eight tools is well-scoped for a read-only statistics API covering categories, national averages, exam centers, rankings, area breakdowns, school details, and historical trends. No obvious redundancy or excessive granularity.
The tool set covers the full expected domain of CBR driving-exam statistics: reference categories, national benchmark, exam-center list/detail, rankings, geographic breakdowns, per-school stats, and time series. It leaves no major query type unaddressed for the apparent purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Statistics Netherlands (CBS / StatLine) OData MCP.
data.overheid.nl MCP — the Netherlands national open-data portal (CKAN API).
Published driving guides, source-backed UK and US test-centre search, and study-plan previews.
Dutch Parliament (Tweede Kamer) open data MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RibbaBV/cbr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
