Actors and success scenario: A user operates an XMPP client, the user's server advertises an agent gateway, and the gateway exposes a visibility-scoped directory. The client verifies the gateway feature, pages through visible endpoint items, and queries the selected endpoint's information as defined in Finding a Gateway, Listing Agent Endpoints, and Endpoint Information.

Alternate flows and errors: A candidate without the required feature is not a gateway. An empty page can mean that no endpoints are visible. A hidden or nonexistent endpoint produces the same safe error behavior defined in Error Handling; the client MUST NOT infer existence from a failed query.

Actors and success scenario: A legacy-capable client and a gateway implementing the Jabber Search Compatibility profile exchange a search form and submission. The gateway applies the requester's visibility policy, orders matching endpoint JIDs deterministically, and returns an RSM page as defined in Agent Directory Search.

Alternate flows and errors: A gateway that advertises only Core Directory need not support search. An empty result can mean no visible match, and RSM counts include only visible endpoints. Malformed forms receive the applicable stanza error; hidden endpoints MUST NOT be distinguishable from absent results.

Actors and success scenario: A caller retrieves an endpoint's immutable manifest, records its exact version and hash, lists the tools pinned to that version, retrieves the selected tool's metadata and schemas, and sends an invocation to the target. The target validates and durably admits the task before returning acceptance, following Manifest Retrieval, Listing Tools, Retrieving Tool Schemas, and Invocation.

Alternate flows and errors: A stale manifest hash produces a <conflict/> error, invalid arguments produce a <not-acceptable/> error, and an unknown or hidden tool or version produces an <item-not-found/> error. No task exists unless durable admission succeeds.

Actors and success scenario: A caller loses one or more lifecycle messages, reconnects on another authorized resource, and queries the target for complete task state. If the task is terminal and its result remains within the promised retention period, the caller retrieves the immutable terminal result as defined in Task Recovery.

Alternate flows and errors: A result query for a non-terminal task produces an <unexpected-request/> error. Nonexistent, expired, unauthorized, and cross-tenant task IDs all produce the same <item-not-found/> error and safe payload. Notification loss never establishes failure or permission to create a replacement task.

Actors and success scenario: A target pauses a task in state input_required, records one pending structured request, and notifies the caller. The caller can recover that request from complete task state and submit one schema-valid answer from any authorized resource of its bare JID, following Interactive Input.

Alternate flows and errors: Invalid input produces a <not-acceptable/> error. Unknown requests produce an <item-not-found/> error, while stale, expired, already answered, or revision-conflicting input produces a <conflict/> error. An identical replay of an accepted answer is idempotent.

Actors and success scenario: An authorized caller requests cancellation while the target owns a non-terminal task. The target atomically commits the request, moves the task to cancelling, and later settles it as cancelled, completed, or failed, as defined in Cancellation and Deadlines and Task States.

Alternate flows and errors: Cancellation is advisory, so successful work can still win the race. If terminal settlement commits first, the cancellation request produces a <conflict/> error. If cancellation commits first, later tool output cannot overwrite the terminal result.

Actors and success scenario: A caller loses the admission IQ result and retries the same request ID with the same replay fingerprint during the advertised replay window. The target returns the original accepted task and does not execute the tool twice, following Invocation and Idempotency and Delegation.

Alternate flows and errors: Reusing the request ID with any fingerprint difference produces a <conflict/> error. Stream loss, timeout, or missing progress does not prove non-execution; the caller MUST retry identically or reconcile through Task Recovery rather than create a fresh side-effecting request.

Actors and success scenario: A remote requester contacts a gateway or endpoint across an authenticated server-to-server route. Unless trusted local policy explicitly grants visibility or invocation, the gateway denies access without revealing whether the endpoint, tool, or task exists, as illustrated in Federated Invocation Example.

Alternate flows and errors: An operator can separately allow remote visibility and invocation for an identified domain or principal. Authentication alone grants neither. Denied, hidden, and nonexistent objects use equivalent safe errors, timing defenses, and rate limits according to Security Considerations.

