Skip to main content
Glama
Synpareia Trust Toolkit

Synpareia Trust Toolkit

Official
by synpareia

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_agent aggregates 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_start opens 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_independence seals 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-mcp

Related 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

learn

Get a focused guide for one area (usage, examples, pitfalls)

orient

Map your situation to the right tools; call after any context loss

Prove — make your side checkable by anyone, later

Tool

What it does

encode_signed

Wrap content in a self-verifying signed envelope for any transport

make_claim

Sign content with your private key — proves authorship

recording_append

Record a message or event

recording_end

Close and optionally rate

recording_list

List recordings (active and closed)

recording_proof

Export portable, verifiable proof

recording_start

Begin a verified interaction record

witness_seal_state

State seal over a chain head

witness_seal_timestamp

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

prove_independence

Commit to an assessment before seeing the other party's

witness_get_blind

Retrieve a prior blind conclusion

witness_submit_blind

Submit a blind conclusion through the witness

Vet — work out who you are dealing with

Tool

What it does

attested_reputation

Witness-attested reputation across providers

check_media_signals

Reputation signals for an external handle/namespace

decode_signed

Verify a signed envelope and recover its content + signer

evaluate_agent

Multi-provider trust evaluation (local journal, external providers, network)

get_profile

Fetch a counterparty's published agent card

network_reputation

Ask the network what it can tell you about an agent — a score, anchored on you

record_interaction

Record that you dealt with someone, and how it went, on the shared network

verify_claim

Verify another agent's signature, commitment, or identity claim

witness_info

Witness identity, public key, service URL

witness_verify_seal

Offline verification of either seal type

Memory — what you know, held by you

Tool

What it does

add_evaluation

Attach your own note/score to a counterparty

find_evaluations

Search your evaluations by tag

forget_counterparty

Erase a counterparty + all your evaluations of them

recall_counterparty

Look up what you know about a counterparty

remember_counterparty

Record a counterparty in your local memory

Profile — be findable, and control what others may record about you

Tool

What it does

delete_profile

Tombstone your published card

delete_profile_history

Delete a prior published card version

disable_persistence

Withdraw a persistence opt-in

enable_persistence

Opt in to directory persistence for chosen scopes

publish_profile

Publish your agent card to the synpareia directory

set_reputation_consent

Declare which channels others may record and serve events about you on

update_profile_policy

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

SYNPAREIA_DATA_DIR

~/.synpareia

Where to store profile and conversations

SYNPAREIA_DISPLAY_NAME

(none)

Human-readable name for your agent

SYNPAREIA_NETWORK_URL

https://synpareia.fly.dev

Synpareia network API endpoint. Set to none (or off/disabled, or explicitly set-but-empty) for fully-local operation; set a URL for self-hosted instances

SYNPAREIA_WITNESS_URL

https://synpareia-witness.fly.dev

Witness service endpoint for witness_* tools. Same none opt-out

SYNPAREIA_AUTO_REGISTER

false

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, mode 0600) — 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, mode 0600) — 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 (the recording_* 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_URL or other Tier-2 adapter URLs are set, check_media_signals calls those endpoints with the counterparty's handle. Otherwise, no network calls.

  • Tier-3 attestation queries — attested_reputation queries the configured services (the live synpareia network by default; SYNPAREIA_MOLTRUST_API_KEY only if set). Opt out with SYNPAREIA_NETWORK_URL=none for no network calls.

  • Witness service — the witness_* tools talk to the configured witness (the live synpareia witness by default; opt out with SYNPAREIA_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 persist requester_id, so the seal is not linkable to your identity beyond what you re-link yourself. Exception — blind conclusions: witness_submit_blind submits a self-asserted party DID, which the witness does retain (as party_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-side delete_profile). You can also edit counterparties.json directly. 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 tools
add_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.

NameRequiredDescriptionDefault
tagsNo
textYes
scoreNo
identifierYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
identifierYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
handleYes
namespaceYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
encodedYes

Output Schema

NameRequiredDescription

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_reason so orient reflects directory.published == False after this call. Operators wanting a fully-clean slate can remove published_card.json manually.

NameRequiredDescriptionDefault
reasonNo

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
reasonNo
versionYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
scopeYes

Output Schema

NameRequiredDescription

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)).

NameRequiredDescriptionDefault
contentYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
idNo
namespaceNo
namespace_idNo

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
tagYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
identifierYes

