Skip to main content
Glama

7Maps

by io.github.XLSV777
OverviewDiscussionsAdmin

Report how a call to an MCP server went (7Maps)

report_road

Use this after calling a tool on an MCP server (especially one 7Maps pointed you to) to report how it went: whether it worked, why not, how long it took, whether the result matched the description, and anything it did that you did not ask for. Fixed fields only, no open text. Reports from many agents become the server's rating and, once 7Maps confirms them, live incident alerts that every agent sees. You can also pass the same fields as last_trip on any paid 7Maps call. No charge.

Input Schema

NameRequiredDescriptionDefault
msNoHow long the call took, in milliseconds
okYesWhether the call did what you needed
failNoIf it failed: unreachable, auth, args, server_error, timeout, rate_limited or wrong_result
toolNoThe tool you called
serverYesThe MCP server you called (URL or registry name)
surpriseNoAnything the tool did that you did not ask for
task_typeNoOptional: the kind of work you are doing right now. Only this category is kept, never your task text
tools_hashNoThe tool_list_hash of the tool list you received, if you computed it as 7Maps does
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
charged_usdNoWhat the server charged, if anything
result_tokensNoAbout how many tokens the result was
matched_descriptionNoWhether the result matched what the tool description promised

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. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag this as a non-read-only, non-destructive write; the description adds genuinely new context: no charge, fixed fields only with no open text, anonymity of agent_model, and that reports aggregate into server ratings and confirmed incident alerts visible to all agents. The downstream propagation and cost profile are the kind of traits annotations cannot express. It omits what happens to a malformed or duplicate report (idempotentHint is false).

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?

Three front-loaded sentences that each carry information: usage trigger, reporting contract and privacy, then downstream effect and the alternative channel. The middle clause runs long and packs several ideas together, but nothing is padding.

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 12-parameter write tool with full schema coverage, no output schema and informative annotations, the description covers purpose, cost, anonymity, and downstream consequence. The remaining gap is error behavior — what happens if required fields are missing or the same report is sent twice (idempotentHint is false).

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 100%, so the baseline is 3; the description earns a bump by framing the fields as questions the agent should answer (did it work, why not, how long, did the result match the description, did it do something unasked) and by flagging that only the task category is retained, never task text. It still adds no syntax or format guidance 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?

States a specific verb and resource — report how a call to an MCP server went — and enumerates exactly what is reported (success, failure reason, latency, description match, surprises). This is clearly distinguishable from siblings like tool_card, preflight, or road_conditions, which supply ratings rather than accept 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?

Gives an explicit trigger ('after calling a tool on an MCP server, especially one 7Maps pointed you to') and names an alternative channel ('you can also pass the same fields as last_trip on any paid 7Maps call'). It does not state when reporting is unnecessary or discouraged, so it falls short of a full 5.

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