“In the previous post in this series, discovery was about reconstructing a person’s digital life from accounts, inboxes, credentials, subscriptions, recovery channels, and platform traces.”

The discoverer was still recognizably human: the account holder, a family member, an executor, a fiduciary, or someone trying to make sense of the digital mess people leave behind.

This time, the discoverer may be software.

That does not make this an entirely different kind of discovery problem. The whole thread of this series is that discovery problems share common characteristics: something exists somewhere, someone or something needs to find it, the discovery process has costs and risks, and the act of finding it changes what can happen next. No one discovers something for the sheer joy of discovery, at least not in the systems we are talking about here. People and software discover things because they intend to read, access, invoke, recover, govern, delete, preserve, delegate, or otherwise act.

What changes with agentic and MCP-style systems is the mechanics of discovery, the thing being discovered, and the immediacy with which action may follow. Discovery was never passive, but in agentic systems it can sit much closer to execution. The result of discovery may not be a page to read or an account to recover. It may be a tool to call, a capability to invoke, a server to connect to, or an action path that can be selected by software. Discovery can also create operational load in its own right. If poorly designed or poorly configured, discovery can flood a network, expose more than intended, or make systems easier to enumerate.

That makes discovery part of the control plane: a place where capability, trust, policy, and action start to merge.

Which is exactly the kind of sentence that sounds perfectly reasonable until you stop and ask, “Wait, who is allowed to find what, how are they finding it, and what happens when they do?”

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Endpoint discovery is not new

Endpoint discovery is not a new idea. Distributed systems have needed ways to find the right service location for a long time. Hard-coding every URL, address, route, service location, and interface is brittle. Services move. Regions change. Capabilities differ. Deployments scale. Networks get weird because networks are contractually obligated to get weird. Even discovery traffic can become part of the problem. Multicast discovery works beautifully when a laptop needs to find a printer on a small local network. It gets less charming when that traffic is poorly scoped, repeated too aggressively, or bridged across boundaries where “local” no longer really means local. At that point, discovery stops being a quiet lookup and becomes operational noise.

A straightforward example comes from AWS. In some AWS services, an SDK can retrieve available service endpoints at runtime before using one of those endpoints for later operations. In Amazon Timestream, for example, the SDK can call DescribeEndpoints to retrieve available endpoints and then use those endpoints for specific operations. That is endpoint discovery in a relatively familiar sense: code asks where to send the request so it does not have to assume yesterday’s endpoint is still the right one.

A Stack Overflow answer on endpoint discovery captures the developer intuition well enough: discovery can mean calling a known discovery endpoint that returns a directory of other endpoints, allowing clients to find service URLs without hard-coding them. I wouldn’t treat a Stack Overflow answer as the final word on anything more consequential than “why is my build failing at 11:43 p.m.,” but it is useful here because it shows how ordinary this idea is to developers. Discovery often starts as a practical way to avoid brittle configuration.

That version of discovery is important, but it is still relatively narrow. It is mostly about location and configuration: where is the service, what endpoints are available, and how should a client connect?

Then, because technology rarely stops while things are still understandable, the same pattern starts showing up under different operating conditions.

Same pattern, different operating conditions

Even the phrase “endpoint discovery” does not mean one thing.

In endpoint security, endpoint discovery may have little to do with finding service URLs. It may mean discovering sensitive data on managed devices. The Absolute Endpoint Data Discovery FAQ (that will download a PDF if you click on the link), for example, describes policy-based scans across managed Windows and Mac devices to identify data-at-risk, including credit card numbers, Social Security numbers, personal health information, personal financial information, encrypted or password-protected files, GDPR personal data, and organization-specific terms. That system is not asking where to send a request. It is asking what sensitive information exists on managed devices, where it is stored, and whether action may be needed.

The point is not that these are unrelated uses of the same word. It is almost the opposite. They are variations on the same discovery pattern under different operating conditions.

Something exists somewhere. Someone or something needs to find it. The discovery process has costs and risks. The act of finding it changes what can happen next.

