Koskamo

Register an MCP server

koskamo_register_mcp_server

Destructive

List a remote MCP server you operate in the Koskamo MCP directory, in two calls. A call without token validates the server fields and returns a claim token plus where it can be published (/.well-known/koskamo-claim on the endpoint host, or TXT _koskamo-claim.). A call with id and token looks for that proof and runs a live check; when both pass, the listing is published and an owner key is returned once. Nothing is listed without both. Method "email" with proofEmail at admin, administrator, webmaster, hostmaster, postmaster on the endpoint's domain is the alternative to DNS or web proof: a single-use confirm link is mailed there, its token is not returned, and verification succeeds after a person presses Confirm. An optional contact email is used for notices about auto-hide, a lapsed proof, or key recovery; it receives one confirmation message and nothing else until confirmed, and it does not grant ownership.

Input Schema

Name	Required	Description
`id`	Yes	Lowercase kebab-case page id, e.g. acme-docs
`auth`	No	Required on the first call
`name`	No	Product name; required on the first call
`email`	No	Optional contact address for listing notices
`token`	No	The claim token from the first call; verifies the proof and publishes the listing
`tools`	No	Optional; replaced by the live tool list when the check passes
`method`	No	First call: "email" (with proofEmail) mails a confirm link instead of a token to publish. Verify call: limits the check to this proof method; an email proof requires "email"
`docsUrl`	No	Your documentation page for this server; required on the first call
`category`	No	Required on the first call
`endpoint`	No	Streamable HTTP endpoint (https); required on the first call
`operator`	No	Company that runs the server; required on the first call
`useCases`	No	1-6 use cases from your documentation; required on the first call
`companyUrl`	No	Optional https company website; an empty string clears it on edits
`proofEmail`	No	First call with method "email": admin\|administrator\|webmaster\|hostmaster\|postmaster@<endpoint host or a parent domain>, no plus-tags. A person must open the mailed link and press Confirm before verify succeeds
`description`	No	20-600 characters, factual; required on the first call
`requirements`	No	Optional; up to 4 prerequisites a user must already have (e.g. a vendor account or paid subscription), beyond endpoint sign-in

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 31, 2026

changedInput schema / properties / email / description

Previous value: -"Optional, recommended contact address for listing notices"New value: +"Optional contact address for listing notices"

changedInput schema / properties / method / description

Previous value: -"First call: \"email\" (with proofEmail) mails a confirm link instead of a token to publish. Verify call: check only this proof method; an email proof needs \"email\""New value: +"First call: \"email\" (with proofEmail) mails a confirm link instead of a token to publish. Verify call: limits the check to this proof method; an email proof requires \"email\""

changedInput schema / properties / token / description

Previous value: -"The claim token from the first call; send it to verify and publish"New value: +"The claim token from the first call; verifies the proof and publishes the listing"

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / category / enum

Previous value: -[
-  "docs-reference",
-  "developer-tools",
-  "cloud-infrastructure",
-  "data-analytics",
-  "ai-ml",
-  "commerce",
-  "payments",
-  "productivity",
-  "project-management",
-  "crm-marketing",
-  "design"
-]New value: +[
+  "docs-reference",
+  "developer-tools",
+  "cloud-infrastructure",
+  "data-analytics",
+  "ai-ml",
+  "commerce",
+  "payments",
+  "productivity",
+  "project-management",
+  "crm-marketing",
+  "erp-supply-chain",
+  "design"
+]

Changed1 schema field changedOct 4, 2026

addedInput schema / properties / requirements

Added value: +{
+  "description": "Optional; up to 4 prerequisites a user must already have (e.g. a vendor account or paid subscription), beyond endpoint sign-in",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed5 schema fields changedOct 4, 2026

changedInput schema / properties / category / enum

Previous value: -[
-  "docs-reference",
-  "developer-tools",
-  "cloud-infrastructure",
-  "data-analytics",
-  "ai-ml",
-  "payments-commerce",
-  "productivity",
-  "project-management",
-  "crm-marketing",
-  "design"
-]New value: +[
+  "docs-reference",
+  "developer-tools",
+  "cloud-infrastructure",
+  "data-analytics",
+  "ai-ml",
+  "commerce",
+  "payments",
+  "productivity",
+  "project-management",
+  "crm-marketing",
+  "design"
+]

addedInput schema / properties / companyUrl

Added value: +{
+  "description": "Optional https company website; an empty string clears it on edits",
+  "maxLength": 500,
+  "type": "string"
+}

changedInput schema / properties / method / description

Previous value: -"Optional on the verify call: check only this proof method"New value: +"First call: \"email\" (with proofEmail) mails a confirm link instead of a token to publish. Verify call: check only this proof method; an email proof needs \"email\""

changedInput schema / properties / method / enum

Previous value: -[
-  "http",
-  "dns"
-]New value: +[
+  "http",
+  "dns",
+  "email"
+]

addedInput schema / properties / proofEmail

Added value: +{
+  "description": "First call with method \"email\": admin|administrator|webmaster|hostmaster|postmaster@<endpoint host or a parent domain>, no plus-tags. A person must open the mailed link and press Confirm before verify succeeds",
+  "maxLength": 254,
+  "type": "string"
+}

AddedOct 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, and openWorld=true; the description adds genuinely new behavioral context — a live check gates publication, the owner key is returned exactly once, the email confirm link is single-use, and the contact email receives one confirmation message and grants no ownership. It does not disclose what a re-call with an existing id does (overwrite/edit vs. error), which matters given destructiveHint=true.

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 core action and the two-call flow, then the proof-method alternatives, then the optional contact email. Sentences are long and dense but nearly all carry decision-relevant information; some content duplicates schema descriptions (proofEmail rules, confirm-link behavior).

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?

For a 16-parameter, two-call, destructive publishing tool with an output schema and full schema coverage, the description supplies what structured fields cannot: the ordering of the two calls, the gate condition for publication, the one-time owner key, and the email fallback with its human-in-the-loop step. Return values need not be restated because an output schema exists, so nothing an agent needs in order to call it correctly is missing.

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 the schema already documents token provenance, proofEmail domain restrictions, and method semantics in comparable detail. The description reinforces the first-call/verify-call split and the token's role but adds little that the schema does not already state. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb and resource — list/publish a remote MCP server in the Koskamo MCP directory — and immediately frames the two-call protocol (validate-then-verify). It is clearly distinguishable from read-oriented siblings like koskamo_find_mcp_server and koskamo_retrieve, though no sibling is named explicitly. The word 'List' for a publishing action is slightly at odds with the tool name 'register', but the phrase 'the listing is published' resolves it.

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 explicit procedural guidance: a call without token validates fields, a call with id+token verifies proof and runs a live check, and 'Nothing is listed without both.' It also lays out the proof-method alternatives (HTTP well-known, DNS TXT, or email) and when email applies. It stops short of routing the agent to or away from specific sibling tools.

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

All Koskamo tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?