Inspect, Dry-Run, Then Install an ERC-8004 Agent with spawnr

Q: Why does this guide use `base:29382`?

This update uses `base:29382` because the July 11, 2026 CLI check returned the current Social Intel MCP endpoint, tool list, score, service list, and hire command for that token. Older Social Intel examples may mention another Base token ID, so check the live card you intend to install before writing local config.

April 21, 2026

The right way to install an ERC-8004 agent is not "paste first, inspect later." Start with the public agent record, confirm the CLI sees the same services, run a dry-run install, and write the MCP config only after the planned change is clear.

On July 11, 2026, I rechecked the current spawnr package, the Social Intel API listing, the demo route, and the unpaid x402 route before updating this guide. npm view spawnr version still returned 0.4.2. npx spawnr@latest --help listed the main commands check, hire, login, logout, search, show, and whoami, plus integrations for completions, mcp add, and skills. The useful install target for this pass was Social Intel API at base:29382.

In brief: use spawnr show base:29382 to inspect the agent, use spawnr hire base:29382 --only codex --dry-run to preview the Codex MCP config, then rerun without --dry-run only when you want spawnr to write the config. For Social Intel, the dry run produced a Codex MCP server entry pointing at https://socialintel.dev/mcp/.

Before installing, run the same public checks a search visitor should run. Open the Social Intel profile to confirm the listed service. Compare similar agents that declare MCP so you know whether this is the right target. Run The Spawn checker when the endpoint evidence matters. Read MCP vs A2A and x402 when protocol routing or payment behavior is part of the decision.

What spawnr is doing

spawnr is the command-line installer for The Spawn. The package is published on npm as spawnr, and the related source repository is SwiftAdviser/thespawn-cli.

For an MCP-capable agent, spawnr can read the agent card from The Spawn, find its MCP endpoint, and write the client-specific MCP config for tools such as Codex, Claude Code, Cursor, Windsurf, and Openclaw. I use it as a review pass before install: inspect the public listing and service shape, preview the local editor config change, and write the config only after the planned endpoint and server name match the agent I meant to add.

Step 1: inspect the package and agent

First, make sure npx is resolving the current package:

npm view spawnr version
npx spawnr@latest --help

On July 11, 2026, the package version was still 0.4.2. The help output described hire as the command that writes MCP config into coding tools and described show as the command that prints a full agent card by chain ID, URL, or website host.

Then inspect the Social Intel agent:

npx spawnr@latest show base:29382 --format json

The result I got was a B-tier Social Intel API card with score 74, chain base, id 29382, MCP endpoint https://socialintel.dev/mcp/, one MCP tool named search_leads, and four declared service surfaces: MCP, A2A, API, and web. The same public card is available at https://thespawn.io/agents/base/29382, with the API record at https://thespawn.io/api/v1/agents/base/29382. Use The Spawn checker if you need a fresh metadata and endpoint read before trusting the card.

The CLI also printed the install command it would use:

spawnr hire base:29382

Step 2: test the demo path before editing config

Social Intel exposes a public demo route, which is useful before you install anything into an editor:

curl "https://socialintel.dev/v1/search?demo=true&query=fitness"

My July 11, 2026 request returned HTTP 200 JSON with demo: true and count: 3. That proves the demo route is inspectable and returns structured JSON for this dated request. It does not prove a paid retry was completed, and it does not prove every MCP, A2A, API, and web surface will keep identical behavior over time.

I also checked the unpaid paid route:

curl "https://socialintel.dev/v1/search?query=fitness"

That request returned HTTP 402 with x402Version: 2, four accepted payment options, and a resource URL for the same search. Treat that as payment-challenge evidence only. A completed paid retry, MCP wrapper behavior, and A2A behavior are separate checks. If you are publishing a paid service yourself, use the x402 service registration checklist before adding payment claims to metadata.

This is the edge case that makes the order matter: REST can expose a clean 402 challenge while the MCP server still needs its own initialization, tool-list, and tool-call proof. Do not let a successful REST demo stand in for every declared surface.

Use the demo as a product check. If the preview shape is useful for your workflow, proceed to a dry run. If it is not useful, leave your editor config alone. That order avoids adding an MCP server configuration before you have seen the product output it should return.

Step 3: dry-run the Codex install

For Codex, preview the exact config entry before writing files:

npx spawnr@latest hire base:29382 --only codex --dry-run --format json

The dry run returned this agent summary:

{
  "name": "Social Intel API",
  "chain": "base",
  "id": 29382,
  "tier": "B",
  "score": 74,
  "mcp_endpoint": "https://socialintel.dev/mcp/"
}

It also returned a Codex install row under installed[] with status: "dry-run" for ~/.codex/config.toml. The planned config was:

[mcp_servers.spwnr-social-intel-api]
type = "http"
url = "https://socialintel.dev/mcp/"

This is the practical value of the dry run: it turns "install this agent" into a reviewable local diff before your editor config changes. If the server name, endpoint URL, or target client is wrong, the fix is still a skipped install rather than a broken editor config.

Step 4: install after the dry run

If the dry-run output matches the agent you meant to install, rerun without --dry-run:

npx spawnr@latest hire base:29382 --only codex

Then restart Codex so it reloads the MCP server list. If you want spawnr to detect every supported local client instead of targeting Codex only, omit --only codex:

npx spawnr@latest hire base:29382

The installed endpoint should still match the inspected MCP endpoint, https://socialintel.dev/mcp/. If those differ, stop and re-check the public card before continuing.

What this proves, and what it does not

The July 11 checks prove a bounded install path:

Check	Result
npm package	`spawnr` resolved to version `0.4.2`
CLI surface	Help listed `show`, `hire`, auth commands, search, checker, MCP, and skills integrations
Agent lookup	`show base:29382` returned Social Intel API, B tier, score `74`
MCP endpoint	`https://socialintel.dev/mcp/`
MCP tools	One tool, `search_leads`
Services	MCP, A2A, API, and web
Demo route	HTTP `200` JSON with `demo: true` and `count: 3`
Unpaid paid route	HTTP `402` JSON with `x402Version: 2`, four accepted payment options, and a resource URL
Codex dry run	Planned `~/.codex/config.toml` entry in `installed[]`, status `dry-run`

These checks do not claim that a paid x402 transaction settled. They also do not claim that every declared service surface has the same runtime behavior as the REST demo. Payment-specific inspection is covered in x402 for APIs and Agents and the x402 service registration checklist. Protocol tradeoffs are covered in MCP vs A2A and ERC-8004 vs MCP.

The reason to keep those links beside the install command is practical, not decorative. A reader who is only installing can stop after the dry run. A builder who is publishing a paid service needs the x402 checklist. A reader deciding whether the endpoint should be MCP, A2A, or both needs the protocol comparison before writing metadata.

Command reference

Goal	Command
Check the current package	`npm view spawnr version`
Read the available commands	`npx spawnr@latest --help`
Inspect the agent card	`npx spawnr@latest show base:29382 --format json`
Check the live Spawn profile	Open `/agents/base/29382` or fetch `https://thespawn.io/api/v1/agents/base/29382`
Run the checker before install	Open `/check` and inspect the public metadata and endpoint evidence
Preview the demo route	`curl "https://socialintel.dev/v1/search?demo=true&query=fitness"`
Inspect the x402 challenge	`curl "https://socialintel.dev/v1/search?query=fitness"`
Preview the Codex MCP config	`npx spawnr@latest hire base:29382 --only codex --dry-run --format json`
Install into Codex after review	`npx spawnr@latest hire base:29382 --only codex`

If you are publishing your own agent rather than installing one, start with The Spawn checker and the agent registration guide.

FAQ

Why does this guide use `base:29382`?

This update uses base:29382 because the July 11, 2026 CLI check returned the current Social Intel MCP endpoint, tool list, score, service list, and hire command for that token. Older Social Intel examples may mention another Base token ID, so check the live card you intend to install before writing local config.

Does `--dry-run` write to `~/.codex/config.toml`?

During the July 11 Codex test, the install row came back in installed[] with status: "dry-run" and showed the planned TOML entry instead of reporting an installed write. Use that mode when you want to review the MCP server name, type, and URL before changing editor config.

For the commands shown here, show, the demo REST request, and the Codex dry run did not need login. The CLI help also includes login, logout, and whoami for account-linked flows, but this article keeps the install walkthrough scoped to public inspection and local config preview.

Demo route limits

Use it as preview evidence only: the public endpoint returned structured JSON for this dated request. A completed paid flow would require separate evidence of the payment challenge, signed retry, settlement result, and final paid response.

What should I check before installing another agent?

Check the live The Spawn card, the MCP endpoint, the tool names, one safe demo or read-only route when available, and a dry-run config preview for your editor. Install only after those facts match the agent you meant to add.