Built-in tools

Runtype provides built-in tools that an Agent or Flow can call without any code. The following table lists the core tools, their IDs, and the models that they work with:

Choose a tool marked Any model when you want to use it with different model providers. A provider-native tool works only with the models listed for it. The tool picker hides it for every other model.

The Anthropic tools don’t list Claude Sonnet 5 or Claude Opus 5, so the picker hides them for those models. To search the web with a 5-series Claude model, use Exa or Firecrawl.

OpenAI Web Search, Anthropic Web Search, xAI Web Search, xAI X Search, and Google Search each add a per-search fee to the model token costs. Review these charges under Cost by built-in tool in Usage data.

Other built-in tools

Runtype also provides the following tools. The tool picker groups them by category:

The Sandbox category tools work in any Agent or Flow. Each call runs in /workspace. To keep one sandbox across calls, start it with sandbox:create and pass its sandboxId to the sandbox:session_* tools. For the Linux computer that you turn on for an Agent, see Agent Sandbox tools.

Before you begin

Add the required provider keys before you configure a tool:

• GPT Image 2.5: Use a Runtype platform key or add an OpenAI API key in Settings > Models.
• OpenAI Web Search: Add an OpenAI API key in Settings > Models.
• Anthropic Web Search and Anthropic Web Fetch: Add an Anthropic API key in Settings > Models.
• xAI Web Search and xAI X Search: Use a Runtype platform key or add an xAI API key in Settings > Models.
• Google Search: Use a Runtype platform key or add a Google API key in Settings > Models.
• Exa: Use a Runtype platform key or add an Exa API key in Settings > Integrations.
• Firecrawl: Use a Runtype platform key or add a Firecrawl API key in Settings > Integrations.
• Massive Web Render: If the tool is enabled for your account, use a Runtype platform key or add a Massive API key in Settings > Integrations.
• Semantic Search: Add an OpenAI API key in Settings > Models for embeddings. If you need background on vector data, see What are Records?.
• Decision judgment: Credentials depend on the selected decision model. Jev through Vercel uses your organization’s gateway key or eligible Runtype platform funding. Native OpenAI Decisions requires your organization’s OpenAI key, without platform fallback. Cloudflare uses eligible Runtype platform funding. See Decision models.
• Send Email: No key is needed to send from the platform-managed sender. To send from your own domain, add a Resend API key in Settings > Integrations.

Add tools to an Agent

To add built-in tools to an Agent, follow these steps:

1. Open the Agent.
2. In the tools strip, click Add tool, or press Cmd+T (Ctrl+T on Windows). The tool picker opens.
3. Select the tools to attach. The picker groups tools by category, such as Web search and Images, and lists only tools that are compatible with the Agent’s model.
4. Optional: If a tool shows Set up, click Set up, enter its settings, and click Save.
5. Close the tool picker and save the Agent.

For the other tool types and the full Agent setup, see Agent tools.

Add tools to a Flow

To add built-in tools to a Flow, follow these steps:

1. Open the Flow and add or edit a prompt step.
2. On the step, click the tools button. It shows No tools until you attach a tool. The tool picker opens.
3. Select the tools to attach. The picker lists only tools that are compatible with the step’s model.
4. Optional: If a tool shows Set up, click Set up, enter its settings, and click Save.
5. Click Save to apply the tools to the step, then save the Flow.

For a complete Flow walkthrough, see Creating and editing flows.

Invoke a built-in tool directly with a Tool Call step

A prompt step lets the model decide when to call a tool. When the call must happen at a fixed point every run, use a Tool Call step instead and set its toolId to the catalog ID:

{
  "type": "tool-call",
  "name": "Store the report",
  "config": {
    "toolId": "builtin:store_asset",
    "parameters": { "url": "{{reportUrl}}", "filename": "report.pdf" },
    "outputVariable": "storedAsset"
  }
}

toolId accepts any built-in or platform catalog ID (builtin:store_asset, builtin:browser:open, builtin:slack:send_message, platform:orthogonal:<vendor>:<op>) as well as a saved Tool. To supply per-tool settings, use the optional config.toolConfig object. It takes the same values that a prompt step’s tool configuration collects.

