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.| Aspect | Native Tools | MCP Connectors |
|---|---|---|
| Origin | First-party, ships with the platform | Third-party MCP servers (yours or vendor-supplied) |
| Credentials | None — pre-provisioned by the platform | OAuth, client credentials, or static API keys per connector |
| Configuration | Declarative JSON on the prompt version | Connector definition + authorization at session time |
| Scope | Stateless utilities (search, fetch, sandbox) | Stateful business systems (CRM, ticketing, custom APIs) |
| Versioning | Carried inside the prompt version | Maintained separately on the connector record |
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.- Open the agent and select the version you want to edit (or create a new version).
- Open Native Tools in the version configuration panel.
- Select the tool you want to enable.
- Provide the tool’s configuration (or accept defaults).
- Save the version.
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