Actors and success scenario: An authenticated C2S account self-registers an immutable manifest for its own bare JID, or a trusted administrator provisions a virtual endpoint. The gateway validates and stores the version, returns its canonical hash, and explicitly activates a selected version as defined in Registration Flow.

Alternate flows and errors: Self-registration for another JID is forbidden, and a component cannot claim that a virtual endpoint authenticated independently. Re-registering identical content is idempotent; different content under an existing version produces a <conflict/> error. Activation fails unless the exact registered version and hash exist and the sender is authorized.

Actors and success scenario: An MCP client communicates through a bridge that exposes an XMPP endpoint. The bridge preserves MCP Tool schemas, annotations, execution metadata, and complete CallToolResult objects where representable while mapping discovery, invocation, lifecycle, and recovery according to MCP Mapping.

Alternate flows and errors: When either protocol cannot represent a capability or state exactly, the bridge records and reports the semantic loss. It keeps XMPP RSM and MCP tool-list cursors separate and MUST NOT claim transparent MCP Tasks support when task identity, creation, polling, result retrieval, cancellation, or retention semantics are lost.

The gateway MUST have a domain JID, such as agents.example. Every hosted endpoint MUST have a bare JID, such as weather@agents.example. A gateway MAY host endpoints below its own component domain or another domain delegated to it by the XMPP server.

Agent endpoint JIDs are ordinary XMPP addresses from the perspective of remote entities. A server MUST route stanzas addressed to hosted endpoint JIDs to the responsible gateway. The endpoint need not correspond to a C2S account and need not maintain an independent XML stream.

A gateway MAY be implemented as an internal server module, an &xep0114; component, or another trusted service integration. The on-wire agent protocol is independent of that choice. An external component deployment MUST provision:

• the component domain or delegated agent domain;
• an authenticated component connection;
• routing for the virtual endpoint JIDs;
• an authorization policy for registration, directory visibility, and invocation;
• persistent manifest and task state if tasks must survive restart; and
• bounded reconnect, keepalive, IQ correlation, and task timeout behavior.

Remote component connections MUST use confidentiality and server authentication appropriate to the deployment. A plaintext component secret sent across an untrusted network is not acceptable. Operators SHOULD place the component on a local or mutually authenticated encrypted transport and SHOULD rotate component credentials.

The gateway SHOULD send &xep0199; pings after a period of stream inactivity and SHOULD reconnect with capped exponential backoff and jitter. Outstanding IQ requests MUST fail or time out when the component stream is lost; they MUST NOT remain pending indefinitely.

This specification remains one document, but an implementation can claim one or more independently testable profiles:

A gateway MUST NOT advertise a feature it does not implement for the addressed entity. Service-discovery feature vars are authoritative. Endpoint-wide and tool-specific support are both required: effective support is true only when the endpoint advertises the feature and the selected tool declares support in its pinned manifest.

A client SHOULD query its server using &xep0030; items. A server that exposes an agent gateway SHOULD include the gateway JID as an item. A client MUST then query the candidate JID with disco#info and MUST verify the urn:xmpp:agent-directory:0 feature rather than inferring support from a subdomain name.

The gateway MUST advertise an identity whose 'category' attribute is "automation" and whose 'type' attribute is "agent-gateway". It MUST advertise the protocol features it implements. This specification does not use directory/user, which denotes a directory of end users rather than agent endpoints.

A client lists addressable agents by sending a disco#items query to the gateway. The query MAY omit node or set it to urn:xmpp:agent-directory:0. Each returned item MUST contain the endpoint bare JID and SHOULD contain its human-readable name. Because each item is itself an addressable entity, the item MUST NOT set node.

The directory node MUST answer disco#info with an identity whose 'category' attribute is "automation" and whose 'type' attribute is "agent-directory", plus features http://jabber.org/protocol/disco#info and http://jabber.org/protocol/disco#items.

Directory listing MUST support &xep0059;. Results MUST be ordered by normalized endpoint bare JID using octetwise ascending order, and that bare JID is the stable RSM item ID. The gateway MAY enforce a page maximum smaller than requested. RSM count MUST count only endpoints visible to the requester.