Test a tool

To check that a tool works before you attach it, run it directly. The following request runs Exa with a search query:

curl -X POST https://api.runtype.com/v1/tools/builtin:exa/execute \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"parameters": {"query": "Cloudflare Workers pricing"}}'

Replace YOUR_API_KEY with your Runtype API key. A successful call returns the tool’s result with its toolId and toolName. To pass a tool’s settings, add a toolConfig object beside parameters.

The runtype CLI runs the same call:

runtype tools execute builtin:exa --input '{"query": "Cloudflare Workers pricing"}'

Use --config to pass tool settings as JSON.

To look up tool IDs and parameters, use these endpoints:

• GET /v1/tools/builtin: list every built-in tool.
• GET /v1/tools/builtin/compatible?model=YOUR_MODEL_ID&provider=YOUR_PROVIDER: list the tools that work with a model. For example, set model to claude-haiku-4-5 and provider to anthropic.
• GET /v1/tools/builtin/YOUR_TOOL_ID/schema: get one tool’s parameter schema and default configuration. Replace YOUR_TOOL_ID with a tool ID, such as builtin:exa.

In an Agent definition, list the IDs in tools.toolIds and put per-tool settings in tools.toolConfigs, keyed by the same ID. For an example, see Decision judgment.

Require approval for tools that act for you

Some built-in tools act outside Runtype. Send Email sends real email, Browser tools act on live sites, and UCP Complete Checkout starts a real purchase. To pause an Agent until a person approves these calls, add them to the Agent’s tool approval list. The following configuration requires approval for email, every Browser tool, and checkout:

{
  "tools": {
    "approval": {
      "require": [
        "builtin:send_email",
        "builtin:browser:*",
        "builtin:ucp_complete_checkout"
      ]
    }
  }
}

For the dashboard setting and how each Surface shows the prompt, see Safety.

GPT Image 2.5

Use GPT Image 2.5 to generate images from text in an Agent conversation or Flow. The tool returns a generated image that you can view or download.

The following settings control image generation:

If you request a resolution outside those size bounds, the tool adjusts it to the nearest accepted resolution and keeps the orientation you asked for. A request for a wide banner stays wide: a 1200x400 banner is scaled up to 1424x480 rather than squared to 1024x1024.

For example, ask an Agent to “Create a logo for a coffee shop.” The Agent calls GPT Image 2.5 and returns the generated image.

Runtype stores a permanent copy of each generated image and returns its hosted URL. If storage fails, the tool returns the original image URL or media content and the execution continues.

The earlier tool IDs builtin:gpt-image-2 and builtin:dalle remain accepted, and both run on GPT Image 2.5. They no longer appear in the tool picker. Use builtin:gpt-image-2-5 for new configurations.

OpenAI Web Search

Use OpenAI Web Search with a compatible OpenAI model to retrieve current information from the web during a conversation.

Configure these settings:

• Search context size: Set the context size to low, medium, or high.
• Location context: Optionally set a city and region for location-specific search results.

Anthropic Web Search

Use Anthropic Web Search with Claude Opus 4.x, Claude Sonnet 4.x, or Claude Haiku 4.5 to retrieve current information from the web.

Configure Max uses as a number from 1 to 10. The default is 5.

Anthropic Web Fetch

Use Anthropic Web Fetch with a Claude Sonnet 4.x model to fetch and read content from a specific URL. Use it when your prompt includes a known URL for retrieval.

Configure Max uses as a number from 1 to 10. The default is 1.

xAI Web Search

Use xAI Web Search with a compatible Grok model to search the live web during a conversation. Grok can issue multiple searches during one response.

Configure these optional settings:

• Allowed domains: Restrict results to specific domains.
• Excluded domains: Omit results from specific domains.
• Enable image understanding: Let the model interpret images in search results.

xAI X Search

Use xAI X Search with a compatible Grok model to search posts on X. Grok can issue multiple searches during one response.

