Tools Available to Claude: Built-In and Custom Options

When people ask what tools are available to Claude, they usually mean one of two things: the built-in capabilities Anthropic ships with Claude (web search, code execution, computer use, etc.), or the custom tools a developer can define and hand to Claude through the API. Both exist, and they solve different problems.

This article covers both categories, what each one is actually good for, and how to wire up your own tools if the built-in set doesn't cover your use case.

Built-in tools Claude can use

Anthropic exposes a small number of first-party tools that Claude can call without you writing any implementation code. They're enabled per-request and run on Anthropic's infrastructure (or in a sandboxed environment for code execution).

• Web search — Claude issues search queries and reads results before answering, useful for questions that need current information beyond its training data.
• Code execution / analysis tool — Claude writes and runs code (commonly Python) in a sandbox to do calculations, parse data, or generate charts, then reports back the output.
• Computer use — Claude can control a virtual desktop: move a mouse, click, type, and read the screen. This is aimed at automating GUI-based workflows rather than API-based ones.
• Text editor tool — lets Claude view and edit files directly, mainly used in coding agents like Claude Code.
• Bash tool — gives Claude a shell to run commands in, again mostly relevant to coding-agent setups.

These are convenient because Anthropic maintains the execution environment. The tradeoff is you have less control over sandboxing, cost, and exactly how results are returned, and not every built-in tool is available on every plan or every API surface.

Custom tools: the more common case

For most product integrations, "tools available to Claude" really means tools you define yourself using the tool use (function calling) mechanism. You describe a function — its name, purpose, and input schema — and Claude decides when to call it based on the conversation. Your application executes the actual logic and returns the result.

A minimal tool definition looks like this:

{
  "name": "get_order_status",
  "description": "Look up the current status of a customer order by ID",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string" }
    },
    "required": ["order_id"]
  }
}

When Claude decides to use it, the API response contains a tool_use block with the tool name and the arguments Claude generated. Your code runs the real lookup, then you send the result back in a tool_result block so Claude can continue the conversation with that data in hand.

This pattern is how Claude gets access to things Anthropic could never build in-house: your database, your internal APIs, your payment provider, your CRM, your ticketing system, anything with a callable interface. In practice this is the tool set that matters most for production apps, because it's the one you fully control.

Typical tools developers give Claude

Across real integrations, the most common custom tools fall into a few buckets:

• Data lookups — order status, user profile, inventory, account balance
• Actions with side effects — create a ticket, send an email, update a record, issue a refund
• Calculations — pricing logic, tax computation, unit conversion
• External APIs — weather, currency exchange, shipping rates, geocoding
• Search over your own data — vector search, SQL queries, document retrieval

A good rule: give Claude the smallest number of tools that fully covers the task. Overlapping or vaguely-scoped tools make it harder for Claude to pick the right one and increase the chance of malformed calls.

Combining built-in and custom tools

You can mix built-in and custom tools in the same request. For example, Claude might use web search to gather context, then call your custom create_ticket tool to log a support case with that context included. There's no conflict between the two systems — they're just two ways of expanding what Claude can act on.

Running tool use through SubToAPI

If you're already sending Claude requests through SubToAPI, custom tool definitions work exactly as documented — you pass your tools array with the request, and tool_use/tool_result blocks flow through the same way. SubToAPI sits in front of your existing Claude access and gives you an application-scoped key (sub_live_...), so you get the same tool-calling behavior plus usage metadata per key, per team member, without changing how you structure tool calls.

A basic call with a tool defined looks like this:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "tools": [
      {
        "name": "get_order_status",
        "description": "Look up order status by ID",
        "input_schema": {
          "type": "object",
          "properties": { "order_id": { "type": "string" } },
          "required": ["order_id"]
        }
      }
    ],
    "messages": [
      { "role": "user", "content": "Where is order 48213?" }
    ]
  }'

Full details on request shape, streaming responses, and handling tool_result turns are in the docs, with a dedicated page on tool use and a quickstart if you're setting this up for the first time. If you want to test it before committing, plans start with a free trial at signup, and pricing for team/scale seats is on the pricing page.

questions

Do I need Anthropic's built-in tools to use custom tools? No. Custom tools (function calling) are independent of built-in tools like web search or code execution. You can use custom tools on their own, or combine them with built-in ones in the same request.

Can Claude call multiple tools in one turn? Yes, Claude can request several tool calls in a single response if the task requires it. Your code executes each one and returns the results, and Claude incorporates all of them before replying.

What happens if a tool call fails on my end? You return a tool_result marked as an error with a short explanation. Claude reads that and can retry with different arguments, ask a clarifying question, or explain the failure to the user.