This template is a planning aid for a business’s public product facts. It is not Schema.org, an MCP server manifest, or a supported ingestion format for the ByAgents product. Populate only information you can support, and keep dynamic values connected to a current source.
Example profile
{
"example": true,
"name": "Example Invoice API",
"canonical_url": "https://example.com/invoice-api",
"capability": "Extract line items from PDF invoices",
"inputs": ["PDF"],
"outputs": ["JSON line items"],
"pricing": {
"unit": "page",
"source_url": "https://example.com/pricing",
"amount": null
},
"authentication": "API key",
"documentation_url": "https://example.com/docs",
"next_step": {
"type": "trial_registration",
"url": "https://example.com/start",
"requires_user_authorization": true
},
"evidence": [],
"limitations": ["Fictional example; no service was tested."]
}Why unknown fields stay unknown
A null price is unknown in this example, not zero. An empty evidence list means no evidence is supplied, not that a product has been disproven. Do not infer certifications, supported regions, current availability, or test results from the presence of a profile.
Adapt to the offering
For commerce, include actual product and variant identifiers, current offer sources, shipping regions, and return-policy links. For services, include scope, service area, deliverables, and the inquiry or booking boundary. For APIs, document authentication, limits, outputs, and completion behavior.
Publish consistently
The public page, structured markup, profile, and action destination should agree. Give each recurring fact an owner and a source. If a value changes rapidly, use the live system as authoritative and indicate when any snapshot was taken. The profile makes facts easier to inspect; it does not guarantee recommendation or acquisition.