Configure these optional settings:

• Allowed X handles: Restrict results to posts from specific handles.
• Excluded X handles: Omit posts from specific handles.
• From date and To date: Limit results to an ISO 8601 date range.
• Enable image understanding: Let the model interpret images in posts.
• Enable video understanding: Let the model interpret videos in posts.

Google Search

Use Google Search with a compatible Gemini model to ground a response in Google Search results. Gemini decides when to search, writes its own queries, and returns inline citations. The compatible models are Gemini 2.5 Pro, Gemini 2.5 Flash, Gemini 3 Flash, Gemini 3 Pro Preview, Gemini 3.1 Pro, and Gemini 3.1 Flash-Lite.

Configure these optional settings:

• includeImageSearch: Also ground on Google Image Search results. The default is false.
• fromDate and toDate: Limit results to an ISO 8601 time window. Set both values, with fromDate earlier than toDate. If you set only one, the tool applies no window.

Exa

Use Exa with any model to search the web with neural or keyword search. Configure optional full text, summaries, highlights, domain filters, and publication-date filters.

Configure these settings:

• Search type: Select auto, neural, or keyword.
• Number of results: Return from 1 to 10 results. The default is 5.
• Content options: Include full text, AI-generated summaries, or highlights.
• Domain filtering: Include or exclude specific domains.
• Date filtering: Limit results to a publication date range.

Use domain filtering to focus research on selected websites, such as documentation sites.

Firecrawl

Use Firecrawl with any model to extract content from a web page. Firecrawl renders JavaScript pages and returns Markdown, HTML, raw HTML, screenshots, or links.

Configure these settings:

• Output formats: Select Markdown, HTML, raw HTML, screenshots, or links.
• Main content only: Keep this setting enabled to remove sidebars, navigation, and footers from the result.
• Wait time: Add from 0 to 30 seconds for dynamic content to load before scraping.

Use Firecrawl to extract a product page as Markdown for summarization or analysis.

Massive Web Render

Use Massive Web Render with any model to fetch pages that resist ordinary HTTP requests. It renders JavaScript, solves CAPTCHAs, retries requests through a residential network, and supports country-based fetching. The tool returns Markdown by default, rendered HTML, or raw HTML.

Massive Web Render appears only when it is enabled for your account. For setup details, see Massive (web rendering).

Configure these settings:

• Output format: Select markdown, rendered, or raw. The default is markdown.
• Country: Enter a two-letter ISO country code, such as us.
• Delay: Add from 0.1 to 10 supplemental seconds before the tool captures content.

Use Massive Web Render when a page returns a 403 response to ordinary requests and you need the rendered content.

Semantic Search

Use Semantic Search with any model to find content in a knowledge base by meaning rather than exact keywords. Add multiple Semantic Search instances to the same Agent or Flow when you need to search different knowledge bases.

Semantic Search supports three providers: Platform Records (pgvector), Weaviate, and Cloudflare Vectorize. Each instance points to one knowledge base, which must already hold embedded content. To load and tune a knowledge base, see Building retrieval that works. To connect Weaviate, see Weaviate (vector search).

Set up a knowledge base instance

To add a Semantic Search instance, follow these steps:

1. In the tool picker, find Semantic Search and click Set up.
2. In Display name, enter a name such as Search Documentation. The model uses this name when it selects the instance.
3. In Provider, select Platform Records (pgvector), Weaviate, or Cloudflare Vectorize.
4. Identify the knowledge base. For Platform Records, select a Record type. For Weaviate, enter the Class name. For Cloudflare Vectorize, enter the Index name.
5. Set the Similarity threshold from 0 to 1. Lower values return more results. Higher values return closer matches.
6. Click Save.

The limit setting controls the maximum number of results per query. Set it from 1 to 20. The default is 5.

Start with a similarity threshold near 0.3 and adjust it based on result quality. A high threshold can omit relevant content. A low threshold can return noisy results.

Decision judgment

Agents using any chat model can call Decision judgment to ask typed questions about text or JSON state and get back probabilities, labels, and scores instead of prose. Select a supported decision model separately for the question set. The stable tool ID is builtin:decision_judge. For what a judgment is and how to act on one, see Judgments.

Configure an instance

A configured instance references a published question set, and the Agent or step supplies only state. Add several instances to the same Agent or Flow when you ask different question sets. The following table lists the instance settings:

This prompt step configuration adds one instance named triage:

{
  "tools": {
    "toolIds": ["builtin:decision_judge#triage"],
    "toolConfigs": {
      "builtin:decision_judge#triage": {
        "questionSetId": "qset_YOUR_QUESTION_SET_ID",
        "displayName": "Ticket triage"
      }
    }
  }
}

Replace qset_YOUR_QUESTION_SET_ID with the ID of your question set. The questions on a configured instance are locked to the referenced question set. A call that also sends questions is refused, so the model can’t rewrite the rubric.

The tool resolves the model in this order: the instance’s model, then the question set’s model, then the default, typesafe-ai/jev.

To run a configured instance outside an Agent or Flow, send the same settings as toolConfig to POST /v1/tools/builtin:decision_judge/execute, with { "state": ... } as parameters. The response adds metadata.judgment with the resolved model, token usage, and estimated cost. For the request and the fields, see Call a configured instance over REST.

An exported Agent or Flow also runs the tool in a self-hosted runtime. The export embeds the question set of each configured instance. For the credentials and key modes, see Run judgments in a self-hosted runtime.

Call the tool ad hoc

Without a questionSetId, the tool is ad hoc: the model supplies inline questions beside state on each call. Use it when the question changes from call to call, such as checking one claim against one piece of evidence. A tool configuration can’t carry inline questions. Save them as a question set instead.

Agent Memory tools

Enable Agent Memory to store facts, preferences, decisions, and events across conversations. Unlike Semantic Search, which queries a knowledge base, Agent Memory stores information associated with an Agent Memory profile. Runtype also records each user and assistant exchange in the background. Agent Memory works with any model and does not need an API key.

To enable Agent Memory, set memory: { enabled: true } in the Agent configuration. For profile scoping and the complete configuration, see Memory.

Runtype adds these tools when memory is enabled:

Configure recall_memory with these optional parameters:

• thinkingLevel: Set the search breadth to low, medium, or high.
• responseLength: Set the synthesized answer length to short, medium, or long.

When memory is not enabled for an Agent, the memory tools return memory_not_enabled instead of failing silently.

Browser tools

Use Browser tools in an Agent or Flow to interact with live web pages. They appear in the Browser category and support quick actions, persistent sessions, and autonomous browsing.

Quick actions

Quick-action tools run against one URL without keeping a session open. Use them to retrieve content from a page and finish the browser operation in one call.

• browser:screenshot: Capture a screenshot of a rendered page.
• browser:content: Return the fully rendered HTML after JavaScript runs.
• browser:markdown: Convert a rendered page to Markdown.
• browser:scrape: Extract data from CSS selectors on a rendered page.
• browser:json: Extract structured JSON from a rendered page.
• browser:links: Retrieve links from a rendered page.
• browser:snapshot: Return rendered HTML and a screenshot together.

Session tools

Session tools share a persistent browser session across turns in the same conversation. Use browser:open to start a session, then pass its sessionId to the other session tools.

• browser:open: Start a session and load a URL.
• browser:navigate: Navigate to a URL in the session.
• browser:click: Click an element.
• browser:type: Type into an input.
• browser:scroll: Scroll the page.
• browser:session-screenshot: Capture the current session view.
• browser:evaluate: Run a script against the page.
• browser:session-info: Read the current session state.
• browser:close: End the session.

Sessions close after 2 minutes of inactivity and have a 10-minute maximum lifetime. Finish multi-step work within that window.

Hand a session to a person

Hand a browser session to a person when the page needs a login, multi-factor authentication, CAPTCHA completion, payment, or another human decision. Do not share credentials with a browser tool.

