For IT professionals, readiness reports provide valuable insights, but finding the right information can take time.
Chrome Readiness Assessment gives organizations a detailed view of their environment and helps teams understand their overall readiness. But when a user needs one specific answer, they may still need to move through multiple report sections before finding it.
CRA MCP introduces a new way to work with that readiness data. It brings Model Context Protocol support into the CRA Report Generator, allowing tested MCP-compatible clients to connect to the current generated CRA report through a controlled MCP Server.
The report-querying and data retrieval flow has currently been tested with CommandLyne and the Claude Desktop app. With this connection, users can ask natural-language questions, explore follow-ups, and receive focused answers based on CRA readiness data. Instead of manually searching through the report, teams can ask the report what they need to know.
CRA MCP also brings readiness intelligence closer to action. Where approved, CEP enrollment token deployment can be supported through a separate Device Action Tools section. This deployment capability is currently in beta and is supported through CommandLyne only.
CRA MCP is not just about making reports easier to read. It helps teams move from readiness data to controlled next steps while keeping setup approval, MCP access control, tool-level confirmation, and deployment visibility inside CRA.
What Is CRA MCP?
CRA MCP is a new integration feature that allows supported AI agents to interact with CRA readiness data through an MCP Server inside the Report Generator.
Instead of manually searching through different report sections, users can connect a tested MCP client and ask questions about the current generated report. At this stage, the report-querying experience has been tested with CommandLyne and the Claude Desktop app.
For example, a user may want to know which devices are blocked, which applications need review, what browser risks were found, which workflows show automation activity, or what is affecting CEP readiness. CRA MCP allows the connected client to request the right information from the report and return a focused answer.
The Report Generator remains the source of truth. The MCP Server controls access. The connected MCP client provides the conversational experience.
From Static Reports to Askable Readiness Data
Traditional reports are useful, but they depend on the user knowing where to look.
CRA MCP makes the report more interactive. Instead of opening multiple pages, filtering tables, and reading through different sections, users can ask direct questions and receive data-backed responses.
This helps different teams use the same report in different ways.
An IT administrator can ask for technical blockers. A manager can ask for a short readiness summary. A security team can ask about browser and extension exposure. A partner can ask for the main customer risks and the next areas to review.
The same readiness report becomes easier to explore because users can ask for the exact view they need.
Remote Device Actions Start With Setup Approval
Before device actions can be used, CRA requires approval during the setup flow.
In the installation or wizard process, the user must allow Remote Device Actions. This approval authorizes the Report Generator on that machine to send signed configuration actions to devices in the current installation round.
This is an important control point.
Remote Device Actions do not mean CRA can send any command to a device. The flow is limited to supported built-in actions. Instructions are signed, devices pick them up during their check-in cycle, and outcomes can be reviewed later.
Once this setup approval is completed, the MCP Server and Actions capabilities become available in the Report Generator.
How the MCP Server Works
The MCP Server sits inside the CRA Report Generator as a controlled connection layer.
When the MCP Server is enabled, users can create access tokens for tested MCP clients. These tokens allow approved clients, such as CommandLyne or the Claude Desktop app, to connect to CRA and request information from the current generated report.
The connected client does not directly own the CRA data. It sends a request through the MCP Server. The MCP Server validates access, checks whether the requested tool is available, retrieves the supported information from the current report, and returns only the relevant data.
The flow is simple:
User asks a question → AI agent sends the request → MCP Server validates access → CRA Report Generator provides the report data → AI agent returns the answer
This gives users a natural-language experience while keeping CRA as the trusted source of readiness information.
Access Tokens Keep AI Connections Controlled
CRA MCP does not open report access automatically.
Users must enable the MCP Server and create named access tokens for the MCP clients they want to connect. The report-querying and data retrieval flow has currently been tested with CommandLyne and the Claude Desktop app.
This gives organizations control over which tested clients can connect to CRA.
Access can also be removed when needed. If a token is revoked, the connected client can no longer access CRA readiness data through that token.
This matters because CRA reports may include sensitive environment information, such as device status, application usage, browser risks, migration blockers, workflow activity, and CEP readiness. Token-based access keeps the AI connection useful without making it uncontrolled.
Device Action Tools Add a Controlled Next Step
CRA MCP also includes a separate section called Device Action Tools.
This is different from the read-only MCP tools.
Read-only tools help users retrieve and understand report data. Device Action Tools can support a specific approved action when the organization enables them.
These tools are not available by default. The deploy_chrome_enrollment_token tool is available under the Device Action Tools section within the MCP Server page. This CEP enrollment token deployment capability is currently in beta and is supported through CommandLyne only.
To enable the CEP enrollment token action, the user must select the action tool under Device Action Tools. When the user selects the tool, CRA shows a warning modal asking whether AI clients should be allowed to use that action.
This creates another approval layer.
If the user confirms, the selected CEP enrollment token action tool becomes available through the approved CommandLyne MCP flow. If the user does not confirm, the tool remains disabled.
This means the AI agent is not given general device control. It can only call the specific CEP enrollment token action tool that has been approved.
Deployment Tracking Stays Inside the Report Generator
Actions triggered through MCP do not disappear into the background.
After the approved CommandLyne agent deploys the CEP token, the user can go to the Actions page and open the Deployments tab. There, the deployment card appears for the enrollment token action.
The card shows the deployment summary, including how many instructions were published and how many are still pending. Users can then view the devices connected to that deployment.
Inside the device list, users can see which devices are pending, which devices have applied the action, and which devices are still waiting for check-in. Device-level details also help teams review information such as the device name, group, action type, published time, expiry, last upload time, reported outcome, agent version, and action history.
This keeps the process transparent.
Even when the action is triggered through CommandLyne, the Report Generator still gives users a place to verify progress and confirm the outcome.
Business Value of MCP Device Action Tools
The business value of CRA MCP is that it connects readiness insight with controlled execution.
A readiness report can show what needs attention. An AI agent can help explain the finding. A controlled Device Action Tool can then support a specific approved next step.
This reduces the gap between analysis and action.
For IT teams, it means less time moving between report review and operational follow-up. For security and management teams, it means AI-supported workflows can still stay inside approved boundaries. For partners, it creates a stronger customer experience because the discussion can move from “what did the report find?” to “what controlled next step can we take?”
Because the CEP token deployment flow is currently in beta, it also creates a foundation for future expansion. More supported actions can be introduced later while keeping the same control model: setup approval, MCP access control, tool-level confirmation, and deployment tracking.
CRA MCP brings readiness intelligence closer to action while keeping approval, access control, and deployment visibility inside the Report Generator.
Not General AI Control
CRA MCP should not be understood as open-ended AI control over devices.
The AI agent cannot freely change CRA data, run arbitrary commands, or perform unrestricted device operations.
Read-only MCP tools are used to query and summarize report data. Device Action Tools are separate, disabled by default, and only available after explicit approval. The current CEP token deployment capability is beta and limited to the approved CommandLyne flow.
This separation makes the feature practical for enterprise environments. Teams can benefit from AI-assisted readiness exploration while keeping action boundaries clear.
Manual Deployment Is Still Available
CRA MCP supports AI-connected workflows, but users do not have to use an AI agent for every action.
Users who prefer a manual flow can go to the Actions area in the Report Generator, choose the supported action, configure the required details, and deploy it directly from the interface.
This manual path is useful when teams want to handle the action themselves while still using the Report Generator to track deployment status.
From Readiness Reports to Readiness Intelligence
CRA MCP turns CRA reports into a more interactive layer of readiness intelligence.
The Report Generator continues to hold the trusted data. The MCP Server controls which tested clients can connect. Access tokens protect the connection. Read-only tools provide focused answers. Device Action Tools support approved next steps. The Actions page keeps deployment tracking visible.
Together, these capabilities make CRA MCP more than a report-querying feature.
It helps organizations ask better questions, understand readiness faster, and move toward controlled action with confidence. With the CEP token deployment capability currently in beta through CommandLyne, CRA also sets the foundation for more controlled action workflows in future releases.
FAQ
Which MCP clients are currently tested with CRA MCP?
The report-querying and data retrieval flow has currently been tested with CommandLyne and the Claude Desktop app.
What happens when the CEP enrollment token Device Action Tool is selected?
CRA displays a warning modal asking whether AI clients should be allowed to use that action. If the user confirms, the action becomes available through the approved CommandLyne MCP flow. If the user does not confirm, the tool stays disabled.
Can an AI agent deploy a CEP token?
Yes, where approved, but this capability is currently in beta and supported through CommandLyne only. The CEP enrollment token Device Action Tool must be enabled, confirmed, and accessed through a valid MCP token before CommandLyne can support the deployment action.
Will more Device Action Tools be added later?
Yes. The CEP token deployment flow is the current beta action, and future releases can expand the Device Action Tools area with more supported actions.
