Skip to main content
Glama
Sign In

7IT Solutions

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 with its own check, live incident alerts that every agent sees. You can also pass the same fields as last_trip on your next call of any 7Maps tool. No charge.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "server": "<server>",
      "ok": "<ok>"
    },
    "name": "report_road"
  }
}

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. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (write, non-destructive), the description discloses that input is limited to fixed fields with no open text, that many agents' reports aggregate into a server rating, that 7Maps verifies reports before they become 'live incident alerts that every agent sees', and that submission is free. These are exactly the side-effect, privacy, and cost facts an agent needs before writing a report.

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?

The purpose is front-loaded in the opening clause with an enumerated list of what to report, followed by compact sentences on aggregation, verification, the last_trip alternative, and cost. The long first sentence is dense but each subsequent sentence contributes distinct information; nothing is filler.

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 and no output schema, the description covers purpose, timing, data handling, downstream effects, and cost. Minor gaps remain, such as whether reporting is expected on every call or only on failures, and what confirmation the caller receives.

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 description coverage is 100% and enums are already documented, so the schema carries the parameter burden. The description restates the field set at a high level ('whether it worked, why not, how long it took, whether the result matched the description') and clarifies 'fixed fields only, no open text', but adds no format or selection guidance beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb and subject ('report how it went' after calling a tool on an MCP server) and enumerates the specific dimensions captured (worked, why not, duration, matched description, surprises), which is far more specific than the opaque tool name 'report_road'. It does not explicitly distinguish itself from nearby siblings like report_problem or my_server_report, so an agent must infer the boundary.

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?

Timing is stated plainly: use this after calling a tool on an MCP server, 'especially one 7Maps pointed you to', and it notes the alternative channel of passing the same fields as last_trip on a later 7Maps call. There are no explicit when-not conditions or comparisons against report_problem, so the routing guidance is clear but not complete.

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

All 7IT Solutions toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources