mcp-server-vanmoof

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools have overlapping purposes that could cause confusion. get_city_rides_thisweek, get_rides_summary, and get_world_rides_thisweek all return similar ride summary data with only subtle differences in scope (city vs. world vs. general). get_rides_for_week also overlaps with these but adds a date parameter, creating ambiguity about when to use which summary tool.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with 'get_' prefix and snake_case naming. The naming is perfectly predictable across all seven tools, making it easy to understand the pattern and anticipate tool names.
Tool Count4/5
Seven tools is a reasonable number for a bike sharing/ride tracking API. While the count is appropriate, the tools feel slightly redundant rather than each earning its distinct place due to the overlapping summary tools.
Completeness3/5
The server provides good read operations for customer data, preferences, cities, and rides, but lacks any write/update capabilities. For a rider data API, there are notable gaps - no tools to update preferences, log new rides, or modify customer information, which limits agent workflows to read-only operations.
Average 3.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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

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 mentions that authentication is required for successful retrieval and specifies the return format (summary with average distance, total rides, average duration), which adds useful context. However, it doesn't cover other behavioral aspects like rate limits, error handling, or data freshness, leaving gaps in transparency.
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 appropriately sized and front-loaded, starting with the core purpose. The 'Returns' section is structured but includes a minor grammatical error ('The a summary'), which slightly affects clarity. Overall, it's efficient with minimal waste, though it could be more polished.
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 tool has no parameters, no annotations, and no output schema, the description provides basic information on purpose, authentication requirement, and return format. However, it lacks details on error cases (e.g., what 'otherwise None' entails), data scope limitations, or how it differs from sibling tools, making it adequate but with clear gaps for a retrieval tool.
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 input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Since there are no parameters, the baseline score is 4, as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Retrieves total world rides summary from VanMoof riders,' which provides a clear verb ('retrieves') and resource ('world rides summary'), but it doesn't distinguish this from sibling tools like 'get_rides_summary' or 'get_rides_for_week,' making the purpose somewhat vague in context. It specifies 'world' scope, which helps differentiate from city-level tools, but lacks explicit comparison to similar global tools.
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 provides no guidance on when to use this tool versus alternatives like 'get_rides_summary' or 'get_rides_for_week,' nor does it mention prerequisites or exclusions. It implies usage for authentication-based retrieval but doesn't clarify context or alternatives, leaving the agent with minimal direction.
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 discloses authentication requirements and the return format (including specific data fields), which is valuable. However, it doesn't mention rate limits, error conditions beyond authentication failure, or whether this is a read-only operation (though 'retrieves' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with clear sections but has some redundancy ('The a summary') and could be more front-loaded. The authentication information is buried after the return format rather than being prioritized. Most sentences earn their place, but the flow could be improved.
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?
For a tool with no parameters, no annotations, and no output schema, the description does a decent job explaining what it returns and authentication requirements. However, it doesn't clarify the scope ('thisweek' in the name vs 'total' in description) or how it differs from sibling tools, leaving some contextual gaps.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on return values and authentication requirements.
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 the tool retrieves a total city rides summary from VanMoof riders, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_rides_summary' or 'get_world_rides_thisweek' - the 'city' scope is implied but not contrasted with alternatives.
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 mentions authentication requirements but provides no guidance on when to use this tool versus similar siblings like 'get_rides_summary' or 'get_world_rides_thisweek'. There's no explicit when/when-not guidance or alternative tool recommendations for different use cases.
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 adds some context by mentioning authentication requirements and the return value (customer data or None), but lacks details on rate limits, error handling, data format, or other operational traits. This is a minimal but adequate disclosure for a simple retrieval tool.
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 appropriately concise with two sentences: one stating the purpose and one detailing the return behavior. It's front-loaded with the core function and avoids redundancy, though the formatting includes extra whitespace that slightly detracts from structure.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough for basic use. It covers the purpose and return conditions, but could benefit from more context on data scope or sibling differentiation to fully guide the agent in a server with multiple retrieval tools.
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 tool has 0 parameters, and the schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
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 the tool's purpose with a specific verb ('Retrieves') and resource ('customer data from the vanMoof API'), making it easy to understand what it does. However, it doesn't explicitly differentiate this tool from its siblings (like get_rider_preferences or get_rides_summary), which would require a more specific scope or comparison.
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 provides no guidance on when to use this tool versus alternatives. It mentions authentication success/failure, but doesn't specify contexts, prerequisites, or exclusions compared to sibling tools, leaving the agent to infer usage based on tool names alone.
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 discloses that authentication is required and describes the return behavior (preferences if successful, None otherwise). However, it lacks details on error handling, rate limits, or side effects, which are important for a tool interacting with an external API.
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 brief and front-loaded, with the main purpose stated first and additional behavioral context in a second sentence. There's no wasted text, but the structure could be slightly improved by integrating the return information more seamlessly rather than as a separate 'Returns:' section.
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 no annotations, no output schema, and 0 parameters, the description covers the basic purpose and authentication behavior adequately. However, for an API tool, it lacks details on response format, error types, or integration context, which would help an agent use it more effectively in complex scenarios.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't need to add parameter details, and it correctly avoids redundancy. A baseline of 4 is appropriate as it focuses on the tool's purpose without unnecessary parameter explanations.
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 the action ('Retrieves') and resource ('rider preferences'), and specifies the source ('from the vanMoof API'). It distinguishes from sibling tools that focus on rides, cities, or customer data. However, it doesn't explicitly contrast with specific alternatives, keeping it at 4 rather than 5.
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 provides no guidance on when to use this tool versus alternatives like 'get_customer_data' or other ride-related tools. It mentions authentication but doesn't specify prerequisites or contextual triggers for selecting this tool over siblings, leaving usage unclear.
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 discloses that authentication is required for successful data retrieval and that the return may be 'None' if authentication fails, adding useful behavioral context. However, it lacks details on rate limits, error handling, or data format, leaving gaps in transparency.
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 with two sentences that directly state the purpose and return behavior, with no wasted words. It is appropriately sized for a simple tool, though the structure could be slightly improved by front-loading key details more explicitly.
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 tool has no parameters, no annotations, and no output schema, the description provides basic purpose and authentication context, which is minimal but viable. However, it lacks details on output format, error cases beyond authentication, or how it fits with siblings, making it incomplete for full agent understanding.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is acceptable here, but it could have mentioned any implicit parameters or context. Baseline is 4 for zero parameters, as it adequately handles the lack of inputs.
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 the verb ('Retrieves') and resource ('list of city data from the vanMoof API'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'get_city_rides_thisweek' or 'get_world_rides_thisweek', which might also involve city or ride data, so it misses full sibling differentiation.
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 provides no guidance on when to use this tool versus alternatives. It mentions authentication success affects the return value, but does not specify contexts, prerequisites, or comparisons to sibling tools like 'get_city_rides_thisweek' for ride-specific data or 'get_customer_data' for user information.
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 discloses authentication requirements and return behavior (returns rides if successful, otherwise None), which is valuable. However, it lacks details on rate limits, error handling, pagination, or data format, leaving behavioral gaps for a read operation.
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 appropriately sized with three sentences: purpose, parameter details, and return behavior. It's front-loaded with the core purpose and uses clear sections (Args, Returns). There's minimal waste, though the formatting with extra whitespace slightly reduces efficiency.
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 no annotations, no output schema, and a simple parameter (1 param with 0% schema coverage), the description is moderately complete. It covers purpose, parameter semantics, and authentication/return behavior, but lacks details on output format (e.g., structure of rides data), error cases beyond authentication, or performance constraints, which could be important for an API tool.
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 description coverage is 0%, so the description must compensate. It adds significant meaning: it explains the parameter 'date_in_week' as 'Any date within the week in format "YYYY-MM-DD"' with a default behavior ('If None, uses the current date'), which clarifies usage beyond the bare schema. This adequately covers the single parameter.
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 the verb 'Retrieves' and resource 'rides for a specific week from the vanMoof API', making the purpose explicit. It distinguishes from siblings like 'get_rides_summary' by focusing on weekly data rather than summaries, but doesn't explicitly contrast with 'get_city_rides_thisweek' or 'get_world_rides_thisweek' which might have overlapping scope.
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 weekly rides and mentions authentication requirements, but provides no explicit guidance on when to use this tool versus alternatives like 'get_city_rides_thisweek' or 'get_world_rides_thisweek'. The context is clear but lacks sibling differentiation or exclusion criteria.
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 mentions authentication dependency ('if authentication is successful, otherwise None'), which is useful context. However, it lacks details on rate limits, error handling, or data freshness, leaving gaps in behavioral understanding for a tool that likely involves user-specific 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by return details. It uses two paragraphs efficiently, though the 'Returns:' section could be slightly more streamlined. Overall, it avoids fluff and stays focused on essential information.
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 no annotations and no output schema, the description provides basic purpose and output details but lacks comprehensive context. It explains the return format (summary with specific metrics) and authentication dependency, which is helpful. However, for a tool that likely involves user data, more details on permissions, data sources, or limitations would improve completeness.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and output. This meets the baseline expectation for tools with no parameters, as it avoids unnecessary repetition.
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 the tool 'retrieves total rides summary for the VanMoof rider being authenticated,' specifying the verb (retrieves), resource (rides summary), and scope (for the authenticated rider). It distinguishes from siblings like 'get_rides_for_week' by focusing on summary totals rather than detailed or filtered ride data, though it could be more explicit about this differentiation.
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 context through 'for the VanMoof rider being authenticated,' suggesting it's for authenticated users, but it does not explicitly state when to use this tool versus alternatives like 'get_rides_for_week' or 'get_city_rides_thisweek.' No guidance on prerequisites, exclusions, or specific scenarios is provided, leaving usage somewhat ambiguous.
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

Copy to your README.md:

[![mcp-server-vanmoof MCP server](https://glama.ai/mcp/servers/stefanstranger/mcp-server-vanmoof/badges/card.svg)](https://glama.ai/mcp/servers/stefanstranger/mcp-server-vanmoof)

Score Badge

Copy to your README.md:

[![mcp-server-vanmoof MCP server](https://glama.ai/mcp/servers/stefanstranger/mcp-server-vanmoof/badges/score.svg)](https://glama.ai/mcp/servers/stefanstranger/mcp-server-vanmoof)

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/stefanstranger/mcp-server-vanmoof'

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