[Bug]: Python server's discovery profile advertises transports it does not serve (mcp, a2a, embedded)

[vishkaty]

What happens

At current main, the Python Flower Shop's /.well-known/ucp profile advertises four transports for dev.ucp.shopping, but only REST is actually served:

advertised transport	endpoint in profile	observed behavior
rest	/	✅ works
mcp	/mcp	tools/call returns -32000 "tools/call is not yet implemented on this sample's MCP endpoint; use the REST transport…"
a2a	/.well-known/agent-card.json	HTTP 404
embedded	null	endpoint is literally None in the profile

Verified by booting the server from main and probing each advertised endpoint.

Why this matters

Agents select a transport from the discovery profile — that's the point of discovery. A profile that advertises transports the server doesn't serve sends conformant agents into dead ends (e.g. an MCP-first agent picks /mcp and can never check out). It also makes the sample a misleading reference for the discovery contract itself: implementers copy this profile shape. (Related signal: #101's author was specifically trying to build against the MCP transport.)

Possible resolutions (maintainers' call)

1. Trim the profile to what's served (smallest change): advertise rest only until other transports are implemented — the profile becomes truthful today.
2. Implement the advertised transports (most valuable): tools/call for MCP would unlock MCP-transport conformance testing; happy to help here if useful.
3. Some combination (e.g. trim a2a/embedded, finish mcp).

Happy to send a PR for whichever direction you prefer.

[vishkaty]

Reproduced on current main (3f9470e). The discovery profile at /.well-known/ucp
advertises four transports, but only REST is actionable end to end:

advertised	probe	result
rest (/)	POST /checkout-sessions	serves (validates) ✅
mcp (/mcp)	tools/list / tools/call	list 200; call → JSON-RPC -32000 "not yet implemented"
a2a (/.well-known/agent-card.json)	GET	404 (no route mounted)
embedded	—	endpoint is null

Source: routes/discovery_profile.json hard-codes the mcp/a2a/embedded bindings;
server.py mounts only rest/order/discovery/mcp routers (no a2a), and mcp.py implements
initialize+tools/list only.

One framing note so this doesn't read as more than it is: this is not a schema violation —
service.json business_schema only requires an endpoint per binding, which the profile
satisfies, and the profile faithfully mirrors the illustrative Business Profile in
overview.md. The gap is runtime truthfulness for a reference server agents act against,
not conformance.

Of the three directions in the issue, Option 1 (advertise only what's served — trim to rest)
is the smallest change that makes the profile truthful today; it stays schema-valid and no test
or CI asserts on the transport list, so it's safe. Option 2 (implement the mcp tools/call
bridge to REST) is the higher-value path if MCP is meant to be first-class. Happy to send a PR
for whichever direction you prefer.