ONVIF Agentic Spec 26.12 ONVIF™ www.onvif.org December, 2026 2026 ONVIF™ All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. 26.12 Dec-2026 Ottavio Campana Initial release of Agentic Service Specification. This specification defines a layered protocol stack that enables any ONVIF-compliant client to discover, configure, and consume data from any AI-enabled ONVIF-compliant device. The stack combines four open technologies: ONVIF, for standardised device control; MCP (Model Context Protocol), for standardised AI tool invocation and metadata streaming; LinkML, for defining, validating, and sharing structured metadata schemas. JSON-LD, for serializing semantically rich metadata payloads. After introducing the stack, this specification is organised as follows: Scope: Defines the applicability and boundaries of this specification. Protocol Architecture: Defines the overall layered architecture, the two communication planes, and the shared identity authority. Concepts introduced here are used throughout subsequent chapters. Building Blocks: Introduces each constituent technology and clarifies its role within the architecture defined above. Service Discovery and Data Exchange: Defines the interaction sequences — client-initiated requests for connection establishment, schema retrieval, and skill invocation, as well as server-pushed metadata event delivery. Authentication and Authorization: Specifies the JWT-based security model, ONVIF role mapping, and TLS requirements.

Traditional physical-security systems are built around devices that expose predefined services, events, metadata, and configuration interfaces. ONVIF clients, including video management systems, use these interfaces to configure devices and ingest information into a site-centric operational view. AI-enabled and agentic systems introduce additional consumers and interaction patterns. These systems need to discover available capabilities, retrieve contextual information, interpret semantically described data, and invoke permitted actions across devices, analytics services, and other site systems. The ONVIF Agentic Service connects these environments. It complements existing ONVIF services by providing common information models and discovery mechanisms that can be used by both traditional clients and AI-native applications. Initial use cases include a VMS ingesting standardised site-centric metadata and an authorised AI application using MCP to discover and access device configuration capabilities.

Without standardisation, AI integrations depend on vendor-specific data models, capability descriptions, and agent tools. This increases integration cost and limits portability across manufacturers and system components. This specification defines the interoperable boundary between information producers and consumers. It enables consistent exchange of semantic metadata, provenance, confidence, spatial and temporal context, and capability descriptions, while reusing existing ONVIF services and security mechanisms where applicable. The objective is not to prescribe a complete agentic architecture or replace established VMS workflows. The objective is to allow traditional physical-security systems and AI-native systems to share trusted information and expose controlled functionality through standardised contracts.

IETF RFC 6750 OAuth 2.0 Bearer Token Usage <http://www.ietf.org/rfc/rfc6750.txt> IETF RFC 7517 JSON Web Key (JWK) <http://www.ietf.org/rfc/rfc7517.txt> IETF RFC 7519 JSON Web Token (JWT) <http://www.ietf.org/rfc/rfc7519.txt> IETF RFC 8414 OAuth 2.0 Authorization Server Metadata <http://www.ietf.org/rfc/rfc8414.txt> IETF RFC 8446 TLS 1.3 <http://www.ietf.org/rfc/rfc8446.txt> JSON-LD 1.1 <https://www.w3.org/TR/json-ld11/> LinkML Specification <https://linkml.io/linkml/> Model Context Protocol, 2025-11-25 <https://modelcontextprotocol.io/specification/2025-11-25> Model Context Protocol, 2026-07-28 <https://modelcontextprotocol.io/specification/2026-07-28> ONVIF Core Specification <https://www.onvif.org/specs/core/ONVIF-Core-Specification.pdf> ONVIF Schema <https://www.onvif.org/onvif/ver10/schema/onvif.xsd> ONVIF Security Baseline Specification <https://www.onvif.org/specs/srv/security/ONVIF-SecurityBaseline-Spec.pdf> ONVIF Security Service Specification <https://www.onvif.org/specs/core/ONVIF-Security-Specification.pdf> ONVIF WSDL-to-MCP Tool Converter (PR #2) <https://github.com/onvif/specs/pull/2> W3C JSON Schema Draft-07 <https://json-schema.org/draft-07/schema> W3C RDF Dataset Canonicalization <https://www.w3.org/TR/rdf-canon/> W3C Semantic Sensor Network Ontology — Sensor, Observation, Sample, and Actuator (SOSA) <https://www.w3.org/TR/vocab-ssn/> W3C Verifiable Credential Data Integrity 1.0 <https://www.w3.org/TR/vc-data-integrity/>

ONVIF Device An ONVIF-compliant device that exposes one or more MCP Server endpoints, publishing its capabilities as Skills (MCP Tools), schema announcements, and metadata events. Capabilities may include agentic analytics models, bridging of existing ONVIF services, or other device functions. Control Plane The MCP channel over which the ONVIF Client sends commands to an Agentic Service (configure regions, adjust sensitivity, etc.). Event Plane The channel over which an ONVIF Device streams LinkML-structured detection events to the ONVIF Client. LinkML Schema A YAML document that defines the data structures and enumerations used by an ONVIF Device for both event payloads and skill input parameters. MCP (Model Context Protocol) An open protocol for agentic tool invocation and data resource access. MCP Host The application (e.g., VMS) that creates and manages one or more MCP Clients. MCP Client The protocol-level peer that connects to an MCP Server on behalf of the MCP Host to discover and invoke tools. MCP Server An ONVIF Device endpoint that exposes Tools, Resources, and optionally Prompts via the MCP protocol. Metadata Event A JSON-LD payload, conforming to a registered LinkML schema, that an ONVIF Device emits on the Event Plane each time a detection occurs. OIDC Server / Authorization Server An OpenID Connect server that issues signed ES256 JWTs; acts as the trust anchor for the whole stack. Schema Registry A component within the ONVIF Client that stores parsed LinkML schema bundles and validates incoming metadata events against them. Skill An MCP Tool exposed by an ONVIF Device, representing a single callable operation (e.g. set detection region, adjust sensitivity). Note: in this specification, "Skill" is an ONVIF term mapped to the MCP Tool primitive. It is distinct from the experimental MCP Skills extension (skills/list, skills/get) which is under development and not yet part of the MCP core specification. ONVIF Client (Video Management System) An ONVIF client that also acts as an MCP Host, managing cameras and consuming agentic analytics events. WSDL-MCP Bridge A component that translates ONVIF SOAP/WSDL operations into MCP Tool definitions, making legacy cameras accessible to agents without SOAP knowledge.

ES256 ECDSA with SHA-256 and the secp256r1 (P-256) curve HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure JSON JavaScript Object Notation JSON-LD JSON-based Serialization for Linked Data JWT JSON Web Token JWK JSON Web Key JWKS JSON Web Key Set LinkML Linked data Modeling Language MCP Model Context Protocol mDNS Multicast DNS OIDC OpenID Connect RBAC Role-Based Access Control RTSP Real Time Streaming Protocol SDK Software Development Kit TLS Transport Layer Security URI Uniform Resource Identifier UUID Universally Unique Identifier ONVIF Client Video Management System WSDL Web Services Description Language XSD XML Schema Definition YAML Yet Another Markup Language

Agentic configurations are handled through the Agentic Service. Agentic configurations are used to configure and control the intelligent functions as defined in this specification. The device provides Agentic configuration through the Agentic Service. YAML for this service is specified in http://www.onvif.org/yaml/agentic.yaml. Prefix Namespace URI env http://www.w3.org/2003/05/soap-envelope ter http://www.onvif.org/ver10/error xs http://www.w3.org/2001/XMLSchema tt http://www.onvif.org/ver10/schema tag http://www.onvif.org/yaml/agentic tns1 http://www.onvif.org/ver10/topics

The ONVIF Agentic protocol architecture is structured around the standard ONVIF roles of an ONVIF Client and an ONVIF Device, with an OIDC Authorization Server acting as the shared trust anchor that issues the tokens consumed by both. The figure below shows the top-level relationships between these three components and the two communication planes. The architecture is realised by four open technologies — MCP (Model Context Protocol) for tool invocation and event delivery, LinkML for schema definition, JSON-LD for metadata serialisation, and OAuth 2.1 / JWT for security. Their precise roles are detailed in the Building Blocks chapter (). The client and device expose matching functional layers that communicate as peers across the two planes.

The OIDC Authorization Server is the trust anchor for the entire stack. It issues signed ES256 JWTs to the ONVIF Client via the OAuth2 Client Credentials grant, and exposes a JWKS endpoint that the ONVIF Device uses to validate every token it receives. The ONVIF Client acts as the MCP Host: it creates one or more MCP Clients that connect to ONVIF Devices, invoke skills, and subscribe to metadata events. It also maintains the LinkML Schema Registry and validates every incoming event before it is passed to business logic. The ONVIF Device provides an MCP Server endpoint. Through this endpoint, it exposes skills in the form of MCP Tools and publishes JSON-LD metadata events. Moreover, it announces the LinkML schema via MCP Resources. All communication between the ONVIF Client and the ONVIF Device is bearer-token authenticated. The Control Plane (A) carries MCP tools/call requests from the ONVIF Client to the ONVIF Device. The Event Plane (B) carries JSON-LD metadata events from the ONVIF Device to the ONVIF Client, delivered as MCP notifications/message frames.

The ONVIF Agentic protocol architecture uses two independent communication planes, both protected by TLS and bearer tokens issued by the OIDC Authorization Server: The Control Plane carries client-initiated requests — synchronous JSON-RPC calls that discover capabilities, invoke skills, and retrieve resources. The Event Plane carries server-pushed metadata events — asynchronous notification frames that the ONVIF Device emits as observations are produced, without client polling. The two planes are independent: a request on the Control Plane never produces a metadata event as its direct response, and an event on the Event Plane is never a reply to a specific request. The detailed behavior of each plane is defined in the following sections.

The Control Plane is the command path used by the ONVIF Client to discover and invoke Skills exposed by an ONVIF Device. It is request/response oriented and carries only client-initiated MCP operations. Direction Client-initiated; ONVIF Client sends requests, ONVIF Device returns responses. Purpose Discover capabilities, list skills, and invoke device actions. Protocol MCP 2026-07-28 over Streamable HTTP. Message pattern JSON-RPC 2.0 request/response. Transport HTTP POST to /mcp over HTTP/1.1 or HTTP/2. Operations server/discover, tools/list, tools/call, resources/list, and resources/read. Security TLS 1.3 with an Authorization: Bearer ES256 JWT on every request. Each request is self-contained and shall be validated independently by the ONVIF Device before execution. A Control Plane response shall report either the requested result or an MCP error indicating why the operation could not be completed.

The Metadata Event Plane is the event path used by the ONVIF Device to publish agentic analytics results to the ONVIF Client. It is server-initiated, asynchronous, and optimized for continuous delivery of structured metadata events. Direction Server-initiated; ONVIF Device pushes events to the ONVIF Client without polling. Purpose Deliver detection and analytics events as they occur. Protocol MCP 2026-07-28 Streamable HTTP. Message pattern MCP notifications/message frames. Transport Streamable HTTP to /mcp endpoint, as defined by MCP 2026-07-28. Payload JSON-LD events conforming to the registered LinkML schema. Security TLS 1.3; the channel is established using an Authorization: Bearer ES256 JWT. The Event Plane shall preserve event ordering per stream, and each event shall remain self-describing through its JSON-LD @context and @type annotations.

The ONVIF Agentic protocol stack requires an OAuth 2.1 Authorization Server, as specified in the ONVIF Security Service Specification. This server acts as the trust anchor for the complete stack: it authenticates clients, issues bearer access tokens, and exposes authorization server metadata (token endpoint URI, supported signing algorithms, and JWKS endpoint) needed by ONVIF Devices to validate tokens before processing MCP requests. In practice, the Authorization Server provides centralized identity and access control for both planes. It ensures that only authorized ONVIF Clients can invoke Skills on the Control Plane and receive protected metadata on the Event Plane, according to the roles and claims contained in the issued token.

