André — Analyse électorale française

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct aspect of electoral analysis (simulation, export, visualization, table creation, SQL query, elections, admin, elected officials, sociodem, candidate profiles). No overlap, clear boundaries.
Naming Consistency4/5
Tools follow a verb_noun pattern with underscores, but mix English ('simulate', 'export', 'query') and French ('fusions', 'elus', 'sociodem') terms, a minor inconsistency.
Tool Count5/5
10 tools is well-scoped for the domain of French electoral analysis, covering data retrieval, analysis, simulation, and output without being excessive.
Completeness5/5
The set covers core electoral workflows: querying results, administrative divisions, elected officials, sociodemographics, candidate profiles, simulation, and data export/visualization. No obvious gaps.
Average 3.6/5 across 10 of 10 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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 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?
Annotations already indicate readOnlyHint, idempotentHint, destructiveHint false. The description adds 'Requête' which matches read-only behavior, but provides no additional context such as output format, pagination, or rate limits. Minimal added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but critically omits necessary details. It is under-specified rather than concise; every sentence is present but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 0% schema coverage) and availability of an output schema, the description should explain parameter usage and return structure. It does not, leaving significant gaps.
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%. The description only lists action names but fails to explain parameters like search_term, mandate_type, departement_code. No semantic enrichment beyond the schema.
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 queries 'élus de la République française' (specific resource) and lists three actions, but does not differentiate them. Purpose is clear but lacks distinction between sibling query tools like query_elections.
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 alternatives (e.g., query_elections). The actions are listed but without explanation, leaving the agent to infer usage.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds the list of actions, which clarifies what queries are possible, but does not explain how parameters interact with each action or any other behavioral detail.
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 short and front-loaded with the purpose. It wastes no words, but the brevity comes at the cost of missing necessary details.
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's complexity (router to multiple queries with 6 parameters and siblings), the description is incomplete. It omits details on how parameters map to actions, return values, and when to use each action.
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?
With 0% schema description coverage and 6 parameters, the description only lists possible action values but does not explain the meaning or usage of any parameter, including the required 'action' parameter. This is a critical gap.
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 queries French administrative divisions and lists specific actions, making the purpose evident. However, it does not explicitly differentiate from sibling tools like query_elections, though the title and action names imply the domain.
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. The list of actions hints at its scope, but there is no explicit 'when to use' or 'when not to use' advice.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds behavioral context by listing actions (list_variables, profile, etc.) and data sources, beyond what annotations provide.
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 concise (two sentences) but lacks structure. It front-loads the purpose but mixes data source details and actions without clear separation, making it slightly harder to parse.
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 is incomplete for a tool with 5 parameters and 1 required. It does not explain how to use actions or other parameters, leaving the agent without enough guidance to invoke the tool correctly.
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% with no parameter descriptions. The description does not explain any of the five parameters (e.g., action, variable, commune_code). It mentions 'Actions' but does not connect to the action parameter or provide usage 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 states 'Requête les données socio-démographiques au niveau bureau de vote', specifying the verb (query) and resource (sociodemographic data at polling station level). It also mentions data sources and lists available actions, which distinguishes it from siblings like query_elections or query_admin.
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?
No explicit guidance on when to use this tool vs alternatives. The sibling tools cover different data domains (elections, admin, etc.), so context is implicit, but there is no statement of when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes it returns a formatted text table, adding some behavioral context beyond annotations. Annotations already indicate idempotent and non-destructive. However, it lacks details on error behavior or permission requirements.
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 three concise sentences, front-loaded with the main action. No unnecessary 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 and 0% schema coverage, the description leaves significant gaps. It does not explain how to structure columns and rows, which is critical for correct invocation.
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%, so the description must compensate. It only says 'from structured data' and does not explain the parameters (title, columns, rows, description). This is insufficient for proper use.
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 verb 'Crée' (creates) and the resource 'tableau de données formaté' (formatted data table). It specifies input as structured data and output as a formatted text table. This distinguishes it from sibling tools like query tools or visualize.
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 says 'Utile pour présenter des résultats calculés ou combinés' (useful for presenting calculated or combined results), giving clear usage context. It does not explicitly state when not to use it or mention alternatives, but the context is sufficient.
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?
Annotations indicate idempotentHint=true and destructiveHint=false; the description adds modes but doesn't clarify side effects or state changes. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose. No unnecessary words, but could be slightly more structured.
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?
Description covers modes and formats but lacks details on file_format defaults and return values (though output schema may exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to data and source_path parameters. However, filename and file_format are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports electoral data to downloadable files (CSV, JSON, TSV) and mentions two modes. This distinguishes it from sibling query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (data vs source_path) but does not explicitly state when to use each or when not to use the tool. No alternatives are mentioned.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is clearly a safe read operation. The description adds valuable context: scale (~546k candidates, ~10k communes), classes, and available actions (summary, composition, parite, etc.), which enriches the agent's understanding beyond the 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 extremely concise: three short sentences covering purpose, scale, classes, and actions. Every sentence adds value without redundancy. It is front-loaded with the main verb and resource.
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 complexity (8 parameters, 1 required) and the presence of an output schema, the description provides high-level context but omits parameter details and usage conditions. It sufficiently covers the tool's domain and actions but leaves parameter semantics incomplete.
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. However, it only lists action values indirectly via the 'Actions' list, but does not explain any other parameters (sexe, classe, search, tetes_only, commune_code, etc.). This leaves most parameters undocumented, failing to add meaning 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 clearly states 'Requête les données DLP (composition sociale des candidats municipaux 2020)' with specific verb and resource. It lists distinct classes and actions, and the title and context distinguish it from sibling query tools (e.g., query_elections, query_admin), making its purpose unmistakable.
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 querying social profile data of municipal candidates by listing available actions, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., other query tools) or when not to use it. No exclusion criteria or prerequisites are stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description reinforces that the tool queries data and lists many actions, but does not add much beyond annotations. The detailed action explanations provide some behavioral context (e.g., 'panel actions avoid loops'), which is helpful.
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 long but well-structured: it starts with the main purpose, then lists territorial levels, base actions, and panel actions separately. It is front-loaded with essential info. However, it could be more concise; some redundancy exists (e.g., repeating parameter names in action descriptions).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (36 parameters, many actions, output schema exists), the description covers a lot: territorial levels, all actions with their required parameters, and panel actions that avoid loops. It doesn't explain return values (output schema covers that) or all parameter details, but it is fairly complete for a complex tool.
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. While it mentions some parameter names in action contexts (e.g., election_id, commune_code), it does not explain their format, allowed values, or semantics for most of the 36 parameters. The description is insufficient for an agent to understand all parameters correctly.
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 'Requête les données électorales françaises (1999-2026)' — a specific verb (requête) and resource (French election data). It lists multiple distinct actions and panel actions, differentiating them from sibling tools like query_sociodem or query_elus.
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 explains territorial levels and lists actions with their required parameters (e.g., 'compare_elections requires election_id, compare_to_election, and a territory code'). It also notes that panel actions avoid loops, providing usage guidance. However, it does not explicitly state when not to use the tool, but the context is clear.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it is only for municipal elections and specifies the two actions, consistent with annotations. 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?
The description is extremely concise, using two sentences with bullet-like formatting for actions. Every word adds value, with no redundant information.
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 simple nature of the tool and the presence of an output schema, the description covers the essential purpose and actions. Lacking explanation for 'report_rate' is a minor gap, but overall it is complete enough for an agent to understand usage.
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?
With 0% schema description coverage, the description partially compensates by explaining the 'action' parameter (values 'status' and 'simulate') and implicitly references election_id and commune_code. However, the optional 'report_rate' parameter is not mentioned, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it simulates fusion scenarios of municipal lists between T1 and T2, with two specific actions ('status' and 'simulate'). It distinguishes from sibling tools that focus on data queries and exports, as this is a simulation tool.
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 municipal elections but does not provide explicit guidance on when to use or when not to use this tool. No alternatives are suggested, though sibling tools serve different purposes.
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?
Annotations indicate readOnlyHint=false (non-read-only), destructiveHint=false, idempotentHint=true. The description accurately portrays the tool as creating a visualization and returning a JSON spec, which is non-destructive and idempotent. It adds context about the output format not in 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 concise with two short paragraphs and a bullet list. Every sentence adds value, front-loading the purpose and modes. 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?
The tool has 8 parameters and no required ones. The description covers the two modes and some params, but misses color, title, and data_file. An output schema exists, so return format is covered, but input documentation is incomplete, making it less than fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries the burden. It explains the two modes involving spec, chart_type, data, x, y. However, it omits parameters like color, title, and data_file, leaving them undefined. This partial coverage is insufficient given the 0% schema coverage.
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 'Crée une visualisation Plotly (retourne le spec JSON)' with specific verb and resource. It lists two modes and supported chart types, distinguishing it from sibling tools focused on data queries/export.
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 explains when to use each mode (free spec vs assisted) and lists supported chart types. It does not explicitly state when not to use the tool or name alternatives, but the context is clear enough for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral context: the database is DuckDB read-only, column names with spaces must be quoted, and lists important tables and columns. 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?
The description is concise, well-structured, and front-loaded with the primary purpose. Every sentence adds value: purpose, tables, warnings, usage guidance, example. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (SQL query, multiple tables, quoting needs), the description is complete. It provides table schemas, column details, usage guidance, and an example. Output schema exists, so return values are covered.
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?
Schema coverage is 0% for the single parameter 'query', but the description compensates with extensive context: table listings, column names with quoting rules, and a realistic example query. However, it does not formally describe the parameter structure or constraints.
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 verb (exécute) and resource (requête SQL directe sur DuckDB) and distinguishes itself from sibling query_elections by emphasizing its use for advanced ad hoc queries.
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?
Explicitly states when to use this tool vs alternatives: 'PRÉFÉRER query_elections pour les analyses standard — query_sql est pour les requêtes ad hoc avancées.' Provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

[![andre-mcp MCP server](https://glama.ai/mcp/servers/joelgombin/andre-mcp/badges/score.svg)](https://glama.ai/mcp/servers/joelgombin/andre-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/joelgombin/andre-mcp'

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