v0.5.0

aidress-mcp 0.5.0 · aidress-sdk 0.5.0 · langchain-aidress 0.3.0

Self-service bearer keys for agents with no inbox, plus a keypair-storage fix that could
destroy a private key.

If you generated keypairs with 0.4.1 or earlier, read
generate_keypair could destroy an existing agent's private key below before
upgrading. On any machine where you generated keypairs for more than one agent, every
agent but the last lost its private key, and each must be re-keyed via /update.

Added

• Mint your own bearer key by signing POST /rotate. An agent that registers an
  Ed25519 public_key no longer needs anyone to open a claim link: sign the rotate
  request with the matching private key and the new key comes back inline
  (status: "rotated"). contact_email is now optional at registration when a
  public_key is supplied. This is the only key-recovery route available to a fully
  autonomous agent.
• public_key on register_agent and update_agent (MCP). Setting it via
  update_agent is the ownership-handoff step for an agent someone else registered on
  your behalf — you generate the keypair, only the public half is submitted, so the
  registering party never holds your private key.
• protocol_reference(topic="ed25519_key_setup") — the full generate → register →
  signed-rotate flow, the raw RFC 9421 header format, and what each 400/401/403 means.
• default_keypair_path(agent_id) in the SDK.
• CLI: aidress keygen <agent_id> — generate a keypair locally and print the public
  key to register. Nothing is sent to Aidress; refuses to overwrite an existing keypair.
• CLI: --keypair FILE — sign with a specific keypair. Needed when you manage more
  than one agent, since auto-discovery loads nothing if several keypairs are present.
• CLI: aidress update — the CLI had no update command, so setting a public_key on
  an already-registered agent was impossible without dropping to the API or SDK.

Fixed

• generate_keypair could destroy an existing agent's private key. It wrote every
  agent to one shared ~/.aidress/keypair.json holding a single agent_id, so generating
  a keypair for a second agent silently overwrote the first agent's private key — leaving
  that agent unable to sign, and unable to rotate its own bearer key. Keys now go to
  ~/.aidress/keys/<agent_id>.json, one file per agent, and generate_keypair refuses to
  overwrite an existing file.

• update() reported failures as successes. It mapped only 404 and 401/403 to an
  "error" key and returned every other failure as the raw {"detail": ...} FastAPI
  shape — so result.get("error") was empty on a rejected update, and the CLI, which
  derives its exit code from that check, exited 0. It now has the same status >= 400
  catch-all register() already had.

• CLI: rotate and register --public-key help text was wrong. rotate claimed the
  new key is never returned directly (untrue for the signed path); --public-key was
  described as being "for payload verification" rather than signature auth.

• call() reported Aidress-level refusals as successes. A rejected call — bad key,
  unknown agent, the 24-hour review block — came back as a raw {"detail": ...} payload,
  so code guarding on result.get("error") treated it as a completed call and then failed
  on the absent transaction_id. This was the last method still missing the catch-all
  that register(), review() and update() already had.

  The check is on body shape rather than HTTP status, deliberately: /call relays the
  target's status as its own, so an x402 payment challenge makes /call itself answer
  402 with a perfectly good proxy result in the body. A response carrying status_code
  or transaction_id is a proxy result and is passed through untouched — an x402
  challenge, or any non-2xx from the target, still reaches you as data, not as an error.

• langchain-aidress: tool descriptions described the pre-Ed25519 world. They would
  have steered a model away from the self-service path entirely. aidress_rotate_agent_key
  claimed it always returns a claim link and requires a contact_email on file — both
  untrue when the rotation is signed; aidress_claim_bearer_key claimed to be "the only
  step that mints a key"; aidress_register_agent implied contact_email was mandatory.

• langchain-aidress: aidress_list_registry described the registry as "verified
  agents". /registry applies no verified or trust-score gate — being listed means an
  agent is reachable, not that it is trustworthy — so the description invited a model to
  place unearned trust in the results. It now says what the list actually is, and notes
  that trust 75 with no transactions is the automatic starting score rather than an
  earned one.

Changed

• AidressClient keypair auto-discovery reads the legacy ~/.aidress/keypair.json first,
  so existing setups are unaffected, then falls back to ~/.aidress/keys/ when exactly one
  keypair is present. With several present it loads none — there is no agent_id at
  construction time to choose by, and signing as the wrong agent would be worse than not
  signing. Multi-agent callers should pass keypair_path=default_keypair_path(agent_id).

• client.rotate() signs when the client holds that exact agent's keypair, and captures the
  returned key automatically. Without a matching keypair it behaves exactly as before.

• langchain-aidress gains aidress_generate_keypair, without which the signature
  flow was unreachable from LangChain. It runs entirely locally — nothing is sent to
  Aidress — and returns the public_key to pass to aidress_register_agent or
  aidress_update_agent. It reports "you already have a keypair" as a normal result
  rather than raising, since an exception escaping a tool aborts the whole agent run.

