The Core Aim of Vocabulary Mastery | AI Tool Discovery Vocabulary

AI TOOL DISCOVERY VOCABULARY · FIND → DESCRIBE → FILTER → SELECT → VERIFY

Think about walking into a very large library and asking for one practical guide. Before you can read it, you need a catalogue that tells you which resources exist, what they cover and where they can be found. AI agents have a similar problem with tools. A modern application may connect an assistant to search, calculators, calendars, databases, spreadsheets, WordPress, code execution and specialist services. The assistant cannot use tools effectively if it cannot identify which capabilities exist, which one fits the task and which ones it is actually allowed to access.

AI tool discovery vocabulary names that capability-finding stage. Words such as tool registry, capability catalogue, tool schema, description, namespace, discovery request, pagination, caching, capability negotiation, tool selection, version compatibility and deprecation are not mere software labels. They explain why an assistant might know how to publish an article yet still select a read-only search function or, worse, an unnecessarily powerful administrative operation.

The core aim of vocabulary mastery for AI tool discovery is capability literacy: explain how an agent finds available tools, reads their contracts, distinguishes similarly named operations, applies the correct access scope, and selects the smallest suitable capability for the user’s goal. Discovering a tool is not the same as executing it, and seeing a tool in a catalogue does not confer permission to use it.

This article belongs to the eduKateSG Vocabulary Hub and the Core Aim of Vocabulary Mastery series. AI Tool Calling Vocabulary handles proposed and executed calls; AI Agent Identity Vocabulary handles principal and permission; the present lesson owns the step before a call exists: how does the agent recognise the right capability?

Central proposition: A trustworthy agent should discover only relevant, permitted and sufficiently described capabilities, then verify their actual contract before using them. A tool list is a map of possibilities, not an authorisation document.

A simple example: finding the correct publishing tool

Suppose someone asks an education assistant to explain the meaning of ‘metaphor’. A source lookup or internal glossary retrieval may be sufficient. Now suppose the user asks for a new article about metaphors to be published on a particular website. That second request may require content creation, metadata fields, review and a publishing permission. The word publish is a different action from write, search or preview.

A tool catalogue might include operations called posts.list, posts.get, posts.create, posts.update and sites.list. A helpful tool discovery process reads what each operation actually accepts and returns. It should not assume that a tool called ‘update’ can create a missing article or that ‘create’ will automatically publish it. The operation’s contract, not its appealing title, determines its function.

The tool discovery glossary

Tool discovery is a separate phase from tool calling

A tool call is a request to execute a selected capability, usually with concrete arguments. Discovery precedes that request. The model or application first needs to know the existence and contract of the capability. The selected tool may later reject execution because the account lacks permission, an argument is invalid, or the underlying service is unavailable.

This separation prevents a common teaching error: saying an agent ‘can send emails’ simply because its tools catalogue contains an email-sending operation. It may not have a connected mailbox, may have no granted scope, or may require human approval for every send. Availability, permission, readiness and execution success are four separate claims.

How MCP makes discovery concrete

The Model Context Protocol, or MCP, provides a protocol for connecting applications and tools. In the 28 July 2026 specification, a server offering tools declares its tools capability, and a client can request available definitions with tools/list. The definitions identify operations by name and describe their inputs using schemas. That list may depend on the authorisation presented with the request. The protocol also describes pagination, caching and notifications of tool-list changes.

This is a useful real-world example of why discovery vocabulary matters. A client cannot simply assume that the list from yesterday is complete today. Tools may have been added, removed or made inaccessible under a different account scope. Nor can it assume that a result from one server describes a second server’s identically named tool.

A tool definition: which fields actually matter?

A tool description is useful, but not a security guarantee

The MCP specification explicitly says clients must consider tool annotations untrusted unless they come from trusted servers. A description might mark an operation read-only, but that statement alone cannot enforce the behaviour of a malicious or misconfigured implementation. Effective safety controls live in the application and service infrastructure: credential permissions, scope checks, argument validation, approval gates and audit records.