• browser:get_live_view: Return a Live View URL that opens the page in a browser tab. Anyone with the URL can control the page, so share it only with the intended person.
• browser:request_handoff: Return a Live View URL and instructions for a person. The tool returns immediately. The person selects Done or Failed in Live View when the task ends.
• browser:get_handoff_state: Return whether the handoff is active or complete, including the person’s success result.

Set a handoff timeout from 30 seconds to 30 minutes. The default is 10 minutes. While a handoff is active, the session’s inactivity timer and maximum lifetime are paused. Each session supports up to 10 handoffs and 60 minutes of total handoff time.

After you call browser:request_handoff, share the Live View URL and poll browser:get_handoff_state until its status is completed. If the handoff reports failure, use browser:session-screenshot to confirm the page state before continuing.

Autonomous browsing with browser:agent

Use browser:agent when you want a browser tool to complete a web task from a natural-language goal. Provide a startUrl for a new session or a sessionId from browser:open for an existing session.

Configure the result with these options:

• Start a session: Set startUrl.
• Use an existing session: Set sessionId.
• Choose the output: Set outputSchema for structured JSON. Without it, the tool returns a text summary.

Session tools use flat per-action billing. browser:agent uses dynamic billing based on usage, with the default account margin of 20%.

browser:agent plans its steps with Gemini 3.5 Flash Lite through the Runtype model gateway on Runtype’s platform credentials, so the page content the task reads is sent to Google. Gemini tokens are billed at catalog rates plus the account margin and appear under Browser agent in usage. The task runs on Cloudflare Workers AI instead when any of these apply:

• The organization uses BYOK-only model credentials or zero data retention.
• The organization’s platform spend is blocked.
• The organization has its own Google or Vercel AI Gateway key. Browser tasks never use your own model keys.

Limit where browser tools can go

To restrict the sites a Browser tool can load, add a domainPolicy to that tool’s configuration in the Agent’s toolConfigs:

{
  "tools": {
    "toolIds": ["builtin:browser:open", "builtin:browser:agent"],
    "toolConfigs": {
      "builtin:browser:open": {
        "domainPolicy": {
          "allowedDomains": ["example.com", "*.example.com"],
          "blockedDomains": ["ads.example.com"]
        }
      },
      "builtin:browser:agent": {
        "domainPolicy": { "allowedDomains": ["*.example.com"] }
      }
    }
  }
}

• An entry is a bare hostname. example.com matches only that host. *.example.com matches its subdomains but not example.com itself, so list both to allow both.
• A host that matches blockedDomains is always blocked. When allowedDomains is set, every host that it does not match is blocked. allowedDomains accepts at most 50 entries.
• The policy applies to every page load in the browser, including links the model clicks, redirects, scripts, images, and popups. A popup that opens on a blocked host is closed.
• A session keeps the policy of the browser:open call that started it. A domainPolicy on a session action (browser:navigate, browser:click, browser:type, browser:scroll, browser:session-screenshot, browser:evaluate, or browser:agent with a sessionId) can narrow that session’s policy but cannot widen it. The narrowed policy applies to every later call in that session.
• browser:session-info, browser:close, browser:get_live_view, browser:request_handoff and browser:get_handoff_state load no page, so saving a domainPolicy on them fails. Set the policy on browser:open instead.
• Only the tool configuration sets the policy. A tool call whose arguments include domainPolicy fails, so a model cannot change the policy.
• Quick-action tools apply the policy to the requested url and to every request the page makes. A policy replaces any allowRequestPattern in the call and adds its blocked hosts to any rejectRequestPattern.

File operations

Use File Operations tools in an Agent or Flow to store files, publish pages, and generate PDFs. They appear in the File ops category.

Store an asset

Use store_asset to store a file from an HTTP or HTTPS URL or from base64-encoded content. The tool returns a public URL or a time-limited signed URL. Stored files are served as downloads instead of rendered inline.

Configure store_asset with these parameters:

Pass exactly one of url or content. Files have a 25 MB size limit. To publish HTML that renders in a browser, use publish_page instead.

Pass media between tools

