RFC: Dynamic Agent Skills discovery and activation over MCP

[randomradio]

Summary

Explore using OpenConnector as a centrally managed Agent Skills registry and activation layer. An agent would connect to one OpenConnector MCP server, receive a compact catalog of available skills, activate the relevant SKILL.md into context, load referenced resources on demand, and continue to execute provider actions through the existing policy/OAuth/audit path.

This is intended as a design discussion before implementation.

Motivation

Local Agent Skills work well, but every client must install and update copies under its own Claude/Codex/Agent Skills directories. OpenConnector already provides one MCP interface over OAuth providers and upstream MCP services. It could also provide one place to distribute, version, govern, and measure reusable workflows that use those capabilities.

Potential benefits:

• one remote skill registry shared across Claude, Codex, and other MCP clients;
• centralized publication, updates, revocation, and organization policy;
• skill capability checks against live actions, connections, scopes, and runtime policy;
• no duplicated action schemas or credentials inside skill packages;
• observable activation and task-quality benchmarks.

AgentSkills.io behavior to preserve

AgentSkills.io uses list-first progressive disclosure rather than search-first discovery:

1. At session initialization, load every visible skill's name and description into an available_skills catalog.
2. When a description matches the user's task, load the full SKILL.md.
3. Load references, scripts, and assets only when needed.

References:

• https://agentskills.io/specification
• https://agentskills.io/client-implementation/adding-skills-support
• https://agentskills.io/skill-creation/evaluating-skills

For OpenConnector, the global registry may be much larger than a local installed set. A reasonable extension is:

• global registry: all skills visible to the user or organization;
• session catalog: a compact, filtered list of pinned, project-associated, recent, provider-relevant, or required skills;
• optional query on the list operation for the long tail;
• activated SKILL.md and resources pinned by immutable package digest.

Proposed MCP surface

list_skills({ query?, limit?, cursor? })

• No query: return the complete session catalog.
• With a query: search the broader visible registry.
• Return compact metadata only: skillId, Agent Skills-compatible name, description, version, digest, and a short availability summary.

The preferred client path is to call this during session initialization and inject the result as available_skills, so the model can activate a known skill without a search turn.

activate_skill({ skillId, version? })

Return:

• the exact SKILL.md body;
• immutable version and package digest;
• resource manifest without eagerly loading every resource;
• current action/connection/scope/policy readiness;
• clearly tagged model-facing content such as <skill_content ...> plus structured MCP content.

read_skill_resource({ skillId, digest, path })

Return one manifest-listed, digest-pinned reference or asset. Reject absolute paths, traversal, files outside the package, digest mismatches, and oversized resources.

There should be no execute_skill. A skill is instructions. External effects continue through search_actions, get_action_guide, and execute_action.

Bootstrap and client integration

A small local openconnector-skills bootstrap skill may be needed as a compatibility fallback when a client does not inject MCP server instructions or preload the session catalog. It would only teach the model to call list_skills, activate_skill, and read_skill_resource; real workflow skills remain remote.

The preferred path is host-managed catalog injection. In that case every remote skill's own description handles triggering, matching native Agent Skills behavior, and the bootstrap may not be required.

Clients that support dynamic activation should also:

• preserve activated skill content across context compaction;
• deduplicate activation of the same package digest;
• re-inject pinned skill content if compaction removes it;
• expose active skill IDs/digests to delegated agents.

A plain MCP server cannot enforce these context-management properties by itself.

Local versus remote overhead

The important cold-path difference is an extra model/tool decision:

• local: catalog already visible → activate → work;
• remote search-first: bootstrap → list/search → select → activate → work;
• remote catalog-first: catalog injected at initialization → activate → work.

Other overheads include registry latency, remote resource reads, larger tool transcripts, availability while offline, and weaker native context semantics. Proposed mitigations:

• content-addressed local package cache outside native skill directories;
• immutable package digests pinned for the session;
• compact session catalog with broader registry search only as fallback;
• cached resources and bounded batch reads;
• package signatures, publisher provenance, review status, and revocation;
• no downloaded remote scripts in the first version—deterministic behavior should use OpenConnector actions.

Benchmark proposal

Compare the same prompts under:

1. no skill support;
2. MCP server instructions only;
3. local bootstrap plus dynamic skill;
4. remote catalog injected at initialization;
5. the exact same target SKILL.md installed locally.

Measure independently:

• whether listing/search was triggered when needed;
• correct skill in top-k results;
• correct activation and hallucinated skill IDs;
• model/tool cycles before task work starts;
• cold/warm activation latency and cache hit rate;
• token cost;
• resource path/digest correctness;
• task pass-rate gap versus the local skill;
• survival across context compaction;
• prohibited external actions.

Initial product target: with a warm catalog and package cache, dynamic task quality should remain within five percentage points of the same local skill, with no more than one additional tool cycle and zero forbidden external effects.

Open questions

1. Should the first implementation require host integration, or target stock MCP clients with a bootstrap skill?
2. Where should the session catalog be exposed: MCP initialization instructions, a dynamic activation-tool description, or an automatic host call to list_skills?
3. How should user, organization, project, and public skill precedence work?
4. Should packages live in the existing runtime data stores or a separate content-addressed object store?
5. What review/signing model is required before remote skill instructions can be activated?
6. Should v1 support only SKILL.md, text references, and assets, explicitly rejecting executable scripts?
7. Which client/model should define the initial local-skill parity benchmark?

@hyrious, could you share your view on whether this fits OpenConnector's MCP/runtime direction, especially the catalog-initialization boundary and the v1 package/security scope?

[BlackHole1]

Currently, our approach is to coordinate with oo-cli, which calls the search API of open-connector. When a user uses a certain provider in a session, oo-cli will recommend that the user install the skills of that provider.

Related projects:

• https://github.com/oomol-lab/oo-cli
• https://github.com/oomol-lab/skills

However, this approach is unrelated to MCP. If support is to be provided, as you mentioned, a guiding scheme similar to openconnector-skills needs to be offered to inform AI on how to use these MCP interfaces.

I would like to know if there are currently similar projects doing this?

[randomradio]

Thanks. I see oo-cli primarily as a CLI that helps agents use OpenConnector. Its provider-skill recommendation flow still ends with installing files into each agent’s local skill directory.

The goal here is different: make OpenConnector a centralized skill management and access layer. It should dynamically enable or disable skills per user, agent, or session; expose only the permitted skill metadata; and serve SKILL.md plus resources on demand through the existing MCP connection. This avoids copying the full skill set into local directories or polluting the model context with every available skill.

SEP-2640 appears to provide the right transport through skill://index.json and MCP resources. OpenConnector would add the management layer: authentication, per-agent filtering, policy, versioning, and capability-aware exposure.

Microsoft’s AgentMcpSkillsSource is a similar client-side implementation.

I suggest an SEP-2640-aligned OpenConnector experiment rather than a separate skill protocol. Local installation can remain an optional compatibility path for clients that do not yet support Skills over MCP.