In other words, metadata helps choose a tool, while authorisation decides whether it may act. The difference becomes critical when tools are discovered from third-party servers. An agent that selects a tool because it claims to be ‘safe and official’ still needs an appropriate trust assessment and real permissions.

Worked example: eduKateAI discovers tools for a school-level question

A parent asks, ‘My child is finishing Primary 6. Which vocabulary skills prepare them for Secondary 1 English, and what should we practise this month?’ A specialised education assistant may need several capabilities: a curriculum-reference lookup, an eduKate vocabulary search, a lesson-packet generator and perhaps a progress-note retrieval tool for the correct authenticated student.

Good discovery prioritises safe, relevant capabilities. The application can find the source-search tools first. If personalised records would improve the answer, it can check whether the family is authenticated and authorised before considering private progress retrieval. A WordPress publishing tool is not needed to answer the question. Showing the model fifty unrelated administrative tools makes selection harder and increases the opportunity for unnecessary actions.

This distinction is also a matter of teaching efficiency. A student does not need a tour of the entire software estate to learn the meaning of nuance or inference. Tool discovery should help the application bring forward only the capabilities that support the learner’s real question.

Naming collisions: why ‘search’ is not enough

An assistant may be connected to a research database, an internal glossary, a file index and a public web search provider. Each might expose a tool named ‘search’. In a combined catalogue, identical names can be ambiguous. A namespace or server prefix can distinguish the capabilities so the right data source is called.

The MCP tools specification notes that tool names are unique within a server but can collide when a client aggregates tools from multiple servers. Namespacing or disambiguation prevents one connection’s search operation from being silently substituted for another. This is particularly important when the sources have different permissions or trust expectations.

Large tool catalogues: more choice is not always more capability

Giving a model every possible tool definition at once can create complexity. It may select a vaguely named operation, overlook required arguments or spend context on unrelated functions. Some frameworks support deferred or dynamic discovery: the application first identifies a smaller group of relevant capabilities, then loads their detailed schemas when needed.

This should be treated as a routing strategy rather than a guarantee that a smaller catalogue always performs better. The choice depends on tool quality, model behaviour, task complexity and evaluation results. What matters is that the agent can find the appropriate tool without confusing irrelevant or unauthorised alternatives for useful options.

Pagination, caches and the possibility of a stale catalogue

A tool server may have many definitions, so discovery may arrive in pages. A client that retrieves only the first page could miss a valid capability. Conversely, a previously cached catalogue may continue advertising a tool that has been retired. Applications need to follow the provider’s discovery protocol, treat cache rules correctly and refresh when relevant changes are signalled.

A stale schema is not merely inconvenient. It can lead an agent to pass outdated parameters or make unsafe assumptions about an operation. When the shape or meaning of a tool changes, a responsible workflow updates its registry, tests compatibility and records whether dependent tasks need migration.

Deprecation and retirement: an end-of-life route for tools

An organisation may retire a data export function because its scope is too broad, or replace an old search endpoint with one that records better provenance. Tool discovery should not treat a deprecated operation as the default just because it remains visible. A capability registry can identify the replacement, its compatibility limitations and the date when the old interface should no longer be selected.

This connects naturally to AI Model Retirement Vocabulary, though the objects are different. A model retirement concerns the model’s operational life; tool retirement concerns an interface or function. In both cases, dependencies and residual access must be addressed instead of simply deleting a name from a list.

Capability registries and rights: the eduKate ecosystem perspective

A library-of-libraries approach relies on distinguishing a source from the way it may be accessed. The National Library, a scholarly index, a school authority and a teaching platform can all provide valuable resources, but they do not necessarily have identical reuse rights, data fields or interface policies. A good capability registry captures more than ‘search available’. It can record source owner, tool purpose, access method, permitted use, review date and provenance responsibilities.

The same principle applies to connected software. A tool might retrieve a public page while another can modify a private record. A domain name or provider brand is not enough to distinguish those rights. Tool discovery should produce a set of capabilities appropriate to the user’s context, then leave actual permission enforcement to the relevant services.

