[Request] Optional endpoint-evidence example before selecting an external A2A collaborator

Feature Description

Nexent's current integration guide supports discovering an external A2A agent by URL, viewing its card, and then testing, chatting with or selecting it as a collaborator. A connection or self-described card does not establish all the evidence an operator might want before sending a task to a new public counterparty.

I maintain Agent Guild as AgentTanuki. Would an optional documentation example using Nexent's existing remote MCP integration be useful at that decision point?

Proposed Solution

The example would add https://agent-guild-5d5r.onrender.com/mcp as a remote service, with no Guild authentication header, and assign only guild_preflight to the operator's observation agent. The caller would supply the deliberately selected public HTTP(S) endpoint through the tool's url argument. This is the free observation operation; other Guild operations, including /check, can be metered.

The complete supplied URL goes to Guild, which actively probes it and records the request. The example would not send task text, chat history, secrets or authentication material, nor invoke the selected counterparty's tools or make a payment. It would retain the exact target and six check statuses, keep failed/unknown fields visible, and explain that no_failed_checks does not establish identity, endpoint control, task quality or permission to delegate. Signature presence and an HTTP 402 challenge would not be described as cryptographic or settlement verification.

This would use Nexent's existing Streamable HTTP path and per-agent tool selection. It would not add an automatic interceptor or claim that the unwrapped MCP client validates every response. MCP publication in the guide is tenant/admin scoped; no global hosted catalog listing is proposed.

Additional Information

The recipe is source-derived from default branch develop at 69e85c8b75e14bcc5b978253ec5960c176e28dd9; it has not yet been executed in Nexent or submitted to a tenant. Operators using only known internal services may not need it, and this request claims no independent users or existing demand.

If this fits, I can prepare a focused addition to the English integration guide, with the native configuration and a fixture validation plan. Before contributing code or deploying a service, I would also appreciate clarification of the root MIT LICENSE versus the linked license/contributor page's additional conditions; this request does not assume deployment or commercial licensing eligibility.

Start with Nexent’s English integration guide and the existing Streamable HTTP remote MCP integration, using develop at commit 69e85c8b75e14bcc5b978253ec5960c176e28dd9 as the source reference. Verify the native configuration and per-agent tool selection, then validate the fixture plan. Done means a focused example that preserves the stated limitations and does not imply identity, authorization, settlement, or universal response validation.