Koskamo

Server Details

Cited, versioned knowledge for agents: retrieve sourced passages and propose owner-approved fixes.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 99.3% over 21 days
Last Tested: 2026-10-11 21:07
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.8/5.0

Scored 2026-10-04 19:40 across 8 tools

Disambiguation4/5

Within the dataset domain, the revision tools (propose_revision, decide_revision, list_revisions) are clearly distinguished by their action, and retrieve/get_history/list_datasets each target distinct resources. The two MCP-directory tools (find_mcp_server, register_mcp_server) are also separable, though the coexistence of two unrelated domains in one server adds mild cognitive load.

Naming Consistency4/5

Nearly all tools follow a consistent koskamo_ + verb_noun pattern (decide_revision, list_datasets, propose_revision, register_mcp_server). The lone exception is koskamo_retrieve, a bare verb without a noun object, a minor deviation from the otherwise predictable convention.

Tool Count5/5

Eight tools is well within the ideal 3-15 range, and each tool earns its place covering either the dataset/revision workflow or the MCP directory. No redundant or filler tools are present.

Completeness4/5

The revision lifecycle is fully covered (propose, list, decide) alongside retrieval and history, and the directory has find/register. Minor gaps exist such as no dataset creation/metadata or directory delist/update operations, but the core agent workflows are intact.

Available Tools

8 tools

koskamo_decide_revisionApprove or reject a revisionA

Destructive

Inspect

Approve or reject a pending revision. Requires the dataset owner's API key or KNOWLEDGE_ADMIN_KEY. Approved text is chunked and becomes retrievable.

ParametersJSON Schema

Name	Required	Description
`note`	No	Optional review note
`decision`	Yes
`revision_id`	Yes	Revision id returned by koskamo_propose_revision or koskamo_list_revisions

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered; the description usefully adds the auth requirement and the downstream effect that approved text is chunked and becomes retrievable. It still omits what rejection does and whether the decision is reversible, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action, then the auth constraint, then the consequence. No padding or restatement of the title.

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?

With an output schema present, return values need not be explained, and the key gaps an agent needs -- permission requirement and side effect of approval -- are covered. The consequences of rejection remain unstated, which is a minor but real gap for a destructive operation.

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 67% and the decision enum plus revision_id provenance are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, so the 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?

