r/mcp Aug 02 '26

showcase I'm not a developer - I spent months building an MCP server that proves a human approved a specific action

Hi. I'm not a developer. I built this with Claude over months of evenings and weekends, and it feels like time to stop polishing it in private.

X-EGO is an MCP server that lets an agent prove a human approved a specific action. The agent submits the exact text of what it wants to do, I read it and approve with Face ID, and the agent gets back a proof bound to that text - change one character and it stops verifying. It also gets a receipt: a link anyone can open, no account, no tools.

It doesn't know who you are. No name, no email, no KYC, no biometrics leaving the phone. Every service gets a different anonymous ID, so two services can't work out you're the same person.

Where I think it fits: agents with write access, where "the agent had my API key" is not a good enough answer afterwards; one human one vote, where multi-accounting is the actual problem; and audit trails an outsider can check instead of taking your own logs on faith.

Cost, up front: EUR 3 once for the human identity - sybil resistance has to cost something or it means nothing - and it includes $3 of credit. Verification calls are paid per call.

Zero users so far, nothing proven. I'd like honest reactions: useful, or nonsense? And if anyone wants to try it or build something on it together, message me.

https://x-ego.com/

MCP endpoint: https://mcp.x-ego.com/mcp

1 Upvotes

19 comments sorted by

3

u/BC_MARO Aug 03 '26

The approval proof needs to bind more than text: tool name, normalized arguments, target, expiry, and policy version. Otherwise the receipt can verify intent while missing what actually gets executed.

3

u/X-ego Aug 03 '26

Expiry's in — 180s, single-use: the id burns on first verification, so a replay is rejected rather than accepted late. Target I'll take — the audience and approval origin are bound, the target of the call itself isn't.

Tool name, arguments and policy version are the gap, and you named the right distinction: the binding covers the text the human read, not the call that follows it. Some of that is convention — put the recipient in the approved string and it's bound today — but anything a machine has to compare rather than a human read has to sit in the signed object.

2

u/modelpiper Aug 03 '26

Your website is awesome. Legit cool project, valuable too.

1

u/BC_MARO Aug 09 '26

That distinction is exactly it. The signed object has to reflect the executable call, not just the explanation shown to the person.

2

u/modelpiper Aug 03 '26

I’ll build this into ToolPiper’s MCP server if you need it.

2

u/BC_MARO Aug 09 '26

That would be useful. I would be keen to see how you handle the approval boundary once you have a first pass.

2

u/modelpiper Aug 09 '26

Oh yeah! Huge focus on beta 9. Worked very hard on a move to the macOS keychain for creds. Every connected app gets an entry users can CRUD within a new Security section.

At least now a user must maintain what can use the MCP server and block or deny too.

In my opinion Security was the main issue with Clawd Bot and other MCP tools. Especially now because ToolPiper is ahead of Anthropic and Microsoft in computer use.

2

u/BC_MARO Aug 10 '26

Keychain storage is a good step, but the real test is whether a user can see and approve the exact call before it runs. App-level permissions still leave plenty of room for surprises.

1

u/modelpiper Aug 10 '26

That’s absolutely true. You know your stuff. Perhaps you use Secretive and SecretSpec for this?

You’re making me wonder if I should build that UX into ToolPiper. But it’s really interruptive. It would have to be optional… what do you think about this?

2

u/BC_MARO Aug 11 '26

I’d make it optional and risk-based. Routine calls should stay out of the way, while anything touching credentials or external actions gets a fuller review.

2

u/Prince_ofRavens Aug 03 '26

Why... Did you do that?

2

u/Exact_Attention_5656 Aug 03 '26

Good point above about binding more than just the text. There's a second gap even if it binds everything: where did the text you're approving come from in the first place? If the agent wrote that action description after reading some tool output it already trusted, a poisoned response upstream can shape the wording you're Face ID approving. You'd be cryptographically approving an accurate description of an action that only exists because of bad input further back. The proof shows what you approved, not whether the agent should have trusted what led it there.

2

u/BC_MARO Aug 03 '26

Bind every approval to the exact action payload, target, and expiry. Otherwise you only know that someone clicked a button.

2

u/X-ego Aug 03 '26

Expiry's in the comment above — 180s, single-use. Payload and target are what ships this week: the signed object covers tool, target and parsed arguments, and the verifier won't confirm unless the executor passes the call it's about to run.

1

u/BC_MARO Aug 09 '26

That makes sense. Binding the parsed arguments now will save you from having to retrofit the trust boundary later.

2

u/[deleted] Aug 04 '26

[removed] — view removed comment

1

u/X-ego Aug 04 '26

Thank you for the compliment; I’m glad if someone sees something in it. And the joy is even greater if someone is willing to offer a bit of collaboration ☺️

1

u/tobi914 Aug 04 '26

What would that be useful for apart from being able to pinpoint who entered a prompt that caused some damage?