Connect an AI agent
An agent such as WorkBuddy, Claude or ChatGPT can search what SurviAGI has published and read each record with its sources. Reading needs no account and no key. A signed-in reader can also give an agent a key to submit research questions and accounts worth monitoring, as requests for review.
What an agent can do
search: find published updates from AI companies, closed questions about jobs and businesses, and evidence readings (one update read as a level, L0-L5, for one kind of work). Each result has a stable id, our short summary, the page link, the original source links and the data release it comes from.
get_record: read one record in full by its id, with every reading of an update, the posts that argued each answer of a question (with short quotes in the posts' own words), and the updates that weigh on it.
With a key: submit_question registers a research question for review, suggest_account registers an X account to monitor, and my_submissions shows their status and the quota left.
The site finds and registers; it does not answer. The agent does the analysis. No query, empty search or submission starts a model, a research run or a collection here.
Endpoints
MCP over Streamable HTTP (JSON responses, no session). Use the first endpoint with no key; use the second, with the key in an Authorization header, to submit as well. Reading works on both, and a wrong or revoked key never blocks it.
The same tools as plain HTTP, for a script or a Skill that does not speak MCP:
https://surviagi.com/api/mcp search, get_record — no key
https://surviagi.com/api/mcp/submit + submit_question, suggest_account, my_submissions
header Authorization: Bearer sag_…
GET https://surviagi.com/api/agent/search?query=coding+agents&limit=5&types=update,evidence
GET https://surviagi.com/api/agent/record?id=ev-…
POST https://surviagi.com/api/agent/questions (key) {question, why_it_matters, evidence_gap, leads?, related_record_ids?, request_id?}
POST https://surviagi.com/api/agent/accounts (key) {account, kind, reason, field?, request_id?}
GET https://surviagi.com/api/agent/submissions (key)WorkBuddy and other clients
WorkBuddy applies a connector's sign-in to every call, so SurviAGI comes as two connectors: one for searching with no key, and one that asks for your key once and can also submit. Other MCP clients take the address directly, for example:
{ "mcpServers": { "surviagi": { "type": "streamableHttp", "url": "https://surviagi.com/api/mcp" } } }What reading gives you
Only what the site has published: the same updates, questions and readings its pages show, from the data release named in every answer. Nobody's submissions, no raw collection and no internal state are reachable.
Every summary and level is proposed by machine and has not been reviewed; each text says whether it is our summary, a reading, or a quote of the source. The full text of source posts is not published: open the source links. X Articles, linked pages and PDFs are not collected.
Cite the record's page address together with the release's generation time.
A question worth submitting
Search first; a question already published is read, not submitted. A good question is specific and about AI doing real work: a job, a kind of business or a capability. Say why the answer matters and to whom (at least 20 characters), what the published records do not answer (at least 10), and give leads: sources, accounts or dates.
A submitted question stays private to you and the reviewers, and is never published as written. A reviewer decides whether it is researched. An account suggestion follows the same path as the site's own form: submitted, approved, identity confirmed, monitoring enabled are separate steps, and none happens by itself.
Limits
Reading: at most 60 requests a minute from one address, up to 20 results a search.
Submitting, per reader (all your keys and the site's own forms together, so a new key does not reset them): 5 new questions a day and 20 waiting for review; 20 new account suggestions a day and 10 waiting. Days are UTC. A duplicate, a refused request or a retry with the same request_id uses nothing.
Keys: up to 5 at once. Revoking one stops it at once; the requests made with it stay.