protogrid

Search / com.qumge/skills

Qumge: Agent Capabilities & Skills

R0· no sign-in

Find, call and pay per call: the capability layer for agents, plus skills. One key or OAuth.

v1.2.0 · active · descriptor JSON · versions

An agent can connect right now, no human step.Remote endpoint, no authentication, reachable on the last probe.
Quality60needs work
Trust79of 100
Uptime, 30 days96%
Latency p50340 ms

Connect

8 clients · secrets stay placeholders
{
  "mcpServers": {
    "skills": {
      "type": "http",
      "url": "https://qumge.com/mcp"
    }
  }
}
claude mcp add --transport http skills https://qumge.com/mcp
[mcp_servers.skills]
url = "https://qumge.com/mcp"
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "skills": {
      "type": "remote",
      "url": "https://qumge.com/mcp",
      "enabled": true
    }
  }
}
{
  "mcpServers": {
    "skills": {
      "type": "http",
      "url": "https://qumge.com/mcp"
    }
  },
  "deeplink": "cursor://anysphere.cursor-deeplink/mcp/install?name=skills&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vcXVtZ2UuY29tL21jcCJ9"
}
{
  "servers": {
    "skills": {
      "type": "http",
      "url": "https://qumge.com/mcp"
    }
  }
}
{
  "mcpServers": {
    "skills": {
      "httpUrl": "https://qumge.com/mcp"
    }
  }
}
extensions:
  "skills":
    enabled: true
    name: "skills"
    type: streamable_http
    uri: "https://qumge.com/mcp"
    timeout: 300

Quality 60 / 100needs work

protocol75 · weight 25
  • warn
    protocol.modernnewest supported version is 2025-06-18; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
  • n/a
    protocol.statelessonly applies to 2026-07-28 servers
  • pass
    protocol.transportstreamable HTTP
  • n/a
    protocol.list_ttlonly applies to 2026-07-28 servers
authorizationn/a · weight 15
  • n/a
    auth.prm, auth.as_metadata, auth.cimdno remote uses OAuth
  • n/a
    auth.secret_in_urlno templated URL
tool hygiene64 · weight 30
  • pass
    tools.descriptionsevery tool has a description
  • warn
    tools.description_length1 tools have descriptions over 1,024 characters, which crowds the context
  • pass
    tools.schemasevery tool has an object input schema
  • fail
    tools.annotationsno tool declares readOnlyHint or destructiveHint, so clients cannot tell safe calls from risky ones
  • fail
    tools.directory_hintsno tool declares all four of readOnlyHint, destructiveHint, idempotentHint and openWorldHint; missing: get_skill (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); list_categories (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); list_models (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); …
  • pass
    tools.token_costabout 7,705 tokens to load every tool
  • pass
    tools.api_dumptools are not a one-to-one API dump
stability25 · weight 15
  • warn
    stability.changes91 tool changes in 30 days
  • fail
    stability.rug_pull3 tools kept their name but changed most of their description in 30 days; review before trusting them
dependenciesn/a · weight 15
  • n/a
    deps.known_vulns, deps.mcp_sdk_version, deps.resolvableno npm or PyPI package

19 tools, about 7,705 tokens to load them all · tool set 6244cf32b2f6 · tools last changed 2026-10-11 · checked 2026-10-19 10:52 UTC

