tiles_jsonTileJSON spec metadata for a MapTiler tileset (zoom range, bounds, layer schema). Specialist tool for GIS integrators — most users want geocode / static_map_url instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tileset | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "tileset": "openstreetmap"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds context about returning TileJSON spec metadata but does not disclose additional behaviors such as rate limits, authentication requirements, or the full response format. Given the strong annotation coverage, a score of 3 is appropriate.
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?
The description consists of two concise sentences. The first sentence defines the tool's output, and the second provides usage guidance. Every sentence serves a clear purpose with no redundancy or filler. It is front-loaded with the core function.
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?
Given the tool's simplicity (single parameter, extensive annotations, no output schema) and its niche audience (GIS integrators), the description covers the essential context: what the tool returns and when to use it. It could be improved by describing the 'tileset' parameter or the TileJSON schema, but the specialist audience may already know this. The example in the schema partially compensates.
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?
The input schema has only one parameter ('tileset') with 0% description coverage. The description mentions 'MapTiler tileset' but does not explain what valid values are, how to specify them, or any constraints (e.g., it only shows 'openstreetmap' in the example). With no schema description and minimal description guidance, the agent may struggle to invoke the tool correctly.
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 precisely states the tool returns TileJSON spec metadata (zoom range, bounds, layer schema) for a MapTiler tileset. It explicitly distinguishes the tool as a specialist tool for GIS integrators, contrasting with geocode/static_map_url for general users. This clearly communicates the tool's purpose and differentiates it from siblings like geocode and static_map_url.
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?
The description provides clear guidance: use this tool when you need TileJSON metadata for GIS integration. It also advises that most users should use geocode/static_map_url instead, effectively telling the agent when not to use this tool. While it doesn't explicitly name other sibling tools for GIS tasks, the guidance is sufficient for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools have distinct purposes, but there is overlap, e.g., ask_pipeworx vs ask_pipeworx_grounded vs deep_research all for data lookup, and multiple Polymarket tools. Descriptions are detailed enough to distinguish, but the set is confusing.
Naming is highly inconsistent: snake_case (ai_visibility_check), verb_noun (resolve_entity), underscores (ask_pipeworx), and domain-specific prefixes (polymarket_). No consistent pattern across tools.
With 38 tools spanning geospatial, data lookup, prediction markets, memory, feedback, etc., the count is too high for a coherent server. Many tools are one-off and unrelated to the server's name (Maptiler).
The tool set covers many areas but lacks obvious gaps for each domain (e.g., MapTiler only has 4 tools). The overall surface is a collection of unrelated features, not a cohesive domain, so completeness is poor for any single purpose.