Skip to main content

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

  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.

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 ToolUse whenAdmin risk
Task ManagementThe agent should create Siesta tasksLow-quality task creation or duplicate tasks
Grounding with Google SearchThe agent must verify current public informationExternal source quality and citation review
Web scraperThe agent should read a specific page URLScraping policy, sensitive URLs, or stale page context
Code interpreterThe agent should analyze files or produce outputsData exposure, generated files, and user trust in calculations
Platform ToolsThe agent should manage Siesta platform objectsAgent, Memory, template, or platform configuration changes
OrchestrationThe agent should route work to sub-agentsCost, call volume, and unclear ownership
JavaScript executorThe agent should run scripts or process structured filesHigh 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.