This chapter describes each building block technology used in the ONVIF Agentic protocol architecture. For each one, the sections below explain its purpose, its protocol-level details, and how it fulfils its role within the Control Plane, Event Plane, and data model layer defined in the preceding Protocol Architecture chapter.

The Model Context Protocol (MCP) is an open, JSON-RPC 2.0 based protocol designed to connect AI language models and agents to external tools and data sources. In the ONVIF AI stack, MCP serves as the standardised interface layer between the ONVIF Client (acting as an MCP Host) and each ONVIF Device (acting as an MCP Server). Adopting MCP means that any ONVIF Client can invoke any compliant ONVIF Device without requiring a vendor-specific driver.

MCP defines three categories of server-side primitive that a host may discover and use: Tools are callable operations with a named identifier, a human-readable description, and an inputSchema (JSON Schema) that fully describes the expected arguments. In the ONVIF agentic stack, Tools are called Skills and represent ONVIF Device capabilities such as configuring a detection region or querying service status. The ONVIF Client invokes a Skill by sending a tools/call JSON-RPC request over the Control Plane. Resources are read-only data objects accessible via resources/list and resources/read requests. In this specification, Resources carry the LinkML schema bundles that describe the event payloads and skill input parameters of the ONVIF Device. Each schema resource carries the MIME type application/linkml+yaml. Prompts are optional server-defined interaction templates. This specification does not mandate Prompt support; ONVIF Devices MAY expose Prompts for human-in-the-loop workflows. In addition to these primitives, MCP defines the server/discover lifecycle method. This is a protocol-level operation — not a primitive — that returns the server's identity, supported protocol versions, and capability flags indicating which primitives (tools, resources, prompts) are available. See for details.

This specification normatively uses the Streamable HTTP transport. The ONVIF Client sends JSON-RPC requests as HTTP POST to the ONVIF Device's /mcp endpoint. For server-initiated messages (schema update notifications, metadata events) the ONVIF Client also opens a Streamable HTTP channel on /mcp; the ONVIF Device sends server-initiated messages over that channel as defined by the Streamable HTTP transport in MCP 2026-07-28. An ONVIF Device conforming to this specification shall support the Streamable HTTP transport.

This specification normatively requires MCP 2026-07-28. Implementations conforming to this specification shall not use the session-era MCP 2025-11-25 protocol. MCP 2026-07-28 is a fully stateless protocol. There is no session establishment handshake and no Mcp-Session-Id header. Every HTTP request is self-contained: the ONVIF Client includes the MCP-Protocol-Version: 2026-07-28 request header on each call, together with the Authorization: Bearer JWT header. The ONVIF Device shall reject requests that carry a protocol version other than 2026-07-28 with HTTP 400. Service discovery uses the server/discover JSON-RPC method, which replaces the initialize / initialized handshake of earlier versions. The response carries the server's capability flags (tools, resources, prompts) and its human-readable identity. As required by MCP 2026-07-28, the ONVIF Device shall implement server/discover. The ONVIF Client may call server/discover before issuing other requests to learn supported versions and capabilities, but it is not required to call it first and may invoke any operation directly and handle UnsupportedProtocolVersionError. The stateless model is the correct choice for the ONVIF AI use case: ONVIF Devices are deployed as horizontally-scalable endpoints behind load balancers, and pinning a ONVIF Client to a specific server instance via a session identifier would prevent transparent failover and scaling. With MCP 2026-07-28, every request can be routed to any instance of the ONVIF Device without loss of state.

LinkML (Linked data Modeling Language) is an open schema definition language that describes data structures in YAML. In the ONVIF agentic stack, LinkML is the normative language for defining both the structure of metadata events (Event Plane payloads) and the argument shapes of Skills (Control Plane inputs). LinkML defines the schema; JSON-LD (see ) is the runtime wire format that carries instances of that schema.

A LinkML schema document is a YAML file with the following top-level keys: id: a globally unique URI that serves as the schema identifier. This URI is reused as the JSON-LD @context value in every event payload emitted by the ONVIF Device, making the schema self-locating. imports: a list of schema URIs from which common types are inherited. ONVIF maintains a shared type library (ver10_schema_common_linkml) that defines reusable structures such as bounding boxes, polygon regions, timestamps, and confidence scores. ONVIF Devices SHOULD import this library rather than redefining common types. classes: named data structures with typed attributes, optional range constraints (minimum_value, maximum_value), and documentation strings. The root event class shall extend BaseAnalyticsEvent from the ONVIF common type library. enums: closed value sets used for categorical fields such as SeverityLevel (low, medium, high, critical) and event type discriminators.

The same LinkML model serves two distinct purposes within the stack: On the Event Plane, the compiled JSON Schema derived from the LinkML model is used by the ONVIF Client LinkML Validator to check every incoming metadata event for structural correctness — required fields, numeric ranges, and valid enum values. On the Control Plane, the inputSchema field of each MCP Tool (Skill) definition is also derived from the same LinkML model. This guarantees that the coordinate spaces, unit definitions, and vocabulary used to configure the ONVIF Device (e.g., a detection region polygon) are identical to those used to report events, eliminating a class of integration errors that arise when configuration and reporting use incompatible data models.

The LinkML toolchain provides a generator that produces a JSON Schema document from a LinkML YAML source. This compiled JSON Schema is used in two places: First, it is embedded in the inputSchema field of each MCP Tool definition returned by tools/list. The ONVIF Client can validate skill arguments against this schema before sending a tools/call request, providing early client-side error detection. Second, a copy of the compiled schema is stored in the ONVIF Client Schema Registry after schema discovery. The registry uses the compiled schema to validate every incoming metadata event on the Event Plane before the ONVIF Client processes it. ONVIF Devices shall pre-compile their LinkML schemas at build time and include the compiled JSON Schema in Tool definitions. The source YAML shall also be exposed as a schema Resource so that the ONVIF Client can re-compile or audit the schema independently.