When a tool returns binary media, such as a browser:session-screenshot PNG, a generated image, or a text-to-speech clip, Runtype stores the bytes and adds a runtype-asset:// handle to the tool result. The model sees the image and the handle in the same turn. On later turns, the transcript keeps only the handle, so the model never re-types the base64 content.

To pass the media to another tool, the Agent puts the handle in a parameter instead of the bytes:

• store_asset and publish_page: accept the handle in the url parameter. The bytes are read from storage server-side, not downloaded.
• Base64 parameters: any parameter whose schema declares contentEncoding: "base64" resolves a handle to the stored bytes before the tool runs. Built-in examples are store_asset.content, publish_page.content, and send_email.attachments[].content. Custom external and MCP tools can declare the same keyword; see Receive binary results from other tools.

Handles are scoped to your organization and expire after 7 days. The same behavior applies on every execution path: Agent turns, Flows, execute_tool on the REST API and MCP server, and Code Mode. When the chain needs logic between hops, such as a loop or a branch, use Code Mode.

Send Email

Use Send Email (builtin:send_email) to send transactional email through Resend from an Agent or Flow. It works with any model. The tool sends real email, so consider requiring approval for it. For the setting, see Require approval for tools that act for you.

The following table describes the parameters:

To attach a file that another tool produced, pass its handle as the attachment content. For details, see Pass media between tools.

Temporal tools

Use Temporal tools when your Agent needs a current time, a time-zone conversion, an elapsed-time calculation, a stored conversation time zone, or a reminder. These tools work with any model and do not need an API key.

The following table describes the Temporal tools:

When you omit a time zone, Runtype uses the explicit tool parameter, the Agent’s default time zone, the conversation’s stored time zone, or UTC. Set the Agent’s default time zone in the temporal configuration.

Set a reminder

Use Set Reminder to schedule a one-time run of the same Agent. The scheduled Agent receives the message value when the reminder fires and can act on it, including sending a message or email.

Configure the reminder with these parameters:

Set Reminder is available only to Agents. Reminders count toward your plan’s active schedule limit, along with schedules created in the dashboard or API. For more information, see Plan limits.

Control media visibility

Set the mediaVisibility setting in a tool configuration to control whether the end user and the model receive media produced by that tool.

The following values control media visibility:

The default is both. Use model for an intermediate image that the model uses for reasoning. Use user for media that you want to display without adding it to the model’s context.

Agent Sandbox tools

To give an Agent a Linux computer, turn on Linux computer in the Agent’s Sandbox section. This applies to an Agent that runs on a Runtype model, not to an external agent. To turn on the sandbox and set its persistence, network access, setup commands, and secrets, see Sandbox.

When the sandbox is on, Runtype adds these tools to the Agent:

• bash: run a shell command in /workspace.
• bash_output: read new output from a running command.
• kill_process: stop a running process and its child processes.
• list_processes: list running and recently finished processes.
• read_file: read a file from the sandbox.
• write_file: write a file to the sandbox.
• edit_file: edit a file in the sandbox.
• expose_port: expose a sandbox port through a public preview URL.

By default, the sandbox can reach only package registries, OS mirrors, and GitHub. A bash command that calls any other host fails. To reach more hosts, add them to networkAccess.allow or choose another network profile.

The bash tool runs in /workspace. Its timeout_ms value sets when the tool returns control, not when it stops the command. Runtype caps timeout_ms at 30,000 milliseconds, or 240,000 milliseconds when slow_ok is true. If the command continues, the result includes a process_id, partial output, and a running status.

When a command returns a deliveryId, pass that value as ack_delivery_id to the next bash_output call. Use wait_for_exit_ms to wait for the process to finish instead of polling in a loop. The tool caps the wait at 240,000 milliseconds.

Use list_processes to check processes without replaying their output. Use kill_process to stop a process, then call bash_output to read any remaining output.

Files you write to /workspace remain available to later calls in the same execution. The sandbox keeps files, not running processes. After the sandbox shuts down, a process does not resume.

Coding-agent sessions

