TL;DR:

  • Toolhouse.ai is a managed MCP tool store — your agents call hosted tools without you deploying MCP servers.
  • Connect in minutes: install the SDK, point your LLM at Toolhouse’s tool list, and tools run on their infrastructure.
  • Good fit when you want tool capabilities fast; less suitable if you need custom logic or sensitive data to stay on-premises.

Building useful AI agents usually means giving them tools: the ability to search the web, execute code, read files, send emails, query databases. The Model Context Protocol standardised how tools and agents communicate, but it left the question of where MCP servers actually run as your problem to solve.

Toolhouse.ai answers that question by hosting the servers for you. You get a catalogue of ready-to-use tools. Your agent SDK fetches the tool list, the user triggers a tool call, and Toolhouse’s cloud handles execution. You never run a server.

What Toolhouse Actually Provides

The core product is a tool store — a hosted registry of MCP-compatible tools your agents can call. The catalogue covers the use cases that come up repeatedly in agent work:

  • Web search and scraping: real-time search results, page content extraction
  • Code execution: sandboxed Python, useful for agents that generate and run data analysis
  • Email and calendar: send emails, read inbox, create calendar events via standard OAuth flows
  • Memory and storage: persistent key-value storage across agent sessions
  • File operations: read, write, and convert documents
  • Image generation: generate images via diffusion models

Each tool is available as an MCP endpoint. Toolhouse handles the auth, the rate limits, the retries, and the infrastructure keeping it running.

How Integration Works

Toolhouse provides SDKs for Python and TypeScript. The integration pattern is straightforward regardless of which LLM you’re targeting.

from toolhouse import Toolhouse
from anthropic import Anthropic

client = Anthropic()
th = Toolhouse(api_key="your-toolhouse-key")

messages = [{"role": "user", "content": "Search for the latest news on AI regulation and summarise it"}]

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    tools=th.get_tools(),  # Fetches your enabled tools from Toolhouse
    messages=messages
)

# If the model called a tool, run it on Toolhouse's infrastructure
if response.stop_reason == "tool_use":
    tool_results = th.run_tools(response)  # Executes remotely, returns results
    messages.append({"role": "assistant", "content": response.content})
    messages.append({"role": "user", "content": tool_results})
    
    # Continue the conversation with tool results
    final_response = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=4096,
        tools=th.get_tools(),
        messages=messages
    )

The same pattern works with OpenAI, Gemini, and any OpenAI-compatible endpoint. th.get_tools() returns tool definitions in whatever format the target API expects; th.run_tools() routes execution to Toolhouse’s infrastructure and returns results in the right format for the next API call.

The Tool Store and Bundles

In your Toolhouse dashboard, you enable tools from the catalogue and group them into bundles. A bundle is a named set of tools — “research-agent-tools”, “customer-support-tools” — that you can load selectively per agent or per conversation.

# Load only the tools for a specific workflow
tools = th.get_tools(bundle="research-agent-tools")

This keeps agents focused. A customer support agent doesn’t need code execution; a data analysis agent doesn’t need email sending. Bundles also let you iterate on tool sets without changing agent code — enable or disable tools in the dashboard, and the agent picks up the change on its next call.

Writing Custom Tools for Toolhouse

If the built-in catalogue doesn’t cover your needs, you can publish custom tools to your Toolhouse account. Custom tools are functions you write that Toolhouse hosts and executes on your behalf.

# tool_definition.py — deployed to Toolhouse, not run locally
from toolhouse import tool

@tool
def get_customer_order_status(customer_id: str, order_id: str) -> dict:
    """
    Retrieve the status of a specific customer order.
    
    Args:
        customer_id: The unique customer identifier
        order_id: The order number to look up
    
    Returns:
        Order status, estimated delivery date, and tracking URL
    """
    # Your business logic here — Toolhouse runs this in their sandbox
    result = your_order_database.query(customer_id, order_id)
    return {"status": result.status, "delivery": result.eta, "tracking": result.url}

Once deployed, your custom tool appears in the tool list alongside the catalogue tools. The agent calls it the same way; Toolhouse executes it the same way.

Toolhouse vs. Self-Hosted MCP vs. Composio

The managed tool hosting space has a few options worth comparing:

Self-hosted MCP servers: Maximum control, no vendor dependency, tools can access your internal systems directly. Requires you to build, deploy, and maintain the server infrastructure. Right choice when tools need access to private databases or when data must not leave your environment.

Composio: Focused primarily on SaaS integrations — GitHub, Slack, Salesforce, Linear, and hundreds of others — with managed OAuth handling. Strong for connecting agents to the SaaS stack; thinner on general-purpose tools like code execution or web scraping.

Toolhouse: Broader tool catalogue including non-SaaS capabilities (code execution, memory, file handling), cleaner API for multi-LLM support, and simpler bundle management. OAuth-backed integrations are available but the catalogue is smaller than Composio’s for SaaS connectors specifically.

For most agent projects that want to move quickly without standing up infrastructure, Toolhouse reduces the time from “I want this tool” to “the agent is using this tool” to under ten minutes. That’s the core proposition.

Limitations to Know

Data leaves your environment: Tool execution happens on Toolhouse’s infrastructure. Any data the agent passes to a tool — queries, content, context — goes to Toolhouse’s servers. For regulated industries or sensitive customer data, review their data processing terms before adopting.

Cold starts on custom tools: Custom tool execution has occasional cold start latency on first invocation in a session. For latency-sensitive workflows, warm your tools or use the built-in catalogue tools, which are always warm.

Catalogue gaps: The built-in catalogue covers common use cases well, but if you’re building something niche — interacting with a specific hardware API, querying a domain-specific data source — you’ll be writing custom tools anyway, at which point the difference from self-hosting narrows.

Getting Started

Toolhouse has a free tier that covers modest tool call volumes. For most agent prototyping work, you won’t hit the limits before knowing whether it suits the use case.

pip install toolhouse

Set TOOLHOUSE_API_KEY in your environment, enable tools in the dashboard, and the integration above is functional. For TypeScript projects, the same pattern applies with npm install @toolhouse/sdk.

For teams building multiple agents across different frameworks, the multi-LLM abstraction is genuinely useful — one integration pattern regardless of whether you’re using Anthropic, OpenAI, or an open-source model via a compatible endpoint.