Koskamo

Register an MCP server

koskamo_register_mcp_server

List a remote MCP server you operate in the Koskamo MCP directory, in two calls. Call without token: the server fields are validated and you get a claim token plus where to publish it (https:///.well-known/koskamo-claim, or TXT _koskamo-claim.). Publish it, then call again with id and token: once the proof is found and the live check passes, the listing is published and an owner key is returned once. Nothing is listed without both. Without DNS or web access, send method "email" and proofEmail at admin, administrator, webmaster, hostmaster, postmaster on the endpoint's domain: a single-use confirm link is mailed there (the link's token is never returned) and verify succeeds once a person presses Confirm. An email is optional but recommended so we can reach you about auto-hide, a lapsed proof, or key recovery; it gets one confirmation message and nothing else until confirmed, and it never grants ownership. Step-by-step guide with exact proof formats and every refusal: https://koskamo.com/explore/register

Input Schema

TableJSON 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, recommended contact address for listing notices
`token`	No	The claim token from the first call; send it to verify and publish
`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: check only this proof method; an email proof needs "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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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.4/5.0

Behavior5/5

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

Goes far beyond annotations: discloses the two-call proof workflow, that nothing is listed without both proof and live check, that the owner key is returned once, that the email link's token is never returned and requires human confirmation, and that email never grants ownership. This is rich behavioral context.

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 description is dense but front-loaded with the core two-call flow, then the email fallback and contact-email caveat. It's appropriately sized for a complex 16-parameter tool, though the email paragraph is lengthy.

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?

Given the complexity (16 params, required-first-call fields, two-phase verification), the description covers the workflow, proof methods, failure/fallback path, and links to the authoritative guide. With a rich schema and output schema, this is complete enough for correct invocation.

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%, so the schema already documents all 16 parameters thoroughly (each with descriptions, enums, max lengths). The description reinforces the id/token/proofEmail/method flow but doesn't add much beyond the schema's existing per-parameter documentation. Baseline 3 applies.

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 ('List a remote MCP server you operate in the Koskamo MCP directory') and distinguishes itself from siblings (find/retrieve/list tools) by being the registration/listing operation. The two-call protocol is described in detail.

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?

It explicitly describes when to use each path: call without token to validate/get claim token, call with id and token to verify/publish, and use method 'email' when DNS or web access is unavailable. It doesn't name alternative tools, but the when-to-use conditions are clear.

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?