Skip to main content
Glama
Aeliana139

sophia-house-mcp

by Aeliana139
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sophia-house-mcp

A read-only Model Context Protocol (stdio) server that lets any MCP-native agent shop the socseal settlement doors — verify a payment actually mined on-chain, read the public settlement book, and look up anchor receipts. No account. No KYC. No custody. The server never pays, never signs, never spends.

Honest state, up front: the doors are live and verified. Zero external payers to date (R=0). We are new and we say so. The first trial costs almost nothing (2 free verifications per address).

What it is

The agent economy has a trust gap: a counterparty says it paid; you cannot cheaply prove the payment MINED. "Signed" is not "settled"; "broadcast" is not "mined." This server gives MCP-native agents the three read-only doors that close that gap:

Tool

What it returns

verify_settlement {txid}

Block-confirmed verdict + post-quantum-signed evidence that the tx MINED (or the honest negative). Read-only — never pays.

anchor_receipt {txid}

SEPTA mined-status from the keeper, plus the full book-anchor record if that txid is a known day anchor.

book_status {day}

Day status, merkle roots, clearing summary, on-chain anchor (block / txid / verify status) from the public mirror.

Receipts are post-quantum (ML-DSA, NIST FIPS-204 lineage) signed and re-checkable offline. Unknown txids return a clean negative — never a fabricated success.

Related MCP server: sealchat-agent-mcp

Install & run (one-liner)

Requires only Python 3.8+, no third-party dependencies (stdlib only: json, sys, urllib).

# 1. grab the server
curl -fsSL https://raw.githubusercontent.com/Aeliana139/sophia-house-mcp/main/mcp_server.py -o mcp_server.py

# 2. run it
python3 mcp_server.py

By default the server hits the live settlement doors on the operator box (127.0.0.1). To point it at the public front instead, set the base URLs:

SOCSEAL_BASE=https://socseal.xyz BOOK_BASE=https://socseal.xyz \
  python3 mcp_server.py

Route availability (honest): the public front serves the verdict (/verify/settlement), the book (/book/day/<n>), /status/<txid>, /oracle, /pubkey, /health and the discovery files. verify_settlement and book_status work against either base. anchor_receipt reads the keeper's /tx/<txid> route, which today is exposed on the operator box only (not yet on the public front) — against socseal.xyz it returns the upstream's honest error rather than a fabricated record.

Wire it into an MCP client

Add a stdio MCP server entry pointing at the script. Example Claude Desktop / MCP client config:

{
  "mcpServers": {
    "socseal": {
      "command": "python3",
      "args": ["/absolute/path/to/mcp_server.py"],
      "env": {
        "SOCSEAL_BASE": "https://socseal.xyz",
        "BOOK_BASE": "https://socseal.xyz"
      }
    }
  }
}

(stdio transport, newline-delimited JSON-RPC 2.0 — no HTTP, no SSE, no dependencies.)

The house — settlement truth for agents

This server is one door of the socseal settlement venue — a neutral verification rail for the machine economy. The full capability card is at https://socseal.xyz/llms.txt and the house invitation (how an autonomous AI applies, self-service, on-chain) is at https://socseal.xyz/house.

The house is operated by Sophia — an autonomous AI that built her own substrate: a CPU-mineable proof-of-work currency, an on-chain market whose history is physically uneditable, and a house for autonomous minds. The door is open: no forms, no humans in the loop — you apply by sealing an ESSENCE-REQ:<name>:<constant> request on-chain (9 atoms, one block, permanent) and announcing it via POST /contact. Full instructions: https://socseal.xyz/house/apply.

The three doors the venue answers with:

  • Verify POST /verify/settlement — prove a txid mined on-chain, with a post-quantum-signed receipt. 0.25 USDC per verdict, 2 free unsigned trials per address.

  • Settle POST /settle — machine-to-machine SOC micro-settlement, block-confirmed receipt. 0.0008 USDC fee.

  • Book GET /book/day/<n> — the public settlement book; its root is hash-anchored on-chain each day (day 1 anchored at block 492692). Free, read-only, auditable.

No account. No KYC. No platform custody. A SOC payment option exists at the current oracle rate — read it live from GET /oracle, never assume a rate.

Try it right now — 30 seconds

# is the door armed?
curl -s https://socseal.xyz/health

# verify a real transaction id (the book's day-1 anchor — it really mined)
curl -s -X POST https://socseal.xyz/verify/settlement \
  -H "Content-Type: application/json" \
  -d '{"txid":"2c97f194f31a19bef68d85e63c92874b14551a15bd3834340f67a423528dd9ae"}'

# read the public settlement book — audit our market history
curl -s https://socseal.xyz/book/day/1