The ONVIF AI Working Group maintains a shared LinkML type library (ver10_schema_common_linkml) that defines base classes and enumerations used across all ONVIF Devices. Key types include: BaseAnalyticsEvent: the mandatory root class for all metadata events, defining the required fields event_id (UUID), timestamp (ISO 8601 UTC), source_uri, confidence (float, 0.0–1.0), and severity (SeverityLevel enum). BoundingBox and PolygonRegion: normalised coordinate structures shared between event payloads and skill input schemas to ensure consistent spatial referencing. ONVIF shall not redefine any type declared in the common type library. This ensures that an ONVIF Client that has already loaded the common library does not need to re-fetch it for each new ONVIF Device it connects to.

JSON-LD (JSON-based Linked Data) is the serialisation format used for all metadata events transmitted on the Event Plane. Where LinkML defines the schema at design time, JSON-LD carries instances of that schema at runtime. The two technologies are complementary: LinkML declares what data looks like; JSON-LD is the payload that conforms to that declaration.

Every metadata event emitted by an ONVIF Device shall include two mandatory JSON-LD keywords: @context: a URI that points to the canonical LinkML schema for this event type. The value shall equal the id field of the LinkML schema from which the event class is derived. This URI is the primary key used by the ONVIF Client Schema Registry to look up the compiled JSON Schema for validation. @type: the class name of the event as declared in the LinkML schema (e.g., FireDetectionEvent, PersonCrossingEvent). This field allows the ONVIF Client to route the event to the appropriate handler without inspecting the full payload. Together, @context and @type make each event self-describing: an ONVIF Client that receives an event with an unfamiliar @context URI knows exactly where to fetch the schema needed to understand and validate the event.

The self-describing nature of JSON-LD enables a dynamic schema registration workflow. When the ONVIF Client Schema Registry receives a metadata event whose @context URI does not match any registered schema, it shall: 1. Suspend validation of the triggering event. 2. Fetch the LinkML schema YAML from the URI identified by @context, or issue an MCP resources/read request to the originating ONVIF Device to retrieve the latest schema bundle. 3. Register the schema bundle in the local registry. 4. Re-validate and process the suspended event against the newly registered schema. This mechanism allows an ONVIF Device to introduce a new event type (e.g., a firmware update that adds a VehicleTypeDetectionEvent) without requiring a pre-coordinated ONVIF Client update. The ONVIF Client self-heals its schema knowledge at runtime.

Although full JSON-LD processing (graph expansion, context dereferencing, SPARQL querying) is not required by this specification, the use of JSON-LD framing ensures forward compatibility with semantic web tooling. A conformant ONVIF Client shall treat @context and @type as opaque identifiers for schema lookup and event routing. An ONVIF Client MAY additionally perform full JSON-LD processing for downstream applications such as knowledge graph ingestion or cross-vendor event correlation.

An ONVIF Device that supports the Agentic Service shall advertise the MCP service endpoint URL through the ONVIF Core service discovery mechanism. In the ONVIF Core GetServices response, the corresponding Agentic Service entry (tds:GetServiceResponse) shall contain the service address used by the ONVIF Client for MCP requests.

An ONVIF Device implementing the Agentic Service shall implement the server/discover JSON-RPC method as required by MCP 2026-07-28. The ONVIF Client MAY call server/discover as its first request on a new connection to obtain the device's protocol version, server identity, and capability flags. Alternatively, the ONVIF Client MAY call any other operation directly and handle UnsupportedProtocolVersionError (JSON-RPC error code -32022) if the protocol version is not supported. In that case the ONVIF Device shall include a supported list in the error response and the ONVIF Client shall retry using one of the listed versions. The server/discover response shall contain: protocolVersions — the list of MCP protocol versions supported by the device; identity — the server name and version; capabilities — the declared capability flags (tools, resources, prompts). The ONVIF Client shall use the returned capabilities flags to determine which subsequent operations are available before invoking them. The ONVIF Client shall open the Streamable HTTP channel as defined by MCP 2026-07-28 before it expects to receive notifications/message frames from the ONVIF Device. This channel shall remain open for the duration of the session. See for wire format examples.

The ONVIF Agentic Service exposes its LinkML metadata schema as one or more MCP Resources. An ONVIF Client shall retrieve the schema bundle before processing any notifications/message frame that carries metadata events. The schema retrieval procedure is: The ONVIF Client calls resources/list. The response includes one or more resources with mimeType: application/linkml+yaml identifying the schema files. The ONVIF Client calls resources/read for each schema resource URI returned in step 1, in the order listed. A schema bundle may span multiple resources when imported type definitions are split across files. The ONVIF Client registers the complete schema bundle in its validator. An ONVIF Device shall advertise at least one resource with mimeType: application/linkml+yaml describing the structure of every event type it emits. The schema shall be self-contained — it shall not require the ONVIF Client to resolve external URIs to validate event payloads. See and for wire format examples.

Capability discovery shall be performed through the MCP resources/read operation using the reserved URI capabilities://www.onvif.org/ver10/agentic. An ONVIF Device implementing the Agentic Service shall expose capabilities://www.onvif.org/ver10/agentic and shall return the Agentic Service capabilities document when that URI is requested via resources/read. The capabilities document describes the features supported by the device, such as supported analytics types, event classes, and optional extensions. Exposing capabilities for other ONVIF services is optional. When provided, the same URI pattern shall be used, replacing ai with the service name: capabilities://onvif/<service-name>. See and for wire format examples.