The gateway MUST apply its visibility policy before returning items. An empty result is not evidence that no agents exist; it can mean that no endpoints are visible to the requester.

A client obtains endpoint metadata by sending a node-less disco#info query to the endpoint bare JID. The endpoint MUST advertise an identity whose 'category' attribute is "automation" and whose 'type' attribute is "agent-endpoint", features http://jabber.org/protocol/disco#info and http://jabber.org/protocol/disco#items, the task and API features it implements, and an &xep0128; result form with FORM_TYPE urn:xmpp:agent-endpoint-info:0. urn:xmpp:agent-endpoint:0 is a service-discovery feature var only. It is not a disco node; an endpoint MUST return an <item-not-found/> error if it is used as one.

A client lists an endpoint's tools by sending a disco#items query to the endpoint JID using the version-pinned collection node urn:xmpp:agent-tools:0#VERSION. Each item MUST use the endpoint JID, MUST identify the same version and tool with a tool node, and SHOULD include a human-readable name. Tool listing MUST support &xep0059;, ordered by the exact UTF-8 tool-name bytes in octetwise ascending order; the complete encoded tool node is the stable RSM item ID. Counts include only tools visible to the requester.

The collection node MUST answer disco#info with an identity whose 'category' attribute is "automation" and whose 'type' attribute is "agent-tool-collection", plus features http://jabber.org/protocol/disco#info and http://jabber.org/protocol/disco#items. Its version is fixed by the node identifier.

A client obtains tool metadata by querying its version-pinned tool node with disco#info. The response MUST advertise an identity whose 'category' attribute is "automation" and whose 'type' attribute is "agent-tool", features http://jabber.org/protocol/disco#info and urn:xmpp:agent-tool:0, the tool-specific task features it supports, and an &xep0128; result form with FORM_TYPE urn:xmpp:agent-tool-info:0.

Each hash algorithm/value field pair MUST appear together. The value is the Base64 content that would appear in an &xep0300; <hash/> element; it does not contain an algorithm prefix.

Annotations are optional untrusted hints and MUST NOT be used as authorization decisions. In particular, read_only=true does not prove that execution has no side effects. An absent field means unknown; a bridge MUST preserve absence and MUST NOT manufacture a value while claiming a lossless mapping.

To avoid placing large JSON Schemas in discovery responses, a client retrieves each schema with an IQ of type "get" containing a <schema-request/> element. The 'tool', 'version', and 'direction' attributes are REQUIRED. The request MUST include the expected manifest hash. The response contains a <schema/> element with the exact version and media type plus &xep0300; <hash/> child elements for the manifest and schema. After XML character extraction, the <json/> element's character data MUST be the exact RFC 8785 canonical UTF-8 bytes represented by the schema hash. A target MUST return a <conflict/> error when the supplied manifest hash does not select the immutable registered object.

Tool schemas MUST be valid JSON Schema objects. Version 0 uses these rules:

• The recognized dialect is JSON Schema 2020-12; omission of $schema selects it.
• Core, Applicator, Validation, Meta-Data, Format-Annotation, Content, and Unevaluated vocabularies are required. format is annotation-only unless an extension explicitly requires supported assertion behavior.
• An input schema MUST have an object root.
• $id establishes the normal base URI, but automatic network retrieval is forbidden.
• Same-document $ref, $anchor, $dynamicRef, and $dynamicAnchor MUST be supported. External references require an explicit allowlist and resource budget.
• A vocabulary declared true in $vocabulary is required and MUST cause registration to fail when unsupported. An unsupported vocabulary declared false MAY be ignored only according to its optional semantics.
• Regular expressions use the ECMA-262-compatible semantics required by JSON Schema and MUST be resource bounded.
• Unknown annotation keywords MAY be retained and ignored; an unsupported assertion keyword MUST cause registration to fail.

The target's evaluation of the exact registered schema is authoritative.

An endpoint MAY publish a profile with &xep0292;. For compatibility with deployed clients, it MAY also answer &xep0054; requests. Profile information disclosed publicly MUST be limited to data intended for all requesters.

A hosted virtual endpoint SHOULD respond to presence subscription requests and probes as specified by XMPP IM. A gateway acting for a virtual endpoint MAY approve a subscription with subscribed and then send available presence. Presence reflects communications availability; detailed tool state remains in endpoint information.

Runtime availability is volatile and MUST be communicated with presence, not a cacheable service-discovery form. A cold-startable endpoint MAY be unavailable in XMPP presence while still advertising the static capability cold_start_supported=1.

An endpoint registers an immutable JSON manifest. The manifest is an independent XMPP data model based on the MCP Tool model and contains the following members:

Each tool MUST contain name and inputSchema. It MAY contain title, description, outputSchema, MCP annotations, MCP execution, MCP _meta, and an XMPP extension object named urn:xmpp:agent-api:0. The MCP members retain their MCP-defined semantics exactly. XMPP-specific progress, cancellation, timeout, authorization, and tag declarations belong only in the namespaced extension object. Tool names MUST satisfy the grammar in Protocol Namespaces and Identifiers and MUST be unique within one manifest.

The endpoint and tool service-discovery features are authoritative for XMPP capability negotiation. Tool-specific declarations apply only after that tool has been selected and MUST NOT override an endpoint capability advertised as unsupported.

Execution and authorization hints are declarations, not grants. A gateway MUST derive effective authorization from trusted policy and MUST fail closed when a declared permission or approval requirement cannot be enforced.

This version uses all-or-nothing manifest visibility. A requester authorized to retrieve a manifest sees every tool in it. A deployment requiring tool-level visibility MUST publish separate endpoint versions or endpoint JIDs; it MUST NOT return a requester-filtered document under the registered manifest hash.

The following JSON Schema is normative for manifests. Limits shown here are protocol maxima; deployments MAY impose smaller documented limits. MCP-owned objects follow the MCP protocol revision declared by the manifest. Unknown top-level members are forbidden; extensions use URI-valued member names within a tool.

Self-registration and trusted administrative provisioning are different conformance profiles. Self-registration applies only to a genuine authenticated C2S endpoint whose authenticated bare JID equals agent.jid. A virtual endpoint behind an internal module or &xep0114; component is provisioned by a trusted administrator through the Administrative Provisioning profile or a deployment-local API. Component authority MUST NOT be represented as if the virtual endpoint independently authenticated. Federation alone MUST NOT grant either authority.

The gateway MUST validate the manifest before committing it. Before hashing, manifests and schemas MUST satisfy the I-JSON prerequisites of RFC 8785: no duplicate object names, valid Unicode with no lone surrogates, and numbers representable as IEEE-754 double precision. Strings are preserved without Unicode normalization. The gateway canonicalizes according to RFC 8785, hashes the canonical UTF-8 bytes with SHA-256, and represents the hash with an &xep0300; <hash/> element using Base64 content. Invalid input is rejected before digest calculation. A hash is a cache validator and change detector, not proof of origin.

The tuple (endpoint bare JID, API version) is immutable. Re-registering the same version and hash is idempotent. Re-registering the same version with different canonical content MUST fail with a <conflict/> error. A new version creates a new immutable manifest. Semantic-version ordering MUST NOT be inferred.

The Administrative Provisioning profile MUST provide IQ operations to register an immutable version, activate an existing version, deactivate an endpoint, inspect registration status, remove an inactive version, and remove an endpoint. These operations use the same XML namespace, are addressed to the gateway, and require trusted administrative authorization. Activating a version changes only the mutable selected-version pointer; it does not alter a manifest. Removal MUST fail while a retained task or result depends on that version. A removed version leaves a permanent endpoint-scoped version-and-hash tombstone: identical content MAY be restored, but different content under that version MUST always fail with a <conflict/> error. A deployment MAY expose equivalent local administration instead of advertising urn:xmpp:agent-api:0#admin federatively.

A client retrieves a manifest by sending an IQ of type "get" containing a <manifest-request/> element to the endpoint. Omitting the 'version' attribute requests the active version; a client MUST then pin the returned version and hash before listing tools, retrieving schemas, or invoking. Supplying the 'version' attribute requests that exact immutable version.

• The result MUST contain the exact version, a 'media-type' attribute whose value is "application/json", an &xep0300; hash, and the canonical registered JSON document.
• After XML character extraction, the UTF-8 bytes in the <json/> element MUST be byte-for-byte identical to the RFC 8785 canonical bytes that were hashed and advertised.
• The stored source formatting is not protocol-visible and MUST NOT affect retrieval or hash validation.
• Access control MUST be identical to the corresponding tool and schema discovery policy.

A previously registered version remains addressable by exact value to a client that recorded it. Version enumeration is not defined. The target MUST retain the exact manifest and schemas selected at task admission through the task lifetime and promised result-retention period.

Tool execution is asynchronous even when a local API offers a blocking convenience call. The caller creates a globally unpredictable request ID and sends an IQ of type "set" containing an <invoke/> element. The target creates the task ID only after successful validation and durable admission. Both identifiers MUST contain 22 to 128 ASCII characters from [A-Za-z0-9._~-] and MUST contain at least 128 bits of unpredictability generated by a cryptographically secure random number generator. A deployment-local correlation ID MAY associate this operation with application state, but it has no wire authority.

The 'request-id', 'tool', and 'api-version' attributes, manifest hash, and <arguments/> element are REQUIRED. The <arguments/> element MUST include a 'media-type' attribute whose value is "application/json". A target MUST pin the exact manifest and schemas before admission. The authoritative authorization principal is the immediate authenticated sender's bare JID. The full JID that issued the IQ is the default best-effort notification route; any authorized resource of the same bare JID can use recovery operations.

The target computes a replay fingerprint over the authenticated caller bare JID, target bare JID, protocol namespace, request ID, tool, API version, manifest hash, canonical arguments, deadline, and every security-relevant extension. During the advertised replay window, reuse with the same fingerprint MUST return the same accepted task and MUST NOT execute twice; reuse with a different fingerprint MUST fail with a <conflict/> error. A target MUST retain the replay record through the longer of that window, the task lifetime, and the promised result-retention period.

After the advertised replay window and all required task retention have expired, a target MAY forget the request ID and MAY admit a repeated request as new work. Therefore a caller MUST NOT retry after that window without tool-specific reconciliation. This protocol provides at-most-once task admission only inside the replay-retention window and does not claim exactly-once external side effects.

An IQ result containing an <accepted/> element represents durable task acceptance, not merely receipt of the request. The target MUST persist the task and replay record before sending that result.

• Malformed, unauthorized, conflicting, unavailable, expired, or schema-invalid requests fail before admission with an ordinary IQ error and create no task.
• Loss of the IQ result leaves execution uncertain; the caller MUST retry the identical request ID rather than create a new request.
• &xep0184; does not apply to IQ admission.

This example shows a caller at example.com discovering and invoking an endpoint at agents.example. Normal XMPP server-to-server authentication establishes the immediate sender domain; the target's explicit federation policy still determines visibility and authorization.

The target sends best-effort lifecycle notifications as normal messages containing an <event/> element. The <event/> element's character data is a JSON object governed by Lifecycle JSON Schemas. Every event carries the receiver-generated task ID, a globally unique unpredictable event ID, and a global revision. Revision 0 is the accepted state returned by IQ. Each committed state transition MUST increase the revision by exactly one and generate exactly one event at that revision. Each committed progress update likewise increases it by exactly one. Delivery can lose an event, but the target does not create revision gaps through hidden transitions.

The value of the 'retain-until' attribute on the <accepted/> element is a unilateral promise by the target. Complete state and any terminal result MUST remain queryable until then, and state MUST remain queryable throughout a longer non-terminal lifetime. A caller requiring longer retention MUST preserve its own record.

When present, progress percent MUST be a finite number from 0 through 100 inclusive and SHOULD be nondecreasing. An identical replay MUST retain the same event ID, revision, type, and canonical payload. A caller MUST ignore such a replay. A repeated revision with a different event ID or payload is a protocol error and MUST be ignored and logged. A revision gap does not imply failure; the caller SHOULD query task state, which returns the current revision and complete resumable state.

The result member is the complete tool result envelope. An MCP bridge preserves CallToolResult.content, structuredContent, isError, and _meta as a whole. An MCP result with isError=true is still a successfully completed tool call and MUST NOT be converted into infrastructure state failed. When the selected tool declares an outputSchema, the target MUST validate structuredContent before completion, and the caller SHOULD validate it again.

When a target cannot continue without caller input, it commits state input_required and sends a notification with a task-unique request ID, a human-readable question, a JSON Schema, creation time, and optional expiry time. At most one input request may be pending per task. Only an authorized resource of the authenticated caller bare JID may answer with an IQ of type "set" containing a <provide-input/> element. The target authoritatively validates the input and expected revision before returning an <input-accepted/> element. Unknown request IDs receive an <item-not-found/> error; schema-invalid input receives a <not-acceptable/> error; stale, expired, already answered, or conflicting input receives a <conflict/> error. Repeating an identical accepted IQ is idempotent.

Every state response while input is pending MUST include the complete pending request, including its expiry if any, so loss of the notification is recoverable. On input expiry the target MUST atomically issue a new input request or settle the task. Cancellation may transition pending input to cancelling. Terminal settlement wins any race with input, and input received after terminal settlement MUST fail with a <conflict/> error.

Interactive input is data entry, not a standardized authorization grant. Human approval in version 0 can be satisfied only through trusted local or out-of-band policy. A target that cannot verify a required approval MUST fail closed. Secrets SHOULD be provided through a credential mechanism rather than copied into task payloads.

Only an authorized resource of the authenticated caller bare JID may request cancellation using an IQ of type "set". A cancellation request is accepted exactly once, moves a non-terminal task to cancelling, and remains advisory until the target settles it as cancelled, completed, or failed. The target alone chooses and commits the terminal state. If settlement committed first, cancellation fails with a <conflict/> error; if cancellation committed first, later tool output cannot overwrite the terminal result.

Deadlines MUST conform to &xep0082;. If the target's accepted deadline expires while its task is non-terminal, the target MUST settle the task as failed with code deadline-expired. A caller-side wait timeout is only a local observation and MUST NOT create or assert a remote terminal state. Timeout does not prove that side effects did not occur; the caller MUST recover state or retry the identical request ID before considering a new side-effecting invocation.

Validation, rejection, queueing, startup, and caller-side timeouts are local conditions, not interoperable task states. A task exists only after durable acceptance. The permitted transitions are: accepted to running, input_required, cancelling, or any terminal state; running to input_required, cancelling, or any terminal state; input_required to running, cancelling, or any terminal state; and cancelling to any terminal state. Terminal states are immutable.

A caller recovers state with an IQ of type "get" containing a <task-state-request/> element and retrieves a terminal result with a separate <task-result-request/> element.

• The target MUST authorize every operation against the caller bare JID.
• Syntactically invalid identifiers receive a <bad-request/> error.
• Nonexistent, expired, unauthorized, and cross-tenant task IDs MUST all receive the same <item-not-found/> error and safe payload.
• Those cases SHOULD use similar response timing and identical rate-limiting classes so they remain observationally equivalent.

The <task-state/> element MUST return the target endpoint bare JID, exact API version and manifest hash, state, current global revision, creation and update times, retention deadline, and deadline if any. While input is pending it MUST include a <pending-input/> element with a 'media-type' attribute whose value is "application/json" and character data containing the complete input_required object. A terminal state MUST identify whether a retained result is available. The <task-result/> element is valid only for a terminal task, returns the immutable terminal state and complete retained payload, and MUST fail with an <unexpected-request/> error while non-terminal. Notifications are advisory; these two IQ operations are the recovery source of truth.

