grand-lyon-mcp

by ThomasCrouzet

Overview Schema Related Servers Score Discussions

Python

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 clearly distinct purpose: place resolution, departures, mobility status, nearby facilities, trip options, parking, accessibility, environment, waste disposal, personal briefing. No overlap or ambiguity.
Naming Consistency4/5
All tools follow a consistent 'lyon_' prefix and snake_case, with a mix of verb_noun and noun phrases but still predictable and readable.
Tool Count5/5
10 tools is well-scoped for a city services MCP, covering mobility, environment, and waste without being excessive or too few.
Completeness5/5
The tool set covers core city life domains: transport (departures, trips, parking, status), accessibility, environment, waste, and personal briefing. No obvious gaps.
Average 3.1/5 across 10 of 10 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
With no annotations, the description must convey behavioral traits. It does not mention read-only nature, authentication, rate limits, or any side effects. The only hint is that it likely returns a list (based on context).
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, very concise. It is front-loaded with the purpose. However, it could be slightly longer to add value without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, nested objects, and an output schema, the description is too minimal. It does not explain parameter semantics or output, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only hints at one parameter (categories) by listing examples. It does not explain 'location,' 'radius_m,' 'open_at,' or 'limit_per_category,' nor their formats or defaults.
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 it deals with nearby urban facilities and lists examples (toilets, fountains, etc.), which gives a general idea. However, it doesn't use an explicit action verb like 'find' or 'list,' and the French phrasing may be ambiguous. It partially distinguishes from siblings by topic but lacks specificity.
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 guidance is provided on when to use this tool versus alternatives like lyon_resolve_place or lyon_mobility_status. There are no explicit use cases or limitations mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the output includes parking with available spaces 'if known', implying a read operation, but offers no details on side effects, authentication, rate limits, or data freshness. The description is insufficient for understanding behavioral traits beyond the basic result.
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 a single short sentence, which is concise but lacks structure and key details. While not verbose, it fails to earn its place by omitting critical information about parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, a required nested object, and an output schema, the description is incomplete. It does not explain how to provide the destination (e.g., format) or the meaning of other parameters like types or minimum_spaces. The presence of an output schema reduces the burden for return values, but parameter guidance is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate. However, it only mentions 'destination' implicitly and provides no explanation of limit, types, radius_m, minimum_spaces, or the structure of the destination object. This leaves the agent with no guidance on how to properly invoke the tool.
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 indicates the tool provides public parking and park-and-ride options near a destination, including available spaces if known. It effectively identifies the resource (parking) and scope (near destination) but lacks a verb like 'list' or 'find' to specify the action. It distinguishes from siblings like lyon_nearby_facilities by focusing on parking specifically.
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. With nine sibling tools including lyon_nearby_facilities and lyon_trip_options, explicit usage context or exclusion statements would be valuable but are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'deterministic taxonomy' but lacks details on side effects, required permissions, error handling, or whether the tool is read-only. The behavioral transparency is minimal.
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 efficiently conveys the core purpose. It is not verbose, though some additional context could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and an output schema, the description is insufficient. It does not explain how to specify location, filter by open hours, or interpret results. The completeness is inadequate for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no information about any of the six parameters (item, limit, open_at, location, radius_m, transport), leaving the agent without guidance on how to use them.
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 classifies waste items into a deterministic taxonomy and proposes recycling centers or collection points. This is a specific verb+resource combination that distinguishes it from sibling tools like mobility or parking services.
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 does not mention prerequisites, excluded scenarios, or any comparative context with the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It lists the types of information but does not disclose read-only nature, authentication needs, whether no parameters returns all data, or any side effects. This lack of behavioral detail limits 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 covering purpose and an exclusion. It is front-loaded and efficient, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered, but the description fails to document the three optional parameters thoroughly. It lacks examples or guidance on parameter combinations, making it incomplete for a tool with multiple inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description adds no parameter information. The three optional parameters (areas, lines, include) are not explained, forcing the agent to rely on names alone, which is insufficient for correct invocation.
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 states the tool provides transport and traffic status (alerts, accessibility, traffic, construction) and explicitly excludes use for next departures at a specific stop. This clearly defines the tool's scope and distinguishes it from sibling like lyon_next_departures, though it could be more specific about the exact output.
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 indirectly guides usage by stating what it is not for (next departures), implying it is for general mobility status. However, it does not explicitly state when to use it over alternatives like lyon_trip_options or provide preconditions, leaving some ambiguity.
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?
Discloses that no notifications are sent and that triggering/delivery is client responsibility. However, with no annotations, it lacks detail on side effects, permissions, or data freshness.
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?
Two concise sentences, with the core purpose in the first. The second sentence adds important behavioral context. Could be slightly improved by front-loading parameter hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not elaborate on what the briefing contains beyond the brief list. Input parameters are insufficiently described, leaving gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only vaguely references 'profil local' and fails to explain the 'at' and 'compare_with_previous' parameters. Most parameter semantics are missing.
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 a personal briefing based on a local profile, mentioning specific elements (usual route, alerts, Vélo'v). It distinguishes itself by not sending notifications, but does not explicitly differentiate from sibling tools like lyon_environment_brief.
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 guidance on when to use this tool versus siblings or when not to use it. The description implies use with a local profile but lacks explicit context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only discloses that it returns immediate passages; lacks details on data freshness, error handling, required format for stop object, or any behavioral constraints beyond 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?
Two sentences, both essential. First sentence states core purpose, second sentence clarifies scope and provides alternative. No redundancy, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to document parameter usage, especially the required nested object 'stop'. For a tool with 5 parameters including nested objects and 0% schema coverage, this is insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and 5 parameters exist. The description provides no information about any parameter, not even the required 'stop' object. No guidance on 'at', 'line', 'direction', or 'limit'.
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?
Clearly states it returns next TCL passages at a stop/station, using specific verb 'retourne' and resource 'prochains passages TCL'. Distinguishes from sibling tool lyon_trip_options by specifying it's for immediate schedules only.
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?
Explicitly states scope: 'Pour les horaires immédiats uniquement' (immediate schedules only) and directs to lyon_trip_options for complete trips. Provides clear context but no other exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 the tool compares modes but does not disclose whether it is read-only, requires authentication, or has other side effects. The list of modes is helpful but insufficient for behavioral understanding.
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 extremely concise: two sentences that front-load the main purpose and include a key exclusion. Every word adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (2 required, nested objects) and no annotations, the description is too brief. It lacks parameter guidance, though the existence of an output schema may partially compensate for return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no information about the parameters (origin, destination, modes, preferences, departure_at, arrival_before). This leaves the agent with no guidance on how to fill these complex fields.
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 compares multiple modes of transport (TCL, Vélo'v, P+R, car, walking) between two locations, which is a specific verb and resource. It also explicitly distinguishes from the sibling tool lyon_next_departures.
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 mentions using this tool for comparing modes between two places and notes it does not replace lyon_next_departures for a single stop. This provides clear context but does not cover when to use other sibling tools.
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 burden. It adds a useful behavioral note that missing data is not treated as accessible, but lacks details on read-only nature, authentication, or rate 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?
Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters lacking descriptions and a complex domain (accessibility check), the brief description does not cover parameter usage or output specifics, leaving significant gaps despite an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the four parameters (needs, stops, origin, destination). Meaning and expected format are left to inference.
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 includes a specific verb ('Vérifie l'accessibilité') and resource ('arrêts ou trajet'), clearly distinguishing it from sibling tools like lyon_trip_options which plan routes, not check accessibility.
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 checking wheelchair and step-free accessibility of stops or a trip, but provides no explicit guidance on when to use this tool versus alternatives like lyon_nearby_facilities or lyon_trip_options.
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 burden. It discloses that indicators without a source are signaled without blocking others, which is a useful behavioral trait. However, it lacks details on update frequency, data accuracy, or authentication needs.
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?
Two sentences with no wasted words. However, could be improved by including brief parameter descriptions without adding length.
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 3 parameters (one nested), no annotations, and an output schema, the description adequately covers purpose and a key behavior but falls short on parameter semantics and output expectations. The existence of an output schema reduces the need to explain return values, but parameter guidance is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'for a zone' and lists indicator types, but does not describe the 'at' (time) or 'indicators' (filter) parameters, nor the structure of the 'location' object. This leaves agents guessing about required parameter semantics.
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?
Description clearly states the tool returns environmental indicators (pollen, air quality, heat) for a zone, with a specific verb ('disponibles' implies retrieves). It distinguishes from sibling tools which cover different domains like transport and parking.
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?
While it doesn't explicitly state when to use vs alternatives, sibling tools are clearly in different domains (mobility, facilities), so usage context is clear. It doesn't provide exclusions or alternative recommendations.
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 provided, so the description carries the burden. It discloses the tool resolves places (non-destructive) and does not calculate routes. It could mention that it returns place IDs or coordinates, but the existence of an output schema partially mitigates this. No contradictions.
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, 45 words, with a clear front-loaded purpose, followed by usage advice and a negative constraint. No unnecessary words.
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 4 parameters and 0% schema description, the description should provide more detail on how to use parameters like 'query' and 'types'. The existence of an output schema does not compensate for missing parameter guidance. The description is adequate for basic understanding but incomplete for full correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description mentions place types (address, stop, station, neighborhood, personal place) but does not link to the 'types' parameter, nor does it explain 'query', 'near', or 'limit'. The agent gains little understanding of how to set parameters beyond 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 explicitly states it resolves addresses, TCL stops, Vélo'v stations, neighborhoods, and personal places in Lyon. It distinguishes from siblings by advising usage before other tools when a place is ambiguous and clarifying that it does not calculate itineraries.
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 provides clear guidance: 'Use this tool before others when a place is ambiguous' and explicitly states what it does not do ('Ne calcule pas d'itinéraire'). No further guidance needed.
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-grand-lyon MCP server](https://glama.ai/mcp/servers/ThomasCrouzet/mcp-grand-lyon/badges/card.svg)](https://glama.ai/mcp/servers/ThomasCrouzet/mcp-grand-lyon)

Score Badge

Copy to your README.md:

[![mcp-grand-lyon MCP server](https://glama.ai/mcp/servers/ThomasCrouzet/mcp-grand-lyon/badges/score.svg)](https://glama.ai/mcp/servers/ThomasCrouzet/mcp-grand-lyon)

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/ThomasCrouzet/mcp-grand-lyon'

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