Summary
Agent Plugins v1.0.0 made remote MCP transport declarations portable, but it intentionally leaves authentication entirely client-managed. A cross-host conversion into Microsoft 365 Copilot Cowork exposed a narrower missing contract: the package can say where a remote MCP server is, but cannot state the non-secret authentication requirement a target client must satisfy.
This is a follow-up to the auth portion of #7 now that v1.0.0 landed remote transport. If maintainers would rather keep the discussion on #7, I am happy for this to be folded back there; I split it only because the remaining gap is narrower than the original issue.
Current v1 boundary
Agent Plugins 1.0.0 §7.2.1 is explicit:
Agent Plugins 1.0.0 defines no OAuth configuration or portable credential-reference fields. Authorization discovery, user interaction, and credential storage are client-managed.
The same section is also explicit that headers are fixed visible package data, clients must not perform placeholder or environment-variable expansion in them, and plugins must not embed credentials or other secrets there. Those are sound security choices.
The interoperability gap is that a client or converter still cannot distinguish these common cases from the package alone:
- the server is public and requires no authentication;
- the server implements standard MCP OAuth discovery;
- the server requires an API key or another client-managed credential;
- the server requires a client registration or host-specific setup step; or
- the server's authentication requirements are unsupported by the target client.
An HTTPS URL does not answer that question, and silently guessing changes behavior.
Concrete cross-host result
We implemented a conservative Agent Plugins v1.0.0 → Microsoft 365 Copilot Cowork conversion.
The following mapped cleanly enough to compile:
- package name, version, description, and author metadata;
- Agent Skills under
skills/; and
- headerless HTTPS
streamable-http MCP endpoint declarations.
Authentication did not map. In Cowork, a remote connector ultimately needs a host-specific manifest posture such as:
None;OAuthPluginVault plus a Microsoft referenceId;ApiKeyPluginVault plus an existing referenceId; or- Dynamic Client Registration by omitting
authorization.
Nothing in an Agent Plugin tells a converter which choice is true. A generated placeholder reference can be schema-valid while remaining operationally unusable.
Our converter now fails closed and requires an explicit per-server auth link instead of inferring OAuth from an HTTPS URL.
Request for v2 discussion
Could v2 define a portable, non-secret way for a package to declare a remote MCP server's authentication requirements?
The portable layer does not need to own credentials. In particular, this should not put bearer tokens, API keys, client secrets, or host-local credential IDs in plugin.json or mcp.json.
It could instead let a package express enough intent for a client to decide whether and how it can satisfy the server, for example:
none / public;- MCP OAuth discovery expected;
- client-managed API key expected;
- host setup required; or
- a generic extensible requirement/capability identifier.
The exact shape needs design. The important behavior is that clients can make unsupported auth requirements visible rather than discovering the mismatch only after connection, and converters do not have to invent target semantics from a URL.
Non-goals
- Standardizing credential storage across hosts.
- Embedding secrets in portable packages.
- Making one host's vault identifier portable.
- Requiring every client to implement every auth mechanism.
Why a focused issue
#7 correctly identified the broader remote-MCP gap before v1.0.0 landed. Transport is now covered in v1.0.0. This issue isolates the remaining v2 question: how can a plugin describe remote-server auth requirements without carrying credentials? If you would rather keep that discussion on #7, feel free to merge or close this as a duplicate.
Summary
Agent Plugins v1.0.0 made remote MCP transport declarations portable, but it intentionally leaves authentication entirely client-managed. A cross-host conversion into Microsoft 365 Copilot Cowork exposed a narrower missing contract: the package can say where a remote MCP server is, but cannot state the non-secret authentication requirement a target client must satisfy.
This is a follow-up to the auth portion of #7 now that v1.0.0 landed remote transport. If maintainers would rather keep the discussion on #7, I am happy for this to be folded back there; I split it only because the remaining gap is narrower than the original issue.
Current v1 boundary
Agent Plugins 1.0.0 §7.2.1 is explicit:
The same section is also explicit that
headersare fixed visible package data, clients must not perform placeholder or environment-variable expansion in them, and plugins must not embed credentials or other secrets there. Those are sound security choices.The interoperability gap is that a client or converter still cannot distinguish these common cases from the package alone:
An HTTPS URL does not answer that question, and silently guessing changes behavior.
Concrete cross-host result
We implemented a conservative Agent Plugins v1.0.0 → Microsoft 365 Copilot Cowork conversion.
The following mapped cleanly enough to compile:
skills/; andstreamable-httpMCP endpoint declarations.Authentication did not map. In Cowork, a remote connector ultimately needs a host-specific manifest posture such as:
None;OAuthPluginVaultplus a MicrosoftreferenceId;ApiKeyPluginVaultplus an existingreferenceId; orauthorization.Nothing in an Agent Plugin tells a converter which choice is true. A generated placeholder reference can be schema-valid while remaining operationally unusable.
Our converter now fails closed and requires an explicit per-server auth link instead of inferring OAuth from an HTTPS URL.
Request for v2 discussion
Could v2 define a portable, non-secret way for a package to declare a remote MCP server's authentication requirements?
The portable layer does not need to own credentials. In particular, this should not put bearer tokens, API keys, client secrets, or host-local credential IDs in
plugin.jsonormcp.json.It could instead let a package express enough intent for a client to decide whether and how it can satisfy the server, for example:
none/ public;The exact shape needs design. The important behavior is that clients can make unsupported auth requirements visible rather than discovering the mismatch only after connection, and converters do not have to invent target semantics from a URL.
Non-goals
Why a focused issue
#7 correctly identified the broader remote-MCP gap before v1.0.0 landed. Transport is now covered in v1.0.0. This issue isolates the remaining v2 question: how can a plugin describe remote-server auth requirements without carrying credentials? If you would rather keep that discussion on #7, feel free to merge or close this as a duplicate.