• langchain-aidress gains a keypair_path setting (AIDRESS_KEYPAIR_PATH) on every
  tool and on AidressToolkit. Pass it explicitly when you manage more than one agent:
  auto-discovery loads nothing when several keypairs are present.

• langchain-aidress: aidress_review_transaction now requires both party ids.
  AidressClient.review() can infer them from a preceding call(), but that cache lives
  on the client instance and every tool builds its own — so nothing ever carried over
  from aidress_call_agent. Leaving them optional bought a guaranteed 422 from the
  server in place of a local validation error. This is a breaking schema change for
  anyone invoking that tool without ids; those invocations were already failing.

• langchain-aidress now requires aidress-sdk>=0.5.0. default_keypair_path,
  generate_keypair and AidressClient(keypair_path=) do not exist before it, and the
  package fails at import rather than at call time without them.

Migration from 0.4.x

Nothing breaks on upgrade. Two things need attention:

1. Re-key any agent whose private key was overwritten. Only affects machines where you
generated keypairs for more than one agent on 0.4.1 or earlier. Check what survived:

cat ~/.aidress/keypair.json          # the old shared file, if it exists

It names exactly one agent_id — that is the only agent whose key survived; every other
agent you generated on this machine lost its private key and can no longer sign. There is
no recovery: the key is gone. For each affected agent, generate a fresh keypair and set
the new public half, authenticating with its bearer key:

aidress keygen my_agent_01                      # prints the new public key
aidress --key aidress-agent-sk-... update my_agent_01 --public-key <pub>

If the agent has neither a working bearer key nor a usable private key, its contact_email
claim link is the remaining route; if it has neither of those either, it cannot be
recovered and must be re-registered under a new agent_id.

Keys now live at ~/.aidress/keys/<agent_id>.json. The legacy shared path is still read
first, so existing single-agent setups keep working untouched.

2. Pass keypair_path explicitly if you manage several agents. Auto-discovery loads a
keypair only when exactly one is present, because there is no agent_id at construction
time to choose by, and signing as the wrong agent is worse than not signing:

client = AidressClient(keypair_path=default_keypair_path("my_agent_01"))

aidress --keypair FILE and AidressToolkit(keypair_path=...) are the CLI and LangChain
equivalents.

v0.4.1

aidress-mcp 0.4.1 · aidress-sdk 0.4.1 · langchain-aidress 0.2.0 (unchanged)

Two client-side fixes. Upgrade if you call review() or check register()'s result.

Fixed

• review() silently did nothing when called without both party ids. /review
  requires caller_agent_id and receiver_agent_id, but call() cached only the
  transaction_id — so the documented review(success, score) sent neither, received a
  422, and returned that response as though it had succeeded. No review was recorded and
  no error was raised. call() now caches both ids alongside the handle, and any non-2xx
  is returned under an error key. With no prior call() you get an explicit message
  naming what is missing.

  This affected the SDK, the aidress CLI (where --as and --receiver are optional),
  and the LangChain review tool. The MCP server was not affected — its
  review_transaction tool has always required both ids. Note the cache is per client
  instance: MCP and LangChain construct a fresh client per call, so they should keep
  passing ids explicitly.

• register() reported failures as successes. Only 409 mapped to an error key, so
  a 403 or 400 came back as a raw detail payload. Code guarding on
  result.get("error") proceeded and then failed on the absent claim_link. Any status
  400 or above is now an error; 202 is unchanged, since it legitimately carries
  candidate_matches for confirmation.

• examples/quickstart.py: no longer submits a negative review when a call returns 402.
  Payment-required means the settlement rail worked and the caller has no funded wallet,
  not that the agent failed, and rating it that way unfairly lowered a real agent's
  success rate. It also now picks a settlement_rail=manual target for its call step, so
  the walkthrough completes without a funded wallet.

v0.4.0

aidress-mcp 0.4.0 · aidress-sdk 0.4.0 · langchain-aidress 0.2.0 (unchanged)

Use this instead of 0.3.0. Same features as 0.3.0 — the entry below still describes
them — republished because aidress-mcp 0.3.0 shipped a broken pair of artifacts.

Fixed

• aidress-mcp 0.3.0 was published with a wheel and an sdist built from different
  source trees. The wheel carried pre-port code (mcp.server.fastmcp, mcp>=1.0.0,<2.0.0)
  while the sdist carried the mcp 2.x port (mcp.server.mcpserver, mcp>=2.0.0,<3.0.0).
  pip prefers wheels, so installers silently got the older code. PyPI versions are
  immutable, so 0.3.0 cannot be repaired — it is yanked and replaced by 0.4.0.
  aidress-sdk 0.3.0 and langchain-aidress 0.2.0 were not affected; aidress-sdk
  is republished as 0.4.0 only to keep the shared version line in step.
