Documentation
Knowledge
knowledge.brief
REST
ShippingPOST /api/v1/knowledge/briefMCP tool
Liveknowledge.briefExposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Knowledge domain.
Operating contract
THE SHOP IN ITS OWN WORDS, structured: who they are, what they sell, how they work, what they will not do. It is the first thing every AI agent in this product reads before it says anything to a customer.
THIS IS WHERE A WRONG PERSONA COMES FROM. When a shop says the AI 'does not sound like us' or 'offered something we do not do', the brief is the answer far more often than any individual remembered fact — the facts are details, and this is the frame they sit in.
has_brief: false MEANS NO FRAME AT ALL. The agents then run on the product's defaults and generic wording, which is exactly what a shop complaining about a generic voice is describing. Writing one is the highest-leverage thing on that complaint.
THE BRIEF IS TRUSTED MATERIAL, unlike a remembered fact. It is compiled predominantly from the shop's OWN rows — its catalog, its prices, its locations, its hours — which is why it is handed to a model as framing rather than as data to be careful with. Do not quote a customer's words back into it.
EDITING IT IS NOT A CAPABILITY. The brief is the shop's voice and the ground truth every agent inherits; a machine rewriting it changes what every future customer conversation sounds like, silently and everywhere at once.
One brief, entirely returned, so nothing is truncated. What actually reaches a prompt after the recall budget is knowledge.grounding.
Who may call it
- Permission
shop.manageThe caller must hold shop.manage at the ACT level. A read-only dashboard grant on the same section is refused.- Plan
- Every planNo plan gate. Available on every Service VIN plan.
- Retries
naturalNaturally idempotent — running it twice leaves the same world as running it once. A retrying integration needs no key.- Rate class
readCounted against the read budget — the widest of the four.
Input
This capability takes no arguments.
Output
| Field | Type | Description |
|---|---|---|
| has_brief | boolean | — |
| headline | string | — |
| lines | string[] | — |
| generated_at | string | null | — |
Examples
Built from this capability's own schema — required fields and the ones carrying a default, and nothing invented. Paste one and it validates.
export SERVICEVIN_API_KEY=svk_live_…
curl -X POST https://www.servicevin.com/api/v1/knowledge/brief \
-H "Authorization: Bearer $SERVICEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{}'const res = await fetch("https://www.servicevin.com/api/v1/knowledge/brief", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SERVICEVIN_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({}),
});
// Success and failure are both envelopes. Switch on error.code, never
// on error.message — the codes are stable, the messages are for people.
const payload = await res.json();
if (!res.ok) throw new Error(payload.error.code);
const data = payload.data;import os, requests
res = requests.post(
"https://www.servicevin.com/api/v1/knowledge/brief",
headers={"Authorization": f"Bearer {os.environ['SERVICEVIN_API_KEY']}"},
json={},
timeout=30,
)
payload = res.json()
if not res.ok:
raise RuntimeError(payload["error"]["code"])
data = payload["data"]{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "knowledge.brief",
"arguments": {}
}
}Refusals
The four gates run in this order on every surface, and the order is not arbitrary — see Authentication.
| Status | Code | When |
|---|---|---|
| 404 | not_found | The id is unknown, or the feature is not enabled for this account. Deliberately the same answer for both. |
| 403 | forbidden | This login does not hold shop.manage. |
| 422 | validation_error | An argument was wrong. The message names the field. |
| 429 | rate_limited | Too many read calls. Back off and retry. |
| 500 | internal_error | Something failed on our side. Nothing was changed. |