MCP does not replace an analytics layer

Connecting artificial intelligence to Jira or Confluence quickly creates a sense of power. The agent can find a work item, summarize a page, relate a few objects and sometimes take action in the tool. That capability is valuable. It does not, however, automatically turn enterprise data into a reliable analytical system.

Not every use case we work on at Ovyka can be documented publicly. The architectural lesson can be shared: as soon as a question involves tens, hundreds or thousands of objects, a generic agent connected through MCP is usually not enough. Retrieval, data preparation, calculation and interpretation need to be organised as separate responsibilities.

A connection is not a data model

MCP standardises how an AI system discovers and calls tools. The distinction matters: the protocol does not create the functions a system needs. It makes available the functions that the server has actually implemented and that the user is authorised to call.

The Atlassian Rovo MCP server (s’ouvre dans un nouvel onglet) (opens in a new tab) illustrates this well. Its tools include reading a work item, JQL and CQL searches, natural-language search and Teamwork Graph context. Some can bring together related objects from several products. These are richer capabilities than basic record-by-record access, but they still do not amount to a business analytics layer ready to answer any question.

MCP is therefore an excellent access contract. The quality of an answer still depends on the tools exposed behind that contract, their limits, the user’s permissions and the shape of the data they return.

Retrieval and aggregation are different operations

Retrieval aims to find the most relevant objects for a request. It is a good fit for questions such as:

which work item describes this incident?
which page explains this decision?
which recent objects discuss the same topic?
can you summarize this file and prepare an action?

Analytics serves a different family of questions:

how does an indicator change across several periods?
what proportion of objects satisfies several combined criteria?
how can teams be compared when their statuses and practices differ?
which correlations remain after checking the complete scope?

A serious answer often requires reading an exhaustive set, handling pagination, normalising fields, reconciling reference data, treating missing values, applying calculation rules and keeping a record of the result. Asking the model to read a large mass of raw work items and “do the maths” mixes all of those responsibilities.

The issue is not that AI cannot reason. The issue is that a language model is neither an analytical database nor a deterministic calculation engine. Its context is bounded, the selection of objects can introduce bias, and the same concept may be encoded differently across projects. A small sample can produce a convincing answer. At portfolio scale, convincing is not a sufficient quality criterion.

An index improves retrieval, not metric definitions

Rovo Search (s’ouvre dans un nouvel onglet) (opens in a new tab) uses content available to the current user to surface relevant results from Jira, Confluence and connected sources. This type of index is essential: without it, finding useful information in a large corpus becomes slow and imprecise.

But a search index primarily answers “which content most closely matches this request?” An analytics layer must answer “which rows are included in this calculation, under which definition, at which date, and with which reproducible result?”

The two approaches complement each other; they are not interchangeable. A good index supplies the AI with relevant documents or objects. Analytical preparation supplies explicit measures, dimensions and aggregates. The model can then explain the result, identify an anomaly or support a decision without reconstructing the entire source dataset itself.

Preparing data that AI can actually use

A robust architecture separates at least five responsibilities.

Access the sources. Jira, Confluence and other tools remain the systems of record. Permissions must be preserved and calls limited to the necessary scope.
Extract the right objects. MCP, JQL, CQL or specialised APIs provide the available search, read and action operations.
Prepare the data. Statuses, dates, identifiers and relationships are normalised. Business rules are applied before the model is called.
Calculate deterministically. Volumes, ratios, trends and controls are produced by code or an analytical engine that can run exactly the same calculation again.
Interpret and act. The AI receives the useful results, their definitions and the required evidence. It can then summarize, explain, compare or propose an action.

This separation is not about making the system heavier. It avoids sending thousands of objects to a model when an aggregate table, a set of exceptions and the right supporting sources are enough. It also improves auditability: the origin of the data, the applied rule and the model’s interpretation remain distinguishable.

Advanced agents are systems, not long prompts

At Ovyka, we work on automations and agent architectures that go beyond a generic agent connected to a handful of tools. The goal is not to multiply agents for effect. It is to give each component a clear responsibility.

An orchestrator can qualify the request and select the right path. A retrieval tool finds the sources. A deterministic process prepares an aggregate. A specialist agent analyses the exceptions. Another checks consistency or prepares a response for a particular audience. Sensitive actions remain subject to permissions and, where appropriate, human approval.

This approach also makes it possible to recognise when a question is not yet answerable. If teams do not share definitions, a decisive field has no history, or access is incomplete, the agent should say so. Inventing precision from an incomplete corpus would be faster, but useless.

Ovyka describes its approach to AI architectures, automation and autonomous agents (s’ouvre dans un nouvel onglet) (opens in a new tab) and to Atlassian AI and Rovo use cases (s’ouvre dans un nouvel onglet) (opens in a new tab) in more detail.

Choose the architecture from the question

Not every request needs a dedicated data platform. Three levels already cover many situations.

Direct retrieval. Native MCP tools may be enough to find information, summarize a few identified objects or create an action. It is the shortest path and often the right one.

Retrieval followed by calculation. When the question has a defined scope and a simple calculation, the agent can build a query, let a deterministic process traverse every result, and then comment on the resulting aggregate.

Prepared data and specialist agents. For recurring, multi-source or high-stakes analysis, it becomes useful to normalise and index the data, pre-compute selected indicators and orchestrate several specialised components.

Before choosing, I ask five questions:

Are we looking for relevant content or an exhaustive result?
Does the result need to be reproducible and reviewable?
Do the fields have the same meaning across the complete scope?
What freshness and history are actually required?
What evidence should accompany the answer?

These questions are similar to those that should precede a migration. Across my projects, work on enterprise platforms repeatedly shows that moving or connecting data is not enough. As I explained in A tool migration is only as valuable as the visibility it creates, value appears when relationships and real-world use become visible again.

Assign each responsibility to the right component

MCP creates a clean, standardised path between AI and work tools. Search engines and knowledge graphs substantially improve access to context. A prepared data layer makes large-scale analysis reliable. Specialist agents can then turn the results into useful explanations and actions.

No single component should be expected to perform all of these roles. Enterprise AI becomes genuinely useful when its architecture knows where to search, what to calculate, what it can claim and when it must ask for validation.