A
licenseA
qualityD
maintenanceProvides real-time Dutch railway (NS) travel information including train schedules, delays, journey planning, ticket prices, and station details for navigating the Netherlands by train.
8
32
MIT
theorie-mcp
Officialby RibbaBV
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., "@theorie-mcpWat is de voorrangsregel op een rotonde?"
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.
theorie-mcp
Een MCP-server met de volledige theorie voor het autorijbewijs B in Nederland: elf hoofdstukken met 134 paragrafen, alle 175 verkeersborden uit bijlage 1 van het RVV 1990, 182 begrippen en de wetsartikelen waar elke regel op rust. Gratis, zonder account en zonder sleutel.
De inhoud zit in het pakket. De server werkt dus zonder netwerk en zonder database.
Gemaakt en onderhouden door Ribba, de vergelijker voor rijscholen en gratis theorie in Nederland.
Installeren
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 Code
claude mcp add --scope user theorie -- npx -y @ribba/theorie-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
codex mcp add theorie -- npx -y @ribba/theorie-mcpOf met de hand in ~/.codex/config.toml:
[mcp_servers.theorie]
command = "npx"
args = ["-y", "@ribba/theorie-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.
Claude Desktop
De chat-app deelt zijn instellingen niet met Claude Code en heeft een eigen bestand:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"theorie": {
"command": "npx",
"args": ["-y", "@ribba/theorie-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.
Cursor, Windsurf en andere clients
Dezelfde JSON als hierboven, in het configuratiebestand van je client.
Related MCP server: anwb-mcp
Werkt het?
Vraag je client:
Wat betekent verkeersbord B6?
Komt er een antwoord met de betekenis en het wetsartikel erbij, 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 foundof een foutmelding over de Node-versie. Je hebt Node 20 of nieuwer nodig. Controleer metnode --version; installeren kan via nodejs.org.De eerste keer duurt even.
npxhaalt het pakket dan nog op, en daar zit de hele theorie in. Daarna start hij meteen, ook zonder internet.Nog steeds niets? Start de server met de hand en kijk wat hij zegt:
npx -y @ribba/theorie-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 je kunt vragen
Wat betekent bord B6, en waar wordt het het vaakst mee verward?
Wie heeft er voorrang op een rotonde?
Leg de regels voor stilstaan en parkeren uit, met de wetsartikelen erbij.
Overhoor me over verkeerstekens en aanwijzingen, zonder de antwoorden te laten zien.
Wat staat er letterlijk in artikel 15 van het RVV?
Wat is het verschil tussen een voorrangsweg en een gelijkwaardig kruispunt?
Gereedschappen
Naam | Wat het teruggeeft |
| Zoekt door hoofdstukken, borden, begrippen en oefenvragen tegelijk. Begin hier als je niet weet waar iets staat. |
| De elf hoofdstukken met samenvatting, niveau en bijbehorende borden. |
| De volledige tekst van één hoofdstuk, per paragraaf met de wetsartikelen erbij. |
| Alle borden uit bijlage 1, te filteren op groep. |
| Eén bord: betekenis, wat je doet, veelgemaakte fouten, plaatsingsvoorschrift en artikelen. |
| De begrippenlijst, doorzoekbaar, met de officiële CBR-woordenlijst apart te filteren. |
| Eén begrip in het volle: uitleg, regels, valkuilen en waar het mee verward wordt. |
| De letterlijke tekst van een artikel, met verwijzing naar wetten.overheid.nl. |
| Oefenvragen met antwoord en uitleg, of zonder antwoord om te overhoren. |
De wet zit erbij
Bij 111 van de 134 paragrafen staat het wetsartikel waar de regel op rust, en de server geeft de letterlijke wettekst mee. Dat is het verschil tussen "je moet rechts houden" en artikel 3 van het RVV 1990, met een verwijzing naar wetten.overheid.nl waar het staat.
Dat is niet alleen netjes. Verkeersregels veranderen, en een theorieantwoord zonder bron is niet na te kijken. Zes regelingen zitten erin, met samen ruim tweeduizend artikelen: het RVV 1990, de Wegenverkeerswet 1994, de Regeling voertuigen, het BABW, het Reglement rijbewijzen en de Regeling eisen theorie-examen rijbewijscategorie B.
Wat dit niet is
Dit is lesstof, geen CBR-examen. De oefenvragen zijn door Ribba geschreven en zijn geen examenvragen van het CBR. Ze zijn er om te toetsen of de stof zit, niet om een examen na te bootsen.
De afbeeldingen van de verkeersborden zijn de officiële borden uit bijlage 1 van het RVV 1990, overgenomen van wetten.overheid.nl. Elk bord in de uitvoer heeft een afbeelding-veld dat naar die afbeelding wijst. Op wetten, besluiten en verordeningen van de openbare macht rust geen auteursrecht (Auteurswet artikel 11).
De inhoud
De theorie in data/ is een momentopname en gaat mee in het pakket. Verandert er iets aan de cursus, dan verschijnt dat in een nieuwe versie van deze server. package.json vertelt welke je hebt; de laatste staat op npm.
Wijkt iets af van wat er op ribba.nl staat, dan is die site de bron. Laat het weten via een issue of team@ribba.nl, dan zetten we het recht.
Testen
npm install
npm run build
npm testDe tests draaien tegen de meegeleverde inhoud, dus zonder netwerk. Naast de gereedschappen zelf controleren ze de samenhang: dat elk bord waar een hoofdstuk naar verwijst bestaat, en dat elke wetsverwijzing in de cursus een echte wettekst oplevert.
Zelf draaien
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.
Deze theorie op het web
Alles wat deze server teruggeeft staat ook als gewone pagina op ribba.nl, met afbeeldingen, voorbeelden en oefenvragen erbij:
Gratis theorie leren: de volledige cursus
Alle verkeersborden uit bijlage 1 van het RVV 1990
De gids: het theorie-examen van begin tot eind
Wil je de theorie op je eigen site zetten? Dat mag, en het kan met een kant-en-klaar kader: zie gratis theorie aanbieden.
Elk bord, begrip en hoofdstuk in de uitvoer bevat een pagina-veld dat naar de bijbehorende pagina wijst.
Licentie
De code staat onder de MIT-licentie. De wetteksten en de bordafbeeldingen zijn overheidspublicaties zonder auteursrecht. De cursusteksten, de begrippenlijst en de oefenvragen zijn geschreven door Ribba en staan onder CC BY 4.0. Verwijs bij hergebruik naar https://ribba.nl.
Verwant
cbr-mcp voor de CBR-slagingspercentages per rijschool, examencentrum, stad en provincie.
rijschool-mcp voor de rijscholen zelf: adressen, prijzen, beoordelingen en dekkingsgebied.
Vragen of iets kapot? team@ribba.nl of open een issue.
Available Tools
9 toolsbegripEén begripA
De volledige uitleg van één begrip: wat het is, welke regels erbij horen, welke fouten ermee gemaakt worden, waar het mee verward wordt en op welke wetsartikelen het rust.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | Het begrip of de slug, bijvoorbeeld "voorrangsweg". |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes an informational lookup returning an explanation, which implies no side effects. However, it does not explicitly state read-only behavior or lack of mutations, so it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, comprehensive without being verbose. It is well-structured and front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description enumerates what the explanation covers (definition, rules, mistakes, confusions, legal articles), giving a thorough picture of the output. For this simple tool, no additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the 'term' parameter with an example, so coverage is high. The tool description adds no extra parameter details, remaining at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides the full explanation of a single concept, distinguishing it from sibling tools like 'begrippen' (plural list) and 'zoek' (search). The verb is implied but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the singular focus is clear, the description does not explicitly mention when to use this tool versus alternatives like the plural 'begrippen' or search. It relies on the user inferring the distinction from the title and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
begrippenBegrippenlijstC
De begrippen die je voor het theorie-examen moet kennen, met een korte omschrijving. Een deel komt uit de woordenlijst van het CBR zelf.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| zoekwoord | No | Beperk tot begrippen waar dit woord in voorkomt. | |
| alleen_cbr | No | Alleen de begrippen uit de officiële CBR-woordenlijst. |
TDQS
C2.9/5.0
Behavior2/5
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 does not mention any side effects, permissions, rate limits, or explicitly confirm that the operation is read-only, although it implies a retrieval action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences with no redundant content. It could be more informative about functionality, but it remains efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the tool is relatively simple, and the schema covers parameters. However, the description lacks information about the expected output structure or usage context, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full descriptions for both parameters ('zoekwoord' and 'alleen_cbr'), achieving 100% coverage. The tool description adds no additional meaning to these parameters, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides the list of concepts needed for the theory exam with short descriptions, and notes that some come from the CBR list. It distinguishes from the singular 'begrip' sibling but does not explicitly differentiate from other list-oriented tools like 'verkeersborden'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as 'begrip' or 'hoofdstukken'. The parameters imply filtering capability, but the description does not advise on selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hoofdstukEén hoofdstukA
De volledige tekst van één hoofdstuk: alle paragrafen met hun kernregel en uitleg, en per paragraaf de wetsartikelen waar de regel op rust, met de letterlijke wettekst.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug van het hoofdstuk, bijvoorbeeld "voorrang-en-voor-laten-gaan". | |
| met_wetteksten | No | De letterlijke wettekst per artikel erbij, standaard aan. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It describes the returned content but does not explicitly state side effects, read-only nature, or error behavior. The absence of mutation language suggests a safe read operation, but this is not made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that directly states the tool's purpose without redundant wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description sufficiently outlines what the result will contain: the full chapter text, sections, explanations, and legal references. It could be more explicit about response format or error handling, but it is complete enough for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters ('slug' with an example and 'met_wetteksten' with its default). The tool description adds no extra parameter meaning beyond what the schema already contains, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full text of a single chapter, including sections, core rules, explanations, and legal articles. This distinguishes it from the sibling tool 'hoofdstukken' which likely lists chapters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when full chapter details are needed, but it does not explicitly mention when to prefer this over alternatives such as 'hoofdstukken' or 'oefenvragen'. No direct when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hoofdstukkenAlle hoofdstukkenA
De elf hoofdstukken van de theoriecursus, met per hoofdstuk de samenvatting, het aantal paragrafen, de bijbehorende verkeersborden en het niveau dat het CBR vraagt.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.8/5.0
Behavior3/5
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 listing operation but does not explicitly mention that it returns all chapters, any limitations, or that it has no side effects. It is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the key per-chapter attributes. It is slightly long but still focused and free of unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context about what the tool returns (chapter summaries, paragraph counts, traffic signs, CBR level) to give a user a clear expectation. It does not specify the output format, but that is not critical for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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. The description does not need to add parameter meaning beyond the empty schema, and it correctly omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing the eleven chapters of the theory course with per-chapter details, and the plural name 'hoofdstukken' implies a listing operation. However, it lacks an explicit verb like 'retrieve' or 'list', so the purpose is inferred rather than stated directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about the content (summary, paragraph count, traffic signs, level) but does not explicitly contrast this with the singular 'hoofdstuk' tool or state when to choose one over the other. The sibling tool list exists, but the description itself offers no direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
oefenvragenOefenvragenB
Oefenvragen met het juiste antwoord, de uitleg en de wetsartikelen erbij. Door Ribba geschreven en geen examenvragen van het CBR.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limiet | No | Aantal vragen, standaard alles. | |
| onderwerp | No | Slug van een hoofdstuk, om alleen vragen daarover te krijgen. | |
| met_antwoord | No | Het juiste antwoord en de uitleg erbij, standaard aan. Zet uit om te overhoren. |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. The description implies a read-only operation (returning practice questions) without side effects, but it does not explicitly state that it does not modify data or cause external effects. It is safe to assume, but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the essential information without unnecessary detail. It is well-structured and easy to parse, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description sufficiently communicates what the tool returns (practice questions with answers/explanations and legal articles). It does not describe response format or pagination, but given the simplicity and lack of output schema, the provided information is adequate for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all three parameters (limiet, onderwerp, met_antwoord) with 100% coverage. The tool description itself does not add any extra meaning beyond what the schema already provides. Since schema coverage is complete, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns practice questions with answers and explanations, distinguishing it from exam questions. However, it does not explicitly use an imperative verb like 'returns' or 'fetches', and the purpose is implied from the title 'oefenvragen' rather than stated as a direct action. It is still readily understandable among sibling tools like 'hoofdstukken' and 'verkeersbord'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as 'zoek' or 'hoofdstukken'. It mentions it is not CBR exam questions, but that is a clarification rather than usage direction. There is no explicit 'use this when' or 'prefer this over X' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verkeersbordEén verkeersbordB
Alles over één verkeersbord: wat het betekent, wat je moet doen, waar je het tegenkomt, de fouten die er het vaakst mee gemaakt worden, de borden waar het mee verward wordt, het plaatsingsvoorschrift en de wetsartikelen.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Bordcode, bijvoorbeeld "B6", "A1" of "j37". |
TDQS
B3.4/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no information about side effects, read-only status, or any behavioral traits. Since there are no annotations, the description carries the full burden, and it fails to disclose anything about safety or state changes, leaving the agent with no insight into potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose ('Alles over één verkeersbord') and then enumerates the covered topics in a clear, concise list. It avoids unnecessary verbosity while efficiently communicating the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the scope of information provided (meaning, actions, location, etc.), which is sufficient for an agent to know what to expect from the tool. It does not mention the output format, but given the absence of an output schema, this is acceptable and does not leave major gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already includes a description for the parameter 'code' with examples ('B6', 'A1', 'j37'), so the baseline is 3. The tool description adds no further clarification about the parameter format, constraints, or how to obtain a valid code, relying entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides comprehensive information about a single traffic sign, enumerating specific aspects such as meaning, actions, location, common mistakes, confusions, placement regulations, and legal articles. It explicitly says 'één verkeersbord' (one traffic sign), which distinguishes it from the sibling tool 'verkeersborden' that likely lists multiple signs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving detailed information about a specific sign, but it does not explicitly state when to prefer this over alternatives like 'verkeersborden' or 'zoek'. No exclusions or comparisons are provided, leaving the context to be inferred rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verkeersbordenVerkeersbordenA
Alle verkeersborden uit bijlage 1 van het RVV 1990, met code, naam en groep. Filter op groep om alleen de snelheidsborden of alleen de voorrangsborden te krijgen.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| groep | No | Groepsletter: A (snelheid), B (voorrang), C (geslotenverklaring), D (rijrichting), E (parkeren en stilstaan), F (overige geboden en verboden), G (verkeersregels), H (bebouwde kom), J (waarschuwing), K (bewegwijzering), L (informatie). | |
| met_uitleg | No | De betekenis per bord erbij, standaard uit. Zet aan bij een klein aantal borden. |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose the read-only nature and any notable behaviors. It mentions the output fields (code, name, group) and the filter option, but does not mention potential large result sets or pagination. For a simple query tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the purpose and the filtering capability. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description appropriately lists the fields returned (code, name, group). It also hints at the filtering option. For a straightforward list tool, this is sufficient, though it could mention that the full list is returned by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with detailed descriptions. The tool description only mentions filtering by group without adding new information. Since schema coverage is 100%, the description adds no extra semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all traffic signs from appendix 1 of RVV 1990, with code, name, and group. It also mentions filtering by group, which distinguishes it from the singular sibling verkeersbord that likely provides details for a single sign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example of when to use the filter (to get only speed or priority signs), but it does not explicitly contrast with the singular verkeersbord tool. The plural vs singular naming implies a distinction, but an explicit statement of when to use which would be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wetsartikelWetsartikel opzoekenA
De letterlijke tekst van een artikel uit het RVV 1990, de Wegenverkeerswet of een van de andere regelingen waar de theorie op rust, met een verwijzing naar wetten.overheid.nl. Zonder verwijzing krijg je de lijst met regelingen.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| verwijzing | No | Regeling en artikelnummer, bijvoorbeeld "RVV 15" of "WVW 5". |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that it returns literal article text and includes a link, and that omitting the parameter yields a list of regulations. It does not describe error handling, response format, or any limits, but for a read-only lookup tool this is reasonably transparent. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The first sentence states the primary purpose and the link, and the second clarifies the behavior without a reference. It is front-loaded and every sentence adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one optional parameter and no output schema, the description covers the essential behavior: what it returns, the reference to the legal text, and the effect of omitting the parameter. It does not address edge cases or errors, but those are less critical for a read-only lookup. The description is sufficient for an agent to call the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the parameter 'verwijzing' with examples (e.g., 'RVV 15'), giving 100% coverage. The description adds valuable context by explaining that omitting the parameter changes the output to a list of regulations. This goes beyond the schema and justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the literal text of an article from specific regulations (RVV 1990, Wegenverkeerswet, etc.) with a link to wetten.overheid.nl. It distinguishes itself from siblings like verkeersbord or begrippen by focusing on articles, though it does not explicitly name the alternatives. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides conditional guidance: with a reference you get the article text, without it you get the list of regulations. This clarifies the behavior of the optional parameter but does not explicitly state when to use this tool versus alternatives like 'zoek' or 'verkeersbord'. There are no explicit exclusions or alternative recommendations, so the guidance is implicit rather than fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
zoekZoeken in de theorieA
Zoek door de hele theorie tegelijk: hoofdstukken, paragrafen, verkeersborden, begrippen en oefenvragen. Geeft per treffer een fragment en de sleutel waarmee je het volledige stuk ophaalt. Begin hier als je niet weet in welk hoofdstuk iets staat.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| vraag | Yes | Waar je naar zoekt, bijvoorbeeld "voorrang op een rotonde". | |
| limiet | No | Aantal treffers, standaard 15. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that each hit provides a fragment and a key, which is useful, but it does not disclose behavior on empty results, rate limits, or whether it is strictly read-only. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the action and scope, the second explains the output and gives a usage hint. Every word contributes, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior: it searches all content types, returns fragments and keys, and provides a usage hint. The schema handles parameters, and no output schema is present, so the description is sufficiently complete for correct invocation, though it could mention how the returned key is used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with descriptions and an example for 'vraag' and a default for 'limiet'. The description adds no extra parameter semantics, so with 100% schema coverage the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching across all theory content (chapters, sections, traffic signs, concepts, practice questions). It explicitly mentions the output format (fragment and key) and provides a usage hint that differentiates it from the sibling tools, which are specific retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage condition: 'Start here if you don't know in which chapter something is.' This implies using this tool for general search and hints at alternatives, but it does not explicitly name the sibling tools or state when not to use this. It is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
9 tool updates
v0.1.0- First observed
begrip - First observed
begrippen - First observed
hoofdstuk - First observed
hoofdstukken - First observed
oefenvragen - First observed
verkeersbord - First observed
verkeersborden - First observed
wetsartikel - First observed
zoek
TDQS
A3.9/5.0
Disambiguation5/5
Each tool has a clear, distinct purpose: chapter lists versus chapter details, sign lists versus sign details, concept lists versus concept details, plus law articles, practice questions, and a search tool. No overlapping functionality.
Naming Consistency5/5
The naming pattern is consistent: singular nouns for single-item details, plural nouns for lists, and a straightforward verb 'zoek' for search. All names are lowercase, without separators, matching a uniform style.
Tool Count5/5
With 9 tools, the set is well-scoped for a traffic theory resource, covering navigation, details, and search without unnecessary redundancy or bloat.
Completeness5/5
The toolset fully covers the domain: chapters, traffic signs, concepts, law articles, practice questions, and cross-cutting search. It provides both overview and detail access, leaving no major gaps for the intended use case.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Dutch vehicle model knowledge, terminology, comparisons and cited sources for AI clients.
Published driving guides, source-backed UK and US test-centre search, and study-plan previews.
Dutch vehicle report by licence plate: MOT, defects, odometer verdict and open recalls.
Search Belgian & EU legislation: verbatim article text, per-article links, legal Q&A.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server for ANWB traffic information, route planning, and location search in the Netherlands. Provides real-time traffic incidents, route calculation with turn-by-turn directions, and location search via natural language.620MIT
- AlicenseAqualityFmaintenanceEnables querying over 3,200 Dutch statutes (AVG, Wetboek van Strafrecht, Burgerlijk Wetboek, etc.) with verbatim, citation-grounded text from official sources, directly from MCP-compatible AI assistants.188812Apache 2.0
- AlicenseNot gradedqualityCmaintenanceProvides comprehensive Dutch vehicle information from license plate numbers, including APK inspection history, recalls, odometer checks, and other signals, via a single MCP tool.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RibbaBV/theorie-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server