GitHub Agent Finder brings ARD discovery into Copilot
GitHub Agent Finder lets Copilot discover allowed agents, skills, tools, and MCP servers through the open Agentic Resource Discovery specification instead of preloading every capability.
GitHub Agent Finder is a new Copilot capability that searches registries of agentic resources, then returns ranked options for the task at hand. GitHub says it uses the open Agentic Resource Discovery specification, so discovery can happen against GitHub's public catalog or a private enterprise registry. The important limit is that discovery is not installation: administrators still decide which resources are allowed and what gets connected.
Key takeaways
- Agent Finder is available across GitHub Copilot plans, according to GitHub's changelog.
- It can search for agents, skills, tools, MCP servers, canvases, and related resources instead of forcing teams to pre-wire every option into context.
- ARD separates discovery from execution: it helps a client find a resource, then the resource still runs through its native protocol or API.
- Google describes ARD as a catalog-and-registry model, with
ai-catalog.jsonfiles and registries that index trusted resources. - Enterprise value depends on governance settings, private catalogs, publisher verification, and whether teams keep installation as an explicit review step.
Practical LinkLoot angle
The useful workflow is a smaller agent context window and a clearer approval boundary. Instead of loading every possible MCP server, internal skill, or workflow into an agent prompt, a team can publish an approved catalog and let Copilot search it when a task needs a specific capability. That is better for context budget, but it also creates a new governance job: catalog quality, resource identity, and egress controls become part of agent operations.
| Option | Best use | Limitation | Source |
|---|---|---|---|
| GitHub Agent Finder | Copilot teams that want task-time discovery of approved resources | Tied to Copilot governance and registry choices | GitHub |
| ARD catalogs | Publishing discoverable agentic resources from an organization-owned domain | Discovery only; execution and auth stay elsewhere | ARD spec |
| Private registry | Internal tools, support workflows, compliance-approved MCP servers | Requires catalog hygiene and admin ownership | Google / GitHub |
| Manual tool wiring | Small projects with a handful of stable tools | Bloats context and does not scale to many ad-hoc resources | Workflow comparison |
For builders, the practical question is not "should every agent search the open web?" It is "which registry should this agent trust for this task?" A support agent might search only internal runbooks and ticket tools. A coding agent might search approved repo-analysis tools, CI helpers, and deployment dashboards. A research agent might use a broader public catalog, but only after the operator accepts the source and permission model.
What to verify before you act
Verify where Agent Finder is enabled in your Copilot plan and whether enterprise-managed settings can restrict the registry it searches. Check whether any catalog you publish is hosted under a domain you control, because ARD's trust model relies heavily on domain ownership and verifiable metadata. Treat Hugging Face, GitHub, Google, or third-party registries as discovery surfaces, not safety guarantees: review the resource, auth scope, data flow, and logs before connecting it to sensitive work.
GitHub confirms the Copilot feature, registry selection, managed settings, and no-auto-install behavior. Google independently confirms the ARD announcement, catalog and registry model, trust metadata, and Gemini Enterprise Agent Platform support. The public ARD specification confirms that ARD is a discovery protocol, not an execution runtime or central marketplace.
It is a GitHub Copilot feature that searches a registry of agentic resources and returns matching tools, skills, agents, or MCP servers for a task.
For adjacent patterns, compare this with LinkLoot's guide to AI agent tools, especially if you are deciding how to organize MCP servers, skills, and internal automation.