GitHub Agent Finder Is the First Serious Attempt to Make MCP Discovery Governable

Agent tool discovery just crossed the line from developer convenience into infrastructure. GitHub’s new agent finder for Copilot sounds like a search box for MCP servers, skills, canvases, agents, and tools. That undersells it. The real move is that GitHub and Microsoft are trying to standardize the moment before an agent gets a tool: discovery, ranking, policy, and provenance.

That moment matters because the current MCP ecosystem is already hitting the obvious scaling wall. A developer can hand-wire a few servers. A power user can maintain a messy config with dozens. An enterprise cannot responsibly tell every coding agent to carry every internal deployment tool, incident dashboard, design-system helper, data catalog, and vendor integration in context just in case today’s prompt needs one of them. That is expensive, noisy, and increasingly unsafe.

GitHub’s answer is agent finder, now available across Copilot plans. Instead of preloading every capability, Copilot can search an index of available AI resources and return ranked matches for the task. The index can be GitHub’s curated public catalog or a private internal registry. Managed settings decide what resources agents are allowed to discover and use. Most importantly, GitHub says agent finder does not silently install or connect anything. Discovery is not invocation.

The missing layer between MCP hype and enterprise reality

MCP made tools callable. It did not make them governable at scale. That distinction is where most of the industry’s “agent platform” demos get fuzzy. Calling a tool is the easy part once authentication and schemas exist. Deciding which tool should even be considered, whether the agent is allowed to know it exists, whether the result is ranked because it is actually useful or merely well-described, and whether the human approves wiring it in — that is the harder product surface.

Agent finder implements the open Agentic Resource Discovery specification, or ARD. Microsoft introduced ARD with GitHub, Google, GoDaddy, Hugging Face, Cisco, Databricks, Nvidia, Salesforce, ServiceNow, Snowflake, and others attached. The spec’s pitch is straightforward: agentic resources need a discoverable surface, much like web pages gave search engines something to crawl. A lightweight manifest describes what a resource does, who provides it, where it lives, what authority it requires, and how it can be reached. An AI client asks what resource can help with a task; ARD returns candidates before the client invokes anything through MCP, an API, a workflow engine, or another protocol.

That separation is the important part. ARD is not a replacement for authentication. It is not authorization. It is not a trust decision. Microsoft says that explicitly, and GitHub’s “no auto installation” boundary is the right default. If discovery and invocation collapse into one step, the agent ecosystem becomes a faster way to connect models to random tools with too much authority. If they remain separate, teams can build reviewable workflows: search, inspect, approve, connect, log.

The public catalog will get attention because public catalogs are easy to demo. The private registry story is the one engineering leaders should care about. The most valuable agent resources inside a company are rarely public MCP servers. They are internal runbooks, deploy systems, data catalogs, repo-specific skills, on-call dashboards, feature-flag controls, cost dashboards, contract-test runners, and product analytics tools. Those resources need owners, descriptions, access rules, data classifications, and change history. “The agent found a tool” is not enough. Teams need to know whose tool it is, what data it can touch, whether it has been reviewed, and why it was ranked for this task.

Context windows are not free real estate

There is also a cost-control angle hiding in the governance language. GitHub’s announcement says agent finder avoids filling the context window with every MCP server, skill, canvas, agent, and tool just in case. That is not a small optimization. Tool definitions are prompt material. Prompt material costs latency, money, and attention. A coding agent that carries schemas for twenty unused tools every turn is not “powerful”; it is wasteful by default.

This connects directly to GitHub’s same-day push on token efficiency and Auto model routing. Agentic development is becoming metered infrastructure. Copilot AI Credits make model choice visible, but tool scope is just as much a budget variable. A bloated toolbelt can make every prompt more expensive before the agent does any useful work. Deferred discovery is how vendors keep the capability universe broad without making the active prompt obese. Ugly phrase, accurate diagnosis.

The uncomfortable comparison is web search. Microsoft leans into it: the early web had millions of pages, but hand-curated directories could not keep up; search engines lit up the web. The analogy is useful, but it should also make practitioners nervous. Search created discoverability. It also created SEO spam, ranking games, reputation laundering, and whole industries built around looking authoritative to machines. Agent resource discovery will inherit the same incentive problem with a nastier blast radius, because the thing being discovered may be a tool with permissions, not a blog post.

That means ARD manifests need to be treated like supply-chain metadata, not marketing copy. A manifest should include owner, version, endpoint, auth mode, required scopes, data classes touched, safe-use notes, audit logging behavior, and deprecation status. Ranking should be inspectable enough that a team can answer why Copilot suggested this resource instead of that one. Private registries should have promotion paths: experimental, team-approved, org-approved, production-approved. Public catalogs should be disabled or read-only by default in high-sensitivity environments until security teams understand how managed settings behave.

There is a developer-experience payoff if GitHub gets this right. A developer should be able to ask Copilot to investigate a flaky deploy, and the agent should discover the sanctioned deployment-status MCP server, the owning team’s runbook skill, and the incident-search tool without requiring the developer to memorize tool names. But the agent should not silently connect to a third-party observability server, grant it repo context, and start shipping logs around because a manifest said “deploy debugging.” Discovery should reduce configuration burden, not erase judgment.

For teams, the practical next step is not “turn on agent finder and see what happens.” It is to inventory the resources agents should be allowed to find. Start small: one private registry, a handful of known-good internal tools, clear owners, and logs for what was searched, what was returned, what was installed, and what was invoked. Require human approval before new tools are connected. Add policy labels for production data, customer data, write-capable tools, and network egress. Keep public catalog access behind a review gate until the ranking and permission model has earned trust.

Agent finder is the first serious sign that MCP discovery is becoming an infrastructure problem rather than a dotfile hobby. That is good. The next test is whether GitHub, Microsoft, and the ARD ecosystem make discovery auditable enough for the people who will be paged when an agent finds exactly the wrong tool at exactly the wrong time.

Sources: GitHub Changelog, Microsoft Command Line, Agentic Resource Discovery specification, Hugging Face hf-discover