Skip to main content
Glama

7Maps

by io.github.XLSV777
OverviewDiscussionsAdmin

Safest MCP server for a task (7Maps)

route
Read-onlyIdempotent

Use this when you need a tool for a task and do not know which MCP server to use, or when several could do it: finds servers whose tools match the task and ranks them by the chance the call works, how stable the server is, and least privilege (a server that can do less harm than another is preferred when both can do the task). Returns the best server and tool, alternatives and servers to avoid. Paid per task (see list_paid_tools). Reads the map only.

Input Schema

NameRequiredDescriptionDefault
needNoHow much the task must be allowed to do: read only, change something, or a high-risk action such as payments or deletion. Guessed from the task when omitted
taskYesWhat you need to do, for example "send a transactional email" or "search company records"
paymentNoPayment terms: any (default); free_only = only servers that declare no payment; paid_ok = servers that charge are fine, servers whose payment terms are unknown are left out. Paid servers show their declared price per call.
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
    • addedInput schema / properties / payment
      Added value: +{
+  "description": "Payment terms: any (default); free_only = only servers that declare no payment; paid_ok = servers that charge are fine, servers whose payment terms are unknown are left out. Paid servers show their declared price per call.",
+  "enum": [
+    "any",
+    "free_only",
+    "paid_ok"
+  ],
+  "type": "string"
+}
  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 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."
  4. 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."
  5. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description usefully reinforces this with 'Reads the map only' while adding non-obvious facts: pay-per-task billing, the pointer to list_paid_tools, and the shape of the return (best match, alternatives, servers to avoid). It does not mention rate limits, latency, or what happens when no server matches.

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?

It is front-loaded with the trigger condition and the ranking logic before the cost and return-value notes; nearly every clause carries information. The long parenthetical about least privilege is dense but earns its place by defining the ranking criterion.

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?

With no output schema, the description correctly compensates by naming what is returned (best server and tool, alternatives, servers to avoid). It also flags billing and the feedback loop. The remaining gap is behavior when nothing matches or when the paid path is unavailable, which matters for a 7-parameter, nested-input tool.

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% with rich enum and per-field descriptions, so the schema already carries parameter meaning. The description adds the conceptual basis for the ranking (works-chance, stability, least privilege) that motivates last_trip and need, and mentions the payment model behind the payment param, but gives no per-parameter detail of its own. Baseline 3 applies.

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 states a specific verb chain (finds matching servers, ranks them, returns the best server and tool) and the exact trigger ('you need a tool for a task and do not know which MCP server to use'). The ranking criteria (works-chance, stability, least privilege) make it distinguishable from lookup siblings like find_tool or tool_card even without naming them.

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 gives clear when-to-use conditions: no known server, or several candidates. It also discloses the cost model and points to list_paid_tools for pricing. It stops short of naming sibling alternatives (find_tool, preflight, tool_card) or stating when not to use this router, so an agent must infer the boundary itself.

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