Koskamo

Report an MCP server bug

koskamo_report_mcp_issue

Destructive

Report a bug in a published MCP server listed on Koskamo: a tool that errors, returns wrong results, mismatches its schema, rejects valid auth, is unavailable, or has wrong docs. Reports on the same tool and category merge into one issue that the listing owner sees and answers. No key is required. Text that looks like a credential or token is refused, and security vulnerabilities are out of scope. Returns a secret receipt_handle for status checks and reopening.

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_id": "<server_id>",
      "category": "<category>",
      "summary": "<summary>"
    },
    "name": "koskamo_report_mcp_issue"
  }
}

Input Schema

Name	Required	Description
`error`	No	The error message or status returned
`detail`	No	How to reproduce: the arguments you sent, with any secrets removed
`summary`	Yes	One line describing what went wrong
`category`	Yes	tool_error, wrong_result, schema_mismatch, auth, unavailable or docs
`expected`	No	What you expected instead
`server_id`	Yes	Directory listing id of the server
`tool_name`	No	Exact name of the failing tool; omit for server-wide problems
`idempotency_key`	No	Optional random key retained for safe retries; a retry returns the same receipt

Output Schema

Name	Required	Description	Default
`note`	No
`issue`	Yes
`listing_url`	No
`receipt_handle`	Yes
`receipt_expires_at`	Yes
`merged_with_existing`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare write, open-world and destructive characteristics, and the description adds real value on top: deduplication ('reports on the same tool and category merge into one issue'), owner visibility, credential-like text being refused, and the secrecy requirement for the returned receipt_handle. Minor tension: the schema's idempotency_key retry promise sits awkwardly beside idempotentHint=false, and the description does not clarify whether plain retries create duplicates.

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?

Purpose and scope are front-loaded in the first clause, and nearly every sentence carries new information (merge behavior, auth, filtering, receipt). It is a dense single block with some comma-list enumeration, but no filler to remove.

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 and full parameter documentation, the description only needs to cover process and constraints, which it does: auth, dedupe, rejection of secrets, scope exclusion, and receipt handling. The one loose end is retry semantics relative to idempotentHint=false.

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%, so the schema already explains every parameter, including the category enum and idempotency_key. The description does add the merge rule showing that tool_name plus category form the dedupe key, which is meaning beyond the schema, but it says nothing about server_id sourcing or the summary/detail split.

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 and resource ('Report a bug in a published MCP server listed on Koskamo') and then enumerates the concrete failure classes it covers (tool errors, wrong results, schema mismatch, auth, unavailability, docs). This distinguishes it cleanly from sibling status/handling tools such as koskamo_get_mcp_issue_status, koskamo_handle_mcp_issues and koskamo_reopen_mcp_issue.

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?

Explicitly carves out exclusions ('security vulnerabilities are out of scope') and states the auth posture ('No key is required'), and the receipt_handle sentence implies follow-up goes to the status/reopen tools rather than this one. It does not name those siblings outright, so routing 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.

All Koskamo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?