When config.sandbox.codingAgents lists a coding agent, the Agent can hand a task to that coding agent inside the sandbox and follow its progress as a typed session. opencode is the only supported coding agent. The Agent gets six more tools:

• agent_session_start: start the coding agent on a task. Set mode to build to let it edit files, or plan to ask for a plan without edits.
• agent_session_prompt: send a follow-up message after the previous prompt stops.
• agent_session_status: read the current digest of a session.
• agent_session_events: page through the session’s recorded events.
• agent_session_cancel: stop the running prompt. The session stays open for a later prompt.
• list_agent_sessions: list sessions with their status, for example to recover a session_id.

Each session tool returns a compact digest instead of raw output. The digest holds the session status, the plan, recent tool titles, counters, a short tail of the latest text, and a deliveryId. Tool arguments, tool results, file contents, and reasoning never appear in it.

A typical loop works like this:

1. Call agent_session_start with a task and a wait_ms value. The tool waits inside the sandbox, up to 240,000 milliseconds, instead of returning at once.
2. To keep waiting, call agent_session_status with the previous deliveryId as ack_delivery_id, plus wait_ms. The acknowledgement moves the digest window forward. If you omit it, the tool replays the unacknowledged digest, so a lost call drops nothing.
3. When status is stopped, read finalText for the result. It appears once, on the digest that first reports the stop.
4. To check the actual changes, run git diff with the bash tool. For more detail, page agent_session_events from offset 0 and continue from nextOffset.

Use wake_on to choose which events end a wait early: stop (the prompt finished), pending (a permission request awaits a decision), or plan (a plan step changed). The default is stop and pending.

The event log keeps a limited number of events. Each event keeps tool titles, kinds, statuses, file locations, and short message text. It does not keep tool arguments, tool results, file contents, or reasoning.

A workspace policy answers the coding agent’s permission requests. An edit, delete, or move must declare a location under the session’s working directory, or the policy rejects it. Shell commands, reads, and searches are allowed.

If agent_session_start times out, retry it with the same session_id. An existing id resumes that session instead of starting a second one.

Use platform keys or your own API keys

Runtype provides platform keys for several tools that Runtype runs for you, such as Exa and Firecrawl. Platform keys are shared and rate-limited. Use them for development and lower-volume workloads.

Connect your own API keys in Settings when you need dedicated rate limits or direct provider billing. For a comparison, see Platform keys vs. bring your own key (BYOK).

Troubleshoot built-in tools

The following issues are the most common:

• A tool doesn’t appear in the picker: The Agent or prompt step uses a model that the tool doesn’t support. Check the model against the table at the start of this page, or run the compatible-tools request in Test a tool. Massive Web Render also appears only when it is enabled for your account.
• A tool returns “API key not configured”: No key is available for that provider. For example, Exa returns Exa API key not configured. Please add your Exa API key in Settings > Integrations. Add the key where the message says. Semantic Search returns a similar error when no OpenAI key is available for embeddings.
• A sandbox command can’t reach a host: The sandbox network profile blocks the host. Add the host to networkAccess.allow, as described in Agent Sandbox tools.

Best practices

Use these practices when you configure tools:

• Describe tool use: Tell your Agent when and how to use each tool.
• Limit result counts: Set a result limit that matches the task.
• Combine tools: Pair Exa with Firecrawl for research, or pair Semantic Search with a prompt step for retrieval workflows.
• Use multiple knowledge bases: Configure separate Semantic Search instances for different data sources, such as documentation and customer Records.

Next steps

Follow these links to continue:

• What are Tools?: compare built-in, custom, and external tools.
• Agent tools: attach tools to an Agent and write tool descriptions.
• Connecting AI model providers: configure provider keys for tools that require them.
• Available AI models: review model compatibility for provider-native tools.
• Resend (email sending): send email from your own domain through Resend.
• Cloudflare (Vectorize and Browser Rendering): connect Cloudflare Vectorize and Browser Rendering.
• Granola integration: connect Granola and use meeting notes in Agents and Flows.