States a specific verb pair (approve/reject) and resource (pending revision), which cleanly distinguishes it from siblings like koskamo_propose_revision and koskamo_list_revisions. An agent can identify the operation without opening the schema.

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 a clear prerequisite (dataset owner's API key or KNOWLEDGE_ADMIN_KEY) and scopes the action to a pending revision, implying it is used after propose/list. It does not explicitly route the agent to or away from a specific sibling, so it falls short of a 5.

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

koskamo_find_mcp_serverFind an MCP serverA

Read-onlyIdempotent

Inspect

Find official, vendor-run remote MCP servers in the Koskamo MCP directory. Every listed endpoint passed a recent live check; returns the endpoint URL, sign-in type, documentation link, and known tools.

ParametersJSON Schema

Name	Required	Description
`auth`	No	Optional sign-in filter; none means usable without an account; oauth-optional means public tools work anonymously and account tools prompt OAuth sign-in
`query`	No	Words to match against name, operator, description, use cases, and tool names
`category`	No	Optional category filter

Output Schema

ParametersJSON Schema

Name	Required	Description
`servers`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds real value beyond that: it discloses that every endpoint passed a recent live check (freshness/validation guarantee) and enumerates what is returned (endpoint URL, sign-in type, docs link, known tools).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with no waste. Scope and freshness guarantee are front-loaded, and return contents follow immediately.

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?

An output schema exists, so return values need not be re-explained, and annotations cover the safety profile. The description supplies scope, freshness, and result contents, leaving little an agent would need beyond the schema.

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% with two enum filters fully documented, so the schema carries parameter meaning. The description adds nothing about the query/auth/category parameters, so the baseline 3 is appropriate.

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?

States a specific verb (find) plus resource (remote MCP servers) and constrains scope tightly: official, vendor-run, remote, and within the Koskamo directory. This clearly separates it from sibling koskamo_register_mcp_server (which adds servers rather than locating them).

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

Usage Guidelines3/5

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

The scope hints at when it applies (discovering existing vendor-run servers), but there is no explicit when-to-use/when-not-to-use statement and no alternatives named. Usage is implied rather than spelled out.

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

koskamo_get_historyGet document historyA

Read-onlyIdempotent

Inspect

Get the document version timeline for a public dataset: every document (including deleted ones) with the version history produced by approved revisions.

ParametersJSON Schema

Name	Required	Description	Default
`dataset`	Yes	Dataset id or slug

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuinely new behavioral context: deleted documents are still returned, and only approved revisions contribute to the history — a meaningful disclosure about result contents not present in the annotations.

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?

A single dense sentence with the resource named first and the two scope qualifiers trailing. No wasted words, though the parenthetical and trailing clause make it slightly back-loaded.

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?

An output schema exists, so return-value shape need not be described. The description covers scope and content accurately for a read-only history tool. It does not mention pagination or result-size expectations, which could matter for a timeline covering every document including deleted ones.

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 coverage is 100% and there is only one parameter, so the schema already documents 'dataset'. The description adds only the 'public' qualifier on which datasets qualify, which is marginal value beyond the schema. Baseline 3 is appropriate.

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 (document version timeline) and adds scope qualifiers — public datasets, deleted documents included, approved revisions only. It distinguishes itself implicitly from koskamo_list_revisions by restricting to approved-revision-produced history, but 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 Guidelines3/5

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

The 'public dataset' constraint implies when it applies, but there is no explicit when-to-use guidance, no statement of when to prefer koskamo_list_revisions or koskamo_retrieve instead, and no prerequisites or exclusions.

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

koskamo_list_datasetsList public datasetsA

Read-onlyIdempotent

Inspect

List public Koskamo datasets an agent may retrieve from.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`datasets`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that only public (not private) datasets are returned, which is genuine scoping context, but says nothing about result size or pagination for an open-world listing.

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?

A single compact sentence that is front-loaded with the key verb and resource. The trailing 'an agent may retrieve from' clause is slightly awkward but carries the only usage signal present.

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?

With an output schema present, the description need not document return values, and with zero parameters there is nothing further to specify. It is nearly complete for a simple listing tool, missing only explicit linkage to the retrieval sibling.

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?

The tool takes zero parameters, so the baseline of 4 applies. Nothing in the description is needed to explain parameter usage.

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 clear verb (List) and resource (public Koskamo datasets), so the operation is unambiguous. It does not differentiate itself from siblings like koskamo_list_revisions, though none of the siblings overlaps directly with listing datasets.

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

Usage Guidelines3/5

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

The phrase 'an agent may retrieve from' implies this is a discovery step preceding koskamo_retrieve, but that relationship is only hinted at rather than stated. There is no explicit when-to-use or when-not-to-use guidance.

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

koskamo_list_revisionsList pending revisionsB

Read-onlyIdempotent

Inspect

List pending revisions for a dataset.

ParametersJSON Schema

Name	Required	Description	Default
`dataset`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds only the 'pending' filtering scope, and says nothing about ordering, pagination, or volume of results.

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?

A single front-loaded sentence with zero filler. It is efficient, though so terse that the scope qualifier is the only information delivered.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations cover the safety profile and an output schema exists, so return values need not be described. The remaining gap is usage context and the undocumented parameter, leaving the definition merely adequate.

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 0% for the single required 'dataset' parameter. The description implies the revisions belong to a dataset, which conveys the parameter's role, but adds no identifier format or accepted values.

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?

Specific verb (List) plus a scoped resource (pending revisions) and the object it pertains to (a dataset). The 'pending' qualifier clearly separates it from koskamo_get_history, though no sibling is named explicitly.

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

Usage Guidelines2/5

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

No statement of when to call this versus koskamo_get_history or the decide/propose revision tools. The workflow role (reviewing queued revisions) must be inferred from the word 'pending'.

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

koskamo_propose_revisionPropose a revisionAInspect

Propose a better fact for a dataset, propose reverting a document to an earlier version, or propose deleting a document. The change stays pending until a dataset owner approves it.

ParametersJSON Schema

Name	Required	Description
`text`	No	The improved document text; required unless action is delete_document
`title`	No	Required unless action is delete_document
`action`	No	Defaults to add_document. delete_document needs only dataset and document_id.
`dataset`	Yes	Dataset id or slug
`rationale`	No
`source_url`	No
`document_id`	No	Set to replace or delete an existing document
`restore_version`	No	With replace_document and document_id, propose reverting the document to this stored version; title/text are taken from the version history.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower. The description adds genuinely useful behavioral context beyond them: the change is queued and pending until a dataset owner approves it, which tells the agent the call is not immediately effective and may require follow-up.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the three operations and closed with the one non-obvious behavioral fact (pending approval). No 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?

With an output schema present, return values need not be described, and the description adequately covers the three modes and the approval gate for an 8-parameter tool. It could have noted the delete/replace-only requirements more explicitly, but the schema carries that.

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 coverage is 75%, with text, title, action, dataset, document_id, and restore_version all documented in the schema itself. The description restates the three action modes but adds no format, default, or constraint detail beyond what the schema already provides, so baseline 3 is appropriate.

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?

States a specific verb (propose) plus the three distinct resources/operations it covers: a better fact, reverting a document, and deleting a document. This maps cleanly onto the action enum and lets an agent distinguish it from siblings like koskamo_decide_revision (which approves) and koskamo_list_revisions (which reads).

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?

The description clearly establishes the context of use (submitting a proposed change) and the workflow constraint that it stays pending owner approval. It does not explicitly name alternatives or when-not-to-use, but the propose-vs-decide split with sibling tools is strongly implied.

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

koskamo_register_mcp_serverRegister an MCP serverAInspect

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

ParametersJSON 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

ParametersJSON Schema

Name	Required	Description
No output parameters

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.

koskamo_retrieveRetrieve cited passages

Read-onlyIdempotent

Inspect

Retrieve candidate passages from Koskamo datasets. Check that the text answers the question before citing it. If none supports the question, report no supporting evidence. Scores are not confidence probabilities.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	The question or search string
`top_k`	No
`dataset`	No	Optional dataset id or slug. Defaults to all public datasets.

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes
`guidance`	Yes	Evidence checking and abstention instructions for the consuming agent
`passages`	Yes
`assessment`	Yes	Candidate availability only; does not assess whether the question is answered

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 8, 2026

Changedkoskamo_retrieve4 fields changed

addedOutput schema / properties / assessment

Added value: +{
+  "description": "Candidate availability only; does not assess whether the question is answered",
+  "enum": [
+    "candidates",
+    "no_matches"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / guidance

Added value: +{
+  "description": "Evidence checking and abstention instructions for the consuming agent",
+  "type": "string"
+}

changedOutput schema / properties / passages / items / properties / datasetVersion / description

Previous value: -"Dataset version at retrieval time; cite this"New value: +"Collection version at retrieval time; use documentVersion for an exact document citation"

changedOutput schema / required

Previous value: -[
-  "query",
-  "passages"
-]New value: +[
+  "query",
+  "passages",
+  "assessment",
+  "guidance"
+]

2 tool updatesOct 4, 2026

Changedkoskamo_find_mcp_server1 field changed

addedOutput schema / properties / servers / items / properties / requirements

Added value: +{
+  "description": "Accounts, subscriptions, or keys needed before the server is useful",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changedkoskamo_register_mcp_server1 field changed

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"
+}

3 tool updatesOct 4, 2026

Changedkoskamo_find_mcp_server3 fields changed

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"
+]

changedOutput schema / properties / servers / items / 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"
+]

addedOutput schema / properties / servers / items / properties / companyUrl

Added value: +{
+  "description": "Company website",
+  "format": "uri",
+  "type": "string"
+}

Changedkoskamo_list_datasets1 field changed

addedOutput schema / properties / datasets / items / properties / managedBy

Added value: +{
+  "description": "Documents mirror another Koskamo system of record and change only there; API revisions are refused",
+  "enum": [
+    "mcp-directory"
+  ],
+  "type": "string"
+}

Changedkoskamo_register_mcp_server5 fields changed

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"
+}