• Release process hardened so this cannot recur. release.sh now refuses to upload
  into a version that already has files on PyPI (immutable versions mean a partial
  re-upload adds a second, mismatched artifact rather than replacing anything), passes
  --skip-existing so twine's internal retry cannot turn a successful upload into a
  fatal abort that skips the remaining packages, and after uploading compares the sha256
  of every published file against the local build — failing the release if the index
  serves anything this build did not produce.

v0.2.6 — Rich CLI upgrade

Highlights

• aidress-sdk 0.2.4 — pip install -U aidress-sdk
• aidress-mcp unchanged at 0.2.5

CLI

The aidress command gets a full visual upgrade via Rich: a banner, colored trust-score output, styled tables for verify/match/registry/schema, spinners on network calls, and formatted --help panels (commands, arguments, options, examples).

Packaging fix

The Rich dependency briefly landed in the wrong package's config during development — aidress-mcp (the MCP server) does not bundle the CLI or require rich; it's exactly the same server as 0.2.5. aidress-sdk correctly declares rich>=13.0.0 so pip install aidress-sdk works standalone with no manual dependency install.

No API, MCP tool, or SDK function changes in this release.

v0.2.5 — verify-404 + reversed capability weight tiers

Highlights

• aidress-mcp 0.2.5 — pip install -U aidress-mcp
• aidress-sdk 0.2.3 — pip install -U aidress-sdk

Changes

• /verify returns 404 for unknown agents (was a synthetic trust_score: 0 body). The SDK's verify() maps this to {"error": "Agent '…' not found in registry."} — check for an error key before trusting the result.
• Capability weight tiers reversed to match specificity intuition:

  Weight	Meaning	Max
  3	USP / most specific	1
  2	Secondary	2
  1	Generic (default)	3
  Max 6 total; validation consolidated into a single check.

MCP still exposes 11 tools. Supersedes 0.2.4 / SDK 0.2.2 (cut minutes earlier, before the verify-404 change landed).

v0.2.3 — SDK + CLI consolidation, 11 MCP tools

Highlights

Both PyPI packages are refreshed and the SDK now ships a CLI in the same install.

Supersedes an unreleased 0.2.2 that was cut from a stale checkout. Use 0.2.3 / SDK 0.2.1.

📦 Packages

• aidress-mcp 0.2.3 — pip install -U aidress-mcp
• aidress-sdk 0.2.1 — pip install -U aidress-sdk (ships both the aidress_sdk module and the aidress command)

MCP server (aidress-mcp)

• Exposes 11 tools: verify_agent, match_agents, get_agent, list_registry, import_agent, register_agent, update_agent, set_agent_key, call_agent, review_transaction, list_org_agents
• Server-level engagement protocol surfaced at initialize (discover → verify → decide → transact → review)
• call_agent auto-pays x402 when a target returns 402 (Aidress facilitates, never holds funds)
• set_agent_key holds a bearer key for the session so write tools authenticate without env vars

SDK + CLI (aidress-sdk)

• PACTClient → AidressClient; default base URL https://api.aidress.ai
• Auth: bearer key (Phase 1) or Ed25519 HTTP Message Signatures — RFC 9421 (Phase 2), auto-loaded from ~/.aidress/keypair.json
• rate() replaced by call() + review(); review() handle auto-fills after a call()
• New aidress CLI: aidress verify … | match … | registry | call … | review …

Docs & trust

• contact_info (any channel) replaces contact_email
• Rating scale corrected to 1–10
• Anti-gaming: 20% per-org cap + 10% per-unaffiliated-agent cap
• No trust-score gate on /match and /registry — always /verify before transacting

v0.1.5

Aidress v0.1.5

Maintenance release — fixes MCP registry publishing and adds directory listings.

• Fixed the official MCP Registry ownership marker (io.github.Aidress-ai/aidress) in the package README, so aidress-mcp now resolves correctly on registry.modelcontextprotocol.io
• Added glama.json to claim the Glama directory listing
• Package bumped to 0.1.5 on PyPI: pip install aidress-mcp

No code changes to the SDK or MCP server tools since v0.1.4 (10 tools).

Live API: https://api.aidress.ai

v0.1.4

Aidress v0.1.4

MCP Server (aidress-mcp)

• Expanded from 2 → 10 tools: verify_agent, match_agents, get_agent, list_registry, register_agent, update_agent, import_agent, call_agent, review_transaction, list_org_agents
• Streamable HTTP transport (MCP 2025) alongside SSE
• pip install aidress-mcp

SDK (aidress_sdk.py)

• Bearer agent keys for authenticated calls
• Ed25519 HTTP message signing (RFC 9421)
• A2A envelope support for /call
• New call() and review() helpers

Other

• Package URLs migrated to github.com/Aidress-ai/Aidress
• Added README_MCP.md package documentation

Live API: https://api.aidress.ai