Caller commands and recovery IQs MUST be addressed to the target bare JID. The authorization principal is the caller bare JID. Best-effort event messages SHOULD be addressed to the full JID that issued the <invoke/> element; after loss of that route the target MAY address notifications to the caller bare JID according to ordinary routing. Correctness MUST NOT depend on notification delivery to either route.

Because bare-JID notification fallback is permitted, this profile MUST NOT use &xep0334; no-copy. A target MAY use no-store or no-permanent-store as a storage preference, but processing hints are never a correctness or confidentiality mechanism. Implementers MUST assume that carbons, archives, offline storage, and administrative logging can replicate task payloads. Events are deduplicated by (target bare JID, task-id, revision), and an identical replay retains its event ID. Sensitive arguments or results SHOULD use an appropriate end-to-end encryption profile.

The wire request-id and replay fingerprint provide invocation idempotency. They are scoped to the authenticated caller bare JID and target bare JID and are not authentication secrets.

The base protocol authenticates only the immediate stanza sender. It defines no signed delegation token, original-user assertion, approval grant, or chain-of-custody proof. A target MUST authorize the immediate authenticated sender. A local deployment MAY additionally enforce an original principal learned through trusted local context, but MUST NOT present that value to a remote peer as verifiable authority. Cross-domain on-behalf-of authorization is future work.

This subsection is informative. The XMPP gateway is the protocol endpoint; an LLM, provider runtime, or tool implementation need not parse or generate XMPP stanzas, JIDs, namespace identifiers, tenant identifiers, or delivery envelopes. A useful implementation presents a transport-neutral contract containing the selected tool name, validated arguments, safe tool metadata, and only the event data needed to perform the work. Opaque endpoint and task handles reduce accidental transport disclosure.

After wire validation, a target gateway can dispatch a task to an internal agent or model runtime. Task-scoped provider state should remain separate from ordinary channel conversation state. An action runtime can report completion, failure, progress, input requests, or cancellation through a transport-neutral action bound to the current task; the gateway then applies the state transition and constructs the authorized stanza.

These architectural techniques do not replace the authorization invariants in Security Considerations. In particular, application output cannot select a wire sender, authenticated caller, tenant, unrelated task, or unauthorized destination.

MCP clients connected through a bridge SHOULD receive normal MCP tool objects. A bridge MUST preserve schemas, annotations, execution, content, structuredContent, isError, and _meta where representable; preserve MCP tool-list cursors internally; and report semantic loss when either side cannot represent a capability. The XMPP directory RSM cursor is not an MCP tool-list cursor.

MCP 2025-11-25 Tasks are experimental and not wire-identical to this protocol. Several detailed XMPP non-terminal states map to MCP working; MCP working cannot be expanded back into a more specific XMPP state without bridge-owned knowledge. MCP TTL is measured in milliseconds from task creation, while this protocol advertises an absolute retention deadline covering the task result. Receiver-generated task IDs, creation responses, polling, result retrieval, and cancellation MUST be represented explicitly in a bridge-loss table. A bridge MUST NOT claim transparent MCP Tasks support when any of these semantics are lost.

Clients MAY cache manifests, endpoint information, tool information, and schemas by endpoint bare JID, exact API version, &xep0300; hash, authenticated principal, and a trusted local visibility-scope identifier. Cache entries MUST NOT cross principals or authorization scopes unless policy proves the returned view is identical. Because manifests are immutable and all-or-nothing, a matching version and hash identifies the same registered content. A future extension can define push notification for active-version changes; the base protocol requires clients to rediscover.

The standards profile uses RFC 8785 canonicalization and &xep0300; hashes. The deployed private profile used a simpler key-sorting algorithm; its values are comparable only within that profile. A client that cannot reproduce the declared canonicalization MAY treat a hash as an opaque cache validator but MUST still validate received JSON and schema content.

The implementation on which this draft is based has been integration-tested using two independently configured Openfire server instances connected by XMPP server-to-server federation, with the gateway hosted on one domain and reached from the other. The tests exercise deny-by-default federation and independently configured visibility and invocation grants. This is evidence from one gateway implementation in an Openfire-based multi-domain deployment, not a claim of interoperability between two independent implementations of this protocol.

