Set Up Tools, APIs, and MCP Access

Tools let agents and workflows read data, create records, send messages, call APIs, run system capabilities, or reach MCP servers. Use the REST API when a customer application, internal portal, or automation backend needs server-side access to Siesta AI. Admins do not need to design every schema, but they do need to decide which tools can run, who can use them, and which actions require confirmation.

Decide Between Ingestion and a Live Tool

The first private agent can often work with an approved data pack and no live tools. Add a live-system branch only when the evaluation proves that stored retrieval is not enough.

Need	Starting point	What changes operationally
Search an approved, reusable document set	Data collection	Content is ingested, processed into chunks, indexed, and reviewed before use
Verify current public information	Grounding with Google Search or Web scraper	The answer depends on a live public source that must be reviewed and cited
Query the current state of an external business system	Shared or private REST/MCP/tool connection	Every request runs against the external identity's current permissions and data
Create, update, send, publish, or delete in another system	Write-capable tool with confirmation	The action can change external state and requires Tool Executions plus target-system verification
Call Siesta AI from a customer backend	A contract in the public REST API reference	The customer owns server-side authentication, error handling, and version compatibility

A synchronized Data source periodically copies and indexes supported content. A REST, MCP, or other tool queries a live system when it runs and may be able to change that system. Do not use a live query as a substitute for a governed evidence pack, and do not promise realtime behavior from an ingested collection.

Add a Live-System Branch to the Pilot

1. Write down the exact current question or external action that the verified data-only agent cannot complete.
2. Choose the narrowest supported connection. Use a shared, admin-managed service or team identity for team-owned systems; use private per-user authorization for personal mailboxes, calendars, Drives, and actions that must run as the individual.
3. For Power BI, add the documented Power BI MCP connection. Power BI is exposed through MCP rather than a separate native connection, and queries remain limited by the Microsoft identity that completed OAuth.
4. Review the exposed functions and disable those the pilot does not need. Require confirmation for write-capable or otherwise consequential functions.
5. Attach only the required tool functions, either directly to the agent or through the specific skill that uses them.
6. Keep the agent private, test with safe records, and verify both the Tool Execution and the result in the target system.
7. Apply the shared-versus-private identity and pilot access rules before letting a team use the live branch.

Tool Setup Flow

1. Create or select the connection.
2. Review available functions, parameters, and credential fields.
3. Classify each function as read, draft, write, delete, publish, or administrative.
4. Apply organization or connection-level function access: enabled, enabled with confirmation, or disabled.
5. Share the connection only with the teams that need it.
6. Assign the tool to the agent, skill, prompt, or workflow.
7. Test with safe data.
8. Confirm the result in Tool Executions and in the target system.

REST API Tools

REST tools are production contracts. Before allowing one in a shared agent:

• Confirm the base URL and environment.
• Confirm authentication lives in the connection, not in prompts.
• Confirm every function has a method, path template, parameter location, and purpose.
• Use static parameters only for values that should never be user-controlled.
• Require confirmation for POST, PUT, PATCH, DELETE, and any operation that changes state.
• Test error responses so users get useful failure messages.

If a REST tool points at an internal system, document the owning team and escalation path.

API Upload Boundary

Use Manual Upload or a supported Data connector for the first data pack. Use an API-based upload only when the currently deployed public REST API reference explicitly documents the upload or ingestion endpoint, authentication, request and file limits, response schema, and failure behavior. Do not build onboarding instructions around browser-observed, private, or undocumented endpoints. If that public contract is absent, treat API upload as unsupported for this onboarding path and confirm the requirement with the product owner.

MCP Tools

MCP servers can expose broad capability through a single connection. Treat them like privileged tools:

• Know who owns the server.
• Review custom headers and secret handling.
• List the tool groups and functions the server exposes.
• Require confirmation for write-capable tools until the functions are proven safe.
• Keep MCP access limited to the teams that need it.

There are two separate MCP directions:

• An MCP Connection brings a third-party MCP server into Siesta AI as agent or workflow tools. See MCP Connection.
• The Siesta AI MCP Server lets an external AI client use the Siesta AI MCP surface. Its client setup is documented under Developers > MCP.

Govern Siesta AI MCP OAuth

The organization must make the MCP Server surface available before members can obtain its setup from Profile > Apps & Extensions. For OAuth clients, apply these controls:

1. Tell users which MCP clients are approved by the organization.
2. Require users to start the authorization from the client and verify the client name and host on the Siesta AI consent screen.
3. Review the requested mcp scope and, when present, offline_access. OAuth does not expand the signed-in user's Siesta AI permissions.
4. Treat Cancel as a completed denial. The user must return to the client and start a new request if they change their mind.
5. For an invalid or expired request, restart from the client instead of reusing a callback URL or authorization value.
6. Review the resulting tool activity through the normal conversation and Tool Executions controls.

Do not place OAuth request values, authorization codes, tokens, API keys, client secrets, or callback URLs in public instructions or screenshots. Do not describe a client as marketplace-approved unless that status has been separately verified.

Remote MCP operational protections

• OAuth access tokens must carry the mcp scope and be issued for the MCP resource. offline_access is requested only when the client needs a refresh token; neither scope expands the signed-in user's existing Siesta AI permissions.
• API-key clients send X-Api-Key together with the organization identifier. OAuth clients send a bearer token. A request containing both an API key and an OAuth bearer token is rejected instead of choosing one identity silently.
• The browser authorization endpoint is limited per source IP to 120 requests per minute. On HTTP 429, clients must wait for the number of seconds in Retry-After instead of immediately retrying.
• Keep client, agent, conversation, workflow, skill, and Graph access within the signed-in identity's effective permissions. Discovery of a tool does not grant access to every referenced object.
• Review MCP tool metadata and governance, require confirmation for state-changing calls, and verify the resulting object or external action after execution.

These controls describe the current protocol surface. They are not evidence that a client or integration has been approved, certified, or published in a third-party marketplace.

Platform Tools

Platform Tools are built-in Siesta AI capabilities assigned to agents. Review them before publishing an agent template or sharing an agent broadly.

Platform Tool	Use when	Admin risk
Task Management	The agent should create Siesta tasks	Low-quality task creation or duplicate tasks
Grounding with Google Search	The agent must verify current public information	External source quality and citation review
Web scraper	The agent should read a specific page URL	Scraping policy, sensitive URLs, or stale page context
Image generation	The agent should create a PNG image through a supported OpenAI model	Brand, rights, safety, and factual-review requirements for generated images
Sandbox	The agent should run commands or explicitly publish files from an isolated conversation workspace	Command review, base image, network access, transfer limits, and workspace reset
Platform Tools	The agent should manage Siesta platform objects	Agent, Memory, template, or platform configuration changes
Orchestration	The agent should route work to sub-agents	Cost, call volume, and unclear ownership
JavaScript executor	The agent should run scripts or process structured files	High autonomy and logic errors

Use advanced Platform Tools only for admin or power-user agents until they have a tested operating pattern.

API Keys And Webhooks

Use Organization > Api Keys for server-side integrations. API keys should never be embedded in browser code, public pages, screenshots, prompts, or client apps.

Use Webhooks when an external system should trigger a Siesta AI workflow. Each webhook should have:

• a name that identifies the source system,
• an active/inactive state,
• an assigned API key,
• a workflow owner,
• a sample payload,
• a failure and replay plan.

Treat webhook callers as server-side integrations. Do not rely on the webhook URL alone as the trust boundary; pair it with the assigned API key and rotate that key when ownership or environment changes.

Keep webhooks inactive until the calling system is ready.

Approval Rules

Use confirmation for functions that send messages, create or update external records, modify permissions, publish content, delete data, move files, trigger production processes, or touch financial/customer data.

Do not rely only on prompt wording for safety. Function-level access is the enforceable control; prompt instructions are supporting guidance.

Release Checklist

• Credentials are stored in the connection.
• The connection is not shared more broadly than needed.
• High-impact functions require confirmation.
• REST/MCP schemas are tested with real parameters.
• Failed calls return actionable errors.
• Tool Executions show arguments, status, result, execution time where available, and approval state.
• A business owner knows how to verify the outcome in the target system.

Attach only accepted tools when you prepare production agents and workflows for teams.