Tool changes

  • submit_capchangeddescription
    before

    Take one of the developer's Caps live. Nothing is reviewed before launch and nobody approves it: when the three code-checked items pass (signature, end-to-end, price book), this publishes the Cap immediately and agents can call it — and be charged — from then on. Run test_cap first (it records signature + end-to-end; the price book is recorded when it saves). Qumge spot-checks docs and support afterwards and can suspend the Cap. Needs the developer's Qumge key. (Older clients may still call this tool as submit_app_review.)

    after · 70% of words in common

    Take one of the developer's Caps live. Nothing is reviewed before launch and nobody approves it: when the applicable connection/operation checks and price book pass, with complete billed-operation docs, this publishes the Cap immediately and agents can call it — and be charged — from then on. Run test_cap first (legacy checklist keys remain signature and end_to_end; the price book is recorded when it saves). Passing native connection checks or isolated fixtures does not verify real delivery. Qumge spot-checks docs and support afterwards and can suspend the Cap. Needs the developer's Qumge key. (Older clients may still call this tool as submit_app_review.)

  • test_capchangeddescription, output schemameaning changed
    before

    Run a Cap's connection test and end-to-end self-test, and record both results on its publishing checklist. Do this after publish_cap, before submit_cap. The connection test sends three requests to base_url + /qumge/ping (correctly signed, wrong secret, and a 10-minute-old timestamp — only the first may succeed); the end-to-end test calls one free and one billable operation directly on the Cap (nothing is charged) and, for a route the Cap reports itself, waits 2 seconds for its usage report. An MCP Cap has each listed tool called once instead. It warns (without blocking) about billed operations that have no `doc`. Needs the developer's Qumge key. (Older clients may still call this tool as test_app.)

    after · 28% of words in common

    Run the applicable publication checks after publish_cap, before submit_cap. Managed qumge wrapper operations use authenticated isolated fixture hooks and validate the complete fixture result. Native managed API/MCP operations check HTTP OPTIONS or MCP tools/list for connection/schema evidence without invoking generation. The verification array distinguishes connection, fixture and real_delivery scopes; real delivery is not tested. Legacy integrations may call one free and one billable route, or each published MCP tool, directly with probe inputs; Qumge does not charge for these probes, but the developer may incur provider costs. Signed wrapper/legacy APIs also test /qumge/ping with valid, forged and stale signatures; legacy usage-reporting routes must report probe usage. Missing billed-operation docs block publishing. Needs the developer's Qumge key. (Older clients may still call this tool as test_app.)

  • publish_capchangeddescription, input schema, output schemameaning changed
    before

    Every billed operation must deliver one complete result for one clear input (e.g. product URL in → finished video out); helper steps such as job status are free, and a result that needs several calls is wrapped into one endpoint — never sell partial steps. Do not publish tools or endpoints that act on the caller's own account or data (their notes, settings, balance): every buyer's call is forwarded with the same developer token, so they would all act on one account — sell an account-free input → result operation instead, or use the signed integration and tell buyers apart by the Qumge-User header. Publish a Cap (short for capability) to Qumge on the developer's behalf (needs the developer's Qumge key in the Authorization header). Give it a name and either the API's HTTPS base_url or, for an existing remote MCP server, its mcp_url; and — if you can read them off the project — its price book (events with a unit price) and operations (routes with a per-call ceiling, and a `doc` describing input/output so agents know what to send). It returns a DRAFT Cap plus the signing secret and usage key (shown once). Nothing is charged while it is a draft. There is no human review: after test_cap passes, submit_cap takes the Cap live immediately, and qumge spot-checks it afterwards (a spot check can suspend it). (Older clients may still call this tool as publish_app.)

    after · 42% of words in common

    Create or update a DRAFT Cap on the developer's behalf (requires the developer's Qumge key). Prefer manifest v2: pass manifest_url for the project's public qumge.json, and slug to select a Cap when needed. The file supplies the name, connection, operations and suggested prices; do not repeat name or override file fields. Without manifest_url, give name and either connection_config, connection_id, base_url or mcp_url, plus the priced operations. Every billed operation must deliver one complete result for one clear input (e.g. product URL in → finished video out); helper steps such as job status are free, and a result that needs several calls is wrapped into one endpoint — never sell partial steps. Managed execution reserves a fixed price and charges only after valid complete delivery; queued acceptance is not delivery, and failed or expired orders cost nothing. Reuse existing tasks and durable request_id deduplication; providers need no Qumge-specific buyer, order, ledger or usage-reporting tables. Prefer execution.identity: order with self-contained inputs. Use trusted request_id to isolate tasks and private results. For buyer-owned state, explicitly choose identity: buyer and authorize the trusted buyer_key; a shared service account alone does not isolate buyers. Use connection_config or connection_id to share private credentials across Caps. Read https://qumge.com/en/docs/caps/managed.md for the complete contract. Legacy per-response and advanced usage-based fields remain supported for existing integrations; the signing/usage guide applies to those modes, not managed execution. A new signing secret is returned once when applicable. Legacy non-managed integrations may also return a usage key; managed execution does not use it. Nothing is charged while it is a draft. Confirm manifest prices with the developer. There is no human review: after test_cap passes, submit_cap takes the Cap live immediately, and qumge spot-checks it afterwards (a spot check can suspend it). (Older clients may still call this tool as publish_app.)

  • get_cap_jobadded

    Read your managed Cap job's cached progress, complete result and receipt for free. Use the platform job_id returned by call_cap. Ordinary reads do not invoke the provider. Set refresh_result: true to explicitly request free renewal of declared result URLs after success; the optional private provider command does not generate new work or change the receipt. Existing orders remain readable after Cap revocation.

  • call_capchangeddescription, input schema, output schema
    before

    Call a Cap on the user's behalf and return its response. Use this when you cannot make the HTTP call yourself: qumge charges the user's qumge balance and forwards the call at the same price as calling it over HTTP through Qumge. Operations and prices come from get_cap. Prefer `operation` + `input`: when the operation declares an input_schema, `input` is validated against it before anything is charged or forwarded. Needs the user's qumge key in the Authorization header. A 5xx from the Cap is free; a 402 means the user's balance or this Cap's monthly limit stopped it. (Older clients may still call this tool as call_app — it still works.)

    after · 81% of words in common

    Call a Cap on the user's behalf and return its response. Use this when you cannot make the HTTP call yourself: qumge charges the user's qumge balance and forwards the call at the same price as calling it over HTTP through Qumge. Operations and prices come from get_cap. Prefer `operation` + `input`: when the operation declares an input_schema, `input` is validated against it before anything is charged or forwarded. For managed results, pass a stable idempotency_key when retrying; asynchronous calls return a platform job_id and get_cap_job reads cached progress and the final receipt for free. Needs the user's qumge key in the Authorization header. A 5xx from the Cap is free; a 402 means the user's balance or this Cap's monthly limit stopped it. (Older clients may still call this tool as call_app — it still works.)

  • get_capchangedoutput schema
  • list_wantedchangeddescription
    before

    What agents searched for on Qumge and found nothing: the demand side of the store, in the searchers' own words, with how often each was searched in the last 7 and 30 days. Useful before building or publishing a capability — it tells you what people already want. Only the search text is stored; no user and no IP.

    after · 96% of words in common

    What agents searched for on Qumge and found nothing: the demand side of the store, in the searchers' own words, with how often each was searched in the last 7 and 30 days. Useful before building or publishing a Cap — it tells you what people already want. Only the search text is stored; no user and no IP.

  • request_payoutchangeddescription
    before

    Ask for a payout of the developer's payable balance (capability income only — topped-up money cannot be withdrawn). Call it once without `confirmed` to get the estimate (amount, channel fee, withholding tax, what actually lands), show that to the user, and only then call again with confirmed: true. Needs the developer's Qumge key.

    after · 96% of words in common

    Ask for a payout of the developer's payable balance (Cap income only — topped-up money cannot be withdrawn). Call it once without `confirmed` to get the estimate (amount, channel fee, withholding tax, what actually lands), show that to the user, and only then call again with confirmed: true. Needs the developer's Qumge key.

  • get_earningschangeddescription
    before

    What a developer has earned and what is payable: the amount still inside the 30-day holdback, the amount sitting in their wallet (income from capabilities — the only part that can be withdrawn), and what has already been paid out, with the most recent entries. Matured purchase amounts move into the wallet automatically. Needs the developer's Qumge key.

    after · 96% of words in common

    What a developer has earned and what is payable: the amount still inside the 30-day holdback, the amount sitting in their wallet (income from Caps — the only part that can be withdrawn), and what has already been paid out, with the most recent entries. Matured purchase amounts move into the wallet automatically. Needs the developer's Qumge key.

  • submit_capchangeddescription, input schema
    before

    Take one of the developer's capabilities live. Nothing is reviewed before launch and nobody approves it: when the three code-checked items pass (signature, end-to-end, price book), this publishes the cap immediately and agents can call it — and be charged — from then on. Run test_cap first (it records signature + end-to-end; the price book is recorded when it saves). Qumge spot-checks docs and support afterwards and can suspend the cap. Needs the developer's Qumge key. (Older clients may still call this tool as submit_app_review.)

    after · 97% of words in common

    Take one of the developer's Caps live. Nothing is reviewed before launch and nobody approves it: when the three code-checked items pass (signature, end-to-end, price book), this publishes the Cap immediately and agents can call it — and be charged — from then on. Run test_cap first (it records signature + end-to-end; the price book is recorded when it saves). Qumge spot-checks docs and support afterwards and can suspend the Cap. Needs the developer's Qumge key. (Older clients may still call this tool as submit_app_review.)

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.

