> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bily.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Approve MCP actions safely

> Keep Bily MCP work scoped, visible, focused, and verified before you trust the result.

Bily enforces identity, organization, and store access on the server. You stay in control by reviewing the plan, scope, and verification for each request.

## Review the complete action

Configure the client to prompt before MCP tool calls. `search` is read-oriented. `execute` can contain reads, writes, or several helper calls.

Before you approve an `execute` call:

1. Read the complete async function.
2. Confirm the intended store and organization.
3. Identify every helper that can write.
4. Check the matching `search` result's planning metadata.
5. Confirm the verification step and any rollback hint.

Planning metadata is advisory. It helps the client prepare a safer request, but it does not prove that a person approved the action.

## Match approval to the highest risk

The catalog classifies each operation as:

* `read` for identity, store, analytics, and connected-platform reads;
* `draft_write` for supported creation, clone, synchronization, and configuration actions;
* `spend_affecting` for actions that can change delivery or budget behavior;
* `destructive` for deletion.

Approval guidance can be `none`, `required_before_write`, or `required_before_spend`.

Use the strongest value returned by any helper as the minimum review level for the entire execution.

## Run one focused action

* Use `search` immediately before an unfamiliar operation.
* Prefer one business action per `execute` call.
* Do not place credentials inside `code`; Bily helpers already use the connection's authentication.
* Return only the fields needed for the task.
* Do not attempt arbitrary network requests; direct outbound network access is unavailable.
* Break long analyses into smaller calls. Each execution must stay within its 20-second runtime.

## Confirm every write

After an approved write, call the appropriate read helper. Return both the action result and the observed state.

Do not report success from the action request alone when the catalog provides a verification step.

If verification disagrees with the requested change:

1. Stop additional writes.
2. Report the action and verification results separately.
3. Follow a catalog rollback hint only after you receive another explicit approval.

## Keep credentials out of the workflow

* Prefer Bily Connect so no long-lived key appears in client configuration.
* Create fallback keys only for clients that need them.
* Select the intended store before creating a fallback key.
* Use a descriptive name and expiration.
* Never paste a key into a prompt, execution function, log, issue, or repository.
* Revoke a key immediately if it may have been exposed.

Review [authentication and scoping](/mcp/authentication) for the exact connection boundaries.