FotMoCP

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 purpose: match discovery, specific stat categories, prediction context, team/player details, etc. No two tools appear interchangeable.
Naming Consistency5/5
All tools follow a clear verb_noun snake_case pattern (e.g., find_matches, get_goalkeeper_match_stats), providing predictable naming.
Tool Count5/5
10 tools cover the core football data domains (matches, teams, players, stats) without being overwhelming or too sparse.
Completeness4/5
The tool set covers search, match details, team/player stats, injury updates, and prediction context. A minor gap is the lack of a direct league standings tool, but overall coverage is solid.
Average 3/5 across 10 of 10 tools scored.
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.
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 provided, the description carries full burden for behavioral disclosure. It only lists the data returned (minutes, appearance, injury status) but fails to state that the tool is read-only, does not specify data freshness or time range for 'recent,' and omits any potential side effects or authentication requirements.
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, efficient sentence with no filler. It front-loads the core action and data, making it easy to scan.
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 one parameter, no output schema, and no annotations, the description is too brief. It fails to specify the output structure, time range for data, or how 'recent' is defined, leaving the agent with insufficient context to use the tool effectively.
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 sole parameter playerId is described only by name in the schema; the description does not add any additional meaning, such as how to obtain the playerId or its format. Since schema description coverage is 0%, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a player's recent minutes, last appearance, and injury status, giving a specific verb and resource. However, it does not distinguish this tool from siblings like get_team_availability or get_match_stats, which could also involve player data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives or prerequisites. The description implies it's for player workload info, but lacks context on when not to use it or what other tools might be better suited (e.g., for match-specific stats).
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 must convey behavioral traits. It only states the action but does not disclose whether the operation is read-only, requires authentication, has side effects, or any rate limits. The agent cannot assess safety or cost.
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 sentence with no wasted words, but it lacks important details that would make it more useful. It is concise but under-specified, trading completeness for brevity.
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 one simple parameter and no output schema, the description provides the core intent. However, it does not describe the output format, how return dates are represented, or whether injured players includes all or only major injuries. It is minimally adequate for a straightforward list 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?
The description does not mention the 'teamId' parameter or explain its format, source, or constraints. With 0% schema description coverage, the description should compensate but fails to add meaning beyond the schema's type and minimum value.
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 lists injured players and their return dates, which is a specific verb+resource. However, the tool name 'get_team_availability' suggests broader availability, while the description narrows to injuries, causing slight misalignment. It distinguishes from siblings like 'get_team_form' or 'get_team_season_profile'.
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., 'get_team_form' or 'search_fotmob'). There is no mention of prerequisites, limitations, or excluded contexts. The agent is left to infer usage from the tool name and description.
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 bears the full burden of disclosure. It mentions that the tool returns results, home/away splits, ranking, and xG, implying a read-only operation. However, it does not describe ordering, pagination behavior, or what 'when present' means for xG, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs information efficiently. However, it could be restructured to list key outputs and parameters more clearly. It is concise but not optimally structured for quick parsing.
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 low complexity (2 parameters, no output schema), yet the description does not fully explain the output format or behavior. Terms like 'home/away splits' and 'ranking' are left undefined, and without output schema, the agent has insufficient detail to expect the result structure.
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 description does not reference either parameter (teamId, limit). Given 0% schema description coverage, the description fails to compensate, leaving the agent without guidance on how to specify the team or control the number of results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'recent results and home/away splits, with ranking and per-match xG when present.' It distinguishes the tool's purpose somewhat from siblings like 'get_team_season_profile' by focusing on recent form, but could be more specific about the exact output scope.
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 such as 'get_team_season_profile' or 'find_matches.' There is no mention of prerequisites or contextual scenarios, relying solely on the tool name for context.
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 fully convey behavior. It only states the counting action but omits details like the meaning of 'recent' (likely tied to the limit parameter), output format, and whether the counts are per-game or aggregated. This is insufficient.
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, clear sentence but is too brief; it does not include necessary parameter or output context. It is efficient but at the expense of completeness.
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?
For a simple tool with no output schema and no annotations, the description should explain what the tool returns (e.g., count numbers, structured data). It only implies counts but does not specify format, leaving the agent uncertain.
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% (no parameter descriptions). The description does not mention the teamId or limit parameters, leaving the agent to guess their purpose. It adds zero semantic value 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 the verb 'count' and the specific resource 'recent wins, draws, and losses after a team led or trailed'. This uniquely distinguishes it from sibling tools like get_team_form, which handles general form without the lead/trail condition.
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 like get_team_form or get_match_stats. No exclusions or prerequisites are provided.
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?
The description notes 'when present' for FIFA ranking, hinting at optional fields, but lacks comprehensive behavioral disclosure. No annotations are provided, so the description should cover safety (e.g., read-only nature), permissions, or potential errors, which it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's output. It avoids redundancy and is front-loaded with the purpose. However, it could be slightly more structured by mentioning the parameter.
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 low complexity (1 parameter, no output schema), the description lists the returned fields adequately. However, it does not specify the return format (e.g., single object vs. array) or how to interpret metrics like xG or xPoints, which would aid completeness.
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 input schema has 0% description coverage, and the description does not mention the 'teamId' parameter or its meaning. Although the parameter name is intuitive, the description fails to add semantic value beyond the schema's type and minimum constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'team's season profile', listing specific data fields (table record, xG, xGA, xPoints, FIFA ranking). This distinguishes it from sibling tools like get_team_form and get_team_availability, which focus on different aspects.
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, or when not to use it. For example, it doesn't mention that this tool provides season-level stats as opposed to per-match stats from tools like get_match_stats.
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 fails to disclose behavioral traits like side effects, authentication needs, or return structure. It only mentions what is returned (score, deduplicated stats) without details on deduplication behavior.
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, concise and front-loaded. It wastes no words, but could benefit from slight structuring (e.g., separate parameter note).
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 complexity (1 param, no output schema, no annotations), the description is minimal. It does not explain the return format or how deduplication works, which is important for a stats tool among many siblings.
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 0%, but the description adds useful context for matchId: it can be an ID or FotMob URL. This supplements the schema's type constraints. However, no other parameter details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'score plus deduplicated team and player stats', specifying a concrete verb and resource. However, it does not explicitly differentiate from sibling tools like get_goalkeeper_match_stats or get_match_prediction_context.
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. The only usage hint is that matchId can be an ID or URL, which is more of a parameter note than a usage guideline.
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?
The description only states the basic purpose and output (IDs). With no annotations, it fails to disclose behavioral traits such as whether it returns multiple results, error handling (e.g., no matches), rate limits, or side effects. It is a read-like operation but not explicitly stated.
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 leads with the action and specifies the output. It avoids unnecessary words but could benefit from a bit more context without becoming verbose.
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 simplicity (one parameter, no annotations, no output schema), the description is incomplete. It omits usage guidelines, behavioral traits, and parameter details. An agent would need additional assumptions to use it correctly.
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 compensates slightly by indicating the query is a name to search for. However, it does not explain format, case sensitivity, or possible values, leaving the parameter underspecified.
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 searches for names and returns FotMob IDs for teams, players, leagues, and matches. It distinguishes itself from sibling tools like get_team_form or find_matches, which are more specific data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 is no mention of prerequisites, limitations, or examples of appropriate queries. The sibling tools imply context, but the description itself lacks any usage direction.
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 full burden of behavioral disclosure. It states what data is returned but does not mention side effects, permissions, or read-only nature. For a tool that likely performs a read operation, this is insufficient.
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 listing the returned items without extraneous text. It is efficient but could be structured with bullets or separated concerns.
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 one parameter, no output schema, and many siblings, the description adequately lists returned data but does not explain the 'prediction context' unifying theme or when to choose this over narrower tools.
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 description adds that matchId 'may be an ID or FotMob URL', which provides context beyond the schema's type specification. However, with 0% schema description coverage, more parameter guidance (e.g., URL format) would be beneficial.
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 lists specific data items (clock, events, lineups, etc.) that the tool retrieves, using the verb 'Get' with a clear resource name. This distinguishes it from sibling tools like get_match_stats or get_team_form, which focus on narrower aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_match_stats or get_team_form. It does not mention prerequisites, exclusions, or contexts where other tools are preferred.
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 fully disclose behavior. It implies a read operation by stating it 'get' stats, which is correct. However, it does not mention potential errors (e.g., invalid matchId), rate limits, authorization needs, or output format. This is adequate for a simple tool but lacks completeness.
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: one sentence stating the tool's purpose and one clarification about the parameter. Every word adds value; no redundancy. The structure is front-loaded with key 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 parameter set (one required parameter) and no output schema, the description adequately covers the tool's purpose and parameter format. However, it omits details about the return structure (e.g., format of stats) and error handling, which would be beneficial for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for matchId. The description adds value by clarifying that matchId can be a numeric ID or a FotMob URL string, which is beyond the schema's type definition (oneOf integer or string without further context).
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 specifies the tool retrieves goalkeeper-specific stats (saves, shots on target, save percentage, xGOT, goals prevented). The verb 'get' and resource 'goalkeeper_match_stats' are explicit. However, it does not differentiate from sibling tools like 'get_match_stats', reducing clarity for agents deciding between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context that 'matchId may be an ID or FotMob URL', which aids correct parameter input. However, it fails to specify when to use this tool over alternatives (e.g., for general match stats vs goalkeeper-specific), nor does it mention any prerequisites or exclusions.
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?
Without annotations, the description carries full burden. It indicates a read operation (list) with date filtering, but no mention of side effects, authentication, or rate limits. Adequate for a simple tool.
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 key info. Every word earns its place; no redundancy or filler.
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 one parameter and no output schema, the description covers purpose and usage but omits output details (e.g., what fields are returned). Adequate for a simple list tool.
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?
Adds meaning beyond schema by clarifying that the date is a UTC date and that results are matches on that date. Schema only provides pattern; description adds context though no format details.
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 the action (list), resource (FotMob matches), and constraint (on a UTC date). The second sentence distinguishes it from tools needing a match ID, aligning with siblings like get_match_stats.
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 when to use ('when you do not have a match ID'), implying when not to use (when you have a match ID). Lacks direct naming of alternatives but is sufficiently clear.
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:

[![FotMoCP MCP server](https://glama.ai/mcp/servers/Margeshy/FotMoCP/badges/card.svg)](https://glama.ai/mcp/servers/Margeshy/FotMoCP)

Score Badge

Copy to your README.md:

[![FotMoCP MCP server](https://glama.ai/mcp/servers/Margeshy/FotMoCP/badges/score.svg)](https://glama.ai/mcp/servers/Margeshy/FotMoCP)

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/Margeshy/FotMoCP'

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