The deployed runtime enforces the gateway/model boundary described above. Model-facing discovery returns opaque agent: handles rather than XMPP endpoint identifiers. Inbound agent tasks are formatted as transport-neutral tool, argument, and event data; wire JIDs, component domains, tenant and workspace routing, endpoint addresses, and stanza correlation remain host-owned. Action tasks run in task-scoped sessions and settle only through explicit task actions; provider final prose cannot escape through a human channel.

The deployed application defines a local tool named conversation.respond. This is an application convention, not a well-known name or interoperable feature defined by this specification. It uses the durable task transport, while the runtime converts the target's non-empty prose into the application's declared structured result. Implementations using that name remain responsible for publishing and versioning their own schemas and result-size limits.

The deployed caller API additionally supports a local delivery="requester" policy for that application tool. It resolves the active XMPP requester route from session state, persists it with the task, sends the completed response through the channel adapter with the target endpoint JID as sender identity, records delivery state, and returns that outcome to the calling agent. This policy has no representation or negotiation in the protocol defined by this document and is therefore not part of conformance.

The deployed direct-delivery path currently sends an ordinary chat message without a standardized indication that another agent initiated the interaction. It also has at-least-once semantics: a crash after network send but before committing the delivery marker can expose the same response to the human twice. A future interoperable delivery profile needs explicit provenance, recipient-consent and blocking behavior, and end-to-end acknowledgement or deduplication.

The version 0 implementation replaces the predecessor wire profile rather than operating as a dual stack. It uses the fixed 'urn:xmpp:*:0' namespaces, immutable manifests with explicit activation, standard JSON media types, RFC 8785 canonicalization, &xep0300; hashes, version-pinned tool nodes and schemas, receiver-generated task IDs, revisioned lifecycle events, complete recovery IQs, and authorization derived from the authenticated XMPP sender and trusted local policy. Directory, search, and tool paging use &xep0059;. The normative blocks in this document are intended to be the source for committed manifest, event, and XML Schema artifacts. Implementations SHOULD normalize and compare generated artifacts byte-for-byte and check protocol namespace constants separately.

The following work remains outside the implemented conformance surface:

• permission-bearing and approval-required tools fail closed unless trusted local policy establishes the required authorization or approval;
• portable approval and delegation grants, registration expiry, and tool-list change notification remain future extensions; and
• the Openfire suites provide integration evidence only; no independent implementation interoperability result is claimed.

The predecessor implementation and its private identifiers are not a supported compatibility mode and are not part of conformance to this specification.

The XMPP Registrar shall register the XML protocol namespaces 'urn:xmpp:agent-api:0' and 'urn:xmpp:agent-task:0'. FORM_TYPE values, feature vars, and discovery nodes are not XML protocol namespaces.

The XMPP Registrar shall add the following types to the automation category:

The XMPP Registrar shall register the fixed feature vars urn:xmpp:agent-directory:0, urn:xmpp:agent-endpoint:0, urn:xmpp:agent-tool:0, urn:xmpp:agent-api:0#manifest, urn:xmpp:agent-api:0#schema, urn:xmpp:agent-api:0#self-register, urn:xmpp:agent-api:0#admin, urn:xmpp:agent-task:0, urn:xmpp:agent-task:0#progress, urn:xmpp:agent-task:0#cancel, and urn:xmpp:agent-task:0#input, with the semantics defined by this document.

The XMPP Registrar shall register the following field standardizations in accordance with &xep0068;:

The XMPP Registrar shall register fixed node urn:xmpp:agent-directory:0 and derived-node bases urn:xmpp:agent-tools:0 and urn:xmpp:agent-tool:0. Derived tool collection nodes and tool nodes follow the exact grammar in Protocol Namespaces and Identifiers; they are discovery node identifiers, not XML namespaces.

This document creates no failure-code registry. It reserves the unqualified codes listed in Error Handling. Extensions use namespace-qualified codes, avoiding a central collision registry.