Design a Tool Registration, Discovery and Safe Execution Layer for LLM Agents

Design the platform layer that lets LLM-driven agents use tools exposed by backend services. Service teams publish capabilities (for example, "query this dataset" or "create a work order") as tools. An agent receives a user goal, finds the tools that are relevant and permitted, asks the model to choose one and produce its arguments, executes the call, and feeds the result back into its reasoning loop. Assume a protocol in the style of the Model Context Protocol (MCP), in which each tool is advertised with a name, a description and a schema for its inputs and outputs. Do not expect to tour a wide system. The interviewer wants to stay on this one architecture and go deep: how tools are registered and discovered, where schemas are defined and where arguments are validated, what the contract between backend services and agents looks like, and how you keep model-chosen actions safe to execute. Be ready to justify trade-offs between latency, safety and scalability, and to say what you would build first and what you would defer. ### Constraints and Clarifications - Tool calls can change real data or trigger real-world actions, so a wrong or malformed call is a correctness and safety problem, not only a quality problem. - Arguments are produced by a language model and must be treated as untrusted input. - Tool results are returned to the model, so anything a tool returns can influence the agent's next step. - Model selection, prompt design and model training are out of scope except where they affect the tool interface. ### Clarifying Questions - Who builds tools: a handful of platform engineers, or many independent service teams with their own release cycles? - Roughly how many tools exist, and does every agent see all of them or only a subset per task, tenant or user? - Do agents act on behalf of a specific user, with that user's permissions, or under a service identity? - Which actions are irreversible or high-impact, and is a human approval step acceptable for them? - Are tool calls short synchronous requests, or can some run for minutes and need to be tracked asynchronously? - What latency budget does one agent step (choose a tool, call it, read the result) have? ### Part 1 — Tool registration and discovery Describe how a service team publishes a tool and how an agent finds the right tools at run time. Cover the tool definition itself, versioning and deprecation, how the registry stays in sync with the services that actually implement the tools, and how you narrow a large catalog down to the few tools a model should see for a given step. ```hint Two different readers A tool definition is read by machinery that routes and validates calls and by a model that has to decide when the tool is appropriate; ask what each of them needs from the definition. ``` #### What This Part Should Cover - A concrete tool record with identity, version, schemas, permissions and operational limits - A registration flow that checks definitions before agents can see them - Discovery that respects permissions and the model's limited context - Versioning and safe retirement of tools that agents may still be calling ### Part 2 — Schema definition versus runtime validation Explain what the schema guarantees at definition time and what still has to be checked on every call. Walk through what happens when the model produces arguments that do not match the schema, arguments that match the schema but are semantically wrong, and a tool response that does not match its declared output. ```hint Valid is not the same as allowed A well-typed argument can still reference a record the user cannot touch or a value outside a safe range; decide which layer owns each kind of check. ``` #### What This Part Should Cover - The split between static checks at registration and checks on every call - Handling of malformed model output, including a bounded repair loop - Semantic and authorization checks that a type schema cannot express - Validation of tool outputs before they reach the model ### Part 3 — The backend–agent interface and safe execution Define the interface between the agent runtime and the services that implement tools, and the path a single call takes through it. Then explain how you make execution safe: whose authority the call runs with, how risky actions are gated, what happens on timeouts and retries, and how you defend against tool results that try to steer the agent. ```hint Classify before you call Not every tool deserves the same treatment; think about which property of a tool should decide whether it runs immediately, needs a dry run, or needs a person to approve it. ``` #### What This Part Should Cover - A single execution path where identity, policy and limits are applied in one place - Risk tiers that decide between immediate execution, preview and human approval - Idempotency, timeouts and partial-failure handling for calls with side effects - Treating tool output as untrusted data, plus an audit trail of every action ### What a Strong Answer Covers - Depth on one coherent architecture instead of a list of components - Explicit trade-offs between latency, safety and scalability, tied to concrete decisions - Least-privilege execution under the right identity, with defense in depth - Clear ownership boundaries between the platform, tool owners and agent builders - A sensible build order: what ships first and what is deferred - Observability that makes every agent step and tool call traceable after the fact ### Follow-up Questions - A tool owner ships a breaking change to an input field while agents are mid-task. What prevents failures, and how is the change rolled out? - How would you support a long-running tool that takes several minutes and reports progress? - An agent loops, calling the same tool repeatedly with slight variations. How do you detect and stop it? - How would you check whether a change to tool descriptions improves the agent's tool choices before rolling it out?