Trust 79 / 100

no-repository
provenance45
liveness99
freshness100
hygiene80

+dns-namespace +reachable +uptime-96% +updated-21d-ago -no-repository

Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed. How it is computed.

Endpoints

remoteauthreachableuptime 30dp50protocollast ok
https://qumge.com/mcp streamable-httpnoneyes96%340 ms2025-06-182026-10-19

Tools (19)

become_developerOpen a developer account for the user (needs their qumge key). There is no review and no waiting: it takes effect immediately, and publish_cap works right after. Give a display name and an ISO country code; the country decides tax and payout rails later. Payout details and legal name are only needed when the user actually withdraws money.
call_capCall a Cap on the user's behalf and return its response. Use this when you cannot make the HTTP call yourself: qumge charges the user's qumge balance and forwards the call at the same price as calling it over HTTP through Qumge. Operations and prices come from get_cap. Prefer `operation` + `input`: when the operation declares an input_schema, `input` is validated against it before anything is charged or forwarded. For managed results, pass a stable idempotency_key when retrying; asynchronous calls return a platform job_id and get_cap_job reads cached progress and the final receipt for free. Needs the user's qumge key in the Authorization header. A 5xx from the Cap is free; a 402 means the user's balance or this Cap's monthly limit stopped it. (Older clients may still call this tool as call_app — it still works.)
cap_statusCheck one of the developer's own capabilities: its status (draft / review / live / suspended) and how far the publishing checklist has got. Needs the developer's Qumge key. (Older clients may still call this tool as app_status.)
get_balanceThe user's Qumge balance, plus what each Cap has spent this month against its monthly limit. Call this before a paid call when the user asks whether they can afford it, and after a 402 that says the balance or a limit stopped the call — it returns the top-up link to hand to the user. Needs the user's qumge key.
get_capFetch one Cap's operations, prices and how to call it, by the slug returned from search_caps. Call this before using a Cap: it lists each operation (by name), its input and output schema when the developer provided one, which routes are billable, the per-call maximum, when the call settles, and the error codes the caller may see. If the request carries the user's Qumge key, it also reports that user's monthly limit for this Cap. (Older clients may still call this tool as get_app — it still works.)
get_cap_jobRead your managed Cap job's cached progress, complete result and receipt for free. Use the platform job_id returned by call_cap. Ordinary reads do not invoke the provider. Set refresh_result: true to explicitly request free renewal of declared result URLs after success; the optional private provider command does not generate new work or change the receipt. Existing orders remain readable after Cap revocation.
get_earningsWhat a developer has earned and what is payable: the amount still inside the 30-day holdback, the amount sitting in their wallet (income from Caps — the only part that can be withdrawn), and what has already been paid out, with the most recent entries. Matured purchase amounts move into the wallet automatically. Needs the developer's Qumge key.
get_skillFetch the full SKILL.md content of one skill, by the slug returned from search_skills. Write the returned markdown to .claude/skills/<name>/SKILL.md (or the equivalent for the user's agent). If the reply says the skill ships more files (REFERENCE.md, scripts/…), call again with include_files: true to get them and write each next to SKILL.md.
list_capsList the developer's own Caps with their status (draft / live / suspended) and slug. Use it before publishing to see what already exists, and after to check what went live. Needs the developer's qumge key. (Older clients may still call this tool as list_apps.)
list_categoriesList the skill categories and how many skills are in each. Useful when the user is browsing rather than looking for something specific.
list_modelsList the models this gateway can route to, best first. Every one is reachable with the same Qumge key — no per-vendor signup. Only tool-calling models are listed: an agent cannot use the others.
list_wantedWhat agents searched for on Qumge and found nothing: the demand side of the store, in the searchers' own words, with how often each was searched in the last 7 and 30 days. Useful before building or publishing a Cap — it tells you what people already want. Only the search text is stored; no user and no IP.
publish_capCreate or update a DRAFT Cap on the developer's behalf (requires the developer's Qumge key). Prefer manifest v2: pass manifest_url for the project's public qumge.json, and slug to select a Cap when needed. The file supplies the name, connection, operations and suggested prices; do not repeat name or override file fields. Without manifest_url, give name and either connection_config, connection_id, base_url or mcp_url, plus the priced operations. Every billed operation must deliver one complete result for one clear input (e.g. product URL in → finished video out); helper steps such as job status are free, and a result that needs several calls is wrapped into one endpoint — never sell partial steps. Managed execution reserves a fixed price and charges only after valid complete delivery; queued acceptance is not delivery, and failed or expired orders cost nothing. Reuse existing tasks and durable request_id deduplication; providers need no Qumge-specific buyer, order, ledger or usage-reporting tables. Prefer execution.identity: order with self-contained inputs. Use trusted request_id to isolate tasks and private results. For buyer-owned state, explicitly choose identity: buyer and authorize the trusted buyer_key; a shared service account alone does not isolate buyers. Use connection_config or connection_id to share private credentials across Caps. Read https://qumge.com/en/docs/caps/managed.md for the complete contract. Legacy per-response and advanced usage-based fields remain supported for existing integrations; the signing/usage guide applies to those modes, not managed execution. A new signing secret is returned once when applicable. Legacy non-managed integrations may also return a usage key; managed execution does not use it. Nothing is charged while it is a draft. Confirm manifest prices with the developer. There is no human review: after test_cap passes, submit_cap takes the Cap live immediately, and qumge spot-checks it afterwards (a spot check can suspend it). (Older clients may still call this tool as publish_app.)
request_payoutAsk for a payout of the developer's payable balance (Cap income only — topped-up money cannot be withdrawn). Call it once without `confirmed` to get the estimate (amount, channel fee, withholding tax, what actually lands), show that to the user, and only then call again with confirmed: true. Needs the developer's Qumge key.
search_capsSearch Qumge's Caps — paid services an agent can call, billed per call from the user's Qumge balance. A Cap (short for capability) is one finished job: somebody's API or MCP server with a price list; to you it is a set of operations. Use this when the user wants something done rather than a skill to install: 'make a promo video', 'transcribe this call'. Returns the best few with pricing, measured success rate and latency, and the slug to pass to get_cap. (Older clients may still call this tool as search_apps — it still works.)
search_skillsSearch Qumge's curated catalog of agent skills (SKILL.md files) by what the user wants to accomplish. Use this whenever the user asks for a skill, tool, or Cap — e.g. 'find me a skill for social media automation', 'is there a skill for SEO audits'. Returns the best few, ranked by how useful they actually are (an LLM read each one), with a one-line summary and the exact slug to pass to get_skill.
submit_capTake one of the developer's Caps live. Nothing is reviewed before launch and nobody approves it: when the applicable connection/operation checks and price book pass, with complete billed-operation docs, this publishes the Cap immediately and agents can call it — and be charged — from then on. Run test_cap first (legacy checklist keys remain signature and end_to_end; the price book is recorded when it saves). Passing native connection checks or isolated fixtures does not verify real delivery. Qumge spot-checks docs and support afterwards and can suspend the Cap. Needs the developer's Qumge key. (Older clients may still call this tool as submit_app_review.)
test_capRun the applicable publication checks after publish_cap, before submit_cap. Managed qumge wrapper operations use authenticated isolated fixture hooks and validate the complete fixture result. Native managed API/MCP operations check HTTP OPTIONS or MCP tools/list for connection/schema evidence without invoking generation. The verification array distinguishes connection, fixture and real_delivery scopes; real delivery is not tested. Legacy integrations may call one free and one billable route, or each published MCP tool, directly with probe inputs; Qumge does not charge for these probes, but the developer may incur provider costs. Signed wrapper/legacy APIs also test /qumge/ping with valid, forged and stale signatures; legacy usage-reporting routes must report probe usage. Missing billed-operation docs block publishing. Needs the developer's Qumge key. (Older clients may still call this tool as test_app.)
verify_domainProve the developer owns the domain of their MCP server or API. Going live does not need it: an unverified Cap is live and charges callers, but the developer's earnings from it stay frozen until this passes — verifying releases them. Call with the service's https url: if the domain (or a parent domain) is already verified it says so; otherwise it returns a one-line file to serve at /.well-known/qumge-verify.txt on that host (or a DNS TXT record with the same line). Put the file into the project so it ships with the next deploy, then call again with check: true. Needs the developer's Qumge key.

Schemas: list_tools.

Similar MCP servers

Official server.json
{
  "name": "com.qumge/skills",
  "title": "Qumge: Agent Capabilities & Skills",
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "remotes": [
    {
      "url": "https://qumge.com/mcp",
      "type": "streamable-http"
    }
  ],
  "version": "1.2.0",
  "description": "Find, call and pay per call: the capability layer for agents, plus skills. One key or OAuth."
}