theorie-mcp

Official

by RibbaBV

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.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.
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.9/5.
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, 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.
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.
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.
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.
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.
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.
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.
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.
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.

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

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

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![theorie-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/RibbaBV/theorie-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RibbaBV/theorie-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.

[![theorie-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FRibbaBV%2Ftheorie-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/RibbaBV/theorie-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/theorie-mcp'

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