cbr-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/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. 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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
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 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.
Parameters4/5
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.
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 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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
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 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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

cbr-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![cbr-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/RibbaBV/cbr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RibbaBV/cbr-mcp)

Score Badge

Copy to your README.md:

[![cbr-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/RibbaBV/cbr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RibbaBV/cbr-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![cbr-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FRibbaBV%2Fcbr-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/RibbaBV/cbr-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/cbr-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server