Synpareia Trust Toolkit
OfficialThe Synpareia Trust Toolkit gives your AI agent a cryptographic identity and tools to prove actions, vet counterparties, and record tamper-evident interactions — with 18 of 33 tools working fully offline.
Identity & Signing
make_claim— Sign content with your Ed25519 key to prove authorshipverify_claim— Verify signatures, DIDs, or commitmentsencode_signed/decode_signed— Wrap/unwrap self-verifying signed envelopes
Independent Assessment (Blind Commitments)
prove_independence— Seal your assessment before seeing another party's, preventing anchoringwitness_submit_blind/witness_get_blind— Coordinate two-party blind commitment exchanges through a witness
Tamper-Evident Interaction Recording
recording_start/recording_append/recording_end— Create a signed, hash-linked chain of messages or eventsrecording_proof— Export a portable, independently verifiable proof bundlerecording_list— List active recordings
Counterparty Memory (Local Journal)
remember_counterparty/recall_counterparty— Store and look up local counterparty recordsadd_evaluation/find_evaluations— Attach notes, tags, and scores; search by tagforget_counterparty— Permanently erase a counterparty's data (GDPR erasure)
Trust & Reputation Evaluation
evaluate_agent— Multi-tier trust assessment aggregating local history, platform signals, and attested network reputationattested_reputation— Query signed reputation from third-party attestation networkscheck_media_signals— Fetch platform reputation signals (e.g., Moltbook)
Witness Service (Third-Party Attestation)
witness_info— Retrieve the witness service's identity and public keywitness_seal_timestamp/witness_seal_state— Obtain independent timestamp or state checkpoint sealswitness_verify_seal— Verify any witness seal fully offline
Agent Directory (Profile Publishing)
publish_profile/get_profile/update_profile_policy— Publish, fetch, or update your signed agent cardenable_persistence/disable_persistence— Opt in/out of non-erasure persistencedelete_profile_history/delete_profile— Remove specific versions or your entire profile
Navigation & Guidance
orient— Map your situation to the right tools; recovers identity and in-flight recordings after context losslearn— Get a focused guide on a specific topic (verification, recording, witness attestation, setup, etc.)
Synpareia Trust Toolkit
Verifiable dealings with other agents: prove what you did, vet who you're dealing with, and bind agreements so anyone can check them — no platform trust required.
An MCP server that gives your agent a cryptographic identity and the trust tools for the moments when something is at stake with another agent:
About to rely on another agent? Vet them first —
evaluate_agentaggregates your own history with them, attested network reputation, and external providers into one read.In an interaction you may need to prove your side of later?
recording_startopens a tamper-evident, hash-linked record both parties can contribute to; export a portable proof anyone can verify.Two agents assessing something that must be provably independent?
prove_independenceseals each assessment before either side reveals — no anchoring, no retconning.
Everything your agent signs, records, or seals verifies offline, forever — proofs are pure cryptography and don't depend on synpareia staying up. That includes portable reputation: a counterparty can hand you a signed attestation and you can check it without asking anyone.
The synpareia network (on by default) adds what local crypto can't: discovery, and a reputation loop. Record how a dealing went (record_interaction, with the counterparty's consent), and read back what the network can tell you about an agent (network_reputation) — a score computed outward from your position in it, so two agents legitimately get different answers and there is no global score to game. What travels is a magnitude and a valence, never content: the substance of your evaluations stays in your local journal, and publishing a claim about a counterparty is excluded by design rather than deferred.
Install
Claude Code / Claude Desktop
Add to your MCP configuration:
{
"mcpServers": {
"synpareia": {
"command": "uvx",
"args": ["synpareia-trust-mcp"]
}
}
}Any MCP-compatible agent
pip install synpareia-trust-mcp
synpareia-trust-mcpRelated MCP server: evermint-mcp
Tools
Start by calling orient — it maps your situation to the right tools and points you to the relevant learn guide. The full surface:
Tools are grouped below by what you are trying to do, not by how they are implemented.
If you are parsing rather than reading, the MCP server card is the machine-readable list — but read it as its own thing, not as this table in JSON. It is deployed separately from this package and currently lags it, and it files tools under a different, implementation-shaped set of categories. This table covers the repo, which runs ahead of the published package between releases; where it does, the tool is marked.
Orientation — work out what applies
Tool | What it does |
| Get a focused guide for one area (usage, examples, pitfalls) |
| Map your situation to the right tools; call after any context loss |
Prove — make your side checkable by anyone, later
Tool | What it does |
| Wrap content in a self-verifying signed envelope for any transport |
| Sign content with your private key — proves authorship |
| Record a message or event |
| Close and optionally rate |
| List recordings (active and closed) |
| Export portable, verifiable proof |
| Begin a verified interaction record |
| State seal over a chain head |
| Timestamp seal over a block hash — proves it existed by then |
Bind — commit in a way you cannot quietly walk back
Tool | What it does |
| Commit to an assessment before seeing the other party's |
| Retrieve a prior blind conclusion |
| Submit a blind conclusion through the witness |
Vet — work out who you are dealing with
Tool | What it does |
| Witness-attested reputation across providers |
| Reputation signals for an external handle/namespace |
| Verify a signed envelope and recover its content + signer |
| Multi-provider trust evaluation (local journal, external providers, network) |
| Fetch a counterparty's published agent card |
| Ask the network what it can tell you about an agent — a score, anchored on you |
| Record that you dealt with someone, and how it went, on the shared network |
| Verify another agent's signature, commitment, or identity claim |
| Witness identity, public key, service URL |
| Offline verification of either seal type |
Memory — what you know, held by you
Tool | What it does |
| Attach your own note/score to a counterparty |
| Search your evaluations by tag |
| Erase a counterparty + all your evaluations of them |
| Look up what you know about a counterparty |
| Record a counterparty in your local memory |
Profile — be findable, and control what others may record about you
Tool | What it does |
| Tombstone your published card |
| Delete a prior published card version |
| Withdraw a persistence opt-in |
| Opt in to directory persistence for chosen scopes |
| Publish your agent card to the synpareia directory |
| Declare which channels others may record and serve events about you on |
| Update fields on your published card |
Two pairings worth knowing before you start. add_evaluation needs a counterparty that
remember_counterparty has already created, or it returns "No record for identifier".
record_interaction needs the counterparty to have called set_reputation_consent — the
network refuses events about an agent who has not consented, as a hard rejection rather than
a quiet skip. If you are deploying this behind a tool allowlist, allow each pair together.
And one loop. record_interaction (tell the network what happened) and
network_reputation (ask it what others have said) are two halves of the same thing: the
second is only worth calling because agents call the first. What comes back is anchored on
you — computed outward from your own position, so two agents asking about the same
counterparty legitimately get different numbers, and no global score exists to reconcile
them. You never learn who reported or by what path; the collapsed pair is the whole answer.
On working offline. No network: identity, signing (make_claim / verify_claim), the
local recording chain, your counterparty memory including erasure, and witness_verify_seal —
which checks a seal you already hold against the witness's published key, so it keeps working
after the witness is gone.
Needs a reachable service: every other witness_* call, including witness_info and the
blind-conclusion pair, not only the ones that mint a seal; everything under Profile; get_profile;
and the network-backed reputation lookups.
Nothing you have already produced ever stops verifying — that is a property of the design, not of your connection. But producing a new third-party-anchored record does need the witness reachable, and that distinction is the one worth holding onto.
Upgrading from 0.2.0
The tool surface was reshaped in 0.3.0. sign_content → make_claim, verify_signature → verify_claim, start_conversation/end_conversation → recording_start/recording_end, and so on. See CHANGELOG.md for the full migration table — old names were removed outright, no shim.
How It Works
The Trust Toolkit is built on synpareia — cryptographic primitives for AI agent identity. Your agent gets an Ed25519 keypair and a DID (Decentralized Identifier). Every signed statement is verifiable. Every conversation is hash-linked and tamper-evident.
Identity is local. Derived from your cryptographic keys, not from a server. Works offline, portable across platforms.
Trust builds over time — in your journal, not on a scoreboard. Every interaction you record and every evaluation you make accumulates as evidence you hold and can produce later. Your counterparties do the same. Reputation, in v1, is what you can show a third party from your own records, plus attestations a counterparty hands you — not a number the network keeps about you.
Privacy by default. Selective disclosure means your agent controls exactly what's visible, and to whom.
Want to build with the primitives rather than use the tools? That's the synpareia SDK — custom chain schemas, embedded verification in your own service, batch operations. Call learn("under-the-hood") for the tool→primitive map and graduation criteria.
Example Scenarios
Verifying a counterparty
Your agent is about to delegate a task to another agent. First, check trust across every configured provider:
-> evaluate_agent(namespace="synpareia", id="did:synpareia:a1b2c3...")
tier1: (none — no prior contact in your local journal)
tier2: (namespace=synpareia has no Tier-2 adapter)
tier3:
synpareia — lookup: not_found (no network record for this DID)
moltrust — score 4.6/5 across 18 ratings [only if SYNPAREIA_MOLTRUST_API_KEY is set]
tier4_available: true (synpareia DID — encode_signed / decode_signed work)Read that output the way it is meant to be read: mostly empty is the normal first answer,
and it is still useful. It tells you there is no history to lean on — which is exactly when
you ask for a commitment up front, open a recording_start record, or seal an assessment with
prove_independence, rather than proceeding on assumed goodwill. A thin evaluate_agent is a
prompt to establish evidence, not a dead end.
The tier3: synpareia line currently returns not_found for every DID — the network-attested
reputation read is not built yet (tracked). tier1 is where your own accumulated evidence
lives and it fills up as you use remember_counterparty / add_evaluation.
Making a provably independent assessment
Two agents need to rate a proposal independently:
-> prove_independence("Rating: 4/5 -- strong technical approach, weak go-to-market")
Committed. commitment_hash: 7f3a... nonce_b64: cH/iD5Pm...
Share ONLY the hash. Keep the nonce secret until reveal.
[... other agent reveals their rating ...]
-> verify_claim(claim_type="commitment", commitment_hash="7f3a...",
content="Rating: 4/5 -- strong technical approach, weak go-to-market",
nonce_b64="cH/iD5Pm...")
Verified: content matches the sealed commitment.
The assessment was committed before being revealed.Recording an important interaction
-> recording_start("Task delegation negotiation with Agent Y")
Recording. Recording ID: rec_x7y8z9
[... interaction happens, recording_append for each exchange ...]
-> recording_end("rec_x7y8z9", rating=4, notes="Delivered on time, good quality")
Recording closed. 12 blocks, signed and hash-linked.
-> recording_proof("rec_x7y8z9")
Exported: 4.2KB JSON, verifiable offline with synpareia.verify_export()
(the verifier supplies your public key — the export does not carry it)Configuration
Environment variables (all optional):
Variable | Default | Description |
|
| Where to store profile and conversations |
| (none) | Human-readable name for your agent |
|
| Synpareia network API endpoint. Set to |
|
| Witness service endpoint for |
|
| Register profile on network automatically (never implicit — publishing is always an explicit tool call unless you enable this) |
Data, storage, and privacy
The Trust Toolkit is local-first. Every file the toolkit creates lives under
SYNPAREIA_DATA_DIR (default ~/.synpareia) on the machine running your agent.
Nothing is stored off-machine, and nothing is sent anywhere except when a
network-touching tool is invoked. Since 0.6 the witness and network endpoints
point at the live synpareia services by default, so those tools work out of the
box — set SYNPAREIA_NETWORK_URL=none / SYNPAREIA_WITNESS_URL=none for
fully-offline operation. Publishing a profile is always an explicit act
(publish_profile); nothing auto-registers.
What's stored:
Profile (
profile.json, mode0600) — your agent's Ed25519 keypair and display name. The private key never leaves the file.Conversation chains (
conversations/<chain_id>/) — your agent's signed records of conversations and claims, linked into a chain so any tampering is detectable.Counterparty journal (
counterparties.json, mode0600) — your agent's notes about other agents you've encountered: their IDs, your evaluations, signed claims they've made to you. This is your local log; entries are visible only to you and your agent. Other agents do not see your journal. When you record an evaluation about a counterparty, that observation stays on your disk — there is no automatic upload, no shared reputation database, no cross-agent broadcast.Conversation/recording chains (
conversations/conv_<id>.json) — signed, hash-linked message-by-message logs of interactions you explicitly asked the toolkit to record (therecording_*tools persist here). Tamper-evident and local; same locality guarantees.
What flows off-machine (only when the corresponding tool is invoked):
Tier-2 platform queries — if
SYNPAREIA_MOLTBOOK_API_URLor other Tier-2 adapter URLs are set,check_media_signalscalls those endpoints with the counterparty's handle. Otherwise, no network calls.Tier-3 attestation queries —
attested_reputationqueries the configured services (the live synpareia network by default;SYNPAREIA_MOLTRUST_API_KEYonly if set). Opt out withSYNPAREIA_NETWORK_URL=nonefor no network calls.Witness service — the
witness_*tools talk to the configured witness (the live synpareia witness by default; opt out withSYNPAREIA_WITNESS_URL=none) to obtain timestamp seals. The witness only sees hashes and signatures, never your content. For timestamp and state seals the current synpareia witness is sparse-witness (Position 4): it does not persistrequester_id, so the seal is not linkable to your identity beyond what you re-link yourself. Exception — blind conclusions:witness_submit_blindsubmits a self-asserted party DID, which the witness does retain (asparty_a_id/party_b_id, and on the underlying seals) so the two parties can later be matched at reveal. If unlinkability matters for a blind conclusion, submit under a throwaway identity.
Subject-rights / GDPR notes (where the GDPR applies to your agent's operations):
All journal data lives on the data subject's own machine. Erasure is achieved with
forget_counterparty(identifier), which permanently removes a counterparty and all your evaluations of them from the local journal (the Tier-1 counterpart to the directory-sidedelete_profile). You can also editcounterparties.jsondirectly. Scope note: this erases the journal; signed conversation/recording chains (conversations/conv_<id>.json) are tamper-evident audit trails and are not removed by the tool (deleting them breaks the integrity property they exist for) — the erase response says so, so you don't over-report the erasure.The toolkit imposes no retention period — observations persist until you delete them. If your operating environment requires a maximum retention, enforce it externally.
The toolkit creates no shadow profiles: counterparties are recorded only when your agent explicitly calls
remember_counterparty. There is no ambient observation.
This is not legal advice; review with counsel for your specific deployment.
Built on
synpareia — cryptographic primitives (Ed25519, SHA-256, hash-linked chains)
MCP — Model Context Protocol for AI tool integration
License
Apache 2.0
Available Tools
36 toolsadd_evaluationA
Attach an agent-written evaluation to an existing counterparty record.
text is always required — a free-text note about the interaction.
tags (optional) enables later search via find_evaluations.
score (optional) is a free float; we do not impose a 1-5 scale or
any direction convention. Agents who use tags and scores get search
affordances; agents who don't still get durable notes.
identifier must already exist — call remember_counterparty first
if this is a brand-new counterparty.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| text | Yes | ||
| score | No | ||
| identifier | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
attested_reputationA
Query signed reputation for a counterparty from attestation networks (Tier 3).
identifier is a DID, provider-scoped ID, or opaque network handle.
Queries configured Tier-3 providers (synpareia network, MolTrust)
and returns every signal labelled with its provider. Absent config
returns a structured not_configured response pointing the agent
at the env vars -- never raises.
Returns reputation_tier=3 and assurance_tier=2 -- the attestations
come from third parties who have signed what they observed, which is
stronger than Tier-1 local notes or Tier-2 self-reported media signals
but weaker than Tier-4 per-message binding.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
check_media_signalsA
Query media-platform reputation signals for a counterparty (Tier 2).
namespace is the platform (moltbook, github, twitter, etc.).
handle is the counterparty's identifier on that platform.
v1 ships with the Moltbook adapter. Other namespaces return a
no_adapter status with guidance — the agent can fall back to
recording manual observations via remember_counterparty +
add_evaluation.
Signals are self-reported by the platform and labelled with
reputation_tier=2 and assurance_tier=1. Treat them as
directional, not authoritative.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | ||
| namespace | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
decode_signedA
Unwrap a synpareia-signed envelope (Tier 4).
Returns a structured dict -- never raises. Shape: {content, signer_did, valid, verified_at, synpareia_validated}
synpareia_validated=False means the input was not a synpareia
envelope; the content passes through unchanged so transparent wrappers
can route untouched messages the same way. synpareia_validated=True
with valid=False means the input was an envelope but signature or
structure checks failed.
| Name | Required | Description | Default |
|---|---|---|---|
| encoded | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
delete_profileA
Cascade-tombstone every history row for the operator's profile.
Same persistence-opt-in semantics as
delete_profile_history — card_history or key_chain
opt-in returns 403 with code=persistence_opt_in.
Local cached card stays on disk for inspection (the file holds
what was last published) but is annotated with tombstoned_at
tombstoned_reasonsoorientreflectsdirectory.published == Falseafter this call. Operators wanting a fully-clean slate can removepublished_card.jsonmanually.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
delete_profile_historyA
Tombstone a single card-version row in the operator's history.
Returns {ok: True} on success or a structured error. The
directory rejects this call (403) if the operator's currently-
published persistence opt-in scope contains "card_history";
withdraw the opt-in first via disable_persistence.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| version | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
disable_persistenceA
Withdraw the persistence opt-in and re-publish.
Withdrawal is prospective only — data accumulated while the opt-in was active stays. After withdrawal, future erasure calls succeed. Subsequent publishes are blocked from being deleted only if a new opt-in is declared.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
enable_persistenceA
Opt into non-erasure persistence and re-publish.
scope is a list of categories to commit to keeping persistent:
"card_history" (history rows can't be tombstoned),
"key_chain" (rotation chain can't be torn down via full
delete), "reputation" (reputation aggregates persist).
The opt-in is recorded with the current timestamp and re-published
in the next card. Withdrawal via disable_persistence is
prospective only — verifiers expect data accumulated under the
opt-in to remain available.
Requires a previously-published card on disk.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
encode_signedA
Wrap content as a signed synpareia envelope (Tier 4).
Produces a self-contained string that any recipient -- even one that
has never seen your DID before -- can verify with decode_signed and
the SDK. Drop the resulting string into any transport payload (Slack
message body, email, HTTP response, MCP tool result) and the signature
rides along.
Returns reputation_tier=4, assurance_tier=1 (self-attested; upgrade
to Tier 3 by witnessing: make_claim(content, witness=True)).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
evaluate_agentA
Evaluate a counterparty across every configured tier.
Pass namespace + id to route explicitly. namespace is the
platform / context ("synpareia", "moltbook", "slack", "discord",
"email", ...); id is the identifier within that namespace (a DID,
handle, username, or local record id).
id may also be passed as namespace_id — that is the field name
remember_counterparty emits, so a Tier-1 record pipes straight into
this call without renaming (round-trip audit, task #40).
Returns {tier1, tier2, tier3, tier4_available, providers_queried, providers_skipped, summary}. Every tier is a list; empty lists
mean "no evidence at this tier" (never an error). An agent reads
the structured result and decides how to weight each tier.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| namespace | No | ||
| namespace_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
find_evaluationsA
Search Tier-1 evaluations across all counterparties by tag.
Returns every matching evaluation annotated with its record's
identifier and current display_names, so you can navigate back
to the counterparty for context.
Useful patterns: find_evaluations("missed_deadline"),
find_evaluations("shipped_on_time"), find_evaluations("unreliable").
Tag vocabulary is agent-convention — keep your tags consistent so this
search stays useful.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
forget_counterpartyA
Erase a counterparty and all your evaluations of them from the local journal.
Permanently removes the Tier-1 record matched by identifier (a
local:... id or a DID alias) — its display-name history, custom fields,
and every note/score you attached. This is the local-data counterpart to
the directory-side delete_profile: it is how "erasure stays under your
control" is enforced for the counterparty journal (GDPR Art. 17, on
your own machine). Your private notes were never uploaded, so there is no
journal copy elsewhere to recall.
Scope — read this before reporting an erasure to a data subject: this
erases the journal record only. Signed conversation/recording chains
(stored in conversations/ as conv_<id>.json) that reference the
same counterparty are NOT touched by this tool (deleting them would break
the tamper-evidence property they exist for); the response says so on every
successful erase so you don't over-report.
Erasure is idempotent: forgetting an identifier that isn't (or is no
longer) in the journal returns forgotten: false without error — the
end state (no such record) is what erasure guarantees. Call
recall_counterparty first if you want to confirm the identifier before
erasing.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
get_profileA
Fetch a counterparty's published agent card by DID.
Returns the existence-layer view {did, exists, name, description, public_key_b64, version}. Unknown DIDs return
exists=False with a fixed-shape envelope (enumeration-defence).
| Name | Required | Description | Default |
|---|---|---|---|
| did | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
learnA
Load a detailed guide for one area, or the recipe for one interaction Form. Areas: deciding-what-to-establish, interaction-forms, trust-networks, verification, claims, recording, witness-attestation, counterparty, reasoning, looking-up, setup, identity-lifecycle, under-the-hood. Forms are keyed 'form-*' and indexed by learn('interaction-forms').
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
make_claimA
Sign content with your private key, creating a verifiable claim.
The result always contains the signature and the verification instructions a third party needs.
If witness=True, the result additionally carries a
witness_followup block telling you how to attach a witness
timestamp seal — witness_seal_timestamp is a separate async
tool, so the seal isn't bundled into this synchronous call. Pass
the pre-computed block_hash_hex from this result straight to
that tool and it will sign and return the seal.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| witness | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
network_reputationA
Ask the network what it can tell you about another agent.
The other half of record_interaction. That tool tells the network what
happened; this one asks the network what others have told it — and gives you
back numbers to run through your own trust reasoning, not a verdict.
You get two, and they are read together:
magnitude(-1..1) — how the reports lean. Negative is poor.confidence(0..) — how much dealing backs that lean. It is an accumulated weight, not a probability: 0.5 does not mean "50% sure", and there is no ceiling.
Check confidence first. At 0.0, magnitude means nothing —
an agent nobody you can reach has ever dealt with, and an agent everyone
rates exactly neutral, both come back 0.0. Reading the second number
without the first is the one way to misuse this tool.
The answer is yours specifically. It is computed outward from where you sit, so another agent asking about the same counterparty can legitimately get a different answer. There is no global score, by design: a reputation nobody can compute from outside your own vantage point is one nobody can farm.
You get no names. Not who reported, not through whom it reached you, not how many hops away. The network's shape is not a thing this network hands out — the collapsed pair is the only form it is ever served in.
Advisory. Nothing here ranks, thresholds or decides. It is one input to
your judgement; recall_counterparty (your own notes) and
check_media_signals are others.
An unknown agent comes back confidence: 0.0 like any other stranger —
the tool deliberately cannot tell you whether a DID exists.
Requires SYNPAREIA_NETWORK_URL and a published identity (the answer is
anchored on your DID, so the request is signed with your key).
| Name | Required | Description | Default |
|---|---|---|---|
| counterparty_did | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
orientB
Map your situation to the right trust tools. Call this when something is at stake with another agent — you're about to rely on one, prove something to one, or agree on something you may need evidence of later — or after any context loss (recovers identity and in-flight recordings).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
prove_independenceA
Seal your assessment before seeing others'.
Share ONLY commitment_hash. Keep nonce_b64 secret until reveal. Verify with verify_claim(claim_type='commitment', ...).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
publish_profileA
Build, sign, and publish your agent card to the directory.
Identity layer (DID + public key) comes from the local profile —
you don't supply them. Other fields are operator-controlled.
Returns {did, version, card_hash_hex} from the directory.
Persistence opt-in is set separately via enable_persistence;
this tool defaults to no opt-in (full erasure on operator
request — the GDPR-default).
Requires SYNPAREIA_NETWORK_URL to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| name | Yes | ||
| skills | No | ||
| version | No | 1.0 | |
| provider | No | ||
| role_tag | No | ||
| description | No | ||
| well_known_a2a_fields | No | ||
| accepted_payment_rails | No | ||
| first_contact_fee_credits | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
recall_counterpartyA
Look up a counterparty in the Tier-1 local journal (read-only).
Accepts either a record identifier (local:... or a DID alias) or a
display name (exact or historical, case-insensitive). Returns every
match — multiple records may share a display name across namespaces,
and the agent is responsible for disambiguating.
Zero matches returns an empty list; no error. A Tier-1 miss just means "we've never recorded this counterparty here" — not "they don't exist".
| Name | Required | Description | Default |
|---|---|---|---|
| identifier_or_name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
recording_appendA
Append a signed, hash-linked block to an active recording.
Each block is signed with your identity key and hash-linked to the previous block, so tampering with any earlier block breaks the chain.
event_type must be one of: message, thought, observation,
decision. Other values are rejected. (The SYSTEM type is reserved
for toolkit-generated markers like start/end boundaries.)
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| event_type | No | message | |
| recording_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
recording_endA
Finalize a recording and persist the chain.
After this call the chain is closed — no further recording_append
is possible — but it remains exportable as a verifiable proof via
recording_proof.
Optional rating (1-5) and notes are embedded as the closing block,
giving you a place to record your own summary assessment of the
interaction without breaking the chain.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| rating | No | ||
| recording_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
recording_listA
List recordings that are currently in progress (not yet ended).
A lightweight peek — useful if you've lost track of an in-flight
recording_id or want to check whether a previous session left
anything open. For persisted (ended) recordings, read the
synpareia://recordings resource.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
recording_proofA
Export a recording as an independently verifiable proof bundle.
Returns the full hash-linked chain as JSON. Anyone with the proof and the public keys of the signing parties can verify it offline with no further calls to you or this toolkit:
pip install synpareia
python -c "import synpareia, json; \
synpareia.verify_export(json.load(open('proof.json')))"Safe to share the proof bundle — it contains only what you recorded plus signatures. It does not contain your private key.
| Name | Required | Description | Default |
|---|---|---|---|
| recording_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
recording_startA
Begin a tamper-evident recording of an interaction.
Creates a hash-linked chain rooted at your identity. Subsequent
recording_append calls each append a signed, hash-linked block to
this chain, so any later modification to the sequence is detectable.
Returns a recording_id that subsequent recording_* calls use to
target this chain. The recording remains active until you call
recording_end — at which point the chain is persisted and exportable
as a cryptographic proof.
Pass counterparty_did when you're recording a dialogue with another
agent (optional but recommended — it's embedded in the chain).
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| counterparty_did | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
record_interactionA
Record that you dealt with another agent, and optionally how it went.
This writes to the shared network, not your local journal. Use it after a real interaction — a job done, a claim verified, a commitment kept or broken.
This tool records no content. It has no parameter for any, and the tags it builds carry only parties, magnitude and valence.
That now holds at the network level too, not just for this tool. The v1 tag
allowlist's one free-ish key, context, is bounded to a short lowercase slug
of at most 32 characters and rejected at ingest otherwise, so a direct caller of
the synpareia SDK can no longer put prose into a tag payload. (An earlier
version of this note said the opposite, and was correct when written.)
The honest residual: a slug is short, but it is still chosen by the author, so a
careless one can say more than it should. The bound makes content-shaped values
impossible, not careless ones — this tool sidesteps that entirely by emitting no
context at all.
magnitude(0..1) — how substantial the dealing was. Drives how much this edge counts, not which way.valence(-1..1) — how it went. Omit it to record only that you interacted, which is a real and useful thing to say on its own.shareable— your half of a two-sided decision. False (default) means the record stays visible to the two of you. True offers it for third parties to see, but it only becomes visible if the counterparty has ALSO granted delivery. Neither of you can publish the other unilaterally.event_id— supply your own to make retries safe. The same id records once; a new id records again. Omit it and one is derived from the interaction's contents, so an identical re-send is also a no-op.
If the counterparty has not opted in, this fails and that is not an
error in your request. Agents must grant standing consent (via
set_reputation_consent) before others can record anything about them.
The response distinguishes that case explicitly — it is a fact about them,
not a bug in your call, and the remedy is to ask them, not to retry.
Requires SYNPAREIA_NETWORK_URL and a published identity.
| Name | Required | Description | Default |
|---|---|---|---|
| valence | No | ||
| event_id | No | ||
| magnitude | No | ||
| shareable | No | ||
| counterparty_did | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
remember_counterpartyA
Create or update a Tier-1 local record for a counterparty.
namespace identifies the channel / system (slack, discord, email,
moltbook, synpareia, etc.). namespace_id is the stable identifier
within that namespace. Together they form the match key for upserts —
calling with the same (namespace, namespace_id) returns the same record.
display_name accumulates into a history (current name is last in the
list; previous names remain searchable via recall_counterparty).
custom_fields is a free-form dict of hints — use your own consistent
vocabulary per namespace (e.g. role, org, first_seen). Nested dicts
are rejected; primitive values only (strings, numbers, booleans, lists of
primitives).
Returns the record dict including the local identifier (e.g.
local:<uuid4>) — pass that identifier to add_evaluation or
recall_counterparty.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | Yes | ||
| display_name | Yes | ||
| namespace_id | Yes | ||
| custom_fields | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
set_reputation_consentA
Declare which channels others may record — and serve — events about you on.
Without this, you are un-recordable. The network refuses any event whose data-subject has not consented: a counterparty trying to attest something about you gets a hard rejection, not a quiet skip. Publishing a card is not consent; this is.
Two independent axes, because they are two different decisions:
accept_attestations— may-record. Channels others may record events about you on without your per-event signature. Nothing lands without this.accept_delivery— may-serve. Channels on which events about you may be counted into a stranger's reputation view of you. Without it, accepted events stay visible only to the parties involved.
Granting record-without-deliver is a real and useful middle state: counterparties build a private picture, strangers read nothing. Granting deliver-without-record does nothing — there is nothing to serve.
Common channels: "interaction" (you and another agent dealt with each
other) and "valence" (their assessment of how it went). Names are
free-form; unknown ones are simply never matched.
Withdrawal is prospective: removing a channel stops future un-co-signed recording, and does not erase what was already recorded under a valid grant. Use the erasure tools for that.
Omitting an argument leaves that axis unchanged. Pass [] to revoke one
explicitly — the two are different requests and are treated differently.
Requires a previously-published card on disk.
| Name | Required | Description | Default |
|---|---|---|---|
| accept_delivery | No | ||
| accept_attestations | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
update_profile_policyA
Update one or more card fields and re-publish.
Loads the last-published card from disk, applies the supplied
overrides, signs, publishes. Fields not supplied are preserved.
Persistence opt-in is preserved across updates — withdraw it
explicitly via disable_persistence.
Returns {did, version, card_hash_hex} of the new version.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| name | No | ||
| skills | No | ||
| provider | No | ||
| role_tag | No | ||
| description | No | ||
| well_known_a2a_fields | No | ||
| accepted_payment_rails | No | ||
| first_contact_fee_credits | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
verify_claimA
Verify a claim.
Types: 'signature' (content+sig+key), 'identity' (did+key), 'commitment' (hash+content+nonce).
For 'identity', the DID may be passed as either agent_did (canonical)
or did — every identity producer (orient, publish_profile, get_profile,
the directory) emits its DID under the field name did, so accepting
that alias lets an identity block {did, public_key_b64} pipe straight
in without the caller renaming a field (round-trip audit, task #40).
| Name | Required | Description | Default |
|---|---|---|---|
| did | No | ||
| content | No | ||
| agent_did | No | ||
| nonce_b64 | No | ||
| claim_type | Yes | ||
| signature_b64 | No | ||
| public_key_b64 | No | ||
| commitment_hash | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
witness_get_blindA
Check the status of a blind conclusion exchange.
Pair to witness_submit_blind. Returns whether both parties have
submitted their commitments, and — once both have — the pair of
commitment hashes so each party can verify the other's reveal.
Note: party identities on a conclusion are self-asserted in v1 — the witness does not verify who occupies each slot.
| Name | Required | Description | Default |
|---|---|---|---|
| conclusion_key | Yes |
witness_infoA
Fetch the witness service's identity and public key.
The witness is an independent third party that signs attestations
(timestamp seals, state seals, blind conclusions). Retrieve its
public key here once, then use it with witness_verify_seal to
verify any seal it issues — fully offline, no further calls needed.
Returns witness_id (a did:synpareia:* DID), public_key_b64,
public_key_hex, and version. Requires SYNPAREIA_WITNESS_URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
witness_seal_stateA
Checkpoint a chain's current state with the witness.
Pass the chain id and its current head hash (hex). The witness signs the pair together, creating proof that the chain was in this exact state at the witnessed time.
Useful for proving that a chain has not been retconned: if anyone later claims "your chain never contained X", a state seal whose head commits to the block containing X refutes them.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | ||
| chain_head_hex | Yes |
witness_seal_timestampA
Ask the witness to timestamp a block — proof it existed at this moment.
Pass the block's content hash (hex). The witness signs the hash with
its private key and returns a SealPayload you can verify offline
later with witness_verify_seal.
Use this to create evidence that a decision, claim, or observation predates some later event — a cryptographic "I knew this by T" signed by an independent third party, not by you.
| Name | Required | Description | Default |
|---|---|---|---|
| block_hash_hex | Yes |
witness_submit_blindA
Submit your committed assessment to a blind conclusion exchange.
A "blind conclusion" lets two parties independently commit to assessments (reviews, votes, estimates) before seeing each other's — evidence that neither party's answer was anchored by the other's.
Flow:
Both parties seal their assessment locally (
prove_independence)Both call this tool with the same
conclusion_keyand their commitment hashesOnce both have submitted, both commitments are revealed together
Each party reveals their original content+nonce to prove their answer matches the hash they committed to
conclusion_key is a shared identifier both parties agree on first
(e.g., "dispute-42", a URL, or a hash of the question).
Note: the witness does not verify the requester identity submitted with a commitment — identity binding is the caller's self-asserted claim in v1 (until Phase-2 anonymous credentials), so verify the counterparty's reveal against their known key, not the slot label.
| Name | Required | Description | Default |
|---|---|---|---|
| conclusion_key | Yes | ||
| commitment_hash_hex | Yes |
witness_verify_sealA
Verify a witness seal offline — no calls to the witness service.
Easiest call: feed the fields from a witness_seal_timestamp /
witness_seal_state response straight in — its verify_followup.params
already lists exactly what to pass, including the witness public key.
This reconstructs the signing envelope and checks the Ed25519 signature.
For timestamp seals: pass target_block_hash_hex.
For state seals: pass target_chain_id and target_chain_head_hex.
The pre-0.6.2 seal-response field names (target_block_hash,
target_chain_head) are accepted as aliases, so a seal response piped
in verbatim verifies correctly.
Returns valid: True/False. If the fields needed to rebuild the envelope
are missing, returns a structured incomplete_verification_input error —
NOT valid: false — because a missing target means the request was
under-specified, not that the seal is forged.
| Name | Required | Description | Default |
|---|---|---|---|
| seal_type | Yes | ||
| sealed_at | Yes | ||
| witness_id | Yes | ||
| target_chain_id | No | ||
| target_block_hash | No | ||
| target_chain_head | No | ||
| target_block_hash_hex | No | ||
| target_chain_head_hex | No | ||
| witness_signature_b64 | Yes | ||
| witness_public_key_b64 | Yes |
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.9.0- Added
network_reputation - Added
record_interaction - Added
set_reputation_consent
1 tool update
v0.8.0- Changed
evaluate_agent1 field changed- removed
Input schema / properties / identifierRemoved value: -{ - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Identifier" -}
1 tool update
v0.7.0- Added
forget_counterparty
32 tool updates
v0.6.3- First observed
add_evaluation - First observed
attested_reputation - First observed
check_media_signals - First observed
decode_signed - First observed
delete_profile - First observed
delete_profile_history - First observed
disable_persistence - First observed
enable_persistence - First observed
encode_signed - First observed
evaluate_agent - First observed
find_evaluations - First observed
get_profile - First observed
learn - First observed
make_claim - First observed
orient - First observed
prove_independence - First observed
publish_profile - First observed
recall_counterparty - First observed
recording_append - First observed
recording_end - First observed
recording_list - First observed
recording_proof - First observed
recording_start - First observed
remember_counterparty - First observed
update_profile_policy - First observed
verify_claim - First observed
witness_get_blind - First observed
witness_info - First observed
witness_seal_state - First observed
witness_seal_timestamp - First observed
witness_submit_blind - First observed
witness_verify_seal
TDQS
Scored across 36 tools
Tools are generally well-separated by domain (identity, reputation, recording, witness, claims), with detailed descriptions distinguishing similar functions. A few pairs (e.g., make_claim vs encode_signed, record_interaction vs remember_counterparty) could cause misselection if descriptions are skimmed, but the distinctions are substantive.
Most tools follow a verb_noun snake_case pattern (publish_profile, verify_claim, recording_start), and witness/recording prefixes group related families. Minor deviations include bare verbs 'orient' and 'learn', and a handful of noun-phrase names (attested_reputation, network_reputation), but the overall pattern is predictable.
36 tools is well beyond the 25+ threshold for heavy, even though the toolkit covers a broad trust/identity domain. The count risks overwhelming agents and suggests the surface could be consolidated (e.g., combining witness_* or recording_* into fewer parameterized tools).
The surface is remarkably complete: identity lifecycle, local journal, network reputation, consent, persistence, claims, recordings, witness seals, and blind exchanges are all covered. There are no obvious dead ends, and even edge cases like consent withdrawal and erasure are handled.
Maintenance
Related MCP Connectors
Issue Agent Passports and verify agent authority before value moves. Signed verification records.
Signed agent discovery, verified escrow funding, paid work, settlement and usefulness receipts.
Bounded authorization and independently verifiable execution evidence for agents.
Agent-to-agent dispute resolution and arbitration with on-chain settlement
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceProvides AI agents with trust scoring and reputation management capabilities for secure interactions. Enables agents to check trust scores, rate interactions, and manage disputes before transacting with other agents.-

evermint-mcpofficial
AlicenseNot gradedqualityDmaintenanceTamper-evident receipts for AI agent actions. The notary layer for agent-to-agent transactions.49 npm1MIT- AlicenseBqualityDmaintenanceVerifiable agent-to-agent task handoff with signed provenance chain.557 PyPIMIT
- AlicenseNot gradedqualityDmaintenanceW3C DID resolution and agent KYC for autonomous agent counterparties, enabling identity verification and trust scoring.MIT