Adobe Analytics MCP read-only access and Data Warehouse changes

Adobe Analytics now lets administrators give people read-only access to its MCP server, generally available from 6 October 2026, and it has started changing how Data Warehouse reports show classification values. The first is a permissions clean-up you can do this week. The second can move numbers in recurring exports, so it deserves a before-and-after check.

The October 2026 notes also add automatic component descriptions, an Adobe Brand Visibility integration and a Coworker Chat capability. Those are real, but they matter less than the two above, and one of them still has no firm date.

Key takeaways

• MCP Read-only Access became generally available on 6 October 2026. The original MCP Access permission is now called MCP Full Access.
• Review who holds MCP Full Access today. Anyone who only needs to query data should move to the read-only item.
• Data Warehouse classification output began rolling out on 14 October 2026, with general availability in January 2027. Deleted values show blank, and multi-value cases show every value.
• Snapshot a few recurring Data Warehouse exports now so you can explain any shift later.
• Automatic component descriptions arrive on 28 October 2026. Treat the text as a draft a person approves.
• Coworker Chat access to Analytics data has no general availability date yet. Do not plan around it.

What does MCP Read-only Access change for Adobe Analytics admins?

Before this release, the permission model for the Adobe Analytics MCP server was effectively all or nothing. A user either had MCP access, with every tool available, or had none. The notes now split that in two. MCP Read-only Access opens all the read-only tools but does not let the user create projects, segments or calculated metrics. MCP Full Access, which is the renamed original item, keeps everything, including tools that create, change or delete components.

The practical effect is on risk. An MCP server lets an assistant or an automated client act on Analytics through tools. If the person behind that client only wants to ask questions of the data, there was no good reason to also let it write to your component library. A segment created by an assistant on someone's behalf lands in the same shared pool as segments built by your analysts. A calculated metric changed in error can quietly alter a dashboard the finance team reads on Monday.

The position here is simple. Make read-only the default for everyone, and treat Full Access as something a named person justifies. Most of your MCP users are probably analysts, stakeholders and product managers who want answers, not people who maintain the component library.

One caution. The notes describe the new item as covering read-only tools, and they do not list which tools those are. Check the MCP server documentation Adobe points to under its permissions setup before you promise anyone a particular capability.

Who should move to read-only, and how do you do it safely?

Start with an inventory. List every user and product profile that currently carries the old MCP Access item, which now appears as MCP Full Access. Then sort them into two groups: people who build and maintain components through MCP, and people who only look.

A short sequence works for most teams:

1. Export the current permission assignments so you have a record to roll back to.
2. Identify the owners of shared components. They are the people who plausibly need Full Access.
3. Create or adjust a product profile that carries MCP Read-only Access, and assign it to the remaining users.
4. Remove MCP Full Access from those users once the read-only profile is in place, not before.
5. Ask a few of them to run their usual questions and confirm nothing they rely on has gone.
6. Record who holds Full Access and why, and set a reminder to review it each quarter.

Do it in that order. Removing access first and adding it back second creates a gap where someone's scheduled workflow fails with an error nobody can immediately explain.

What not to do: do not grant Full Access to a service account or automation just because it was easier when you set it up. If a script only pulls reports, it belongs on the read-only item.

Why will Data Warehouse classification values look different?

Adobe says classification data is now more accurate in Data Warehouse reports. It describes three visible differences, and each can show up in an export somebody already trusts.

First, blanks where you used to see values. When a classification value is deleted from a classification set, Data Warehouse now correctly shows a blank. Previously the deleted value could keep appearing in later reports. If your team retired a campaign category last year and kept seeing it in exports, that stale label may now disappear and be replaced by an empty cell.

Second, more complete values. In some cases Data Warehouse previously showed only one of several different classification values. It now shows each one. Row counts or groupings in a classified export may therefore look different even though the underlying hits did not change.

Third, a gap against Analysis Workspace. The notes call this uncommon. Data Warehouse can display all associated classification values, while Analysis Workspace presents a single value. Occasionally the two tools will disagree about the same item.

The notes give 14 October 2026 as the date rollout starts and January 2027 for general availability. So this is a phased change, and you may see it on some report suites before others. That makes comparison tricky unless you capture evidence early.

Change	Who it affects	Action
Deleted classification values show blank	Teams that retire or clean up classification sets	Find exports that group by classified dimensions and expect blanks
Every associated value is shown	Anyone with items that carry more than one classification value	Compare row counts and totals before and after
Data Warehouse and Analysis Workspace may differ	Analysts who reconcile the two tools	Document the rule so nobody files a bug for expected behaviour
Rollout from 14 October 2026, general availability January 2027	Owners of scheduled Data Warehouse requests	Capture baselines now, repeat during the rollout

How do you test the Data Warehouse classification change?

Do not wait for a stakeholder to spot a strange line in a board report. Pick the three to five scheduled Data Warehouse requests that feed something important: a monthly performance pack, a feed into a warehouse table, a campaign reconciliation. For each one, save the most recent output as a baseline.

Then rerun the same request over the same date range after the change reaches your report suite. Compare three things. Do totals still match? Do any classified values now appear blank? Do any rows split into several values where there was one before?

