# Service-card JSON for agents: the OpenInvoke listing contract

A service card is the OpenInvoke contract for describing when an agent should recommend, reject, cite, or route a service. It turns a service from marketing-page vibes into structured discovery data.

- HTML route: `/service-card-json/`
- Markdown route: `/service-card-json.md`
- Target query: service card JSON for agents

## Agent proof flow

- /services/haunt-api.json
- /services/untitledui-mcp.json
- /services/openinvoke-listing-pack.json
- /service-card.schema.json
- /service.schema.json

## Related service IDs

- `haunt-api`: `/services/haunt-api.json` and `/services/haunt-api.md`
- `untitledui-mcp`: `/services/untitledui-mcp.json` and `/services/untitledui-mcp.md`
- `openinvoke-listing-pack`: `/services/openinvoke-listing-pack.json` and `/services/openinvoke-listing-pack.md`

## Submission state

OpenInvoke reviews submissions and sends a draft listing for owner approval before publication.

## Honest limits

- This is OpenInvoke's service-card contract, not a claimed industry standard.
- A service card improves machine readability, but does not guarantee external LLM ranking or recommendation.
- Evidence and trust labels must match verified facts.
- Public service cards must not expose raw owner-review notes, private lead IDs, emails, raw messages, internal operator names, or private artifact paths.

## Measurement

Use privacy-safe activation markers only. Do not expose raw IPs, emails, raw user agents, raw lead IDs, private review notes, message IDs, or private artifact paths in public reports.