DNDzgz MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. The tools are organized by transport mode (Bizi, bus, tram) and function (stations/stops vs. estimations), and the geolocation and Google Maps tools serve unique supporting roles. An agent can easily distinguish between them based on their specific targets.
Naming Consistency5/5
All tool names follow a consistent pattern of 'zaragoza-[transport]-[function]' or a descriptive prefix like 'geolocation-from-address' and 'google-maps-link'. This verb-noun or noun-noun structure is uniform throughout, making the set predictable and readable.
Tool Count5/5
With 8 tools, the count is well-scoped for the server's purpose of providing Zaragoza transport information. Each tool earns its place by covering distinct aspects like stations, real-time estimations, and location utilities, without being overwhelming or insufficient.
Completeness5/5
The tool set offers complete coverage for the domain of Zaragoza transport. It includes CRUD-like operations (list stations and get estimations) for all major modes (Bizi, bus, tram), plus supporting tools for geolocation and maps, ensuring no gaps in the workflow for finding and using transport services.
Average 2.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 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 ISC 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 the full burden of behavioral disclosure. It mentions 'realtime' estimation, which hints at dynamic data, but fails to describe other traits like potential rate limits, error handling, data freshness, or response format, leaving significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (real-time data retrieval), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't cover key aspects like response structure, error cases, or data sources, leaving the agent poorly equipped to use the tool effectively.
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 input schema has 1 parameter with 0% description coverage, and the tool description adds no information about the 'station' parameter. It doesn't explain what the number represents (e.g., station ID, code), valid ranges, or examples, failing to compensate for the schema's lack of detail.
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 with a specific verb ('Get') and resource ('estimation of when arrives to a tram station in Zaragoza in realtime'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'zaragoza-bus-estimations' or 'zaragoza-bizi-estimations', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contextual factors that might influence tool selection, such as comparing tram estimations to bus or bizi estimations, leaving the agent without 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 the full burden of behavioral disclosure. It mentions 'realtime' estimation, which is useful, but fails to cover critical aspects like rate limits, error handling, data freshness, or authentication requirements. For a tool that likely queries an external API, this omission leaves significant gaps in understanding its operational 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, well-structured sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded with the key action ('Get the estimation'), making it easy to parse quickly. Every part of the sentence adds value, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (real-time data query), lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain the return format (e.g., JSON structure), error cases, or how to interpret 'bikes and free slots' data. This leaves the agent with insufficient information to handle the tool robustly in various scenarios.
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 1 parameter with 0% description coverage, so the description must compensate. It only implies a 'station' parameter without explaining what it represents (e.g., station ID, name, or how to obtain valid values). This lack of semantic detail makes it harder for an agent to use the tool correctly, as the parameter's meaning and format are unclear.
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: 'Get the estimation of bikes and free slots in a Bizi station in Zaragoza in realtime.' It specifies the verb ('Get'), resource ('bikes and free slots'), and context ('Bizi station in Zaragoza'), making it easy to understand. However, it doesn't explicitly differentiate from its sibling 'zaragoza-bizi-stations', which might list stations rather than provide real-time availability estimates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'zaragoza-bizi-stations' (which might list stations) or other estimation tools (e.g., 'zaragoza-bus-estimations'), leaving the agent to infer usage based on context alone. This lack of explicit comparison reduces effectiveness in tool selection.
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 states the tool retrieves data ('Get all Bizi stations'), implying a read-only operation, but doesn't clarify whether it requires authentication, has rate limits, returns real-time or static data, or what format the output takes. The description is minimal and lacks essential behavioral 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple data retrieval tool and front-loads the core functionality.
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 apparent simplicity (2 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the purpose of the required latitude/longitude parameters, what data is returned, or how it differs from sibling tools. For a tool with undocumented parameters and no output schema, more context is needed.
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 2 required parameters (latitude, longitude) with 0% description coverage, and the tool description provides no information about these parameters. It doesn't explain what the latitude and longitude represent (e.g., center point for search, user location), their expected format, units, or valid ranges, leaving parameters undocumented.
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: 'Get all Bizi stations in Zaragoza, the bicycle rental public service.' It specifies the verb ('Get'), resource ('Bizi stations'), and location context ('in Zaragoza'), though it doesn't explicitly differentiate from sibling tools like 'zaragoza-bus-stops' or 'zaragoza-tram-stations' beyond the bicycle rental focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'zaragoza-bizi-estimations' (which might provide availability or timing data) or other transportation tools, nor does it specify any prerequisites or exclusions for usage.
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 states the tool provides 'realtime' estimations, which hints at dynamic data, but does not cover critical aspects such as data freshness, rate limits, error handling, authentication needs, or response format. For a real-time data tool with zero annotation coverage, this is a significant gap.
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 directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, with every part contributing to understanding the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (real-time data retrieval), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not address how estimations are returned, what data is included, or potential limitations, making it inadequate for effective agent use.
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 1 parameter with 0% description coverage, and the description does not add any semantic information about the 'stop' parameter. It does not explain what 'stop' represents (e.g., stop ID, name, or code), valid ranges, or examples. With low schema coverage, the description fails to compensate, leaving the parameter poorly documented.
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: 'Get the estimation of when a bus arrives to a stop in Zaragoza in realtime.' It specifies the action ('get the estimation'), resource ('bus'), and scope ('Zaragoza'), distinguishing it from sibling tools like zaragoza-bizi-estimations (bikes) and zaragoza-tram-estimations (trams). However, it doesn't explicitly differentiate from zaragoza-bus-stops, which might be related but serves a different function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like zaragoza-bus-stops (which might list stops) or other estimation tools for different transport modes, nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit 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 provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: whether it returns all stops globally or filtered by proximity, what format the results are in, whether there are rate limits, or any error conditions. This leaves significant gaps for an agent to understand the tool's operation.
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 at just one sentence with no wasted words. It's front-loaded with the core purpose and uses clear, straightforward language. Every word earns its place in this minimal description.
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 tool with 2 required parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the parameter purpose, result format, or behavioral characteristics. The agent would struggle to use this tool effectively without additional context or experimentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two required parameters (latitude, longitude), and the description provides no information about what these parameters mean or how they affect the results. The description says 'Get all bus stops' which seems to contradict the need for location parameters, creating confusion about whether filtering occurs.
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 action ('Get') and resource ('all bus stops in Zaragoza'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'zaragoza-bus-estimations' or 'zaragoza-bizi-stations', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention whether it's for general listing, proximity-based queries (implied by latitude/longitude parameters but not stated), or how it differs from other Zaragoza transportation tools like 'zaragoza-bus-estimations' or 'zaragoza-tram-stations'.
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 states what the tool does but doesn't describe how it behaves—e.g., whether it returns a list, how it handles errors, if it requires authentication, or if there are rate limits. This leaves significant gaps for an agent to understand 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, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to parse quickly, and every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool with two required parameters and no output schema) and the lack of annotations, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of station objects), how parameters influence results, or behavioral aspects like error handling, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the two required parameters (latitude, longitude) are undocumented in the schema. The description doesn't add any meaning beyond the schema—it doesn't explain what these parameters represent (e.g., a center point for filtering stations) or how they affect the output, failing to compensate for the low coverage.
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 resource ('all tram stations in Zaragoza'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'zaragoza-tram-estimations' or 'zaragoza-bus-stops', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'zaragoza-tram-estimations' (which likely provides real-time data) or 'zaragoza-bus-stops' (which covers a different transit mode), nor does it specify 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.
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 states the tool generates a link but doesn't describe what the link looks like (e.g., URL format, whether it opens in a browser), any rate limits, error handling, or authentication needs. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 concise and front-loaded: the first part clearly states the core function. The additional context about helping find stations or stops is useful but could be more integrated. It avoids unnecessary words, though it could be slightly more structured for clarity.
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 (2 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format (e.g., what the link looks like), error cases, or usage constraints. For a tool that generates external links, more context on behavior and results would be helpful for an AI agent to use it effectively.
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 mentions 'coordinates' but doesn't specify the parameters (latitude and longitude) or their semantics (e.g., decimal degrees, range constraints). With 0% schema description coverage, the description adds minimal value beyond implying coordinate input. It doesn't compensate for the coverage gap, but since there are only 2 parameters, the baseline is slightly higher than minimal.
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: 'Get a Google Maps link from coordinates' specifies the action (get) and resource (Google Maps link). It adds context about helping people find stations or stops, which clarifies the use case. However, it doesn't explicitly differentiate from sibling tools like 'geolocation-from-address', which serves a related but different purpose.
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 minimal usage guidance: it mentions helping people find stations or stops, which implies a navigation context. However, it doesn't specify when to use this tool versus alternatives (e.g., 'geolocation-from-address' for reverse geocoding) or any prerequisites like coordinate format. No explicit when-not or alternative guidance is given.
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 mentions the tool returns 'geolocation (latitude and longitude)' and 'formatted address,' but doesn't cover other important aspects like error handling, rate limits, authentication needs, or what happens with invalid addresses. For a tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds usage context. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple geocoding with 1 parameter), no annotations, and no output schema, the description is somewhat complete but has gaps. It covers purpose and usage but lacks details on behavior, parameters, and return values. For a tool with no structured support, this is adequate but not fully comprehensive.
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 has 1 parameter with 0% description coverage, so the description must compensate. It mentions 'address' as the input but doesn't add details beyond what's implied (e.g., format, examples, or constraints like 'only for Zaragoza' addresses). This provides minimal semantic value, aligning with the baseline when schema coverage is low but not fully compensating.
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: 'Get the geolocation (latitude and longitude) from an address and the formatted address that was found, only for Zaragoza.' It specifies the verb ('Get'), resource ('geolocation'), and scope ('only for Zaragoza'). However, it doesn't explicitly differentiate from sibling tools like 'google-maps-link' or other geospatial tools, which would require a 5.
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 provides clear context for usage: 'only for Zaragoza' and 'Can be used to find a bus stops, tram stations or bizi stations.' This gives practical guidance on when to use it. However, it doesn't explicitly state when not to use it or name alternatives (e.g., 'google-maps-link' for broader geocoding), which would be needed for a score of 5.
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-dndzgz MCP server](https://glama.ai/mcp/servers/danilat/mcp-dndzgz/badges/card.svg)](https://glama.ai/mcp/servers/danilat/mcp-dndzgz)

Score Badge

Copy to your README.md:

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

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/danilat/mcp-dndzgz'

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