mcp-mayotte

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
mayotte_search_data_gouv and mayotte_search_datasets both target the same data.gouv.fr dataset search and could be confused, and list_reference_items is vague next to get_sources. Otherwise the tools separate fairly clearly into dataset, commune, source, and vigilance functions.
Naming Consistency5/5
All tools consistently use the mayotte_ prefix with lowercase snake_case and clear verb-object combinations such as list_communes, find_commune, get_vigilance, and fetch_source_excerpt. The naming pattern is uniform and predictable.
Tool Count5/5
Ten tools is well within the ideal range for a regional information server. Each tool contributes to a distinct area such as datasets, communes, sources, or vigilance without unnecessary bloat.
Completeness4/5
The tool surface covers the core read-only workflows: searching and retrieving datasets, looking up communes, listing curated sources, and getting vigilance information. Minor gaps exist, such as no dedicated commune detail tool and some vagueness around reference items, but agents can work around them.
Average 3.7/5 across 10 of 10 tools scored. Lowest: 3.1/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 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.
This repository includes a glama.json configuration file.
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 provided, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, if it accesses an external API (data.gouv.fr) with potential rate limits, what the response format looks like, or any side effects. The description merely states the action without revealing behavioral traits, leaving the agent in the dark about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. It is front-loaded and contains zero filler words. Every word earns its place, making it efficient and easy to scan.
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 simple search tool, the description is minimally adequate: it names the resource, scope, and optional topic. However, it does not explain the return format (e.g., list of datasets with metadata), nor does it clarify what 'Mayotte-specific' filtering entails or elaborate on pagination beyond the schema. Given that no output schema exists and sibling tools could cause ambiguity, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters: 'topic' with examples and 'page_size' with default and constraints. The description adds no additional meaning beyond what the schema states, merely restating that it 'optionally adds a topic'. Since the schema fully documents parameter semantics, this meets the baseline for this dimension.
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: searching data.gouv.fr for Mayotte-specific datasets. It uses a specific verb ('search') and specifies the resource ('data.gouv.fr') and scope ('Mayotte-specific'). However, it does not differentiate itself from the sibling tool 'mayotte_search_data_gouv', which likely has a similar function, so it misses the opportunity to distinguish its unique role.
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?
There is no guidance on when to use this tool versus its sibling 'mayotte_search_data_gouv' or other related tools. The description only says it optionally adds a topic, giving no context about preconditions, exclusions, or alternative usage scenarios. This leaves the agent without direction on selecting this tool for the right task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral transparency. 'List' implies a read-only operation and 'when available' hints that the result may conditionally be empty, but it does not describe error cases, whether the list is exhaustive, or what sort of data these reference items contain. For a zero-parameter tool, this minimal transparency is acceptable but not rich.
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?
A single sentence with no filler or redundancy. It is appropriately sized for a zero-parameter, informational listing tool and front-loads the key verb and object.
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?
The description does not explain what 'reference items' are, what the output looks like, or how 'available' is determined. Since there is no output schema and no annotations, the description should provide more context for the agent to know the value and expected return of this tool. The information provided is minimal and leaves important semantic 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 input schema has zero parameters, and schema coverage is effectively 100%. With no parameters to describe, the description does not need to add parameter semantics, and the baseline for zero parameters applies.
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 uses a specific verb 'List' and identifies the resource as 'built-in reference items' for this MCP, which distinguishes it from sibling tools that list communes, sources, or datasets. However, 'reference items' is somewhat vague and the conditional phrase 'when available' adds ambiguity.
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. There are no explicit prerequisites, exclusions, or distinctions from sibling tools. The only usage clue is the description's self-evident label, which is not enough to guide an agent choosing among the nine siblings.
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 for behavioral disclosure. It states the operation is a search via the official public API, implying read-only access, but it does not mention return format, pagination behavior, or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose without fluff or 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?
The tool has no output schema, so the description should ideally clarify what the search returns. It also doesn't differentiate from the sibling mayotte_search_datasets, leaving ambiguity. For a simple two-parameter tool, key contextual details are missing.
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 description coverage is 100% for both parameters (query and page_size). The description adds no extra parameter semantics, but the schema already documents each parameter adequately, so the baseline of 3 applies.
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 specifies the verb 'search' and resource 'public datasets on data.gouv.fr', with the additional detail of the official public API. It clearly indicates the tool's function, though it doesn't explicitly distinguish from the similarly named sibling mayotte_search_datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to search for public datasets specifically on data.gouv.fr. It does not discuss when to prefer alternatives or any exclusions, but the context is unambiguous.
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 must carry the burden. It only says it uses geo.api.gouv.fr, but doesn't disclose whether it's read-only, what it returns (e.g., a single commune object or array), or error behavior (e.g., not found). This is insufficient for a lookup tool with zero annotation coverage.
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?
One clear sentence, no fluff, front-loaded with the verb 'Find' and the 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 simplicity of the tool (single param, no output schema), the description is mostly complete, but it lacks any mention of return value or potential ambiguity (e.g., multiple matches). It could be improved by stating what it returns.
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 100% for the single parameter 'query', which already describes its possible values. The description adds the explicit list of input types (name, INSEE, postal code) but this is redundant with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: finding a Mayotte commune by name, INSEE code, or postal code. It uses a specific verb ('Find') and resource ('Mayotte commune'), and the mention of three lookup types distinguishes it from sibling tools like 'list_communes' which lists all communes.
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 (when you need to look up a specific commune), but it does not explicitly state when to prefer this over alternatives like mayotte_list_communes or mayotte_search_data_gouv. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure; 'Return' and 'public page excerpt' imply a read-only public fetch, but the description does not explicitly state that no data is modified, whether network failures are possible, or how the excerpt is truncated. It is minimally transparent but lacks deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every phrase ('official', 'Mayotte Météo-France', 'vigilance URL', 'short public page excerpt') adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only retrieval tool, the description is reasonably complete: it states what is returned and implicitly that the source is public. An output schema is absent, but the return values (URL and excerpt) are described adequately. A little more context around failure behavior would be needed for a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter, include_excerpt, with a clear description and default. The tool description adds little parameter-specific detail beyond the notion of a 'short public page excerpt,' so the schema handles the semantics and the description earns the baseline 3.
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 uses a specific verb ('Return') and identifies the exact resource: the official Mayotte Météo-France vigilance URL plus a short public excerpt. This distinguishes it from sibling tools like mayotte_get_sources or mayotte_search_datasets, which target different resources.
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 gives no guidance on when to use this tool versus alternatives, and does not mention any exclusions or preconditions. Usage context is only implied by the tool name and the reference to Mayotte/Météo-France.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. The verb 'inspect' implies a read-only operation, and 'using the official public API' suggests a safe, external call. However, it does not explicitly state non-mutation, rate limits, or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the tool's purpose without any fluff. Every word adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description explains its core functionality. However, it does not mention what happens on failure or what the return format is, leaving some details unspecified. For a basic get-by-id tool, this is adequate but not thorough.
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 description coverage is 100%—the parameter 'dataset' is already described as 'Dataset slug or id.' The description adds no additional meaning beyond what the schema provides, so it meets the baseline but does not exceed it.
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 inspects a single data.gouv.fr dataset by slug or id, using a specific verb (inspect) and resource. This distinguishes it from sibling tools like search or list, which handle different operations.
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 conveys a clear use case: when you have a specific dataset slug or id and want to inspect it. It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to infer its purpose.
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 must carry the transparency burden. It adds 'short excerpt' and 'curated source' context beyond the schema, and hints at a simple read operation. However, it does not disclose potential side effects (unlikely), error behaviors (e.g., if URL is not found), or any rate limits. Since this is a simple read, the level of disclosure is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the primary action and then provide a key detail about parameter usage. Every word earns its place; there is no redundancy or filler. It perfectly balances brevity with necessary 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 simplicity of the tool (2 parameters, no output schema), the description is relatively complete. It covers the core purpose, hints at the source of source_key, and implies a read-only operation. The only minor gap is that it does not describe the return format edge cases, but for such a simple fetch tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying that source_key can be 'a number' (interpreting 'index') and connects it to `get_sources`, which is not explicit in the schema. This extra guidance helps agents understand the accepted formats without additional lookups.
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 fetches a short text excerpt from one curated source URL. It uses a specific verb ('Fetch') and resource ('short text excerpt' from a curated source), and distinguishes itself from siblings like `get_sources` by focusing on the excerpt itself. The reference to `get_sources` further differentiates it as the next step in a workflow.
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 by stating the source_key comes from `get_sources`, but it does not explicitly say when to use this tool over siblings (e.g., when you need a quick excerpt vs. full metadata). It gives some guidance on the source_key format but lacks clear 'use this when' or 'alternatives' language, so it falls to implied 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?
With no annotations, the description must carry the burden of disclosing behavior. 'List' implies a read-only operation with no side effects, but it does not mention authentication requirements, data freshness, or any potential limitations. The description is minimal and lacks explicit behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without any fluff. It is well-structured and directly addresses the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of parameters or output schema, the description is mostly complete. It tells the user what the tool does, though it does not elaborate on what constitutes 'curated official and high-value sources' or how the list is structured. This is a minor gap but not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is nothing to explain. The description does not need to add parameter meaning, and the lack of parameters is fully reflected in the schema. This dimension is not applicable and scored as perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists curated official and high-value sources for Mayotte, using the verb 'list' and specifying the resource. It distinguishes itself from sibling tools like search, get, and find by focusing on a curated list of sources.
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 indicates the tool returns a list of sources but provides no explicit guidance on when to use this tool versus alternatives like search_data_gouv or get_dataset. It implies usage for obtaining curated sources but lacks comparative context.
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 burden. It discloses that the tool accesses geo.api.gouv.fr and returns specific fields, implying a read-only operation. However, it does not mention data freshness, potential API limitations, or whether this is a simple static listing. It adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs all necessary information: the action, the data source, and the returned fields. No fluff, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides sufficient detail about the return values. It doesn't mention pagination or bulk size, but for a simple listing of communes with known fields, this is adequate. No serious 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 zero parameters and the schema is empty. Since there is nothing for the schema to document, the description's text effectively defines the tool's behavior. It clearly states the output fields, which is the only meaningful semantic content needed for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Mayotte communes from geo.api.gouv.fr and specifies the exact data fields returned (INSEE code, postal codes, population, center geometry). It distinguishes itself from sibling tools like mayotte_search_data_gouv or mayotte_find_commune by focusing on listing all communes.
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 implies this is the go-to tool for retrieving a full list of communes with their reference data, but it does not explicitly state when to use it over alternatives like mayotte_find_commune for a single commune search. The context is clear enough for an agent to infer usage, but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It clearly states the tool is explanatory (read-only in nature), but it doesn't explicitly confirm no side effects or any additional behavioral details like return format. For a zero-param explanation tool, the risk is low, but the description could be more explicit about what 'explain' entails (e.g., returns a text summary).
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?
One concise sentence that captures both the purpose and the guidance. No fluff, front-loaded with the primary action.
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?
For a tool with no parameters announced and no output schema, the description is sufficient. It tells the agent what the tool does and hints at how to use it (combining sources). There are no complex behaviors or missing parameter details to compensate for.
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?
There are zero parameters, so the baseline is 4. The description doesn't need to explain parameters. No additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Explain what this MCP is useful for and how an agent should combine its sources.' This is a specific verb+resource (explain scope) that distinguishes it from sibling lookup/search tools. It's unambiguous and not a tautology.
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?
It implies when to use it: when an agent needs to understand the overall MCP's utility and how to combine sources. It doesn't explicitly name alternatives, but the context is clear for a meta-orientation tool. Sibling tools are data retrieval, so this stands out as 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:

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

Score Badge

Copy to your README.md:

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

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/Hug0x0/mcp-mayotte'

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