Tool loading

When Claude connects to a profile, FloConnector tells it which tools are available. This page explains what decides that list, why its size matters, and how to keep it working well.

What Claude sees

A profile exposes the tools of the connectors it pins, namespaced by vendor (xero_, servicem8_). Claude loads that list on connect and calls from it. The live count is shown on the profile in the dashboard, so you always know how many tools a given endpoint presents.

What decides the list

Four filters, each narrowing the one before it. A tool has to survive all four to reach the model, which is why the count on a profile is usually far smaller than the connector's catalog.

flowchart TD

    A["<b>1. The catalog</b><br/>Every tool this connector publishes"]

    B["<b>2. The connection</b><br/>What you left switched on for it<br/><i>Connectors page, applies to every profile</i>"]

    C["<b>3. The profile</b><br/>The subset you ticked for this endpoint"]

    D["<b>4. Read only</b><br/>Write tools dropped if the connection<br/>or the profile is read only"]

    E["<b>What Claude loads</b><br/>Plus the flc_ built-ins"]

    A --> B --> C --> D --> E

 

    class B accent

    class E good

Step 2 is the one people miss. The tool selection on the Connectors page is the ceiling for that connection everywhere: turn a tool off there and no profile can expose it, however it is ticked. The profile can only ever narrow further.

That is also the difference between the two ways to switch a tool off. Turn it off on the profile to change one endpoint; turn it off on the connection to be sure it is off across all of them.

Why the count matters

Every tool you expose is a tool the model has to read, hold in context, and choose between. A tight, relevant set makes Claude faster and more accurate. A sprawling one costs tokens and invites wrong turns, especially when several tools look similar.

How your client loads the list

What the count means in practice depends on the client you plug the endpoint into.

• Clients that search the list. Some clients index the tools and let the model search for what a task needs, loading only those few. A profile with 300 tools then behaves much like one with 30. At the time of writing, Anthropic's and OpenAI's own clients offer a tool-search mode of this kind, though exactly how each client loads tools is up to that client and changes over time.
• Clients that load everything. Other clients hand every tool to the model on every request. There the count matters: past roughly 50 tools the model gets measurably worse at picking the right one, and each request carries the whole list. If your client works this way, keep profiles focused.

The tool search indexes tool names and descriptions, which is why FloConnector keeps both short and specific.

Keep a profile sharp

• Split by job, not by person. A profile for "manage leads" and one for "read reports" each stay lean, and you assign people to the one they need.
• Turn off what you never call. A profile pins a tool set; trim it to the tasks that endpoint is actually for.
• Prefer fewer, richer tools. FloConnector's composite tools already fold many vendor calls into one, so you rarely need the long tail of thin endpoints.

Progressive disclosure

For workspaces that connect several vendors at once, FloConnector can keep the initial list short and let Claude turn a vendor on when it is needed. A server-owned meta-tool, flc_enable_vendor, switches a vendor's tools on, and FloConnector notifies Claude that the tool list changed so it reloads without a reconnect. The result: Claude starts focused and expands on demand, rather than loading everything up front.

Learn more

FloConnector endpoints speak MCP (Model Context Protocol); the tool list is the standard tools/list response. The on-demand behaviour above is client-side tool search with deferred loading:

• Anthropic — the tool search tool
• OpenAI — MCP and connectors

Related