Evaluate remote MCP endpoint and Server Card discovery

[darron]

Decision

Do not publish an MCP Server Card as metadata-only. The current site exposes browser-local WebMCP tools, but it does not currently expose a remote MCP transport at /mcp or another endpoint. A card without a working transport would be misleading.

Scope if adopted

1. Re-check the accepted/current Server Card schema and /.well-known path immediately before implementation; SEP-1649/2127 is still evolving and the draft discussion has changed both the card shape and path conventions.
2. Implement a public, read-only MCP HTTP transport for the same safe discovery actions exposed by WebMCP: list provinces, list record types, list records, and retrieve one record. Reuse the existing Markdown/public data boundaries, but return valid MCP protocol responses.
3. Define the transport contract, protocol version handling, CORS policy, rate limits, error behavior, and any authentication requirements. Never expose admin, ingest, mutation, or credential-bearing actions.
4. Serve the Server Card only after the endpoint works, including the site/server name and version, the real transport endpoint, supported protocol information, and accurately declared capabilities. Do not invent a /mcp URL solely to satisfy discovery scans.
5. Add protocol/route tests, card schema tests, and a deployed smoke test that connects to the advertised endpoint and runs at least one read-only tool.

Relationship to current WebMCP work

The browser WebMCP implementation is tracked separately in #23. This issue may be closed by the same PR only if that PR intentionally adds and verifies the remote MCP transport as well; otherwise it should remain separate.

References

• Skill: https://isitagentready.com/.well-known/agent-skills/mcp-server-card/SKILL.md
• SEP-1649/2127: SEP-2127: MCP Server Cards - HTTP Server Discovery  modelcontextprotocol/modelcontextprotocol#2127

Closes when a real remote MCP endpoint and its accurate Server Card are deployed.