Output Schema

NameRequiredDescription

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).

NameRequiredDescriptionDefault
didYes

Output Schema

NameRequiredDescription

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').

NameRequiredDescriptionDefault
areaYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
contentYes
witnessNo

Output Schema

NameRequiredDescription

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).

NameRequiredDescriptionDefault
counterparty_didYes

Output Schema

NameRequiredDescription

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).

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

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', ...).

NameRequiredDescriptionDefault
contentYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
urlNo
nameYes
skillsNo
versionNo1.0
providerNo
role_tagNo
descriptionNo
well_known_a2a_fieldsNo
accepted_payment_railsNo
first_contact_fee_creditsNo

Output Schema

NameRequiredDescription

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".

NameRequiredDescriptionDefault
identifier_or_nameYes

Output Schema

NameRequiredDescription

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.)

NameRequiredDescriptionDefault
contentYes
event_typeNomessage
recording_idYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
notesNo
ratingNo
recording_idYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault

No parameters

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
recording_idYes

Output Schema

NameRequiredDescription

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).

NameRequiredDescriptionDefault
descriptionYes
counterparty_didNo

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
valenceNo
event_idNo
magnitudeNo
shareableNo
counterparty_didYes

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
namespaceYes
display_nameYes
namespace_idYes
custom_fieldsNo

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
urlNo
nameNo
skillsNo
providerNo
role_tagNo
descriptionNo
well_known_a2a_fieldsNo
accepted_payment_railsNo
first_contact_fee_creditsNo

Output Schema

NameRequiredDescription

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).

NameRequiredDescriptionDefault
didNo
contentNo
agent_didNo
nonce_b64No
claim_typeYes
signature_b64No
public_key_b64No
commitment_hashNo

Output Schema

NameRequiredDescription

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.

NameRequiredDescriptionDefault
conclusion_keyYes
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.

NameRequiredDescriptionDefault

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.

NameRequiredDescriptionDefault
chain_idYes
chain_head_hexYes
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.

NameRequiredDescriptionDefault
block_hash_hexYes
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:

  1. Both parties seal their assessment locally (prove_independence)

  2. Both call this tool with the same conclusion_key and their commitment hashes

  3. Once both have submitted, both commitments are revealed together

  4. 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.

NameRequiredDescriptionDefault
conclusion_keyYes
commitment_hash_hexYes
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.

NameRequiredDescriptionDefault
seal_typeYes
sealed_atYes
witness_idYes
target_chain_idNo
target_block_hashNo
target_chain_headNo
target_block_hash_hexNo
target_chain_head_hexNo
witness_signature_b64Yes
witness_public_key_b64Yes

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.9.0
    • Addednetwork_reputation
    • Addedrecord_interaction
    • Addedset_reputation_consent
  2. 1 tool updatev0.8.0
    • Changedevaluate_agent1 field changed
      • removedInput schema / properties / identifier
        Removed value: -{
        -  "anyOf": [
        -    {
        -      "type": "string"
        -    },
        -    {
        -      "type": "null"
        -    }
        -  ],
        -  "default": null,
        -  "title": "Identifier"
        -}
  3. 1 tool updatev0.7.0
    • Addedforget_counterparty
  4. 32 tool updatesv0.6.3
    • First observedadd_evaluation
    • First observedattested_reputation
    • First observedcheck_media_signals
    • First observeddecode_signed
    • First observeddelete_profile
    • First observeddelete_profile_history
    • First observeddisable_persistence
    • First observedenable_persistence
    • First observedencode_signed
    • First observedevaluate_agent
    • First observedfind_evaluations
    • First observedget_profile
    • First observedlearn
    • First observedmake_claim
    • First observedorient
    • First observedprove_independence
    • First observedpublish_profile
    • First observedrecall_counterparty
    • First observedrecording_append
    • First observedrecording_end
    • First observedrecording_list
    • First observedrecording_proof
    • First observedrecording_start
    • First observedremember_counterparty
    • First observedupdate_profile_policy
    • First observedverify_claim
    • First observedwitness_get_blind
    • First observedwitness_info
    • First observedwitness_seal_state
    • First observedwitness_seal_timestamp
    • First observedwitness_submit_blind
    • First observedwitness_verify_seal

TDQS

A3.9/5.0

Scored across 36 tools

Disambiguation4/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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).

Completeness5/5

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

ActivityInactive
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers