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.
Tool Setup Flow
- Create or select the connection.
- Review available functions, parameters, and credential fields.
- Classify each function as read, draft, write, delete, publish, or administrative.
- Apply organization or connection-level function access: enabled, enabled with confirmation, or disabled.
- Share the connection only with the teams that need it.
- Assign the tool to the agent, skill, prompt, or workflow.
- Test with safe data.
- 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.
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.
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 |
| Code interpreter | The agent should analyze files or produce outputs | Data exposure, generated files, and user trust in calculations |
| 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.