Partner plugin application: optional Agent Guild endpoint observations and public passport verification

Is this a new feature, an improvement, or a change to existing functionality?

New Feature

How would you describe the priority of this feature request

Low (would be nice)

Please provide a clear description of problem this feature solves

I maintain Agent Guild as AgentTanuki. I would like to apply for the provider-owned plugin path described in the third-party plugin guide.

The intended workflow is an operator or agent selecting a new public MCP/A2A endpoint and requesting a bounded observation before separately deciding whether to connect. A second operation would verify a public passport supplied by a counterparty against independently selected expected issuer and subject DIDs. These are optional observations; neither operation grants authorization or establishes endpoint ownership, task quality, or safety. No NeMo user request or adoption is claimed here.

Describe your ideal solution

A provider-owned agentguild function group with two deliberate operations:

• preflight(url): send the selected public HTTP(S) URL to the fixed Agent Guild /preflight route. Validate exact target equality, the complete six unique checks, statuses, summary lists and derived verdict. Preserve unknowns in a fixed structured projection and omit remote prose. Guild receives the URL and performs the probe; this function does not invoke a target tool.
• verify_public_passport(credential, expected_issuer_did, expected_subject_did): send the complete supplied public credential to the fixed /credentials/verify route, keep both expected DIDs separate from the credential, and report the online verification flags alongside separate signed-date/freshness checks. The route records passport_verified, including unsuccessful verification. This is not independent local signature verification or a binding between a DID and the selected endpoint.

Both routes are public free operations. The plugin would have bounded input/body/deadline handling, explicit disclosure, no registration, credential issuance, enrollment, payment or paid fallback. Host restrictions would be optional so a caller can supply a newly selected public endpoint directly. Hostname validation would be lexical, with no DNS-publicness guarantee.

Proposed distribution details, subject to your naming/design review:

• Provider: Agent Guild; maintainer/support identity: AgentTanuki.
• Existing owned source and issue tracker: AgentTanuki/agent-guild. This application is not claiming a NeMo plugin exists there yet.
• Proposed dedicated repository name: NeMo-Agent-Toolkit-agentguild (not yet created).
• Proposed distribution: nemo-agent-toolkit-agentguild; permissive original code under Apache-2.0.
• Proposed import namespace: nat.plugins.agentguild; entry point: nat.plugins / nat_agentguild = nat.plugins.agentguild.register.
• Proposed _type: agentguild; functions preflight and verify_public_passport, yielding guild__preflight and guild__verify_public_passport for an instance named guild.

I would build against the stable nat.plugin_api, with real entry-point discovery, native function-group execution, strict response fixtures, local HTTP end-to-end tests, and compatibility CI before requesting listing. No package, native test result, listing eligibility or toolkit endorsement is claimed by this application.

Additional context

I also reviewed the related identity and delegation governance proposal #1788. This application does not implement its delegation chains, authorization scope, issuance or revocation system; it proposes a separate provider-owned pair of optional observation functions.

I inspected develop 013255a4dfdf6afe89e80729caba0b2c3bc9513d. The awaited function middleware can stop a function call, but the reviewed static context does not expose the selected MCP session/client generation. The current MCP group also connects and discovers tools during construction. Consequently this proposal does not claim a middleware hook prevents all initial MCP contact or binds a later transport dispatch to a prior observation. The initial example would keep observation and subsequent MCP attachment as separate, explicit steps.

Does this provider-owned scope fit the application stage, before creating the dedicated repository and implementing the plugin? I will use the existing Agent Guild issue tracker for provider-specific support and request documentation listing only after the required loader and execution checks exist.

Code of Conduct

• I agree to follow this project's Code of Conduct.
• I have searched the open feature requests and have found no duplicates for this feature request.

Start with docs/source/extend/third-party-plugins.md and the stable nat.plugin_api, then inspect real entry-point discovery and native function-group execution. Done would require the proposed entry point, strict response fixtures, local HTTP end-to-end tests, and compatibility CI before any listing request.