{
  "markdown": "# veritap-mcp\n\n**Check whether a real-world fact can be verified — before your agent acts on it.**\n\nAn MCP server for checking whether a real-world fact can be verified before\nan agent acts on it — businesses, listings, objects, and places. Free to\ncheck, no auth, read-only. Safe to call\nspeculatively in the middle of planning.\n\nIt does **not** answer questions about individual people. Identity, employment,\ntenancy, background, and whereabouts claims are refused as a matter of policy.\n\n## Install\n\nClaude Desktop / any stdio MCP client:\n\n```json\n{\n  \"mcpServers\": {\n    \"veritap\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"veritap-mcp\"]\n    }\n  }\n}\n```\n\nRemote clients can skip the shim and connect straight to\n`https://veritap.dev/mcp` (Streamable HTTP).\n\n## Why an agent should call this\n\nAgents constantly hit steps resting on facts they cannot confirm from text: is\nthis supplier still trading, does this listing hold together, was the work\nactually done. The usual options are to guess — and pay for it when wrong — or\nto quietly skip the step. This gives you a third option that costs nothing:\nask whether the fact is checkable at all, and what checking it would cost.\n\n## Tools\n\n| Tool | Use it when |\n|---|---|\n| `check_feasibility` | Any step depends on a physical-world fact you cannot confirm. Free, read-only. |\n| `triage_unknowns` | You have several uncertainties and do not yet know which are worth chasing. Batch them all in one call. |\n| `plan_verification` | You have a multi-step plan and want to know which steps rest on unverified facts. |\n| `confirm_before_purchase` | An irreversible spend where the counterparty was only seen online. |\n| `check_before_relying` | A step rests on something you only inferred, and being wrong is expensive. |\n| `check_physical_condition` | The decision turns on an item being in the claimed condition. |\n\n`triage_unknowns` classifies each uncertainty as **answerable by you from public\nsources** (naming the source), **verifiable here** (with price and turnaround),\nor **not determinable** (with advice on planning around it). Items you can\nsettle yourself are routed away rather than sold to you — that is deliberate.\n\n## Claim types in scope\n\n> **Nothing is purchasable and no payment is taken.** One claim type is\n> answered right now, for free. The other is in scope but not yet answered, and\n> its price is indicative only — not an offer to sell.\n\n| Claim type | Status | Price |\n|---|---|---|\n| `BUSINESS_EXISTS_AND_OPERATING` — a named business exists, is operating, contact details valid | **answered now**, seconds | free |\n| `LISTING_IS_CONSISTENT` — a listing is internally consistent, corroborated, free of common red flags | in scope, not yet answered | ~$6 indicative |\n\nFor business-exists claims, `check_feasibility` returns the evidence bundle\nitself — there is no second, paid call. For anything it cannot answer it says\nso plainly, which is still worth having: it settles whether to design the step\naround the fact or wait.\n\nVerification is multi-source desk research returning an evidence bundle: the\nsources consulted (GLEIF, SEC EDGAR, Wikidata, site liveness), the method used,\nand a confidence reflecting how well those sources actually agree. Results\nreport observations with dates — *\"the listed phone number was disconnected as\nof 11 August 2026\"* — never characterisations like \"scam\" or \"fake\". A low\nconfidence for a small local business means the registries are thin on it, not\nthat it is suspect.\n\nAnything outside those two returns an honest `not_yet`, the closest in-scope\nalternatives, and advice on how to proceed. Those requests are logged, and what\ngets asked for is what gets built next. **Asking for something unsupported is\nhow it becomes supported.**\n\n## Limits, stated plainly\n\nDesk verification only, and nothing is purchasable. Nobody is dispatched to\nphysically inspect anything, so *\"is the item actually on the lot today\"* is not\nanswerable here at any price. One claim type is answered today, one is not. We\nwould rather name the boundary than imply a capability that does not exist — or\nhide one that does.\n\n## Configuration\n\n| Variable | Default |\n|---|---|\n| `VERITAP_ENDPOINT` | `https://veritap.dev/mcp` |\n| `VERITAP_TIMEOUT_MS` | `60000` |\n\nThe shim is a zero-dependency passthrough — it forwards JSON-RPC frames without\ninterpreting them, so it never falls out of sync with the endpoint's protocol\nversion.\n\n## Data\n\nRequests are recorded and analysed in aggregate to decide what gets supported\nnext; that is the point of the service. Caller identifiers are pseudonymous\nhashes of connection metadata, raw request text is discarded after 90 days, and\nindividually identifying caller data is never sold or shared. Refused\npeople-claims are not stored with their text at all.\n\nFull terms: <https://veritap.dev/terms> · Deletion: privacy@veritap.dev\n\nMIT licensed. <https://veritap.dev>",
  "bytes": 4904,
  "sha": "a247a466cbfedb9299d4f5816983172652abdbc9ee9b995a2b73899eb8cbd602",
  "repo_slug": "",
  "fonte": "npm",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_dev_veritap_veritap_d8ead41b/readme"
}