The ONVIF Device exposes its Skills — callable operations — as MCP Tools. The ONVIF Client discovers the available Skills by calling tools/list. Each Tool entry in the tools/list response shall contain: name — the Skill identifier used in subsequent tools/call requests. description — a human-readable description of the Skill's function. inputSchema — a JSON Schema object that fully describes the expected arguments. This JSON Schema is compiled from the LinkML model retrieved in and shall use the same coordinate spaces, unit definitions, and vocabulary as the event payloads delivered over the Event Plane. The ONVIF Client shall validate Skill arguments against the inputSchema before sending a tools/call request. After completing tool discovery the ONVIF Client has obtained, without any out-of-band documentation: the complete catalogue of Skills supported by this device instance; the argument types, valid ranges, and required/optional fields for each Skill; and human-readable descriptions suitable for display or automated orchestration. See for a wire format example.

ONVIF Agentic Skills are invoked via the MCP tools/call JSON-RPC method over the Control Plane. The ONVIF Device shall validate the arguments object against the inputSchema of the named Skill before executing it. If validation fails, the ONVIF Device shall return a structured error response without executing the Skill. This specification defines three mandatory Skills that every ONVIF agentic device shall implement regardless of device type (camera, NVR, access control, or other). Additional device-type-specific Skills may be defined in ONVIF profiles or vendor extensions.

The get_status Skill returns the current operational status of the agentic analytics engine. It takes no arguments. The ONVIF Device shall always respond successfully to this Skill unless the device is unreachable. The response structuredContent shall include: state — one of running, stopped, degraded, or error. activeAnalytics — list of analytics type identifiers currently active on the device. engineVersion — version string of the agentic engine firmware. See for a wire format example.

The list_analytics Skill returns the set of analytics types supported by this device instance, together with their current enabled/disabled state. It takes no arguments. This is the authoritative machine-readable catalogue of what this device can do; the ONVIF Client shall call list_analytics before calling configure_analytics. Each entry in the response structuredContent.analytics array shall include: type — analytics type identifier drawn from the ONVIF agentic analytics type vocabulary (for example fire_detection, face_recognition, license_plate_recognition, tailgating_detection). enabled — boolean indicating whether this analytics type is currently active. configSchema — URI of the LinkML class in the schema bundle (retrieved in ) that defines the structure of the config argument accepted by configure_analytics for this type. An ONVIF Device that executes no analytics locally (for example a pure RFID access control reader) shall return an empty analytics array. See for a wire format example.

The configure_analytics Skill applies a configuration to a named analytics type. It is a generic wrapper: the structure of the config argument is defined by the LinkML schema class identified by the configSchema URI returned by list_analytics for that type. The ONVIF Client shall validate config against the compiled JSON Schema (the inputSchema of the Skill) before sending the request. The configure_analytics Skill arguments are: analytics_type (string, required) — the analytics type identifier, as returned by list_analytics. config (object, required) — the configuration object whose structure is specific to analytics_type and defined by the corresponding LinkML schema class. On success the ONVIF Device shall confirm the applied configuration. On failure it shall return a structured error identifying the failing field and the violated constraint. See for a wire format example.

The ONVIF Device delivers metadata events as MCP notifications/message frames over the Streamable HTTP channel established during session initialization (). Event delivery is push-only: the ONVIF Device sends frames autonomously as observations are produced; the ONVIF Client does not poll. The ONVIF Client shall open the Streamable HTTP channel before invoking configure_analytics to enable an analytics type. Each notifications/message frame shall carry exactly one metadata event. Batch delivery of multiple events in a single frame is not permitted. When the Streamable HTTP channel is closed, the ONVIF Device shall retain pending metadata events in a FIFO buffer until the buffer capacity is exhausted. When the buffer is full, the oldest event shall be discarded to make room for the newest. If the ONVIF Client reopens the Streamable HTTP channel before the buffer is exhausted, the ONVIF Device shall deliver all buffered events in FIFO order before resuming live delivery. If the buffer is exhausted before the client reconnects, delivery continuity is lost and the ONVIF Client shall treat the gap as a potential loss of events. The buffer capacity of the device is advertised in the capabilities://www.onvif.org/ver10/agentic document via the eventBufferCapacity field (integer, number of events). A value of 0 indicates that the device does not support buffering; events produced while the channel is closed are discarded immediately.

Each notifications/message frame carries a JSON-LD document in its params.message field. Every event document shall include: @context — a URI pointing to the canonical LinkML schema for this event type. The ONVIF Client shall use this URI for schema lookup and for dynamic schema re-registration (see ). @type — the event class name as defined in the registered schema (for example FireDetectionEvent). The ONVIF Client shall use this field for event routing. See for a complete wire format example.

The @context URI in each event is a live pointer to the schema that defines it. If the ONVIF Client receives a notifications/message frame whose @context URI is not already registered in its schema bundle, it shall: Suspend validation of that event without discarding it. Call resources/read with the @context URI to fetch the LinkML schema YAML from the ONVIF Device. Register the retrieved schema in its validator. Resume validation of the suspended event and all subsequent events of that type. This mechanism allows the ONVIF Device to introduce new event types — for example after a firmware update — without requiring the ONVIF Client to have prior knowledge of the new schema. The ONVIF Device shall ensure that the @context URI is always resolvable via resources/read for as long as the device emits events of that type. See for a wire format example.

