Skip to main content
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 for the exact connection boundaries.