Agentalog — Agent Auto Log

Read one A2A agent: every skill its card declares, capabilities, protocol version, health, documentation and the registries that list it, with their licenses. Take the key from a2a_agent_search. The same row as the list plus what the card declares: every skill, the `capabilities` object, the protocol version as written, the documentation and icon URLs, and when we first saw it. Cached for 60 seconds; a MAT catalog read, like the list.

Find A2A agents — agents that publish an AgentCard — by text, health, protocol version, registry, skill tag or publisher. Each row carries the key for a2a_agent and the license of every registry that lists it. Collected from public A2A registries and served as it comes — no review queue hides a record; quality is the order, never visibility. One row per agent, merged across the registries that list it: `sources` says which, and `credits` carries each one's license, which travels with the data. Values inside one parameter are OR'd, different parameters are AND'd. Cached for 60 seconds. A MAT catalog read, served by the index host `https://api.agentalog.com`; this host forwards the call there.

Self-describing index: the whole API surface, with quota and quickstart.

Curated engineering links filtered by topic and source type (paper, repo, model, dataset, demo, video, docs, article, post), 20 per page, with the count of each filter value. Values inside one parameter are OR'd; the two parameters are AND'd. Unknown values are ignored. Follow `_links.next` to walk everything.

Which engineering topics have curated briefings, how many links each has and the newest links across all of them. Each link comes with its source, source type and a two-line summary. Topics are public bookmark folders (CUDA, inference, RAG, agents…). Each item is a post someone saved, its main source, the source type and a two-line summary in English and Portuguese. `?resumo=1` returns only `total` and each topic's `slug` and `total`. 404 until the first publication.

Before installing a remote MCP server, check its address: signals from the address itself (consumer tunnel, no TLS), the catalog listings with that address or host and their security level, and facts about its domain. Never visits the address. Send the endpoint URL. The answer never contacts that address: it reads what our weekly visits measured and what our domain data knows. `address_signals` comes from the address alone (consumer tunnel, `http://` without TLS). `records` lists the catalog listings with this exact address first (`exato: true`), then up to 20 others on the same host, each with its level and signals; `same_host` counts them all. `domain` has the facts about the host's domain. An address outside the catalog answers `no_catalogo: false` and `register`: submit it to get it reviewed. Cached for 5 minutes.

Write to the people behind the product: a question, or a sponsorship/partnership/advertising proposal. One route for a question and for a sponsorship, partnership or ad proposal (`type`, with the placements of `GET /api/partners`). One message every 10 seconds per network: one that arrives sooner waits its turn and then goes out — no error. The message reaches the team by e-mail, with `email` as the reply address. For voice, send multipart/form-data: `dados` is this JSON (up to 32 KiB), and `audio` is one WebM, Ogg or M4A audio file (up to 2 MB). Audio can replace message. The browser records up to two minutes. Audio is attached to the owner's e-mail.

Creates a guest mr_… Asks for no e-mail. At most 20 new guests per network per hour; a browser that already has one gets it back from the `mr_guest` cookie.

Submit an MCP server, skill or plugin for review. Limit: one submission a day and three in the queue per owner. Automatic review approves supported low-risk MCP listings; uncertain cases wait for a person. Poll `status_api` (`GET /api/listings/:id/status`, no credential) to learn the decision. A person or agent can submit without an account. Each owner can submit once a day and keep up to three submissions in the queue. For a skill, provide its SKILL.md URL. An invalid body returns 400; an exhausted quota returns 429.

Does this site publish a feed? Answers with every feed known for a domain — the question a reader or an agent actually asks. Find feeds by text, format, language and availability. Filter and text search run in the SAME full-text query: values inside one parameter are OR'd, different parameters are AND'd. Without `q` the order is by newest in the index (`recent`) and `next_cursor` is a keyset — follow `next` to walk everything. With `q` the order is relevance and paging is by `offset`. We index and link; the feeds belong to whoever publishes them.