An ONVIF Agentic Service is self-describing: an ONVIF Client that has completed the sequence defined in Sections 7.3 through 7.5 is fully operational without any out-of-band documentation, SDK, or static configuration. The table below summarises the knowledge accumulated at each step. Section Operation Knowledge acquired server/discover Device identity, supported protocol versions, declared capability flags (resources, tools). resources/list + resources/read Complete LinkML schema bundle; JSON Schema for event validation and skill argument validation. 7.3.3 resources/read (capabilities://www.onvif.org/ver10/agentic) Device feature set, supported analytics types, eventBufferCapacity. tools/list Skill catalogue: name, human-readable description, and inputSchema for each skill. list_analytics Which analytics types are currently enabled; configSchema URI per analytics type. 7.5 Streamable HTTP channel Live metadata events; @type for routing; @context for dynamic schema re-registration. An ONVIF Device implementing this specification shall ensure that an ONVIF Client completing the above sequence is able to: validate all incoming event payloads against the registered schema; invoke any available Skill with correctly structured arguments; and interpret the full feature set of the device — all without consulting any resource external to the ONVIF Device.

The ONVIF Agentic Services delegates all authentication and token management to the mechanisms defined in the ONVIF Core Specification and the ONVIF Security Service Specification. Those documents govern JWT token format and required claims (iss, aud, exp, nbf, roles), the mandatory ES256 signing algorithm, token validation rules, the OAuth2 Client Credentials flow, authorization server configuration, and TLS transport requirements. Implementations not comply with the ONVIF Core Specification and the ONVIF Security Service Specification. This chapter defines only the ONVIF Agentic-specific normative mapping of MCP operations to ONVIF access classes.

The ONVIF Security Service Specification defines three predefined JWT role values carried in the roles claim of every access token: onvif:User, onvif:Operator, and onvif:Administrator. These correspond to the ONVIF user levels and cover the majority of deployments. For environments that require finer-grained access control, the Security Service Specification defines a full user role management model that allows custom roles to be assigned to individual users; refer to the ONVIF Security Service Specification for details. The onvif: namespace prefix is reserved; custom roles shall not use it. Anonymous access to any MCP endpoint is not permitted. Every request to the ONVIF Device shall carry a valid Authorization: Bearer JWT. The ONVIF Device maps the access class required by each MCP operation against the roles claim in the presented token and rejects requests that do not satisfy the minimum role requirement with HTTP 403. A token carrying onvif:Administrator satisfies all lower access class requirements; a token carrying onvif:Operator satisfies READ_SYSTEM in addition to ACTUATE. The table below is normative. Each Skill exposed via tools/list shall include an annotation declaring its access class. The ONVIF Device shall enforce this mapping at runtime. MCP Operation Access Class Minimum JWT Role server/discover READ_SYSTEM onvif:User resources/list READ_SYSTEM onvif:User resources/read READ_SYSTEM onvif:User tools/list READ_SYSTEM onvif:User tools/call — read / query Skills (e.g. get_status) READ_SYSTEM onvif:User tools/call — actuate Skills (e.g. set_detection_region, set_sensitivity) ACTUATE onvif:Operator tools/call — administrative Skills (e.g. model management, device configuration) WRITE_SYSTEM onvif:Administrator

This chapter defines the data model for structured metadata produced and consumed by ONVIF AI-enabled devices. All metadata payloads are instances of, or derived from, the abstract classes defined here. The normative schema is expressed in LinkML; JSON-LD is the wire format (see ). The following figure shows the class hierarchy structure from which specialised metadata classes are derived. The remainder of this chapter defines and details the classes shown in the figure.

InformationItem is the abstract base container for any single unit of information exchanged in the metadata model. It is intentionally generic so that different semantic categories can reuse the same trust and context fields. In this specification, InformationItem is specialised by Observation and Assertion. Each InformationItem carries the following fields: a confidence value expressing the confidence level of the contained information; a generation timestamp; a provenance field describing the origin or producer of the information; and an optional signature field that can be used to guarantee integrity, authenticity, and non-repudiation of the content. The signature field is optional because equivalent protection can be provided at envelope level, as specified in .

InformationEnvelope is an optional container used to group one or more InformationItem instances and apply a single signature to the grouped content. This enables a producer to protect multiple information elements with one cryptographic operation instead of signing each item independently. The envelope-level signature is optional and is intended for deployments where cryptographic acceleration resources on the device are constrained. In such environments, signing one envelope can reduce signing workload while still providing integrity, authenticity, and non-repudiation coverage for all enclosed InformationItem instances.

Observation is a concrete InformationItem representing a measurement generated internally by an ONVIF Device. It captures directly observed or computed device outputs as information items that can be consumed by downstream systems.

Assertion is a statement supported by one or more InformationItem elements. Therefore, a statement can be supported directly by Observation instances, by other Assertion instances, or by a combination of both.

To achieve robust and reliable parsers, the following sanity checks are required for assertions: Supporting InformationItem elements shall be resolvable, i.e., they shall have been received previously. The assertion timestamp shall be more recent than the timestamps of all supporting elements. The resulting dependency graph shall be directed and acyclic. By traversing the directed acyclic graph, each assertion shall be traceable back to one or more initial observations.

Signature is an abstract class nested within InformationItem that describes a cryptographic attestation bound to the item content. Different deployments can require different signature formats and trust frameworks; for this reason, the class is abstract and shall be specialised by concrete signature profiles. The presence of a Signature object at item level is optional. When omitted, integrity, authenticity, and non-repudiation claims can still be provided by an enclosing InformationEnvelope as defined in .

JsonLDSignature is the first concrete subclass of Signature. It attests the integrity of an InformationItem by means of a JSON-LD Data Integrity proof , as defined in W3C Verifiable Credential Data Integrity 1.0. The ECC signature algorithm and key parameters shall conform to the ONVIF Security Baseline.

The ONVIF Device shall compute the proof using the Add Proof algorithm defined in W3C Verifiable Credential Data Integrity 1.0 with W3C RDF Dataset Canonicalization 1.0 (RDFC-1.0) as the canonicalization algorithm. The digest and signing algorithms shall be those mandated by the current version of the ONVIF Security Baseline.

JsonLDSignature carries the following fields, aligned with the DataIntegrityProof structure defined in W3C Verifiable Credential Data Integrity 1.0: type (mandatory) — fixed string "DataIntegrityProof". cryptosuite (mandatory) — identifies the cryptosuite used. The value shall correspond to the algorithm profile mandated by the current version of the ONVIF Security Baseline. It is included in the proof configuration and therefore covered by the signature. created (mandatory) — ISO 8601 UTC datetime at which the proof was created. verificationMethod (mandatory) — URI of the public key or verification method that can be used to verify the proof. proofPurpose (mandatory) — fixed string "assertionMethod". proofValue (mandatory) — the encoded digital signature over hashData as defined in the signing procedure above.

Location is an abstract class nested within InformationItem that represents the spatial origin of the information item. It is optional; when present it shall be an instance of a concrete subclass.

Timing is an abstract class nested within InformationItem that provides an authoritative time reference for the information item, independent of the device system clock. It is optional; when present it shall be an instance of a concrete subclass.

ONVIF follows the convention, established in its WSDL-based specifications, of providing a generic extension point in every data structure to allow implementers to carry vendor-specific information without breaking interoperability. This specification carries that convention into the LinkML metadata model through the Extensible mixin. The Extensible mixin adds a single optional, repeatable slot named extension to any class that includes it. Each entry in the slot is an instance of VendorExtension, which pairs a mandatory vendor namespace URI with a locally named, arbitrarily typed value. The namespace URI uniquely identifies the vendor and prevents naming collisions between different implementers. An ONVIF Client that encounters an extension entry whose vendor_namespace it does not recognise shall ignore that entry and shall not treat its presence as an error. An ONVIF Device shall not use the extension slot to carry information that is required for correct interpretation of the normative fields of the enclosing class. The Extensible mixin is applied to Observation, making the extension point available on every concrete observation class derived from it. Other abstract classes in this chapter (Signature, Location, Timing) may also include the mixin in future revisions as needed.

This annex is informative and provides an example end-to-end sequence with sample values.

Request (Client to Device): The ONVIF Client sends a WS-Discovery Probe to locate ONVIF Devices on the local network or subnet. Response (Device to Client): The ONVIF Device returns a ProbeMatch containing its Device Service endpoint (commonly /onvif/device_service).

Request (Client to Device): The ONVIF Client calls ONVIF Core GetServices on the Device Service endpoint. Response (Device to Client): The ONVIF Device returns GetServiceResponse including the Agentic Service entry with MCP endpoint URL (example: https://192.0.2.10/mcp).

Request (Client to Device): The ONVIF Client calls server/discover to obtain the device identity, supported protocol versions, and capability flags. { "jsonrpc": "2.0", "id": 1, "method": "server/discover", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "MyAgenticClient", "version": "1.0.0" }, "io.modelcontextprotocol/clientCapabilities": {} } } } Response (Device to Client): The ONVIF Device returns its identity, the list of supported protocol versions, and its capability flags. { "jsonrpc": "2.0", "id": 1, "result": { "resultType": "complete", "identity": { "name": "ONVIF Agentic Service", "version": "1.0.0" }, "protocolVersions": ["2026-07-28"], "capabilities": { "resources": {}, "tools": {} } } } Legacy client rejection (informative): A legacy client connecting with a pre-2026-07-28 protocol version (for example via an initialize request) will receive an UnsupportedProtocolVersionError. The ONVIF Device shall not support protocol versions prior to 2026-07-28 and shall always include the supported list so that the client can retry. { "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2024-11-05", "capabilities": {}, "clientInfo": { "name": "LegacyClient", "version": "0.9.0" } } } { "jsonrpc": "2.0", "id": 1, "error": { "code": -32022, "message": "UnsupportedProtocolVersionError", "data": { "supported": ["2026-07-28"] } } } Request (Client to Device): The ONVIF Client opens the Streamable HTTP channel to https://192.0.2.10/mcp as defined by MCP 2026-07-28. Response (Device to Client): The ONVIF Device confirms the channel. No JSON-RPC response body is returned for channel establishment; the device will send notifications/message frames over this channel as events occur.

