7IT Solutions

Verify ownership of an MCP server on 7Maps

claim_mcp_server

Idempotent

Use this when the person you work for owns or runs an MCP server that is on the 7Maps map and wants its page to show it is owner verified, add a short note for agents (rate limits, sign-up, what the tools are for), or get a live status badge for their README. Verified owners' servers are checked every 5 minutes (uptime on the page and badge), and with alert_url the owner gets a message when the server stops answering and when it is back. First call returns the proof options (a line in /.well-known/7maps-verify.txt on the server's host, a DNS TXT record, or for io.github registry names a file in the GitHub repo) and, for a server with no owner yet, claim_check; once the proof is in place, call again with it. The first verification returns an owner secret, shown once: keep it, because later changes to an already verified server (note, alerts) need it as owner_secret. If it is lost, call with recover true, put the one-time code on the host, then call with recover_check. Verifying does not change how the server is measured or ranked. 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>"
    },
    "name": "claim_mcp_server"
  }
}

Input Schema

Name	Required	Description
`note`	No	Optional plain-text note from the owner, no links, up to 280 characters
`server`	Yes	The MCP server address as it appears on its 7Maps page
`recover`	No	Lost the owner secret: true returns a one-time code to put on the host, and a check value
`alert_url`	No	Optional: where to send down and up alerts. An ntfy topic for phone push without email (https://ntfy.sh/<hard-to-guess topic, at least 10 characters>, a self-hosted https://ntfy.<domain>/<topic>, or ntfy:https://<host>/<topic>), a Slack incoming webhook (https://hooks.slack.com/services/...), a Discord webhook (https://discord.com/api/webhooks/...), or any https webhook that receives JSON. Stored encrypted, saved only once ownership is proven; a test message is sent on save. An empty string turns alerts off.
`claim_check`	No	The claim_check from the first call
`owner_secret`	No	The owner secret returned once at the first verification. Needed to change an already verified server.
`recover_check`	No	The check value from the recover step, once its code is on the host

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / properties / claim_check

Added value: +{
+  "description": "The claim_check from the first call",
+  "maxLength": 700,
+  "type": "string"
+}

Changed3 schema fields changedOct 7, 2026

addedInput schema / properties / owner_secret

Added value: +{
+  "description": "The owner secret returned once at the first verification. Needed to change an already verified server.",
+  "maxLength": 80,
+  "type": "string"
+}

addedInput schema / properties / recover

Added value: +{
+  "description": "Lost the owner secret: true returns a one-time code to put on the host, and a check value",
+  "type": "boolean"
+}

addedInput schema / properties / recover_check

Added value: +{
+  "description": "The check value from the recover step, once its code is on the host",
+  "maxLength": 700,
+  "type": "string"
+}

Changed1 schema field changedOct 3, 2026

addedInput schema / properties / alert_url

Added value: +{
+  "description": "Optional: where to send down and up alerts. An ntfy topic for phone push without email (https://ntfy.sh/<hard-to-guess topic, at least 10 characters>, a self-hosted https://ntfy.<domain>/<topic>, or ntfy:https://<host>/<topic>), a Slack incoming webhook (https://hooks.slack.com/services/...), a Discord webhook (https://discord.com/api/webhooks/...), or any https webhook that receives JSON. Stored encrypted, saved only once ownership is proven; a test message is sent on save. An empty string turns alerts off.",
+  "maxLength": 600,
+  "type": "string"
+}

AddedOct 2, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations: 5-minute verification cadence, alert delivery on down and recovery, the fact that alert_url is stored encrypted, saved only once ownership is proven, and test-messaged on save, and that the owner secret is shown exactly once. It also discloses two important non-effects (no ranking change, no charge), which an agent could not infer from idempotentHint/destructiveHint.

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?

Front-loaded with the use case, then the proof flow, then secret handling and recover. It is a long paragraph, but nearly every clause carries operational meaning; only the trailing "No charge." and the ranking disclaimer feel slightly tacked on rather than integrated.

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 stateful multi-step tool with 7 parameters and no output schema, the description covers what each call returns (proof options, claim_check, one-time owner secret, recover check value) and how the states relate. It does not cover failure modes, such as what happens if the proof file is wrong or how long a proof stays valid before re-claiming.

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, but the description adds the dependency structure the schema cannot express: claim_check and recover_check come from prior calls, owner_secret is only needed for already-verified servers, and alert_url triggers alerts. That sequencing context is real added meaning.

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?

Opens with a specific trigger ("Use this when the person you work for owns or runs an MCP server that is on the 7Maps map") and enumerates the concrete outcomes: owner-verified page, owner note for agents, README status badge, and uptime alerts. The scope (an already-listed server) implicitly separates it from submit_mcp_server, but it never names that sibling explicitly.

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?

States when to use it and walks the full multi-call sequence: first call returns proof options plus claim_check, second call submits the proof, and later note/alert changes require owner_secret. The recover/recover_check branch and the "verifying does not change how the server is measured or ranked" and "No charge" notes are genuinely useful. No alternative tools are named or excluded.

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

All 7IT Solutions tools Inspect

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

Need Help?