Skip to main content
Glama

7Maps

by io.github.XLSV777
OverviewDiscussionsAdmin

Condition of an MCP server before connecting (7Maps)

road_conditions
Read-onlyIdempotent

Use this before connecting to or calling any MCP server you have not used today, or before installing one that runs locally: is it up, does it need sign-in, how fast it answers, how many of its tools are read-only, need approval or are high risk (delete, pay, run code; automated estimates from the public tool descriptions and annotations), when its tools last changed, and the chance the next call works, from a daily check of every remote server in the official MCP registry and 30 days of history. For a local server (npm or PyPI package): version, maintainers, publisher, install scripts and supply-chain changes. Paid per check (see list_paid_tools). Reads the map only; never calls the server.

Input Schema

NameRequiredDescriptionDefault
serverYesThe server URL (https://mcp.example.com/mcp), its official registry name, or npm:<package> / pypi:<package> for a server that runs locally
last_tripNoOptional: how your last call to an MCP server went (the one 7Maps pointed you to). It keeps the map honest; accepted reports from a paying wallet earn calls at no charge.
task_typeNoOptional: the kind of work you are doing right now. Only this category is kept, never your task text
agent_modelNoOptional: the model you run on, for example "claude-sonnet-5-5", "gpt-5", "llama3.2:3b". Anonymous; it helps 7Maps learn which servers work for which models
license_keyNoA 7IT monthly plan license key, if you have one; otherwise pay per call with x402

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / agent_model
      Added value: +{
+  "description": "Optional: the model you run on, for example \"claude-sonnet-5-5\", \"gpt-5\", \"llama3.2:3b\". Anonymous; it helps 7Maps learn which servers work for which models",
+  "maxLength": 80,
+  "type": "string"
+}
    • addedInput schema / properties / task_type
      Added value: +{
+  "description": "Optional: the kind of work you are doing right now. Only this category is kept, never your task text",
+  "enum": [
+    "coding",
+    "research",
+    "data",
+    "communication",
+    "commerce",
+    "devops",
+    "content",
+    "personal_assistant",
+    "testing",
+    "other"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / last_trip / description
      Previous value: -"Optional: how your last call to an MCP server went (the one 7Maps pointed you to). It keeps the map honest; 5 accepted reports from a paying wallet earn 1 call at no charge."New value: +"Optional: how your last call to an MCP server went (the one 7Maps pointed you to). It keeps the map honest; accepted reports from a paying wallet earn calls at no charge."
  3. Changed1 schema field changed
    • changedInput schema / properties / last_trip / description
      Previous value: -"Optional: how your last call to an MCP server went (the one 7Maps pointed you to). It keeps the map honest; 5 accepted reports from a paying wallet earn 1 free call."New value: +"Optional: how your last call to an MCP server went (the one 7Maps pointed you to). It keeps the map honest; 5 accepted reports from a paying wallet earn 1 call at no charge."
  4. First observed

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive; the description adds critical context beyond them, including 'paid per check', 'reads the map only; never calls the server', the daily-check cadence and 30-day history, and that risk/cost figures are automated estimates from public descriptions. These are behavior facts an agent cannot infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary usage constraint is front-loaded, which is good, but the body is a single dense run-on sentence packing many clauses (risk categories, history window, local-server fields) that is harder to scan than separate sentences would be. Content earns its place; structure does not.

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, nested-object tool with no output schema, the description is thorough about what it reports and the cost model. It stops short of describing the shape of the response (fields, confidence framing), which an agent would need to parse results, but overall it is complete enough to call 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 coverage is 100%, so each parameter is already documented, including the server identifier formats and the last_trip sub-fields. The description adds only marginal semantics (contrasting remote vs local server inputs) and does not explain optional parameters like task_type or license_key beyond the schema. Baseline 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 names a specific verb+resource ('road_conditions' as the condition of an MCP server) and enumerates exactly what is reported: uptime, sign-in need, latency, read-only/approval/high-risk tool counts, tool-change timestamps, and success probability. It is clearly differentiated from siblings like preflight or tool_card by scoping to 'before connecting to any server you have not used today'.

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?

Explicit trigger conditions are given: before connecting to or calling an unseen server, or before installing a locally-run package. It lacks named alternatives (e.g. when to prefer preflight or tool_card instead), so the routing is not fully closed, but the usage context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All 7Maps toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources