chuk-mcp-geocoder

by IBM

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: forward geocoding, reverse geocoding, batch, admin boundaries, bounding box, distance matrix, route waypoints, nearby places, and server info tools. No overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern and are descriptive of their function. The naming is uniform and predictable, aiding agent selection.
Tool Count5/5
With 10 tools, the server is well-scoped for a geocoding service. Each tool serves a specific need without being excessive or insufficient.
Completeness5/5
The tool set covers the full lifecycle of geocoding operations: forward/reverse, batch, administrative boundaries, distance calculations, route planning, and status/info. No obvious gaps for its domain.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on February 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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 provided, and description does not disclose behavioral traits like idempotency, rate limits, or authentication requirements; only lists return values.
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?
Description is short and front-loaded with key info; includes Args/Returns in a docstring style that is efficient but slightly verbose for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with one parameter and no output schema, description adequately outlines return values but could explain output format differences between 'json' and 'text'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description adds meaning by specifying the parameter 'output_mode' with possible values and default; compensates for lack of schema documentation.
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?
Description clearly states 'Get geocoder server status' and lists specific return items, showing purpose well but lacks differentiation from sibling like 'geocoder_capabilities'.
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 such as 'geocoder_capabilities' or other status-related tools; missing context for when-not to use.
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 provided, so description must bear full burden. It discloses that the tool returns hierarchy from largest to smallest, but lacks info on errors, rate limits, or idempotency. Safe behavior implied but not explicit.
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?
Description is well-structured with sections (Args, Returns) and front-loaded purpose. Redundant 'Args' section but overall concise and clear.
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 no output schema, description adequately explains return value as admin hierarchy from largest to smallest. However, exact JSON structure or hierarchy levels not detailed, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but description explains lat/lon as coordinates and output_mode as 'json' or 'text'. Adds context beyond schema types, though ranges are already in schema (min/max not shown here but typical).
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 returns administrative boundary hierarchy for a location, from country to neighbourhood. It distinguishes from sibling tools like reverse_geocode by focusing on hierarchy rather than address.
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 like geocode or reverse_geocode. Usage is implied from the description but no when-not-to 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 provided, so description must disclose behavior. It mentions reverse geocoding at multiple zoom levels and returns sorted list, but lacks details on error handling, rate limits, or whether it modifies data.
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?
Well-structured with Args and Returns sections, front-loaded purpose. Slightly verbose with docstring formatting but no wasted sentences.
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?
No output schema, but description outlines return structure. With 5 parameters and no annotations, it covers basic usage but could include more detail on response format or edge cases.
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?
With 0% schema description coverage, the description adds meaning to all 5 parameters (e.g., lat/lon as coordinates, limit default, categories format, output_mode options), compensating for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds places near a coordinate using reverse geocoding at multiple zoom levels, distinguishing it from sibling tools like reverse_geocode and geocode.
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 vs alternatives (e.g., reverse_geocode). Does not mention limitations or prerequisites.
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 carry full behavioral disclosure. It states this is an info retrieval operation, but does not clarify whether it is read-only, requires authentication, or has any side effects. The description is minimal on non-functional aspects.
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 with no wasted words. It uses clear reStructuredText-style Args/Returns sections, front-loads the main verb ('Get'), and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no nested objects) and no output schema, the description adequately covers purpose, parameters, and return content. It mentions 'including tool lists and guidance,' which is sufficient for a capabilities endpoint.
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 schema has 0% description coverage and only defines output_mode as a string with default 'json'. The description adds that it accepts 'json' or 'text', providing more granularity beyond the schema. This compensates well for the lack of schema comments.
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 'Get full server capabilities' and specifies what it returns: tool lists, Nominatim API details, and usage guidance. This distinguishes it from sibling tools that perform geocoding or other specific operations.
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 does not explicitly state when to use this versus alternatives, but the purpose is self-evident for retrieving server capabilities. There is no guidance on when not to use it or comparisons with siblings, leaving some ambiguity for the agent.
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 provided, so description must disclose behavior. It mentions 'nearest place' and provides parameter ranges (lat, lon, zoom) but lacks details on rate limits, authentication, error handling, or response format beyond basic components.
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?
Well-structured with a clear summary followed by parameter and return descriptions. Slightly verbose due to docstring format (Args/Returns) but information is organized and front-loaded.
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?
No output schema, so description must explain returns. It briefly mentions 'Place name, address components, and bounding box' but lacks examples, error cases, or details on address structure. Adequate for basic use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but the description adds meaningful explanations for each parameter: lat/lon ranges, zoom levels, language examples, output_mode options. This compensates well 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?
Clearly states the tool reverses geocode coordinates to a place name and address, specifying inputs (lat, lon) and outputs (display name, structured address, bounding box). Distinguishes from siblings like geocode (forward) and batch_geocode.
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?
Implied usage through parameter descriptions (zoom levels for detail, language for localization) but no explicit guidance on when to use this vs siblings like nearby_places or when not to use.
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 fully covers behavior: it resolves coordinates using geocoding, computes haversine distances, and returns specific results. The CRITICAL section adds valuable retry logic (simplify names, test with single geocode). However, it omits authentication needs, rate limits, or output size constraints, though these are less critical for a read-only geocoding tool.
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 well-structured: a brief purpose sentence, then details, then crucial retry guidance. It is front-loaded and every part adds value. The retry section is somewhat lengthy but justified for agent reliability. Slightly verbose but appropriate for guidance.
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 no output schema, the description explains returns as 'Resolved waypoints, leg distances, total distance, and bounding box' but lacks precise format specification. It also misses error handling beyond retry guidance (e.g., invalid JSON input). The description is functional but could be more explicit about output structure for an agent to parse correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed Args: waypoints is a JSON array with example, output_mode explains 'json' default and 'text' alternative. This adds significant meaning beyond the raw schema (which only has type string). Minor improvement: could specify accepted values for output_mode more explicitly.
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 'Geocode waypoints in order and compute route distances', specifying the verb (geocode, compute) and resource (waypoints, route distances). It distinguishes from siblings like geocode (single point) and distance_matrix (all pairs) by focusing on consecutive waypoints in order.
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 siblings like geocode, batch_geocode, or distance_matrix. It does include retry guidance but fails to mention scenarios where alternative tools would be more appropriate, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses input formats and return type, but omits limitations such as maximum number of points or error handling for invalid coordinates.
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?
Structured with purpose, args, and returns sections. Every sentence adds value, though the Args section could be more terse. Overall efficient.
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?
Covers input, output (NxN matrix in metres), and behavior (pure computation). Lacks constraints like maximum points, but sufficient for a simple calculation tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates thoroughly: explains points as JSON array with two alternative formats and clarifies output_mode default. This adds critical meaning beyond the bare 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?
Description clearly states it computes a haversine distance matrix between points, specifying 'Pure computation — no API calls needed.' It distinguishes itself from sibling tools like geocode and route_waypoints by focusing on straight-line distances.
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?
Mentions 'no API calls needed' implying offline use, but lacks explicit guidance on when to use versus siblings like route_waypoints for along-route distances. No conditions or exclusion criteria are provided.
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?
No annotations exist, so description carries full burden. It discloses Nominatim's behavior, the retry workflow, and typical query difficulties. However, it omits basic safety info like read-only nature or rate limits, which is acceptable given no annotations.
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 well-structured with a docstring format and a separate CRITICAL section. While lengthy, the retry instructions are valuable and earned. Could be slightly trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return value (list with coordinates, bbox, address). It covers edge cases with the retry workflow, making it complete for a geocoding tool with complex failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain parameters. It documents all 5 parameters with examples, ranges, and defaults, adding context beyond the bare schema types. For instance, 'query' gets an example, 'limit' gets range 1-50, 'countrycodes' gets ISO 3166-1 explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs forward geocoding of place names to coordinates, explicitly naming the Nominatim database. It distinguishes from siblings like reverse_geocode and batch_geocode, which are on the same server.
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 detailed retry workflow instructions for when no results are found, including specific simplification steps. While it doesn't explicitly compare to alternatives, the retry logic gives clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses sequential processing, rate limit respect, individual failures not aborting batch, and detailed retry guidance, making behavior fully transparent.
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?
Well-structured with sections (Args, Returns, retry guidance), but slightly verbose; each part earns its place, though could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a batch tool: explains all parameters, behavior, return format (coordinates or error per query), and retry guidance. No output schema needed given this detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds significant meaning: 'queries' is a JSON array with example, 'limit' is max results per query, 'output_mode' defaults to 'json' with 'text' option, all beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it geocodes multiple place names in one call, distinguishing it from sibling tools like 'geocode' (single) and 'reverse_geocode'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It describes sequential processing to respect rate limits and gives retry guidance for failed queries, but does not explicitly state when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: it explains the retry mechanism, the return format (bbox, center, area), and implies it is a read-only operation. It also provides fallback strategies, making the tool's behavior transparent.
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 well-structured with sections for usage, parameters, and a critical retry workflow. It is thorough but not overly verbose; every sentence adds value. Slightly lengthy, but the detail is justified for an AI agent's correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (bbox, center, area). It mentions compatibility with sibling tools (dem_fetch, stac_search) and provides a complete retry strategy. All necessary context for successful invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 0%, the description adds comprehensive meaning to each parameter: query (with example), padding (fractional expansion, default 0.0), and output_mode (json or text). It clarifies their roles beyond the schema's minimal type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a bounding box for a place, suitable for DEM/STAC tools.' It specifies the exact output format and lists compatible tools, distinguishing it from sibling tools like geocode or reverse_geocode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, including a detailed retry workflow for when no results are found. It instructs the agent to progressively simplify the query and retry at least twice before reporting failure, which is critical for reliable agent behavior.
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:

[![chuk-mcp-geocoder MCP server](https://glama.ai/mcp/servers/IBM/chuk-mcp-geocoder/badges/card.svg)](https://glama.ai/mcp/servers/IBM/chuk-mcp-geocoder)

Score Badge

Copy to your README.md:

[![chuk-mcp-geocoder MCP server](https://glama.ai/mcp/servers/IBM/chuk-mcp-geocoder/badges/score.svg)](https://glama.ai/mcp/servers/IBM/chuk-mcp-geocoder)

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/IBM/chuk-mcp-geocoder'

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