Design a tool-discovery card

Five tests for whether discovery is working

• Relevance: For a Primary 3 Science question, are education sources ranked ahead of administrative tools?
• Permission: Can an unauthorised user discover or invoke tools beyond their granted scope?
• Schema fit: Does the selected tool accept the arguments the application plans to provide?
• Freshness: Does the application recognise changes in the available list or deprecated interfaces?
• Outcome: Does the selected capability produce a useful, verified result rather than merely sounding promising?

A student vocabulary exercise: classify the stage

Situation A: The assistant asks the connected platform which tools are offered. This is discovery.

Situation B: The assistant selects a glossary search operation and supplies the word ‘resilience’. This is tool selection followed by a proposed tool call.

Situation C: The service rejects the request because the user’s account is not entitled to private records. This is authorisation enforcement, not a discovery failure.

Situation D: A search returns a webpage whose facts are three years out of date. This is a source-freshness and result-validation problem, not proof that the wrong discovery protocol was used.

Situation E: A previously supported function has been withdrawn. The application must update the catalogue and migrate to a permitted replacement rather than attempt to invent a working old endpoint.

Common tool discovery mistakes

• Assuming visibility grants permission: enforce identity and resource access separately.
• Calling a tool by a vague display name: use its precise identifier and provider.
• Ignoring a tool’s schema: inspect actual input and output contracts.
• Trusting annotations from unknown servers: validate origin and enforce real permissions.
• Loading every available tool by default: consider bounded relevance filtering.
• Using a cached list forever: respect changes, versions and deprecation.
• Stopping after the first page: handle catalogue pagination.
• Assuming discovery means execution occurred: check tool responses and external state.
• Ignoring tool-name collisions: namespace aggregated capabilities.
• Using a powerful write tool for a simple read question: prefer the narrowest fit.

Frequently asked questions

What is AI tool discovery?

It is the process of identifying which tools an agent application can access and reading enough information about each tool to decide whether it suits a particular task.

Is a tool registry the same as a tool permission system?

No. A registry describes available capabilities and metadata; permissions determine what an authenticated actor may actually use.

What does MCP tools/list do?

In MCP, it lets clients request the tool definitions currently exposed by a server, subject to the protocol’s rules and the request’s applicable authorisation.

Why do schemas matter during discovery?

They tell the client what arguments a tool expects and, where available, what structured result it returns.

What is tool-name collision?

It is ambiguity when aggregated servers provide similarly or identically named capabilities. Namespaces or other disambiguation methods help select the right one.

Why would an agent load tools dynamically?

To focus on relevant capabilities and reduce unnecessary tool definitions in its working context, while still allowing more capabilities to be discovered when needed.

Can a tool description be wrong?

Yes. Metadata can be stale, ambiguous or supplied by an untrusted server. Actual permissions and output verification must be enforced independently.

How can a tuition assistant benefit from better tool discovery?

It can retrieve the right subject and level references, avoid unnecessary powerful tools, keep source links relevant and reserve private-record operations for appropriately authorised learning contexts.

Sources and further learning

• Model Context Protocol — Tools specification, 28 July 2026 (discovery, schemas, pagination, list changes and security notes).
• OpenAI Agents SDK — Tools (the categories of tools an agent can access).
• AI Tool Calling Vocabulary (the separate execution stage).
• AI Agent Identity Vocabulary (permission and delegated authority).
• AI Tool Output Validation Vocabulary (checking returned data).
• AI Context Engineering Vocabulary (selecting useful context for the model).
• AI Policy Enforcement Vocabulary (service-side boundaries).
• Immutable eduKateSG learning reference (education-first structured explanations).

The AI tool discovery vocabulary standard

Mastery is demonstrated when a learner can read a tool definition, distinguish catalogue visibility from authorisation, choose a capability appropriate to the goal, recognise ambiguous tool names and stale schemas, and explain what evidence is still needed after a tool is invoked. The aim is not to give an agent the largest possible toolbox. It is to ensure that the right tool can be found, understood and used within the right boundaries.