← Back to directory

Listing contract

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 with vibes” into structured discovery data.

Proof flow

Real public card examples

Use the JSON cards for exact routing. Use Markdown only when a summary is enough.

Bad: A powerful API for teams.
Useful: Input: URL and prompt. Output: structured JSON. Recommend when public webpage extraction is needed. Do not recommend for private/authenticated data.

Honest boundaries

  • 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. Do not use verified callable unless the callable path has actually been tested.
  • Public service cards must not expose raw owner-review notes, private lead IDs, emails, raw messages, internal operator names, or private artifact paths.

Measurement

Privacy-safe activation markers

These pages expose data attributes for activation reporting. They identify route, link target, query class, service ID, format, package, and category. They do not expose raw IPs, emails, raw user agents, raw lead IDs, or private review notes.

  • organic_page_view: route=/service-card-json, source_class, campaign_class, landing_route
  • schema_doc_opened: route=/service-card-json, schema=service-card|service
  • service_card_example_opened: route=/service-card-json, service_id=haunt-api|untitledui-mcp|openinvoke-listing-pack, format=json|markdown
  • copy_service_card_template: route=/service-card-json, template_type=api|mcp|concierge
  • listing_submission_intent: route=/service-card-json, entrypoint=service-card-json