MapmyIndia Mappls MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool maps to a distinct location API operation: geocoding, reverse geocoding, typeahead suggestions, routing, distance matrix, road snapping, nearby POI search, place details, and text search. The only real overlap is between autosuggest and text_search, but their descriptions clarify the intended use cases.
Naming Consistency4/5
All tools share a consistent mappls_ prefix and snake_case format. Most names follow a verb-plus-object style like get_directions or search_nearby, though a few are bare nouns such as distance_matrix and place_details, so the pattern is clean but not perfectly uniform.
Tool Count5/5
Nine tools is well-scoped for a location/mapping server. Each tool covers a distinct workflow with no obvious redundancy, and the count is within the ideal range for an MCP toolset.
Completeness4/5
The server covers the core read-only location lifecycle well: geocode and reverse geocode, place search and details, directions, distance matrix, and map matching. Advanced features like static map rendering or route optimization are absent, but common mapping workflows have no critical gaps.
Average 3.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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?
No annotations are present, so the description carries the full behavioral burden. It only discloses vehicle modes and India coverage; it does not mention route semantics (e.g., turn-by-turn instructions, traffic/toll behavior), API requirements, or limits. This is a thin behavioral profile for a routing 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?
The description is a tight single sentence that front-loads the action and packs in modes, endpoints, and region. Every word contributes to core meaning; there is no redundant or filler text.
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 schema fully documents parameters and an output schema covers return shape, so the minimal description is serviceable. However, it omits sibling differentiation and usage context, and with no annotations the behavioral side is thin, leaving the definition merely adequate.
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%, and each parameter is already documented in the schema. The description simply restates origin/destination as coordinates/eLocs without adding new meaning, so the schema baseline applies.
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 opens with a specific action, 'Get ... navigation directions', and identifies the resource and supported modes (driving/walking/biking/trucking) plus the geographic scope. This makes it distinct from the geocoding/search siblings and from mappls_distance_matrix, which focuses on distance/time rather than routes.
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 explains what the tool does but never states when an agent should choose it over mappls_distance_matrix, snap_to_road, or other siblings. There are no exclusions, prerequisites, or route-selection scenarios, leaving the selection decision entirely to inference.
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 of behavioral disclosure. It implies a non-destructive read via 'Retrieve', but does not disclose error behavior, invalid eLoc handling, authentication needs, rate limits, or response characteristics. This is a significant gap for a 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?
The description is a single, well-structured sentence that states the action, object, and required input format without any filler. Every word contributes meaning and no information is buried.
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 one-parameter lookup with an output schema, the description is adequate at a basic level, but it lacks sibling differentiation and behavioral context that would help an agent confidently choose and call this tool. It is minimally viable, not fully complete.
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% and the schema already documents the eloc parameter with format and examples. The description adds no new parameter semantics beyond what the schema provides, so the baseline score of 3 applies.
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 ('Retrieve'), names the resource ('rich location attributes and details'), and identifies the unique key ('6-character Mappls eLoc code'). This clearly separates it from sibling tools like geocode or reverse_geocode, which use addresses or coordinates instead of eLocs.
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 such as mappls_autosuggest or mappls_geocode. The only implied usage is that the caller must have an eLoc, but no explicit conditions or exclusions are stated.
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 carries the behavioral burden, and it does add one useful trait: auto-correction for spelling variations. It also implies a read-only search over place entities, but it does not disclose ordering, result limits, fallback behavior, or how the optional location bias affects ranking, so transparency is only partial.
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 one sentence with no filler or repetition; it front-loads the core action and includes the key behavioral feature. Every word adds value, making it an example of appropriate conciseness.
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 description is sufficient for understanding the basic operation, and the schema plus output schema cover parameters and return structure. However, with eight sibling tools and no mention of how this differs from mappls_autosuggest or mappls_geocode, the definition lacks enough contextual grounding for reliable tool selection.
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%, so the schema fully documents both 'query' and 'location'; the description does not need to repeat parameter details. Baseline 3 applies because the description adds no parameter-specific semantics beyond the general notion of text search already captured by 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 a clear action ('perform smart text search') and a clear resource ('place entities'), adding a distinctive feature ('auto-correction for spelling variations'). It does not explicitly differentiate from siblings like mappls_autosuggest or mappls_search_nearby, so it falls short of a 5, but the core purpose is unambiguous.
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 about when to use this tool versus alternatives such as mappls_autosuggest, mappls_geocode, or mappls_search_nearby. 'Perform smart text search' restates the function rather than providing selection criteria or exclusion conditions, leaving the agent to infer usage context from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds the geographic constraint 'in India' and the implied read-only nature of 'Calculate'. It does not disclose potential API limitations, error behavior, or any other operational traits.
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 front-loads the core action and resource, with no wasted words. It efficiently conveys the essential purpose and scope.
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 schema and output schema cover parameter details and return structure, but the description lacks explicit usage guidance and behavioral context beyond the basic purpose. For a relatively simple tool, this is adequate but not complete; an agent would benefit from knowing when this tool outranks get_directions or snap_to_road.
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 provides 100% coverage of origin, destination, and profile parameters, including coordinate format and default values. The description adds no parameter-specific detail beyond what the schema already contains, so the baseline of 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 uses a specific verb ('Calculate') and resource ('travel distances and durations matrix'), clearly distinguishing it from sibling tools like get_directions, which focuses on individual routes, and geocoding tools. The geographic scope ('in India') adds further precision.
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 phrase 'between multiple origin and destination points' implies the tool is suited for matrix-style requests rather than single-route calculations, giving some context. However, it does not explicitly mention when to prefer this over siblings like get_directions or mention any exclusions 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?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that this is India-focused geocoding and that results include standardized address details and eLoc codes, but it does not mention limits, edge cases, or any special behavior. The read-only nature of geocoding is reasonably clear from the tool name and description.
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, efficient sentence that front-loads the action and captures the resource, geographic scope, and key return values. There is no filler or redundant phrasing.
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 two-parameter tool with complete schema documentation and an output schema, the description is largely sufficient. The main missing piece is explicit guidance on when to use this instead of closely related location 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 input schema already documents both parameters clearly with an example for address and a default for region, so the description adds little beyond restating the output. With 100% schema description coverage, a baseline of 3 is appropriate.
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 and resource — 'Geocode an address or location text' — and names concrete outputs: latitude, longitude, eLoc code, and standardized address details. It does not explicitly contrast with siblings like mappls_autosuggest or mappls_text_search, but the forward-geocoding intent is 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 through examples like 'Connaught Place, New Delhi', but it never states when to choose this tool over alternatives such as mappls_autosuggest or mappls_text_search. The intended context is inferable but not explicit.
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?
With no annotations, the description carries the behavioral burden. It clearly identifies the operation as a read-only lookup ('get') and tells the agent what kind of result to expect: formatted address plus administrative details. It does not describe edge cases or coordinate-system assumptions, but it doe disclose the core behavior without contradiction.
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 starts with the action, names the exact inputs, and states the outcome. There is no filler or repetition; every part of the sentence contributes to understanding what the tool does.
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 low complexity tool with two fully documented parameters and an existing output schema, the description covers the essential invocation context. The only notable omission is explicit guidance about selecting this tool over its sibling geocoding tools, which is handled separately under usage guidelines.
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 documents both parameters with descriptions and examples, achieving 100% coverage. The description adds no new parameter-level meaning beyond naming latitude and longitude, 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?
Th description clearly states a specific verb-resource action: reverse geocoding coordinate pairs into formatted addresses and administrative details. It is unambiguous about what the tool does, though it does not explicitly contrast itself with the sibling mappls_geocode or other address-related 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 implies the natural use case: when you have latitude and longitude and need an address. However, it does not explicitly state when to prefer this tool over mappls_geocode, mappls_reverse_geocode sibling alternatives, nor when not to use it.
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?
It discloses the core behavior: search for POIs around supplied coordinates. With no annotations provided, the description carries the full burden, but it does not disclose pagination behavior, radius constraints, or any auth/rate-limit context beyond what the schema already provides.
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 sentence, tightly scoped, with action and object front-loaded. The category examples are useful and concise; there is no fluff or redundant restating of the tool title.
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 5-parameter search tool with full schema coverage and an output schema, the description plus structured fields is enough for basic invocation. It lacks explicit sibling-routing guidance, but that is a usage-guidelines concern rather than a blocker to calling this tool 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?
Schema description coverage is 100%, so the baseline applies. The description's keyword examples roughly mirror those already in the schema and add no new parameter constraints, formats, or relationships beyond what the input schema documents.
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 states a specific verb ('Search'), a clear resource ('points of interest'), and the scope ('near given coordinates'), with concrete category examples. This cleanly distinguishes coordinate-based nearby search from sibling tools like geocoding or place details.
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 coordinate phrase implies this tool is appropriate when the agent has a latitude/longitude and wants nearby POIs. However, it does not explicitly state when not to use it or mention alternatives such as mappls_text_search for text-based queries without coordinates.
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 of explaining behavior. It does state the transformation ('snap to nearest road segments') and the purpose ('smooth GPS noise'), but it does not disclose limitations, edge cases, or behavior differences across transport profiles.
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 that front-loads the core operation and purpose with no redundant wording. Every part contributes meaningful 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?
For a straightforward tool with a fully described schema and an output schema available, the description and schema together provide enough context to invoke the tool correctly. It could be slightly richer, but nothing critical is 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%, so the schema already documents both parameters and their formats. The description adds no additional parameter semantics, making the baseline 3 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 uses a specific verb ('Snap') and names both the input resource ('raw GPS coordinates trace') and the target ('nearest road network segments'). This clearly differentiates it from the geocoding, directions, and search sibling 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 intended use is implied through the description: apply it when you have a noisy raw GPS trace that needs road-network snapping. However, it does not explicitly state when not to use it or mention any alternative tool.
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?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool operates on partial user input, returns suggestions live as text is typed, and ranks places by relevance. It could add more detail about ranking criteria, but it is not misleading or severely incomplete.
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 short, information-dense sentences. The core behavior and output type are front-loaded, with no filler or repetition.
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 output schema exists and all parameters are documented, the description provides enough context for an agent to understand what to expect. It could be stronger by explicitly contrasting with mappls_text_search or mappls_geocode for complete-query use cases, but the autocomplete context is clear.
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%, with query, zoom, and location each already documented. The description confirms the query prefix pattern but adds no parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate.
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 names a specific behavior—auto-suggesting location search predictions as text is typed—and notes that it returns ranked place recommendations. This goes beyond a tautology and helps distinguish it from related tools like mappls_text_search or mappls_geocode, though it does not explicitly name those alternatives.
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 phrase 'as text is typed' gives clear contextual guidance for when this tool is appropriate: interactive prefix-based autocomplete. It does not explicitly state when not to use it or name alternative tools, but the intended usage context is strong.
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

MapmyIndia Mappls MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![MapmyIndia Mappls MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Bhupendrajee07/MMI-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Bhupendrajee07/MMI-MCP)

Score Badge

Copy to your README.md:

[![MapmyIndia Mappls MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Bhupendrajee07/MMI-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Bhupendrajee07/MMI-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/Bhupendrajee07/MMI-MCP'

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