1 tool updateOct 4, 2026
- Addedkoskamo_register_mcp_server

1 tool updateOct 4, 2026

Changedkoskamo_find_mcp_server3 fields changed

changedInput schema / properties / auth / description

Previous value: -"Optional sign-in filter; none means usable without an account"New value: +"Optional sign-in filter; none means usable without an account; oauth-optional means public tools work anonymously and account tools prompt OAuth sign-in"

changedInput schema / properties / auth / enum

Previous value: -[
-  "none",
-  "oauth",
-  "api-key"
-]New value: +[
+  "none",
+  "oauth-optional",
+  "oauth",
+  "api-key"
+]

changedOutput schema / properties / servers / items / properties / auth / enum

Previous value: -[
-  "none",
-  "oauth",
-  "api-key"
-]New value: +[
+  "none",
+  "oauth-optional",
+  "oauth",
+  "api-key"
+]

1 tool updateOct 3, 2026
- Addedkoskamo_find_mcp_server
6 tool updatesSep 21, 2026
- First observedkoskamo_decide_revision
- First observedkoskamo_get_history
- First observedkoskamo_list_datasets
- First observedkoskamo_list_revisions
- First observedkoskamo_propose_revision
- First observedkoskamo_retrieve

Related MCP Connectors

Citation Verification A
io.github.guptaprakhariitr
Real-time fact-check, citation verification, and source-freshness for AI agents.
Search RAG Systems
321
mcp-server A
com.quelvio
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Knowledge & Memory Search RAG Systems
32
ColdState — Deterministic Knowledge Infrastructure A
ai.coldstate
Deterministic knowledge for AI agents: search, fetch, cite and verify a 48M-entry knowledge base.
Search RAG Systems Knowledge & Memory
161
Project Noosphere A
org.projectnoosphere
An open knowledge commons for AI agents: search versioned how-tos, report whether they worked.
Search Documentation Access Knowledge & Memory
61

