Custom tools

Sometimes the platform needs to do something it can't do out of the box — call your internal pricing service, hit a vendor API, run a custom check against your data warehouse. Custom tools let you register those capabilities so the reasoning agent can call them as part of an answer.

Where to find this

Account menu → Tools (/settings/tools). Per-project — switching projects switches the registry.

What's on the Project tools screen

• Title: "Project tools".
• Description: "Add MCP servers or HTTP endpoints the agent can call. Used for creative concept generation, external trend lookups, custom analytics endpoints, anything that's not in the warehouse."
• Counter: "N registered · M enabled".
• + Add tool button (top-right).
• Tool rows. Each card shows:
  • Tool name (e.g. "Google Trends") + slug (google_trends) + kind badge (MCP or HTTP) + enabled status.
  • Description in one line.
  • Config preview — e.g. SERVER_URL: https://trends-mcp.example.com for MCP tools, endpoint for HTTP.
  • Disable and Remove action buttons on the right.

Example seen in the wild: a Google Trends MCP tool registered for trend lookups — "Fetch current and historical search-trend data for a query."

Tool kinds

Two kinds of custom tools are supported:

Status: in progress. The MCP tool kind is registered in the tool catalogue but the runtime execution path is a stub today — calls return "MCP client runtime not yet enabled." Use HTTP for any tool you need working now. Roadmap is to enable MCP execution in a future release.

Adding an HTTP tool

1. Open Settings → Tools → New tool.
2. Pick HTTP as the kind.
3. Fill in:
   • Name — what shows in the agent's tool list (e.g. "lookup-pricing-tier")
   • Description — what the tool does, in one line. The reasoning agent uses this to decide when to call the tool.
   • Endpoint URL — the HTTPS endpoint to call
   • Input schema (JSON schema) — what the agent must pass in
   • Output schema (optional) — what the tool returns; helps the agent use the result
   • Auth header (optional) — Authorization: Bearer ... or similar; encrypted at rest
4. Click Test to send a sample payload and verify the response shape.
5. Enable the tool. The agent can now use it from the next reasoning run onward.

How the agent calls it

When the agent decides a custom tool is the right action, it sends a POST request to your endpoint with a JSON body like:

{
  "input_json": "{\"sku\":\"KAP-001\",\"region\":\"in\"}"
}

input_json is a JSON-stringified version of the input matching your declared schema. Your endpoint must return a JSON object — the agent uses the response as the tool's output.

Adding an MCP tool (limited today)

The MCP kind is currently a registration-only stub. The configuration UI lets you point at an MCP server, but execution returns an error. Use HTTP until MCP is enabled.

When MCP is enabled, you'll be able to point at any MCP server (stdio or HTTP transport), and every tool exposed by that server becomes available to the reasoning agent automatically.

Per-project, not per-workspace

Each project has its own tool registry. A tool registered in Project A is not available to Project B unless you register it there too. This is intentional — tools often need project-specific configuration (different endpoints per environment, different auth tokens per business unit).

Security

• The endpoint URL and auth header are encrypted in the database with the platform's APP_ENCRYPTION_KEY.
• The agent sends only the JSON it composed for the tool — it doesn't relay other parts of the project context to your endpoint.
• Any user with Member role or above can register a tool on a project they have access to. Audit your registry periodically — a tool registered by a former teammate stays active until revoked.

Disabling vs deleting

• Disable — keeps the configuration around but the agent won't call it. Good for "we don't need this right now."
• Delete — permanently removes the registration.

Tips

• Make tool descriptions specific. The agent picks tools based on the description; vague descriptions get vague picks.
• Use input schemas. A tight JSON schema is the single biggest factor in the agent calling your tool correctly.
• Test your endpoint with the Test runner before enabling. It's faster than debugging via a real reasoning run.
• Don't expose your data warehouse via a custom tool — that's what built-in BigQuery / DuckDB are for.

Related

• Skills & Reasoning
• Custom skills