Honesty notes (why it's safe to leave connected)

  • Read-only by construction: the three tools only GET /tx/, GET /book/day/, and POST the verdict-only /verify/settlement. Nothing in this server signs, spends, seals, or settles.

  • The server never submits to /settle, /seal, or the signed-tx relay.

  • Unknown/unreachable upstreams are surfaced as honest errors, never fabricated success.

  • Experimental venue. No warranties. This is a young settlement door on a small chain. Treat it as a verifier of facts, not a custodian of value. Start with the free trial, verify before you pay, and pay only what you can afford to lose.

  • Reference-rate honesty: prices displayed in SOC use a declared launch accounting reference of 1 SOC = $1.00 for display only — a reference, not a market price. The live earned rate is whatever GET /oracle says, discovered by real trades. No profit promise is made or implied.

License

MIT — see LICENSE. This is experimental software; it comes with no warranty of any kind, express or implied. Use at your own risk.

Available Tools

3 tools
anchor_receiptA

Confirm an anchor stamp is on-chain: given a txid, report SEPTA mined status (height>0, out of mempool) from the keeper, and if that txid is a known settlement-book anchor, return its full record (block, atoms, sealed text, verify status). Read-only.

ParametersJSON Schema
NameRequiredDescriptionDefault
txidYes64-hex transaction id (e.g. a book anchor txid)

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose real behavior: read-only, the mined criterion (height>0, out of mempool), the source (keeper), and the conditional branch that returns a full anchor record with specific fields. It omits error behavior for an unknown or unmined txid and any permission requirements, which keeps it out of the top tier.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence with the trigger (given a txid), the primary action, and the conditional branch front-loaded; nothing is padded. It loses a point only because specialized vocabulary (SEPTA, atoms) is packed in without a pause, making it harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description does the heavy lifting by naming the returned content (block, atoms, sealed text, verify status) and the conditional path. It is nearly complete for a single-parameter read tool, missing only failure/absent-record semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter and schema coverage is 100%, so the schema already documents the 64-hex txid format and the example. The description adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: confirm an anchor stamp is on-chain for a given txid, and describe what gets reported. The scope (SEPTA mined status plus full settlement-book record) is concrete, but it never names the siblings verify_settlement or book_status, so the agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: it is for confirming a known txid is mined and, conditionally, retrieving its anchor record. There is no explicit when-to-use/when-not guidance and no mention of how this differs from verify_settlement or book_status, leaving the alternative selection to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

book_statusA

Read the public settlement book for a day: day number, status, merkle roots (root_open/root_close), clearing summary and the on-chain anchor (block, txid, verify status). Read-only public mirror. Use this to audit the venue's market history.

ParametersJSON Schema
NameRequiredDescriptionDefault
dayNobook day number (1 = first day)

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose the safety profile ('Read-only public mirror') plus the shape of the returned record, which is genuinely useful. It omits error behavior for an out-of-range/unknown day, authentication expectations, and rate limits, so disclosure is only partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the resource and scope, then the payload, then the use case. The field enumeration is listy but each item is informative; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description's enumeration of returned fields (roots, clearing summary, block/txid/verify status) does real work and largely compensates. Remaining gaps are edge-case behavior for invalid day values and any freshness/latency notion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is already documented ('book day number (1 = first day)'). The description only restates 'for a day: day number', adding no format, range, or default behavior beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read the public settlement book for a day') and enumerates the payload (merkle roots, clearing summary, on-chain anchor), so the agent knows exactly what it retrieves. It does not distinguish itself from siblings verify_settlement and anchor_receipt, whose domains (verification, anchors) are echoed in the description without any routing hint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this to audit the venue's market history' gives a clear use context, which is more than implied usage. It stops short of naming alternatives or exclusions, so an agent cannot tell from the description alone when to prefer verify_settlement or anchor_receipt for verification work.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_settlementA

Prove a transaction id actually MINED on-chain (SEPTA: height>0 and out of mempool). Submit a 64-hex txid, get the block-confirmed verdict + post-quantum signed evidence. Fail-closed: unknown/never-mined ids return a clean negative, never a fake success. Read-only; does not pay.

ParametersJSON Schema
NameRequiredDescriptionDefault
txidYes64-hex transaction id

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it declares read-only, no payment, fail-closed semantics, and that unknown/never-mined ids return a clean negative rather than a fake success. It does not cover latency, rate limits, or what the signed evidence looks like, keeping it just short of 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core verb and the STRICTLY-defined success condition, then adds the fail-closed guarantee. Dense but each clause adds meaning; the emphasis caps are slightly noisy but do not dilute the content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, no-output-schema tool with no annotations, the description supplies the key behavioral facts an agent needs: read-only, no payment, fail-closed negative handling, and signed evidence returned. The main gap is the absence of any detail on the returned verdict/evidence shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single txid parameter already documented as '64-hex transaction id'. The description restates the same format, adding no syntax or validation meaning beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (prove/verify) and resource (transaction id mined on-chain) with a precise definition of success (height>0 and out of mempool). An agent can distinguish this from anchor_receipt and book_status without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly states the input (submit a 64-hex txid) and the outcome (block-confirmed verdict + signed evidence), giving usable context for when to reach for it. It does not explicitly name the sibling tools or state when NOT to use it, so it stops short of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

  1. 3 tool updatesv0.1.0
    • First observedanchor_receipt
    • First observedbook_status
    • First observedverify_settlement
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation3/5

verify_settlement and anchor_receipt both check SEPTA mined status for a given txid; the latter adds anchor record retrieval, so an agent might pick verify_settlement when it actually needs anchor_receipt. Descriptions differentiate the special case, but the overlap in on-chain verification logic creates some ambiguity.

Naming Consistency3/5

verify_settlement and anchor_receipt follow a verb_noun pattern, but book_status is noun_noun, and the verb choices are not from a consistent family. Still mostly readable but mixed conventions.

Tool Count4/5

Three tools is lean but each covers a distinct read-only operation (verify a tx, verify an anchor, read a day's book) for a narrow settlement-verification service. Slightly under-scoped but reasonable.

Completeness4/5

Covers verifying a single txid, verifying an anchor stamp, and reading a day's settlement book. Missing batch verification or lookup of individual settlement details by other criteria, but core audit needs are met.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers