Hi HN. We've been working on this for a while and figured it's ready for people to poke holes in.
The short version: when you ask an AI about a company, it scrapes the website and guesses. We wanted a way for the company to answer directly — with signed data the agent can verify.
So we wrote a spec. It's an MCP Server Profile. You run a standard MCP server, agents connect over JSON-RPC 2.0, call tools/list to see what you offer, and go from there. Responses carry Ed25519 signatures over JCS-canonicalized data (RFC 8785), keys published at /.well-known/jwks.json per RFC 7517.
The part we're most interested in feedback on: the access model. We went with "no auth by default" — agents connect and ask questions freely, like browsing a website. If you want buyer info before unlocking certain tools, there's a qualify tool that handles it conversationally. OAuth only shows up if someone needs to access their own account data, which most businesses won't need.
We weren't sure that was the right call. It's simpler, but maybe too permissive for some use cases.
To make this concrete instead of theoretical, we built a bakery:
git clone https://github.com/salespeak-ai/agentic-web
cd agentic-web/examples/bakery
python server.py
Zero dependencies. Ask about gluten-free cakes, place an order, get a confirmation. Four JSON-RPC calls end to end. We picked a bakery deliberately — if the spec only works for enterprise SaaS it's not general enough.
MIT licensed. Genuinely curious what this community thinks about the tool naming conventions and whether structuredContent (our extension to MCP tool results) is the right approach or if there's a cleaner way.
Hi HN. We've been working on this for a while and figured it's ready for people to poke holes in.
The short version: when you ask an AI about a company, it scrapes the website and guesses. We wanted a way for the company to answer directly — with signed data the agent can verify.
So we wrote a spec. It's an MCP Server Profile. You run a standard MCP server, agents connect over JSON-RPC 2.0, call tools/list to see what you offer, and go from there. Responses carry Ed25519 signatures over JCS-canonicalized data (RFC 8785), keys published at /.well-known/jwks.json per RFC 7517.
The part we're most interested in feedback on: the access model. We went with "no auth by default" — agents connect and ask questions freely, like browsing a website. If you want buyer info before unlocking certain tools, there's a qualify tool that handles it conversationally. OAuth only shows up if someone needs to access their own account data, which most businesses won't need.
We weren't sure that was the right call. It's simpler, but maybe too permissive for some use cases.
To make this concrete instead of theoretical, we built a bakery:
Zero dependencies. Ask about gluten-free cakes, place an order, get a confirmation. Four JSON-RPC calls end to end. We picked a bakery deliberately — if the spec only works for enterprise SaaS it's not general enough.Spec: https://agentic-web.ai/specification.html GitHub: https://github.com/salespeak-ai/agentic-web
MIT licensed. Genuinely curious what this community thinks about the tool naming conventions and whether structuredContent (our extension to MCP tool results) is the right approach or if there's a cleaner way.