mapnetwork-mcp
Server Details
Generate styled PNG/SVG map images of any location with 11 customizable color themes.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- toruproject/mapnetwork-mcp
- GitHub Stars
- 0
- Server Listing
- MapNetwork MCP Server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 2 of 2 tools scored.
The two tools have clear and distinct purposes: compute_route handles routing between locations, while generate_map produces a styled map image. There is no overlap in functionality.
Both tool names follow a consistent verb_noun pattern (compute_route and generate_map), making them predictable and easy to understand.
With only 2 tools, the server is on the low end of the acceptable range. While the tools cover basic map operations, the count feels slightly thin for a map network server, but not unreasonably so.
The server provides routing and map generation, but lacks common features like geocoding (address to coordinates) or distance matrix calculations. This gap is notable but can be partially worked around if users supply latitude/longitude directly.
Available Tools
2 toolscompute_routeBInspect
Compute a walking or driving route between two locations.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'walking' (default) or 'driving'. | |
| to_location | Yes | Same format as from_location. | |
| from_location | Yes | {"label": "place name"} or {"label": ..., "location": {"lat":..., "lng":...}}. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states the modes (walking/driving) but does not disclose what the route includes (e.g., distance, duration, turn-by-turn directions), whether it's real-time, or any auth/cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, front-loaded with the verb, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and nested objects, the description is too terse. It does not explain the output (no output schema) or how route results are presented, leaving significant ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description's mention of 'walking or driving' mirrors the schema enum and adds no additional meaning beyond what the parameter descriptions provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Compute', the resource 'route', and the scope 'walking or driving between two locations'. It distinguishes from the sibling tool 'generate_map' which likely handles map visualization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling 'generate_map' or under what conditions (e.g., prerequisites, limitations). The description lacks explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_mapAInspect
Generate a styled map image for a location. Specify 'place', 'lat'+'lng', or 'markers'.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude of the map center. Must be combined with lng. | |
| lng | No | Longitude of the map center. Must be combined with lat. | |
| name | No | Map name stored in the data file. | |
| place | No | Place name to center the map on. Use this OR lat/lng, not both. | |
| route | No | Route to overlay, as returned by compute_route. | |
| config | No | Overrides for automatic layer-visibility defaults. Omit any field to keep the default. | |
| format | No | 'png' (default) or 'svg'. | |
| layers | No | Map layers to render. Default ['road', 'poi']. Valid: road, highway, driving, walking, railway, waterline, greenarea, poi. | |
| radius | No | Circular coverage radius in meters (max depends on layers). Mutually exclusive with size_ew/size_ns. | |
| markers | No | List of locations to pin on the map, e.g. [{"label": "Tokyo Station"}]. | |
| size_ew | No | East-west width of a rectangular coverage area in meters. Must be combined with size_ns. | |
| size_ns | No | North-south height of a rectangular coverage area in meters. Must be combined with size_ew. | |
| color_set | No | Color theme. One of: darkBlue, darkGreen, popArt, lightBlue, lightGreen, beige, magenta, white, gray, black, brawn. | |
| poi_types | No | Filter POI categories when 'poi' is in layers. | |
| place_icon | No | Custom icon override for the place/center pin. | |
| edge_weight | No | Road/line width adjustment. Positive thickens, negative thins. | |
| canvas_width | No | Canvas width in pixels (default 1000). | |
| canvas_height | No | Canvas height in pixels (default 700). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully disclose behavior. It does not mention side effects, permissions, mutual exclusions (e.g., radius vs size_ew/size_ns), or limitations. This is insufficient for a 18-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two sentences, front-loaded with the main action. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 18 parameters, no required ones, and no output schema, description is too brief. It doesn't explain output format, how to choose among many options, or interaction between parameters. Falls short for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal value beyond schema by naming three parameter groups. Does not explain complex parameters like config or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates a styled map image for a location, with specific mention of three location specification methods (place, lat+lng, or markers). This distinguishes it from the sibling tool compute_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides guidance on specifying location (place, lat+lng, or markers), which is essential for usage. However, it doesn't explicitly mention when not to use or alternatives like compute_route, missing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.