hamsa softwareA maintenance brief needs seventy-five reads whichever interface performs them. Tool discovery changes what the model sees; it does not automatically reduce the work behind it.
Before an assistant can look up the maintenance history, it may have to choose among hundreds of operations. Several names sound right, their parameters overlap and their permissions differ. Giving it every definition supplies more information without necessarily explaining which operation returns the needed record. I would first identify the accepted equipment identifier and the result this task needs, then ask whether choosing among a larger catalogue helps the assistant obtain it.
Anthropic's 24 November 2025 announcement of advanced tool use introduced tool search, programmatic tool calling and tool-use examples.[1] The announcement addresses more than model capability. It raises a design question about where information should live while the work happens: in the model's immediate context, in a discoverable catalogue or inside ordinary code that processes intermediate results.
Tool definitions, catalogue discovery and code orchestration move different kinds of work. A larger context can hold more definitions without clarifying them. Search can locate an operation without authorising its use. Code can keep intermediate rows out of the conversation while still making every external request. If the brief becomes shorter, it is worth finding out which of those things became smaller: the model’s reading, the remote work or the recovery the operator will face.
For a small business, this is easy to miss because the first integration often has only a few tools. Adding a second platform feels like adding another convenient connection. Over time the assistant inherits a directory, terminology conflicts and several ways of accomplishing what looks like the same task. I would review that information architecture before treating another search layer as the automatic solution.
Consider an illustrative maintenance brief for 25 pieces of equipment. For each, the operator wants its warranty information, recent service history and assigned technician. Suppose the available service has three separate read operations. One complete pass requires 75 external reads. The numbers are assigned to make the boundary visible, rather than drawn from a real maintenance system or a model benchmark.
In a mixed catalogue, get_asset might mean equipment, a document or a finance record. Describe which identifier it accepts, the fields it returns, the account it reads and what an empty result means. Otherwise the assistant has to infer the business convention from a broad name on every call. More prose helps when it answers those questions; promotional adjectives can make the definition longer while leaving the same uncertainty in place.
The Model Context Protocol (MCP) connects AI applications to external systems. Its tool specification describes named tools with input schemas, optional output schemas and other metadata.[2] Structure can tell the client which arguments fit. It cannot supply all the business meaning behind a service-history field. Last updated and last serviced are different dates. If the latter is missing, selecting the newest timestamp does not become correct merely because it satisfies the schema.
Examples help when they expose such conventions. Show an equipment identifier that does not exist, an asset with no service history and a technician assignment the caller cannot access. These examples explain expected outcomes that a clean success case leaves open. They should use synthetic material. Their job is to reduce ambiguity, rather than make every operation look as though it produces the requested information without awkward qualifications.
Start with a static interface exposing the three relevant operations. The assistant can request the required information for each asset, then prepare the brief. The surrounding application must keep track of which results belong to which equipment. Large raw histories can occupy substantial conversational space even when the final brief needs only a few facts. That is a reason to examine result handling, not evidence that the external service is too slow.
Discovery might search the larger catalogue and load just the three definitions the maintenance brief needs. That keeps unrelated tools out of the initial context, at the price of another selection step that can fail or return an ambiguous match. The 75 reads remain. If every quarterly brief needs the same three operations, we have added a search for an answer the application already knew. Discovery becomes more interesting when the route genuinely varies.
A programmatic route can gather the three records for each asset in a bounded loop, join them by the stable identifier and return the fields required by the brief. It still performs 75 reads under our assumed service contract. The model may see one concise result instead of every intermediate payload, but that is a change in information flow, not a claimed reduction in remote operations. A supported batch endpoint might change the arithmetic; we have not assumed one.
A concise result still has to account for the equipment it cannot describe. Suppose the brief lists only overdue assets and quietly drops one whose history was unreadable. The operator cannot tell that omission from an asset with no maintenance issue. Keep the requested population, unavailable information, completeness state and source references with the result. Moving raw payloads outside the conversation should leave someone able to check the recommendation and notice what is missing.
One possible interface is prepare_maintenance_brief with an explicit asset list, an as-of date and a maximum of 25 assets. The tool returns completed records, unavailable fields and source references. It does not book service visits, change technician assignments or infer permission from a request containing an unfamiliar identifier. These are proposed application boundaries for this example, not standard MCP field names.
The higher-level operation may be easier to use than 75 separate calls, but it needs an inspectable account of those reads and their failures. Access still depends on the authenticated user at the service boundary and on the credentials the implementation actually holds. A read-only description cannot establish that boundary. An overly broad domain operation could give a single call more reach than the narrower atomic interface it replaces.
Put bounds on the work before it begins. A request for the whole estate should not silently expand a 25-asset brief into thousands of reads. Decide whether to reject it, paginate explicitly or create an owned background job. Return partial results only with a clear account of their incompleteness. If one dependency becomes unavailable, the operator should know which section needs attention instead of receiving a complete-looking brief assembled from the remaining two.
The operator need not examine all 75 successful reads after every run. They need to know whether all 25 assets and their three sources were covered, and how to inspect the evidence behind a consequential recommendation. That is part of designing prepare_maintenance_brief, alongside its input fields. Otherwise the shorter result simply makes the missing information harder to find, and the time saved by the model reappears as work for the person reading its brief.
There are tasks where the useful tool genuinely depends on earlier findings. A maintenance question may lead from one fault code to a specialist manual, then to an approved diagnostic service. Loading a small relevant subset as the route develops can be a sensible alternative to presenting every possible operation in advance. The task contains exploration, and discovery supports that exploration.
The routine quarterly brief is a different candidate. Its inputs and route may be stable enough that a fixed, well-described interface is easier to maintain. Before adding discovery, write down the variation it must handle. New asset types, different source systems or optional investigation paths are concrete reasons. A growing count of tool names, without a changing business task, may instead indicate that the interface needs pruning or a clearer domain operation.
When comparing routes, keep three measures separate: information supplied to the model, external work performed and effort needed to recover incomplete results. A reduction in one does not imply a reduction in the others. The comparison figure uses the same 75-read assumption throughout to keep that distinction visible. An actual trial should record its inputs and calls before reporting savings; the conceptual choice can be understood without inventing a performance result.
The November announcement offers useful ways to divide the task: search for capabilities when the route is uncertain, use code for bounded iteration and let the assistant interpret the material returned. For this brief, I would compare the resulting coverage and recovery effort alongside context size. A compact answer is welcome. It earns its place when the operator can still see which equipment it covers, where its recommendations came from and which missing records need attention.
25 assets each need warranty, service history and technician records. The example assumes three separate reads per asset and no batch endpoint:25 × 3 = 75 external reads.
Expose three known operations. The assistant receives their definitions and the application associates each result with its asset.
Search a larger catalogue and load the relevant definitions. Discovery adds a selection step; the three reads per asset remain.
Code joins the same 75 reads and returns selected fields, missing-data flags and source references. Intermediate results stay outside the main conversation.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotPrimary sources behind this article. Living documentation may change.
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A saved replacement, a running service and an attacker’s existing access can change at different times. Railway’s guidance explains why that matters; PingCAP and PHP show where the next job differs.
Computer use needs an observation contract for account, object and outcome, especially when a visible click produces only partial completion.
Local inference offers a different operating boundary. Evaluate the completed task, data routes and maintenance responsibility before buying into it.