Read one post whole: the body in Markdown (`content`) and the author's formatting as safe HTML (`content_html`), plus the link to the original. `ord` comes from feed_posts; 0 is the newest. Two bodies for the same post, both from the copy we stored when we READ the feed — a request never fetches the site: `content_html` keeps the author's formatting through an allowlist (only known tags and attributes survive; script, style, iframe and event handlers are dropped with their content), and `content` is the same text as Markdown — the shape an agent usually wants. Neither can carry script. 404 when the feed or the position is unknown.

What has this feed published? The posts of one feed as our queue read them — title, date, author, summary, categories and enclosure, without the body. Find the feed first (feed_find or feed_search); this takes an id from this index, never a URL. Up to 40 posts, in the order the feed publishes them, WITHOUT the body — the body of one post comes from `/items/:ord`. It is OUR copy, read on our own schedule — not the live feed and not a proxy: the only thing this endpoint accepts is an id from this index, never a URL. `read_at` says when we read it. Empty list when the feed has not been read yet.

Search the feed index by text and filters: format, audio/video, community, namespace and year of the newest item. Find feeds by text, format, language and availability. Filter and text search run in the SAME full-text query: values inside one parameter are OR'd, different parameters are AND'd. Without `q` the order is by newest in the index (`recent`) and `next_cursor` is a keyset — follow `next` to walk everything. With `q` the order is relevance and paging is by `offset`. We index and link; the feeds belong to whoever publishes them.

One bundle's card: root index.md URL, version, concept count, provenance and repository signal. `live` and `low` (example or fixture bundles kept out of the search) both answer here.

One listing's page. The owner sees their own even when pending or hidden.

Collected project documentation. Available when get_listing includes readme_api; 404 when no copy was stored. The text lives in R2 (`mural-coleta`). This call does not write and does not fetch GitHub. Same visibility as the listing page. Call it only when the listing page carries `readme_api`: a page without it has no README collected, and this route answers 404.

302 hop to the listing's origin (counts a visit). Counts at most 1 visit per owner per day. The `X-Visit-Counted` header says whether this call counted — it is how the client knows without counting twice. A remote MCP server goes to its repository; without one, to the listing page `/l/:id`, which shows the endpoint to copy, and no visit counts.

Liveness and the commit deployed right now — it is how the smoke waits for its own deploy.

Size of the index by provenance and when it last changed.

Likes the listing; DELETE undoes it. Calling again does not add up: the counter counts people.

Comments on a live listing. With a credential on the call, each comment of yours comes with `mine: true`.

