Skip to main content

Documentation Index

Fetch the complete documentation index at: https://budecosystem-b7b14df4.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Overview

Native tools are first-party capabilities embedded directly in Bud AI Foundry that agents can call during inference. Unlike MCP connectors, which integrate external systems through credentials and authorization flows, native tools are always available on every project — you enable them per prompt version. The platform ships with three native tools today: Web Search, Web Fetch, and Code Interpreter. Each has its own configuration shape and operational characteristics, but all share the same enablement model and lifecycle.

Native Tools vs MCP Connectors

Both surface as tools the agent can call, but they target different problems.
AspectNative ToolsMCP Connectors
OriginFirst-party, ships with the platformThird-party MCP servers (yours or vendor-supplied)
CredentialsNone — pre-provisioned by the platformOAuth, client credentials, or static API keys per connector
ConfigurationDeclarative JSON on the prompt versionConnector definition + authorization at session time
ScopeStateless utilities (search, fetch, sandbox)Stateful business systems (CRM, ticketing, custom APIs)
VersioningCarried inside the prompt versionMaintained separately on the connector record
You can mix both on the same agent — a single prompt version can enable, for example, Web Search alongside a Salesforce MCP connector.

Enable a Native Tool

Native tools are activated per prompt version so behaviour stays pinned over time and changes go through versioning. The flow is the same for all three tools.
  1. Open the agent and select the version you want to edit (or create a new version).
  2. Open Native Tools in the version configuration panel.
  3. Select the tool you want to enable.
  4. Provide the tool’s configuration (or accept defaults).
  5. Save the version.
Once enabled, the tool is registered with the agent at inference time and the LLM can decide whether and when to invoke it. You do not call the tool from code — the model does.

How Configuration Is Stored

Each native tool defines a schema (the catalog entry) describing its display name, icon, description, and accepted fields. When you enable a tool on a prompt version, only the values you set are persisted — the schema itself stays in the catalog. This keeps prompt-version records small and makes the catalog the single source of truth for default values and validation rules. When the platform ships an updated catalog with new optional fields, existing prompt versions keep their saved configuration unchanged; the new fields take their defaults until you edit the version. Changes that alter behaviour in a non-backward-compatible way are handled through normal prompt versioning.

Operational Considerations

  • Keep tool access aligned with the model’s task — enabling unused tools widens the model’s surface and can hurt instruction-following.
  • For internet-facing tools (Web Search, Web Fetch), treat returned content as untrusted; pair them with guardrails for sensitive workflows.
  • For Code Interpreter, plan capacity — each prompt version provisions an isolated sandbox on demand.
  • Native tools do not require additional credentials, but their actions may still touch billing meters (sandbox compute, search egress) depending on your deployment.

Available Tools

Web Search

DuckDuckGo-backed search returning titles, URLs, and snippets

Web Fetch

Fetch a URL and convert it to markdown, with SSRF protection

Code Interpreter

Isolated Jupyter + bash sandbox for Python and JavaScript