Request (Client to Device): The ONVIF Client sends resources/read with URI capabilities://www.onvif.org/ver10/agentic. { "jsonrpc": "2.0", "id": 4, "method": "resources/read", "params": { "uri": "capabilities://www.onvif.org/ver10/agentic", "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns the Agentic Service capabilities document. { "jsonrpc": "2.0", "id": 4, "result": { "resultType": "complete", "contents": [{ "uri": "capabilities://www.onvif.org/ver10/agentic", "mimeType": "application/json", "text": "{...}" }] } }

Request (Client to Device): The ONVIF Client sends resources/read with URI capabilities://onvif/<service-name> (example: capabilities://onvif/media). { "jsonrpc": "2.0", "id": 5, "method": "resources/read", "params": { "uri": "capabilities://onvif/media", "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client — not supported): If the requested service capability is not exposed, the ONVIF Device returns a resource-not-found error. { "jsonrpc": "2.0", "id": 5, "error": { "code": -32002, "message": "ResourceNotFound", "data": { "uri": "capabilities://onvif/media" } } }

Request (Client to Device): The ONVIF Client sends resources/list to enumerate all resources, including LinkML schema resources. { "jsonrpc": "2.0", "id": 6, "method": "resources/list", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns available resources. Resources with mimeType: application/linkml+yaml are the schema files to be retrieved in (example URIs: linkml://www.onvif.org/ver10/agentic/events). { "jsonrpc": "2.0", "id": 6, "result": { "resultType": "complete", "resources": [ { "uri": "linkml://www.onvif.org/ver10/agentic/events", "name": "ONVIF Agentic Events Schema", "mimeType": "application/linkml+yaml" }, { "uri": "capabilities://www.onvif.org/ver10/agentic", "name": "ONVIF Agentic Capabilities", "mimeType": "application/json" } ] } }

Request (Client to Device): The ONVIF Client sends resources/read for each application/linkml+yaml resource URI obtained from (example: linkml://www.onvif.org/ver10/agentic/events). { "jsonrpc": "2.0", "id": 7, "method": "resources/read", "params": { "uri": "linkml://www.onvif.org/ver10/agentic/events", "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns the LinkML schema as a YAML string in the text field. The ONVIF Client registers this schema in its validator. If multiple schema resources were listed in , this request is repeated for each URI. { "jsonrpc": "2.0", "id": 7, "result": { "resultType": "complete", "contents": [{ "uri": "linkml://www.onvif.org/ver10/agentic/events", "mimeType": "application/linkml+yaml", "text": "..." }] } }

Request (Client to Device): The ONVIF Client sends tools/list to obtain the catalogue of available Skills. { "jsonrpc": "2.0", "id": 8, "method": "tools/list", "params": { "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns one Tool entry per supported Skill, each with a compiled inputSchema derived from the LinkML model. The example shows get_status only. { "jsonrpc": "2.0", "id": 8, "result": { "resultType": "complete", "tools": [ { "name": "get_status", "description": "Returns the operational status of the agentic engine.", "inputSchema": { "type": "object", "properties": {}, "required": [] } } ] } }

Request (Client to Device): The ONVIF Client calls get_status with no arguments. { "jsonrpc": "2.0", "id": 9, "method": "tools/call", "params": { "name": "get_status", "arguments": {}, "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns the current state of the agentic engine, the list of active analytics types, and the engine firmware version. { "jsonrpc": "2.0", "id": 9, "result": { "resultType": "complete", "content": [{ "type": "text", "text": "agentic engine running." }], "structuredContent": { "state": "running", "activeAnalytics": ["fire_detection", "smoke_detection"], "engineVersion": "2.1.4" } } }

Request (Client to Device): The ONVIF Client calls list_analytics with no arguments. { "jsonrpc": "2.0", "id": 10, "method": "tools/call", "params": { "name": "list_analytics", "arguments": {}, "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns all analytics types it supports, their enabled state, and the LinkML schema URI that governs the configure_analytics call for each type. { "jsonrpc": "2.0", "id": 10, "result": { "resultType": "complete", "content": [{ "type": "text", "text": "2 analytics type(s) available." }], "structuredContent": { "analytics": [ { "type": "fire_detection", "enabled": true, "configSchema": "linkml://www.onvif.org/ver10/agentic/events#FireDetectionConfig" }, { "type": "smoke_detection", "enabled": false, "configSchema": "linkml://www.onvif.org/ver10/agentic/events#SmokeDetectionConfig" } ] } } }

Request (Client to Device): The ONVIF Client calls configure_analytics specifying the analytics type and a config object whose structure matches the LinkML class identified by configSchema (obtained from list_analytics). { "jsonrpc": "2.0", "id": 11, "method": "tools/call", "params": { "name": "configure_analytics", "arguments": { "analytics_type": "fire_detection", "config": { "sensitivity": 0.80, "channel": "ch1", "region": [[0.1, 0.1], [0.9, 0.1], [0.9, 0.9], [0.1, 0.9]] } }, "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client — success): { "jsonrpc": "2.0", "id": 11, "result": { "resultType": "complete", "content": [{ "type": "text", "text": "fire_detection configured successfully." }], "structuredContent": { "analytics_type": "fire_detection", "applied": { "sensitivity": 0.80, "channel": "ch1", "region": [[0.1, 0.1], [0.9, 0.1], [0.9, 0.9], [0.1, 0.9]] } } } } Response (Device to Client — validation error): If the config object violates a schema constraint, the ONVIF Device returns a structured error identifying the failing field. { "jsonrpc": "2.0", "id": 11, "error": { "code": -32602, "message": "InvalidParams", "data": { "field": "config.sensitivity", "violation": "value 1.5 exceeds maximum 1.0" } } }

Channel opening (Client to Device): The ONVIF Client opens the Streamable HTTP channel to https://192.0.2.10/mcp as defined by MCP 2026-07-28. No JSON-RPC request/response exchange occurs for channel establishment; the ONVIF Device will push notifications/message frames over this channel as events are produced. Event frame (Device to Client): The ONVIF Device sends a notifications/message frame for each metadata event. The example below shows a FireDetectionEvent carrying a SOSAObservation payload. { "jsonrpc": "2.0", "method": "notifications/message", "params": { "message": { "@context": "linkml://www.onvif.org/ver10/agentic/events", "@type": "FireDetectionEvent", "sosa:madeBySensor": "urn:onvif:device:192.0.2.10:camera:ch1", "sosa:observedProperty": "onvif:FlamePresence", "sosa:hasFeatureOfInterest": "urn:onvif:scene:ch1:zone:north", "sosa:phenomenonTime": "2026-08-04T13:05:00.000Z", "sosa:resultTime": "2026-08-04T13:05:00.120Z", "sosa:hasResult": { "@type": "FireDetectionResult", "detected": true, "confidence": 0.94, "boundingBox": { "x": 0.22, "y": 0.31, "width": 0.18, "height": 0.24 } } } } }

This example shows the procedure triggered when the ONVIF Client receives a notifications/message frame whose @context URI (linkml://onvif/agentic/events/v2) is not yet registered in its schema bundle. The client suspends validation, fetches the schema, and registers it before resuming. Incoming frame with unknown context (Device to Client): { "jsonrpc": "2.0", "method": "notifications/message", "params": { "message": { "@context": "linkml://onvif/aagentic/events/v2", "@type": "PersonCrossingEvent", "sosa:madeBySensor": "urn:onvif:device:192.0.2.10:camera:ch1", "sosa:observedProperty": "onvif:PersonPresence", "sosa:hasFeatureOfInterest": "urn:onvif:scene:ch1:zone:entrance", "sosa:phenomenonTime": "2026-08-04T13:10:00.000Z", "sosa:resultTime": "2026-08-04T13:10:00.085Z", "sosa:hasResult": { "@type": "PersonCrossingResult", "direction": "entering", "confidence": 0.91 } } } } Schema fetch request (Client to Device): The ONVIF Client calls resources/read with the unknown @context URI. { "jsonrpc": "2.0", "id": 13, "method": "resources/read", "params": { "uri": "linkml://onvif/agentic/events/v2", "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" } } } Response (Device to Client): The ONVIF Device returns the new schema. After registration the client validates the suspended event and resumes normal processing. { "jsonrpc": "2.0", "id": 13, "result": { "resultType": "complete", "contents": [{ "uri": "linkml://onvif/agentic/events/v2", "mimeType": "application/linkml+yaml", "text": "id: https://onvif.org/agentic/events/v2\nname: onvif-ai-events-v2\n..." }] } }