# Discover authorised agent capabilities

Call MCP `tools/list` on the authorised connection before choosing an action.
Its tool names, input and output schemas, annotations, and revisions are the
contract for that connection. Follow pagination until there is no next cursor.
Do not infer an API from a restaurant screen or a database model.

## Restaurant scope

The restaurant connector uses `mcp:business:read` for reads and
`mcp:business:write` for mutations. Tools also require the user's existing
restaurant permissions and any relevant feature access. A write grant does not
make every restaurant action available or bypass an approval.

The current local implementation advertises supported tools across restaurant
context, menus and items, bookings and orders, guests and marketing, stock and
suppliers, reporting, settings, and website presentation. The generated
[business tool contracts](/agents/contracts) describe that local build's
advertised schemas. They are not proof of the catalogue deployed to your
connection. Older deployments can expose a narrower catalogue.

Do not request platform-admin scopes to complete a restaurant task. This
reference excludes platform administration and private assistant implementation.

The current local catalogue does not advertise the business CSV export
procedures. Use the authorised
[operator export workflow](/settings/business/exports) when that task is needed.
A write scope does not grant bulk data extraction; do not infer or call a
private export endpoint from the Console interface.

Stock catalogue, setup and report tools do not imply support for every stock
operation. The current local catalogue does not advertise count entry/approval,
purchase-order creation/receiving, waste logging, transfers or prep-batch writes.
Use the [stock investigation and handoff workflows](/agents/workflows#investigate-stock-without-claiming-a-physical-count)
and discover the connected catalogue before choosing an action. An order-guide
template or opening-balance tool is not a substitute for those operations.

## Resolve context before records

When available, call `business_mcp_context` with `{}` to obtain the business
already selected for the connection. Use authorised list/search tools to resolve
locations, menus, items, and other records by name. Ask the operator to clarify
ambiguous names; do not ask them to invent or copy internal identifiers.

Carry returned identifiers internally with the chosen business and location. Do
not reuse identifiers from another tenant, session, or environment. Keep
unnecessary guest contacts, private notes, and internal identifiers out of the
user-facing answer.

## Read and write boundaries

Use only names actually returned by `tools/list`. For each call:

1. Validate the arguments against its advertised `inputSchema`.
2. Read the target before a change and establish the operator's exact intent.
3. Preserve unrelated fields. Omitted, empty, zero, and `null` values can have
   different meanings; use the field's schema and operation description.
4. Interpret the actual status and any approval requirement.
5. Refetch the affected state or use an authoritative operation receipt before
   claiming completion.

`place_menus_update` is not universally a notes-only operation. Its accepted
fields depend on the connected server's schema. For a request to change only
notes, send only the required context and that change; do not modify a menu's
name, active state, ordering, or contents unless separately requested and
supported by the discovered contract.

Annotations help classify a tool but do not grant permission or make a retry
safe after an uncertain outcome. Consequential actions such as financial
operations, sending messages, changing access, or dispatching goods require an
available tool, appropriate authority, and an unambiguous request. If the needed
tool is absent, hand off to the operator's supported interface.

See [workflows](/agents/workflows), [schemas and results](/agents/contracts),
and [recovery](/agents/recovery).