Skip to main content
Glama

7IT Solutions

by io.github.XLSV777
OverviewDiscussionsAdmin

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); after one is in place, call again to confirm. 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNoOptional plain-text note from the owner, no links, up to 280 characters
serverYesThe MCP server address as it appears on its 7Maps page
recoverNoLost the owner secret: true returns a one-time code to put on the host, and a check value
alert_urlNoOptional: 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.
owner_secretNoThe owner secret returned once at the first verification. Needed to change an already verified server.
recover_checkNoThe check value from the recover step, once its code is on the host

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
+}
  2. Changed1 schema field changed
    • 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"
+}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses the 5-minute re-check cadence, alert delivery on down/up via alert_url, that the owner secret is shown only once and required for later edits, and the one-time-code recovery mechanics. This is rich behavioral context an agent cannot infer from readOnlyHint/idempotentHint alone.

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 a dense single paragraph but front-loads the trigger condition and every sentence carries needed information about the multi-step verification, recovery, and alerting. It could be more scannable with structure, but given the tool's complexity little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 compensates by explaining return values (proof options on first call, owner secret shown once) and the full call sequence. Nothing an agent needs to invoke this 6-parameter, multi-step tool correctly is missing.

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 description coverage is 100%, so the schema already documents each parameter and the baseline is 3. The description adds genuine value by explaining the sequencing and dependency between owner_secret, recover, and recover_check that the flat schema cannot convey.

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 and resource (verify/claim ownership of an MCP server on 7Maps) and frames the trigger as the owner wanting a verified page, agent note, or status badge. It is clearly distinguishable from siblings like submit_mcp_server, my_server_report, and verify_lock.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use conditions, the exact multi-step flow (first call returns proof options, call again to confirm), and the alternative recovery path (recover true, then recover_check). It even clarifies what the tool does NOT do (does not change measurement/ranking) and that there is no charge.

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