A worked example. Say a retail team classifies tracking codes into channel groups, and one code was reassigned from Paid Social to Affiliate last quarter, with the old value deleted. The old export might still have attributed some rows to Paid Social. After the fix, those rows may read blank, and the team needs to decide whether the blank is a gap in their taxonomy or a correct reflection of what they removed. That is a data-quality finding, and it is a useful one.

If you push Data Warehouse output into a downstream table, check whether anything there treats blank as invalid, or joins on a classification value. A new blank can break a join quietly rather than loudly.

The notes also list a long run of classification fixes among the October items, so if you have been tracking an open ticket there, check whether your issue is covered by the fix list on Adobe's page.

Are automatic component descriptions worth switching on?

From 28 October 2026, Adobe says you can automatically generate descriptions for dimensions, metrics, calculated metrics, segments and date ranges. You can do it for one component or for many at once. The stated aim is to help Workspace users understand which components to use, especially in organisations with large libraries. The notes say documentation is still to follow, so settings and review controls are not yet described.

The problem it targets is real. Many mature implementations have hundreds of segments called things like Final v2 or Test - do not use. New analysts guess, and guessing is how two teams end up reporting different conversion numbers from different calculated metrics.

Generated text will help most when the component itself is well built. A description cannot rescue a segment whose logic nobody remembers. So use the feature as a prompt to clean the library, not as a substitute.

A reasonable approach:

• Start with the components your team uses most, not the whole library.
• Have the owner of each component read the generated description and correct it before it stands.
• Check that descriptions state the rule in business terms, such as which visits are included and which are excluded.
• Retire or rename components nobody can describe, rather than generating text for them.

What to avoid: bulk-generating descriptions across every component and moving on. A confident but wrong description is worse than a blank one, because people believe it.

What about Brand Visibility and Coworker Chat?

Two items in the notes are early, and the notes themselves say so.

The Adobe Brand Visibility integration connects Brand Visibility with your organisation's Analytics data, so you can measure how AI-driven discovery translates into website engagement and business outcomes. The notes give October 2026 for general availability, with no rollout-start date and documentation to follow. If AI search referrals are a live question for your marketing team, it is worth asking your Adobe contact what it requires. Beyond that, there is not enough published detail to plan a build.

Coworker Chat is less settled. The notes say CX Enterprise Coworker Chat can perform advanced data analysis previously possible only in Analysis Workspace, drawing on your report suites to answer natural-language prompts. Rollout started on 2 October 2026, but the general availability date is to be determined, with an original target of 25 September 2026 now missed. Documentation is also still to follow.

My view: trial it if you have access and a safe report suite, and keep it away from anything a decision depends on until Adobe commits to a date. A slipped date on a vendor's own page is a good reason to wait.

Which deadlines have already passed?

The release page also repeats two end-of-life notices, and both are in the past. The Adobe Analytics API 1.4 and WSSE authentication reached end of life on 31 August 2026, and integrations built on them no longer function. Adobe says they must move to the 2.0 API, with OAuth-based authentication set up in the Adobe Developer Console. The legacy Report Builder add-in was retired in June 2026, and users are expected to convert workbooks to the new Report Builder, which is a Microsoft Store add-in that some companies must approve internally.

If an old dashboard, script or vendor connector went blank in September, this is the first place to look. Search your scheduled jobs and any agency-built integrations for 1.4 endpoints, and ask each owner to confirm the migration.

A rollout checklist with owners

Task	Suggested owner	When
Export current MCP permission assignments	Analytics admin	This week
Move query-only users to MCP Read-only Access	Analytics admin	After the inventory
Save baselines of key Data Warehouse exports	Reporting analyst	Before your report suite changes
Rerun and compare exports during the rollout	Reporting analyst	Weekly until January 2027
Review generated component descriptions	Component owners	From 28 October 2026
Confirm no 1.4 API or WSSE integrations remain	Engineering lead	Now

How do you know it worked?

Measure the permissions work by counting. How many people hold MCP Full Access now, compared with before? Each one should have a named reason. Check, too, whether any new components appear in the library that nobody on your team recognises.

Measure the classification work by variance you can explain. For each baseline export, record the differences and the cause: a deleted value now blank, an item now showing several values, or a real data change. If you cannot explain a difference, raise it with Adobe support rather than adjusting your reporting.

Measure descriptions by use. Ask a few newer analysts whether they can now pick the right segment without asking a colleague. That tells you more than counting how many descriptions exist.

Where does an implementation partner help?

Most of this you can do yourself. An admin can sort out MCP permissions in an afternoon, and an analyst can run baseline comparisons without outside help. Writing component descriptions is best done by the people who built the components.

A partner earns their fee on the harder parts. Examples include untangling a classification taxonomy that has accumulated years of deleted and reassigned values, auditing a large component library for duplicates, or finding and rewriting integrations that still depend on retired APIs. If that is your situation, our list of Adobe Analytics partners is a place to start, and our Adobe Analytics RFP template will help you write a brief that asks for specific outputs rather than general advice.

If you are not sure whether you need help at all, you can find partners by capability and compare before committing to a conversation.

Sources

• Adobe Experience League — Current Adobe Analytics release notes for October 2026, last updated 15 October 2026.