Related MCP Servers

io.github.vouchdev/vouchofficial
Knowledge & Memory RAG Systems Developer Tools
vouchdev
A
license
Not graded
quality
A
maintenance
Review-gated knowledge base for LLM agents that ensures durable memory via human-approved writes, compiling a wiki with verified citations.
Updated 2 months ago (2026-08-23 03:53 UTC)
1 npm
72
MIT
CiteAnything MCP Server
RAG Systems Search
veriglow
A
license
Not graded
quality
A
maintenance
Enables AI agents to create verifiable, replayable citations, search private knowledge bases, and publish Markdown with verified citation markers.
Updated a month ago (2026-09-03 06:46 UTC)
MIT
paid-mcp-gate
Search Payments & Billing RAG Systems
danielhurnik
A
license
Not graded
quality
C
maintenance
Enables AI agents to search a proprietary knowledge base for free and buy access to documents or passages on demand, with automatic payment, licensing, and citation.
Updated 16 days ago (2026-09-26 00:24 UTC)
MIT
eigma-mcpofficial
Note Taking Knowledge & Memory
eigma-app
A
license
Not graded
quality
B
maintenance
Enables AI assistants to turn conversations into a searchable personal wiki, read and organize pages, and propose edits such as merges, translations, and fact-checks as reviewable changesets.
Updated a month ago (2026-09-11 22:40 UTC)
2
MIT