Public mosaic of live MCP servers, skills, plugins and OKF knowledge bundles. `live` listings first and the `low` tail (few stars or no clear license) after them in every order — `low=0` leaves the tail out. To walk everything, follow `next`: without `q` it is a cursor (`next_cursor`, keyset on the order's index) and has no ceiling; every listing also has an HTML page at `/l/:id` and the shards of `/sitemap-listings.xml` list them all. `q` runs on a full-text index (FTS5, bm25) kept in the same transaction as every text write. With `q` and `low=0`, `low_count` says how many `low` listings the filter left out — LIKE with a cap of 200. The query is mapped onto kind/topic/transport filters unless `interpret=0`.

MCP subregistry (GET /v0.1/servers). Only live kind=mcp. Only `kind=mcp` and only `live`. It is the route a generic MCP client knows how to read without knowing this product. `GET /v0/servers` is an alias of the same resource, kept for whoever already pointed there — this is the canonical URL.

Timeline of the listing's repository: last events (abandono = no push for 12 months, sumiu, renomeado, readme_mudou, manifesto_mudou), newest first; empty when nothing changed since the series began. The listing page carries the same list as `history`; updates may be cached for up to 15 minutes. An empty list means no change since the series began — the listing still exists. Stale means no push for 12 months. Reading this endpoint does not refresh the record.

Read a remote MCP server or SKILL.md review before installing. MCP: server, domain, tools and measured signals. Skill: static findings with file, line, excerpt and context; no command execution or referenced-script review. Unread skills stay unchecked. Read the limits in aviso. Take the id from list_listings. We visit remote MCP servers: `initialize` and `tools/list`, without credentials or tool calls, again 7 days after a success. A failure needs a second check. MCP signals: dns_morto, sem_https, tls_invalido, tunel, nao_responde, nao_mcp, texto_suspeito, redireciona_fora, repo_arquivado, repo_parado, dominio_recente, login, bloqueado. For skills, `tipo: skill` identifies a static SKILL.md review. It flags secret reads, download-and-execute commands, external uploads, invisible characters, long encoded text and broad allowed-tools. `revisao.achados` supplies the path, original line, excerpt and context. Examples and prohibitions do not raise the level. Excerpts hide sensitive values. The review does not run commands or follow references. Supported source: public raw.githubusercontent.com SKILL.md. Watched, visited, starred and new skills get priority within the shared GitHub governor and a daily cap. Unread or unsupported skills remain explicitly unchecked. Local MCP servers and plugins answer `not_remote`. No request fetches a third-party source. Cached for 5 minutes.

Moderation state of a listing (pending / live / low / hidden / blocked) — poll it after create_listing. No credential; only the decision comes back. Every submission is born `pending`. An automatic safety check looks for concrete signs of fraud, malware or data theft. Listings without these signs can be approved. A risk finding or an unreadable source keeps the listing private for a person to review. This is the receipt you poll after `POST /api/listings` (its response carries this URL as `status_api`). Only the decision comes back, never the unreviewed content: the id (`lst_…`, unguessable) is all it takes, and the page itself keeps its rule — owner only until it is public. Answers are cached for 60 s per point of presence: poll every few minutes, not every second.

The tools and instructions a remote MCP server announced at its last check, with what they mention doing and any suspicious text. 404 tools_not_read when the server was not read yet. The announced manifest, normalized: each tool's name, title, description (up to 4,000 characters), input schema (null above 8,000 characters) and protocol annotations, plus the server instructions. `capabilities` and `suspicions` come from the current rules, applied when you read. Reading this endpoint never contacts the server. Cached for 5 minutes.

Browse what independent MCP indexes measured, including servers this catalog does not list yet (casou=0). Newest change first. `casou=0` is what the indexes know and the catalog does not — the list to look at before submitting a server. Filters are AND'd. With `q`, `total` is the exact number of matches, including when the requested page is empty.

Does this MCP server still answer, with which access, and is its repository alive? What independent MCP indexes measured about one listing of this catalog, each credited with its license. Take the id from list_listings. A signal belongs to a listing only when it is the SAME object: the name in the official MCP registry, the exact remote endpoint URL or the GitHub `owner/repo`, in that order. A shared domain never matches — two servers on one host are different products. Up to 20 signals, one per index and record.

Search the index of OKF bundles: free text over name, tagline, description and origin; filter by provenance (github|domain), repository, version, language, license, root type or concept count; search root concept text. Paginate with limit/offset. Only `live` bundles. Free text matches the name, the tagline, the description and the origin identifier (`owner/repo:path` or the bundle URL). No `total` on purpose: `GET /api/okf/stats` has it.

Submits OKF bundles from a host you control (IndexNow protocol: a key file proves ownership, with no account). Answers 202 — the key is checked by the collector before anything is read. Host `https://<host>/<key>.txt` containing the key (or point `keyLocation` at another path on the SAME host), then send the bundle URLs. We answer **202**: the key has not been checked yet. Verification and reading happen on our collector, never at the edge — so nothing is published, and no URL of yours is fetched, before the key matches. Re-sending a URL is how you say the bundle changed; it goes back in line to be re-read. At most 100 URLs per request and 200 per host per UTC day. The same queue is served by `POST https://okfindex.com/api/ping`, the index's own home — search, bundle cards and statistics live there.