GitHub Agent Finder makes agent tool selection an operations problem

Tech

The next bottleneck in AI-assisted development is no longer only model quality. It is wiring. Every MCP server, skill, custom agent, and internal API makes an agent more useful, but it also expands the surface area that platform, security, and finance teams have to understand. GitHub Agent Finder and Microsoft’s Agentic Resource Discovery specification are important because they move tool selection from a personal setup habit into an operating model.

Workflow diagram showing agents discovering capabilities through a governed registry and feeding telemetry and budget signals back to platform teams
Workflow diagram showing agents discovering capabilities through a governed registry and feeding telemetry and budget signals back to platform teams

What happened

On June 17, 2026, GitHub announced Agent Finder for GitHub Copilot. Instead of pre-wiring every MCP server, skill, canvas, agent, or tool into every agent session, Copilot can search a selected catalog, return ranked matches, and pull in capabilities on demand. GitHub’s announcement emphasizes three controls that matter to companies: you can point discovery at a curated public catalog or a private registry, managed Copilot settings constrain what can be surfaced, and Agent Finder does not silently install connections. Microsoft’s ARD announcement describes the broader specification behind that pattern: agentic resources need structured, discoverable manifests so AI clients can find suitable capabilities without hand-maintained directories.

Why it matters

For working developers this changes a routine but fragile workflow. Today many teams accumulate AI tools through local IDE settings, copied JSON snippets, one-off tokens, README notes, and “ask this person for the MCP config” messages. That works for experiments. It breaks down when an agent can touch production data, deploy previews, open tickets, run browser sessions, or summarize customer conversations. A discovery layer lets the company decide which resources are visible, which are blocked, and which are only available under specific policy. It can also reduce context bloat by loading the right tool when needed instead of dragging an entire toolbox into every prompt.

Community signal

Community signals show why this matters now. Developers have been asking whether Copilot Code Review reads AGENTS.md, how that overlaps with existing instruction files, and whether content is duplicated across agent surfaces. GitHub’s June 18 changelog says Copilot Code Review now uses repository-level AGENTS.md files. At the same time, Copilot usage-based billing discussions keep circling around budgets, Actions minutes, user-level consumption, and how admins can forecast spend. The question has shifted from “does this feature exist?” to “how do we make this feature auditable, predictable, and affordable for a team?”

Development and operations impact

The operational impact is threefold. First, teams need a capability catalog. MCP servers and skills cannot live only in personal dotfiles if they can read data, mutate systems, or influence code review. Second, repository instructions become production infrastructure. Once AGENTS.md influences coding agents and review agents, it should be versioned, reviewed, and tested like any other engineering contract. Third, cost and telemetry become part of agent design. GitHub’s usage metrics API now includes per-user daily AI credits, but the changelog notes that this is not broken down by feature, model, or surface. That means the metric is a useful signal, not a full attribution system.

Team checklist

• Move MCP servers and skills from personal setup notes into an approved catalog or registry.

• Record owner, purpose, permission scope, data classification, and rollback path for each capability.

• Make AGENTS.md the reviewed contract for tests, security rules, code style, and migration policy.

• Log tool use, approvals, denied network activity, and user intent where your agent platform supports it.

• Track AI credits and Actions minutes by team, and put limits around long-running agent workflows.

Old patternManual IDE wiring, personal MCP configs, scattered instruction files
New patternTask → Agent Finder → approved catalog → just-in-time capability loading
Operating pointDiscovery, permissions, AGENTS.md quality, telemetry, and budget

What to do now

A practical first step is not to connect more tools. It is to narrow the blast radius of discovery. Start with a private registry for approved capabilities. Add owner, purpose, scopes, data classification, expected inputs, and an emergency disable path to each entry. Treat AGENTS.md as the repository’s executable review brief: testing expectations, forbidden changes, security assumptions, migration rules, and style conventions. Then wire telemetry and budget alerts around the workflows that can run for a long time, such as automated code review, issue-to-PR agents, browser QA agents, and data-heavy research sessions.

Risks and counterarguments

The counterargument is important: discovery is not trust. A ranked result is not a security review. A manifest can be incomplete. A similarly named tool can confuse users. A useful internal MCP server can still carry more authority than the task needs. ARD also does not replace authentication, authorization, governance, or organizational trust decisions. Teams should treat Agent Finder as a routing layer, not a permission system. The winning setup will pair discovery with approval, sandboxing, logs, spend limits, and periodic removal of stale capabilities.

Sources and further reading

다른 글