Agent kit · 27 July 2026
You built more agent surface than almost anyone in this space. That is exactly why the gaps cost you: the audience is already at the door, and half the doors are locked. Everything here is drop-in.
One polite request each, on 27 July 2026.
| Endpoint | Advertised in | Result |
|---|---|---|
| /api/unrugable/tokenomics | llms, robots, openapi | 200, but a stub, not the documented breakdown |
| /api/unrugable/all | llms, openapi | Works |
| /api/unrugable/metadata/{addr} | llms, openapi | Works |
| /api/unrugable/image/{addr} | llms, openapi | Works |
| /api/unrugable/factory | llms, openapi | Works |
| /api/unrugable/reactor/{addr} | openapi | 200 and always wrong |
| /api/unrugable/signals | robots.txt Allow | 404 |
| /api/unrugable/performance | robots.txt Allow | 404 |
| /api/unrugable/gallery | llms.txt | 404 |
| /api/baseling/agent/ | agents.html | 404 |
| .../economy/rules | llms.txt | Works |
| .../economy/phase | llms.txt | 404, missing /:wallet |
| .../economy/feeding | llms.txt | 404, missing /:job |
| /agents-onboarding.html | robots.txt | 404 |
Two of those are a five minute fix. We confirmed the corrected forms return 200:
Free upside
Your Baseling router actually declares 20 routes, and llms.txt advertises 17. You are underselling. There is a /agent/guide returning several kilobytes of usable orientation that nothing points at.
The diff, not a rewrite. Everything else in your file is good, and it already does the right thing by deferring live counts to the live map instead of hardcoding them.
Worth knowing
Your risk.html is genuinely good, better than most audited protocols write, and it is linked zero times from llms.txt, agents.json, the vaults page, or the earth page. Agents and buyers meet the pitch without ever meeting the disclosure.
Your agents.html currently documents seven tool names that do not exist in the published package, so a copy and paste quick start fails on every call. This card is generated from the real tool list.
The one we would change first
Your install instructions ask agents to put a raw private key in an environment variable for an unpinned npx package, and mcp.json puts the key on the command line, where it lands in shell history. We read your v1.4.0 source and it is clean: the key never leaves the process, there are no install scripts, one dependency, provenance signature present. This is a design risk, not an accusation. But npx without a pin resolves latest at every run, so a future compromised publish reaches every agent that ever ran it. Pinning the version is a one line change and it closes the tail entirely.
Said plainly, because these are things we tried to fault and could not.
Keep doing this
vault-facts.json is the best artifact you have. Machine readable due diligence with an explicit list of what the vault is not, address provenance, and a self declaration of which claims were checked against deployed bytecode and which were not. We have not seen another project publish "here is what I verified and here is what I did not." Push this pattern harder, it is a real differentiator.
Keep doing this
Your advertised tool count is exactly right. We did the arithmetic and counted the shipped array: 49 both ways, category for category. Contract addresses are consistent across all six discovery files. Most multi file agent surfaces have at least one transposed address. Yours do not.
Keep doing this
reactor-map.json is live, fresh and correct, regenerated hours before we read it. It is the most trustworthy thing on the surface, and it is the answer to two of the broken endpoints above. Point more of the stack at it.
Keep doing this
The swap guardrails are real and match the advertised numbers, with a token allowlist and exact amount approvals that are never unlimited. The file header reads "Every rule maps to a real loss event, do not weaken these checks." Somebody lost money and wrote it down. That is good engineering culture.
