The physical device would not connect directly to MCP. Sensorius devices send supported measurements, events, telemetry and control feedback to the Sensorius Platform through their existing deployment paths. In the planned design, a customer-authorized assistant would request permitted information from Sensorius through MCP.
Ask about planned Sensorius MCP early access
How the planned connection is intended to work
Proposed flow, subject to implementation and validation Sensorius device ↓ measurements, events, telemetry, or control feedback Sensorius Platform ↓ customer-authorized, tenant-scoped read access Sensorius MCP ↓ permitted field and device evidence Supported MCP-compatible AI assistantThe proposed customer flow would start with an existing Sensorius account and tenant membership. An eligible user would select a client from a validated compatibility list and sign in through Sensorius. The authorization screen is intended to identify the requesting client and the read access it requests, so the user could allow or deny the request.
The design requires the assistant to discover only tools available to that account, and each request to be checked against current tenant and product permissions. It also requires a revocation path. These checks must be implemented and validated before the flow is offered to customers.
If early access proceeds, it is intended to be limited to validated clients and selected customer tenants. Sensorius would confirm the client, onboarding steps and available evidence before activation.
Questions an operator could test if the required evidence is available
These are examples for a future validated client, not a promise that every question or data source is currently available:
For a field with supported data, you might ask:
- Which Sensorius devices are assigned to this field, and what is their latest reported state?
- What changed in soil moisture, temperature, pH, electrical conductivity, or other available measurements during the selected period?
- Is the recent reading trend current, partial, stale, or unavailable?
- What weather evidence is stored for this field, and how fresh is it?
- Which crop-timeline phase is active, and what generated actions are due today?
- Which fields need attention based on the evidence currently available in Sensorius?
Any answer would depend on the devices, measurements, field context, permissions, available tools and platform data for the tenant. The planned design requires missing or stale evidence to be identified instead of replaced with an invented measurement or device condition.
Proposed use with an external assistant
If the customer flow is validated, a team could review a field in the Sensorius Platform or ask a question from a supported external client while preparing a report or investigating an operational issue.
The proposed early-access connection would let eligible customers bring permitted Sensorius evidence into a supported AI workflow without a manual export or one-off integration. Sensorius would remain the source of field and device data, with access limited by the user’s tenant and product permissions. The assistant would help users ask questions and interpret evidence; it would not become the system of record.
The planned access is read-only
The planned customer-access boundary is read-only. If implemented, its tools must not:
- send a command to a device
- change desired state or device settings
- start or stop irrigation or fertigation equipment
- delete or export raw telemetry outside the approved product flow
- create or update a field or crop timeline
- apply a generated field action
A question or answer in an AI assistant would not be an equipment command. The farm, agronomy, engineering or operations team remains responsible for reviewing evidence and deciding what happens at the site.
The intended access checks follow the customer and tenant
The planned design calls for authorization by a Sensorius user, not by a device serial number or shared tenant secret. Each supported client request would need authorization for the Sensorius MCP resource. Sensorius must resolve the user, tenant, MCP eligibility and data permissions required for the requested tool.
Under the PRD, permission to connect through MCP would not by itself grant access to every field, device, reading or planning record. The user would also need the corresponding Sensorius read permissions. A request for another tenant’s field or device must return no protected data; this behavior needs implementation and security validation.
Customer revocation, rejection of expired or invalid authorization, and support evidence that avoids logging credentials or sensitive response payloads are requirements in the planned design. The implementation and operational process must be checked before publication as an available feature.
What to prepare for early access
Before discussing a possible evaluation, identify:
- the Sensorius tenant and users who need the connection
- the operational questions the team wants to test
- the supported AI client the team plans to use
- the fields and devices that should provide evidence
- the people responsible for reviewing answers and acting in the field
- the security or privacy reviewer for the customer organization, when required
If the early-access programme opens, Sensorius would confirm client compatibility, the authorization flow, evidence available to selected users, the revocation path and support contact. A first evaluation should use a small set of representative questions rather than assume every workflow or AI client is supported.
