Skip to main content
Glama

knowngood

by sh.knowngood
OverviewDiscussionsAdmin

Find agent-ready websites

find_capability
Read-only

Find websites where an agent can accomplish a task. Returns probe-verified agent-readiness signals, unverified apparent actions read from page content, the verification tier, how each site was found (it declared agent access, probe discovery, or it was submitted), and a report URL to cite. Returns count:0 with an empty_note when nothing in the index matches — never a nearest guess.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNoWhat you are trying to do, in plain language. Optional when at least one filter is set: with no query the tool lists every listed site matching the filters, in a fixed published order, with `total`.
has_mdNoOnly sites with verified markdown: negotiation that passed the strict re-grade (the body is markdown and differs from the HTML), or a .md twin. Omit both class flags for the whole index — the default.
countryNoISO 3166-1 alpha-2, e.g. GB
has_mcpNoOnly sites whose MCP server answered tools/list when we tested; results include the tool names
has_webmcpNoOnly sites whose in-page WebMCP tools were RUNTIME-VERIFIED: the page was executed in a headless browser with a modelContext supplied, and it registered at least one tool. Source-only hosts — the registration code is present but registers nothing when the page runs — are excluded, exactly as an MCP card that never answers is. Results include the registered tool names.
entity_typeNo
has_endpointNoOnly sites with a verified endpoint surface (working MCP server or API catalog).
transactionalNoOnly sites where an agent can act, not just read

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / has_md / description
      Previous value: -"Only sites with verified markdown (negotiation or a .md twin). Omit both class flags for the whole index — the default."New value: +"Only sites with verified markdown: negotiation that passed the strict re-grade (the body is markdown and differs from the HTML), or a .md twin. Omit both class flags for the whole index — the default."
    • changedInput schema / properties / query / description
      Previous value: -"What you are trying to do, in plain language"New value: +"What you are trying to do, in plain language. Optional when at least one filter is set: with no query the tool lists every listed site matching the filters, in a fixed published order, with `total`."
    • changedInput schema / required
      Previous value: -[
-  "query"
-]New value: +[]
  2. Changed1 schema field changed
    • changedInput schema / properties / has_endpoint / description
      Previous value: -"Only sites with a verified endpoint surface (working MCP server or API catalog; OpenAPI/WebMCP join with the next crawl)."New value: +"Only sites with a verified endpoint surface (working MCP server or API catalog)."
  3. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, non-destructive), and the description adds real value on top: it discloses the return content (probe-verified signals, unverified apparent actions, verification tier, discovery source, report URL) and the empty-result contract ('count:0 with an empty_note — never a nearest guess'). It does not cover pagination or ordering beyond a brief mention of 'fixed published order' in the schema.

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?

Two sentences, front-loaded with the purpose, followed by the result contract. Dense but every clause carries information about what comes back. 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 nine optional parameters and no output schema, the description correctly takes on the return-shape burden and names what the agent will get. It is nearly complete for a search tool; the main gap is that filter interplay (e.g., no query requires at least one filter) is left entirely to 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 78% and the schema itself gives rich filter semantics (has_md, has_mcp, has_webmcp, has_endpoint, transactional). The description adds only the notion of discovery source ('declared agent access, probe discovery, or submitted') and does not restate or extend the filter meanings, so the schema is doing the heavy lifting.

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 with scope: 'Find websites where an agent can accomplish a task.' An agent immediately knows this is an index search over agent-ready sites. It does not explicitly contrast itself with siblings (check_webmcp, get_site_report), though those are distinct enough that the risk is low.

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?

Usage is implied rather than stated — the description never says when to reach for this versus check_webmcp or get_site_report. It does clarify one important behavioral rule ('never a nearest guess'), which helps the agent interpret a null result, but there are no explicit when-to-use or when-not-to-use instructions.

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

All knowngood toolsInspect
Try in Browser
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources