GitHub Agent Finder lets Copilot discover allowed MCP servers, tools, skills, and agents through registries governed by enterprise settings.
What Agent Finder solves
Copilot is useful only when it can reach the right tools at the right time. As teams add MCP servers, skills, and specialized agents, the hard part is not installing more pieces—it is knowing which ones are allowed, where they live, and how an assistant should choose among them. Agent Finder addresses that gap by turning discovery into a first-class step: Copilot can look up allowed MCP servers, tools, skills, and agents instead of relying on ad hoc prompts, tribal knowledge, or hardcoded tool lists.
That model is often described as ARD-style discovery: the assistant queries registries rather than assuming a fixed catalog. The practical benefit is fewer dead ends. When a task needs a deploy skill, a ticket tool, or a domain agent, Copilot can resolve what is available under policy instead of guessing names or failing on tools the user cannot access.
Registries as the source of truth
Discovery only works if the catalog is trustworthy. Agent Finder treats registries as the controlled inventory of what may be offered. Registries group MCP servers, tools, skills, and agents so Copilot sees a coherent set of options rather than a flat, unbounded list. That structure also helps operators reason about ownership: which team publishes a skill, which server exposes a tool, and which agent is meant for a given workflow.
For engineering teams, the registry is less about marketing a feature and more about operational hygiene. If a tool is retired, renamed, or restricted, the registry entry should change first. Copilot then discovers the updated set without every developer updating local config by hand. That reduces drift between “what the docs say we use” and “what the assistant can actually call.”
Enterprise settings as the guardrail
Open discovery without policy is a risk. Agent Finder is designed to surface only what enterprise settings allow. That means the same discovery flow can behave differently across tenants: a sandbox org might expose experimental agents, while a production org limits Copilot to approved MCP servers and vetted skills. Governance sits in front of discovery, not after the fact as a manual review of every chat.
- Allowed catalogs only: Copilot should not invent or reach tools outside the governed set.
- Consistent access: users and agents see the same policy-backed inventory for a given context.
- Safer rollout: new skills and agents can be published to a registry, then enabled through settings when ready.
This split—registry for inventory, enterprise settings for permission—keeps discovery useful without turning every assistant session into an unmanaged plugin free-for-all. Security and platform teams keep control; developers still get automated lookup when they work inside approved boundaries.
How to use it in day-to-day workflows
Treat Agent Finder as part of task design, not as a one-time setup screen. When starting a multi-step job—code review plus issue update plus docs sync—let Copilot discover the allowed tools and agents for that path before you hardcode tool names into prompts. Prefer registry-backed skills over pasted shell recipes so the same capability stays shareable and revocable. When something fails, check whether the tool is missing from the registry or blocked by settings; those are different fixes.
For platform owners, keep registries small and intentional. Publish clear names and short descriptions so discovery results are understandable in chat. Align agent scopes with real team boundaries so Copilot does not surface a billing agent to a frontend-only workspace. Review enterprise settings whenever you add MCP servers or retire skills, and treat the allowed set as living infrastructure. Done well, Agent Finder makes Copilot’s tool use predictable: discover what is permitted, choose what fits the task, and stay inside the rules the org already defined.