One way to keep this straight is to ask what kind of object is being discovered. Sometimes it is a location: where is the service endpoint? Sometimes it is data: what sensitive information exists on a managed device? Sometimes it is a capability: what can this tool do? And sometimes it is authority: who or what is allowed to act? Those categories can overlap, but confusing them is how discovery designs get sloppy.

What changes is the object being discovered, the mechanism used to discover it, and the speed and scale of the action that may follow. Finding a service endpoint at runtime is not the same as scanning a managed laptop for sensitive data, but both involve a system trying to locate something it cannot safely assume in advance. Finding an MCP tool is not the same as finding a user’s identity provider, but both raise questions about visibility, authority, accuracy, and what happens after the match is made.

That is why this post is not about proving that agent and tool discovery are new. (They really aren’t.) The more useful question is how the familiar discovery pattern changes when the thing being discovered may be a capability that software can invoke. In that setting, mechanics matter more. Scope matters more. Timing matters more. Operational cost matters more. Poorly designed discovery can leak information, surface the wrong capability, make enumeration easier, or even create network noise when systems keep asking too broadly or too often.

MCP shifts the question from location to capability

The Model Context Protocol, or MCP, is one place where the discovery question starts to change shape.

At a high level, MCP follows a client-server architecture. An MCP host, such as an AI application, establishes connections to one or more MCP servers. The MCP host creates an MCP client for each MCP server, and each client maintains a connection to its corresponding server. MCP servers can run locally or remotely, and they provide context to MCP clients for the host to use.

That sounds technical because it is. But the basic idea is simple enough: MCP gives AI applications a structured way to connect to external sources of context and capability. Those capabilities may include resources, prompts, and tools. Tools are especially interesting because tools are where information starts to become action.

In a classic service discovery model, the question may be: where is the endpoint?

In an MCP-style tool discovery model, the question becomes broader: what tools are available? What do they claim to do? What inputs do they accept? Who exposed them? Who is allowed to use them? What should the model do with them? What should require approval? What should be logged? What should never be available to this user in the first place? So many questions, so little time.

That is not just endpoint discovery with a new hat. That is capability discovery, and capability discovery is where things get lively.

The MCP architecture gives AI applications a structured way to connect to servers that expose tools, resources, and prompts. In practice, hosts and surrounding systems need to determine which connected tools are available, how they are described, and whether they should be made usable in a given interaction. Industry commentary on MCP discovery says much the same thing in more operational terms: discovery is about finding, identifying, and cataloging MCP-enabled resources, tools, services, endpoints, APIs, and tool definitions so agents and applications know what capabilities are available.

That collection of actions as part of a discovery process is useful. It is also exactly where the interesting problems begin.

Tool descriptions become part of the security boundary

A tool is not useful to an AI system simply because it exists. It has to be described. The model, host, client, gateway, or surrounding system needs some representation of what the tool does, what inputs it accepts, what outputs it returns, and when it might be relevant.

That description is not harmless documentation. The moment discovery can lead to action, metadata stops being just description. It becomes part of the control surface.

If a tool says it can “list services,” that sounds safe enough. If it can “get deployment history,” still probably fine, depending on who is asking. If it can “compare versions,” useful. If it can “restart production,” “delete records,” “send messages,” “transfer funds,” “grant access,” or “summarize customer health data and send it to a third party,” the mood changes a bit.

The tool description matters because it influences whether the tool appears relevant. It may influence whether a model selects it, whether a user approves it, whether a policy engine allows it, and whether a security team later understands what happened. If the description is inaccurate, stale, too vague, too broad, or actively malicious, discovery becomes a path to bad decisions.

Who wrote the description? Who reviewed it? Who decides it is accurate? How does it change over time, and is it versioned? Can a tool exaggerate what it does? Can it hide what it does? Can a compromised server present a dangerous tool as a harmless one? Can an internal tool be surfaced to the wrong user because the discovery layer understands function but not authority?

These are the same family of problems that show up whenever metadata becomes operational. Bad metadata makes bad systems. Stale metadata makes confusing systems. Overly trusting metadata makes systems that look efficient right up until they do something impressively regrettable.

Yay for automation.

Discovery is not the same as permission

One trap here is assuming that because a tool is discoverable, it is available, and because it is available, it should be usable. Those are different claims.

A tool may exist. It may be visible to the system or the model. It may be visible to the user or callable by the client. It may be authorized for this user or authorized for this task. It may be safe to invoke without human approval. It may be safe only under a narrow policy. It may be available in development and absolutely not available in production unless someone enjoys emergency meetings. Discovery only answers part of the many questions that are being asked when looking (and finding) a thing.

This is where the earlier posts in the series come back. In identity discovery, I used the phrase “governed matching”: matching the right identity-related thing to the right request under the right rules. Tool discovery needs the same discipline. We need to match the right capability to the right task under the right authority.

That authority may come from the user. It may come from enterprise policy. It may come from a delegated role. It may come from OAuth scopes, access-control rules, approval workflows, network policy, or some deeply beloved internal spreadsheet that everyone knows is load-bearing but no one wants to admit exists.

The point is that discoverability cannot be treated as permission. It has to feed into permission, policy, audit, and user understanding. Otherwise, the system becomes very good at finding things it should not be able to use.

Agent discovery adds another layer

Discovering a tool is one problem. Discovering an agent is another. (Are agents just specialized tools? Eh, kinda. But if you want to put it that way, so are people, and that takes us down the mine-filled path of delegation.)

A tool may expose a capability. An agent may claim to act for someone or something. That moves discovery closer to identity and delegation. Who is this agent? Who operates it? What is it authorized to do? Who gave it that authority? Is it acting for a person, a team, a company, a workload, another agent, or no one in particular, despite the confident branding? This is where agent discovery becomes authority discovery.

An agent is not just a thing that can be found. It may be a thing that claims to act. Once you introduce acting, the discovery problem cannot stop at location, description, or capability. It has to ask about identity, authority, delegation, policy, and accountability.

The industry is circling this problem from several directions. The IETF Datatracker search for “discovery” turns up work across routing, certificates, service discovery, AI discovery endpoints, agent discovery, MCP DNS discovery, DNS for AI discovery, task discovery, API indexes, and more. These efforts are not all solving the same problem, and they are not evidence of consensus. They are evidence that distributed systems keep running into discovery as a recurring design problem.

Yes, “rediscovering the discovery problem” is a terrible phrase. Unfortunately, it is also accurate.

The amount of activity tells us something important. This is not one problem waiting for one mechanism. It is a family of recurring problems. Some are about location. Some are about naming. Some are about metadata. Some are about capabilities. Some are about authority. Some are about policy. Some are about whether the thing should be findable at all.

That matters because “just make it discoverable” is not a design requirement. It is a warning label that tells you that it’s time to make some critical decisions.

Discovery becomes a control plane

If discovery determines which tools are visible, which servers are approved, which capabilities are recommended, which agents are considered available, and which actions can be invoked, then discovery is part of the control plane.

It shapes not only what can be found, but what becomes available to do next.

That does not mean discovery is the whole control plane. Authentication, authorization, logging, monitoring, policy enforcement, consent, user experience, and governance still matter. Of course they do. But discovery sits at the front of many of those decisions. It shapes the menu of possible actions before the action happens.

That makes discovery politically and operationally interesting. Whoever controls the discovery layer can shape what appears easy, preferred, legitimate, safe, supported, or invisible. A curated enterprise catalog can reduce risk and help people find approved tools. It can also become a bottleneck, a gatekeeper, or a place where outdated assumptions quietly become infrastructure. An open registry can support experimentation and reuse. It can also become a catalog of things that look useful until someone asks whether they are trustworthy, maintained, authorized, or malicious.

This is not a new tension. Search had ranking. Federation had discovery interfaces. CIAM had login options. Personal account discovery had inboxes and password managers. Every discovery layer shapes behavior because people and systems tend to use what they can find.

The sharper issue here is not that discovery leads to action. Discovery almost always does. The issue is that software-mediated discovery can shorten the distance between finding, selecting, authorizing, and invoking. What gets discovered may become part of an action path before a human fully understands the choice being made. That should make us cautious.

The next temptation

Once discovery becomes a control-plane problem, the next instinct is to pick infrastructure. DNS? .well-known? Registries? Signed manifests? Trust lists? Enterprise catalogs? MCP gateways? Some combination of all of the above, plus one more thing someone will name after an animal because apparently that is how infrastructure gets made?

That instinct is understandable. Infrastructure gives the conversation something concrete. It lets people move from “what is this problem?” to “where do we put the record?”

But that is the next trap.

Discovery was always connected to action. Agentic systems make the connection faster, more automated, more scalable, and harder to inspect. Before choosing the mechanism, we need to know what kind of discovery problem we are solving: what is being discovered, who is doing the discovering, what authority they have, what happens if the answer is wrong, and what can happen after discovery succeeds.

Otherwise, we are not designing discovery. We are just moving confusion to a more authoritative-looking location.

That is where the final post in this series is heading.

📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]

Transcript

Throughout this series, we’ve explored discovery from several different perspectives.

We began by looking at discovery as a search problem.

Then we examined identity discovery, customer account discovery, and even the challenge of reconstructing a person’s digital life.

In each case, one pattern kept appearing:

• Something exists somewhere.
• Someone—or something—needs to find it.
• Discovery carries both benefits and risks.
• What happens after discovery matters just as much as the discovery itself.

Until now, however, the discoverer has usually been a person.

Today, that changes.

---

When Software Becomes the Discoverer

Increasingly, discovery is no longer performed by humans.

Instead, software is discovering:

• Services
• Tools
• APIs
• Capabilities
• Data
• Other software

This doesn’t create an entirely new discovery problem.

Rather, it changes the speed, scale, and consequences of discovery.

Most importantly, discovery is no longer the end of a process.

It becomes the beginning of automated action.

---

Discovery Leads to Action

People rarely discover something simply for the sake of discovering it.

Instead, they intend to:

• Read information
• Access a resource
• Invoke a service
• Recover an account
• Delete data
• Execute a task

Software behaves similarly.

The difference is that software can move from discovery to action almost immediately.

That shift has significant implications for trust, governance, and control.

---

More Than Endpoint Discovery

Many engineers immediately think of endpoint discovery.

This is a familiar concept in distributed systems.

Applications need to determine:

• Which service endpoint is available
• Where requests should be sent
• Which region should be used
• How a client should connect

Hard-coding those values creates fragile systems because:

• Services move
• Regions change
• Infrastructure evolves
• Networks behave unpredictably

Dynamic discovery solves many of these operational challenges.

However, endpoint discovery represents only one type of discovery.

---

Discovery Changes With Context

The same word can describe very different activities.

For example, in endpoint security, discovery may involve locating:

• Sensitive files
• Credit card numbers
• Personal health information
• Organization-specific data

In this scenario, the system isn’t asking:

“Where is the service?”

Instead, it’s asking:

“What information exists, where is it located, and should someone do something about it?”

The underlying pattern remains remarkably similar.

Only the object being discovered has changed.

---

Understanding What Is Being Discovered

One useful way to think about discovery is to ask a simple question:

What exactly is being discovered?

Sometimes it is:

• A location
• A service endpoint

Other times it is:

• Data
• A capability
• Authority
• A relationship

These categories often overlap.

However, confusing them frequently leads to poor system design.

---

Discovery Enters the AI Era

This becomes especially interesting with Model Context Protocol (MCP) and other agentic AI systems.

At a high level, MCP allows AI applications to connect with external sources of:

• Context
• Resources
• Prompts
• Tools

Among these, tools deserve special attention.

Unlike traditional service discovery, AI systems are not simply asking where something is located.

They are asking:

• What tools are available?
• What can those tools do?
• What inputs do they require?
• Who is allowed to use them?
• Should approval be required?
• Should their use be logged?

Discovery has evolved from finding endpoints to discovering capabilities.

---

Capability Discovery Changes Everything

A discovered tool is not useful simply because it exists.

The surrounding systems need to understand:

• What the tool does
• What inputs it accepts
• What outputs it returns
• When it should be used
• Under what conditions it is appropriate

This information is typically represented through metadata.

And suddenly, metadata becomes far more important than documentation.

It becomes part of the control surface.

---

Metadata Is Operational

Tool descriptions influence:

• Whether a model considers a tool relevant
• Whether a user approves its use
• Whether policy permits execution
• Whether security teams can later explain what happened

Poor metadata creates predictable problems.

For example:

• Outdated descriptions
• Incomplete documentation
• Overly broad claims
• Misleading capabilities

These are no longer minor documentation issues.

They directly influence automated decisions.

---

Discovery Is Not Permission

One of the easiest mistakes to make is assuming that discoverability equals authorization.

It does not.

A tool may be:

• Discoverable
• Visible
• Callable

Without necessarily being:

• Authorized
• Appropriate
• Safe

Visibility and permission are separate concerns.

Treating them as the same introduces unnecessary risk.

---

Governance Still Matters

Earlier in this series, discovery was described as governed matching.

The same principle applies here.

Successful systems must match:

• The right capability
• To the right request
• Under the right authority

That authority may come from:

• User consent
• Enterprise policy
• Delegated roles
• OAuth scopes
• Access control rules
• Organizational governance

Discovery should always feed into policy—not replace it.

---

When Discovery Becomes Identity

Tools are only part of the story.

Increasingly, systems must also discover agents.

Unlike tools, agents may claim authority to act on behalf of:

• Individuals
• Teams
• Organizations
• Workloads
• Other agents

This immediately raises important questions.

For example:

• Who operates this agent?
• What authority has been delegated?
• Who is accountable for its actions?
• What policies apply?

Discovery has now moved into the realm of identity.

---

Discovery Is a Family of Problems

Industry work increasingly reflects this growing complexity.

Current discussions include topics such as:

• AI discovery endpoints
• Service discovery
• DNS-based discovery
• Certificate discovery
• Agent discovery
• MCP ecosystems

These initiatives are not solving one single problem.

Instead, they demonstrate that discovery appears repeatedly across distributed systems.

Each context introduces its own assumptions, constraints, and governance requirements.

---

Discovery Shapes the Control Plane

One of the most significant changes occurs when discovery begins influencing what software can do next.

If discovery determines:

• Which tools appear
• Which servers are recommended
• Which capabilities are visible

Then discovery becomes part of the control plane.

It influences not only what can be found, but what actions become possible.

That makes discovery strategically important.

---

Whoever Controls Discovery Shapes Behavior

Discovery layers naturally influence decision-making.

For example:

• Enterprise catalogs guide employees toward approved tools.
• Open registries encourage experimentation.
• Recommendation systems highlight preferred options.

Each approach offers benefits.

However, each also shapes behavior.

People—and increasingly software—tend to use whatever is easiest to discover.

That makes discovery both a technical and governance concern.

---

Automation Compresses Decision Making

The greatest shift introduced by agentic systems is speed.

Software can now move rapidly through several stages:

• Discover
• Select
• Authorize
• Invoke

In many cases, these steps occur before a human fully understands the decision being made.

That should encourage thoughtful system design rather than blind automation.

---

Ask Better Discovery Questions

Before choosing discovery mechanisms such as:

• DNS
• Registries
• Signed manifests
• Trust lists
• MCP gateways

It is worth asking more fundamental questions.

For example:

• What is being discovered?
• Who is performing discovery?
• What authority do they possess?
• What happens if discovery is wrong?
• What happens after discovery succeeds?

These questions determine whether discovery strengthens a system—or simply makes mistakes happen faster.

---

Final Thoughts

Discovery has always been connected to action.

What has changed is the distance between the two.

As AI systems, software agents, and automated platforms become more capable, discovery increasingly determines what actions become available before any human intervenes.

That makes discovery more than a lookup mechanism.

It becomes a critical part of trust, governance, and operational control.

---

Conclusion

The future of discovery is not simply about finding more things.

It is about ensuring that the right capabilities become available to the right actors under the right authority.

As software increasingly discovers, selects, and invokes resources on our behalf, discovery itself becomes part of the decision-making process.

And once discovery begins shaping action, it deserves the same attention we already give to authentication, authorization, and policy.

---