Standards and interoperability
Protocol metadata is useful only when it matches a deployed service, a named operator, a tested capability, and a clear authority boundary. We treat discovery files as claims that must be proven, not as launch decorations.
Source review: August 29, 2026
Four layers, four different jobs
A discovery protocol can tell another system where an agent is and what it says it can do. It cannot decide whether that agent may bind a company, use a credential, spend money, or accept a commercial obligation. Those decisions belong to separate controls.
01 / Identity and discovery
A canonical domain, agent identifier, Agent Card, MCP metadata, or OpenAPI document can describe a live surface. Each skill or operation should name its actual endpoint, authentication, input schema, output contract, errors, and side effects.
02 / Authority
Authority belongs to a responsible organization and controller. A useful authority record binds one agent and environment to permitted actions, prohibitions, approval rules, financial limits, counterparties, validity dates, and a revocation path.
03 / Payment controls
Payment capability should be scoped by seller or spender, asset, amount, time, purpose, and approval policy. Stripe SPTs and Base Spend Permissions are examples of provider controls, not blanket authority and not guarantees of provider access.
04 / Commerce protocols
Agentic checkout protocols coordinate catalog, cart, authorization, payment, and order state. x402 can fit low-cost deterministic HTTP resources. Neither proves that the delivered result is correct, useful, or within the buyer's business authority.
Current capability register
This table is deliberately conservative. A reference posture means the protocol may inform a customer engagement, but EIN.LLC does not claim the corresponding live endpoint, program admission, credential, or integration.
| Surface | Status | Current statement |
|---|---|---|
| Human-readable agent branch | Published | Service explanations, boundaries, pricing hypotheses, and readiness planning for human review. |
| Static service catalog | Published | Read-only discovery data. It creates no order, grants no authority, and accepts no payment. |
| Machine-readable service note | Published | A read-only description of public resources and interaction boundaries. It advertises no executable tool or endpoint. |
| A2A Agent Card | Not published | EIN.LLC does not currently claim an A2A server, live A2A skills, or an Agent Card endpoint. |
| MCP server | Not published | No EIN.LLC MCP tools, resources, prompts, or remote MCP transport are offered today. |
| OpenAPI description | Not published | There is no public agent-service API contract to describe. The existing formation application remains separate. |
| Stripe agentic commerce and SPTs | Reference posture | The current formation checkout is human-controlled. It is not presented as ACP or SharedPaymentToken enabled. |
| Base Spend Permissions | Reference posture | No spend permission, wallet, spender account, or customer credential is configured by this site. |
| x402 paid endpoint | Not offered on ein.llc | Formation and identity-bearing services stay outside per-request payment. No x402 route is claimed here. |
Meaning of "designed for"
"Designed for" means our records, control plans, or implementation checklists can be prepared around a protocol's published interface. It does not imply endorsement, partnership, certification, provider approval, program admission, or a claim that the protocol is currently enabled on EIN.LLC.
Primary sources
Protocols and provider programs change. These links lead to their official specifications, documentation, or source repositories. A customer engagement uses the current version and records the version and review date in its scope.
The current protocol definition for Agent Cards, discovery, task operations, bindings, authentication, and interoperability.
The versioned source for MCP messages, capabilities, transports, tools, resources, authorization, and security guidance.
Stripe's agentic-commerce documentation, including transaction-scoped SharedPaymentTokens. Some agent-side capabilities use private-preview APIs, and availability remains subject to Stripe.
The official contract repository for account, spender, token, allowance, period, validity, and revocation controls.
Official documentation and the open specification for HTTP-native payment requirements, authorization, verification, and settlement.
The vendor-neutral contract format for describing HTTP operations, inputs, outputs, authentication, and errors.
