Junyr: a business foundation connected to your AI assistants through MCP

A Croissance & Transitions manifesto

---

The principle: separate the business foundation from the AI model

Junyr proposes keeping business data, rules and actions in a foundation separate from the model that reasons, allowing a company to choose its assistants without rebuilding its operational system whenever the model market changes.

• The foundation organises the company’s information and processes.
• The MCP interface exposes only the intended tools and resources to compatible assistants [1].
• The model supplies reasoning capabilities according to the product, plan and terms selected.
• The Junyr contract covers the platform and agreed services, while model costs remain separately identifiable.

This architecture makes responsibilities easier to understand, but it does not establish that a subscription will always cost less than an API or that the full cost will remain fixed.

• A subscription can have a fixed price while still imposing usage or feature limits.
• Model APIs are generally priced according to the volumes and options consumed [3][4][5].
• The full bill also includes Junyr, integration, any hosting, operations and support.

---

What makes the cost of an AI architecture vary

Cost depends on how each use case combines the business platform, model access, context volume, action frequency and required service level, rather than on a simple contest between two pricing models.

• Volume-priced API: cost changes with input and output tokens, caching, the model and the tools used.
• User subscription: the monthly fee is known, but limits, permitted uses and connection options differ by provider.
• Business platform: the fee pays for the foundation, its modules, maintenance and the services explicitly included.
• Company project: migration, configuration, controls, support and change management complete the operating cost.

A fair comparison therefore measures the same service over the same period and publishes its assumptions instead of applying a general multiplier to unlike uses.

• Record actual volumes by token type and model.
• State the number of users, plan limits and automated tasks.
• Add technical and human costs that are absent from the model price.
• Test several load scenarios, then track the gap between forecast and invoice.

---

Three layers to budget separately

Junyr’s proposition is easier to assess when the company separates the operational platform, access to reasoning and the deployment options it wants to keep under its own control.

• The split avoids confusing the price of business software with the price of third-party models.
• Each layer needs an owner, a consumption measure and a reversibility condition.
• The current quotation and contract define the exact functions and credits included.

Layer	Cost item	Decision question
Junyr foundation	Platform fee and agreed services	Which data, business functions, access rules and services are included?
Third-party assistant or model	Subscription, API or selected infrastructure	Which uses, caps, data-processing terms and service levels apply?
Controlled deployment	Hosting, model or API key supplied by the customer, where offered	Which skills, operations and responsibilities does the company take on?

Server-side calculated answers can reduce the context sent to a model for some questions, but the gain depends on each tool’s design and must be measured from real traces.

• A business aggregation can avoid transmitting many raw rows.
• A well-defined tool can reduce the number of calls needed for a task.
• Latency, tokens and correctness should be compared with a stated baseline method.
• No savings factor can be generalised without scope, period and usage logs.

---

Choose the assistant without moving the business foundation

The main economic and technical benefit of this separation is the ability to change model access while keeping business data, rules and tools in a durable layer.

• A company can select an assistant compatible with its needs and internal rules.
• It can compare a subscription, an API and a model deployed on selected infrastructure.
• It reduces dependence on one model if business tools remain described through a stable interface.
• It must still check each provider’s terms and the MCP host’s actual compatibility.

An assistant subscription and the corresponding API access are not interchangeable by default, as Anthropic illustrates by describing them as separate products with separate billing [2].

• The subscription serves a user experience with its own limits and features.
• The API serves software integration and has its own pricing.
• Some automations, service identities or guarantees may require the API even when a subscription exists.

---

Turn sovereignty into verifiable controls

Junyr.eu presents Junyr Suite as independent of Big Tech and hosted in Europe [7], an orientation that each customer’s contract must complete with precise commitments covering the data lifecycle.

• Locate primary hosting, backups and any subprocessors.
• Define who administers accounts, roles, MCP tools and access logs.
• Confirm the company’s ownership of its data and specify the rights attached to configurations or agents developed for it.
• Document export, portability, deletion timescales and exit from the service.
• Assess data sent to the third-party model under that provider’s separate terms.

Confidentiality then depends on minimising the data exposed to each tool and applying authorisation to every call, turning an intention to protect data into testable rules.

• Restrict tools to the fields and actions required for their purpose.
• Apply individual and company rights before the server returns any result.
• Log sensitive calls and require human approval for material commitments.
• Test access refusals, scope errors and rights revocation before production.

---

An open interface between Junyr and compatible assistants

MCP provides a shared convention for connecting an AI application to a system’s tools and data, allowing Junyr to position itself as a business layer for several hosts rather than as a language model [1].

• The server describes the tools, resources and prompts it makes available.
• A compatible host chooses the capabilities it supports and requests the necessary permissions.
• Tool schemas make inputs and outputs more explicit than direct database access.
• The standard makes switching assistants easier without guaranteeing identical compatibility across products.

The value of this layer depends on its actual business coverage and permission quality, because an agent can only read or change what its tools make accessible.

• Map the modules actually connected, their source data and their owners.
• Distinguish reading, calculation, proposal and binding action for every tool.
• Plan for errors, manual recovery and traceability of decisions.
• Expand the scope gradually after validating priority uses.

---

Assess Junyr as a management system accessible to agents

Junyr presents itself as a management suite with an agent interface, so it should be assessed simultaneously as business software, a data architecture and an access point for assistants.

• Business functions: check available modules against real processes.
• Data: examine quality, rights, history, export and migration.
• Agents: review exposed tools, approvals and activity logs.
• Economics: compare total cost with the current system and alternatives over a defined period.

A company-level fee may make the Junyr cost item easier to forecast, while the quotation should identify the variables that remain across the wider system.

• Users or entities covered.
• Included credits, modules, storage, support and maintenance.
• Separately charged integration, migration and configuration services.
• Costs of models and third-party services selected by the customer.

---

What the company should verify in the product

The positioning describes a structured foundation connected through MCP to management functions and assistants, but a decision should rest on the scope delivered today rather than on a future vision.

• Request a demonstration of priority processes with realistic roles and permissions.
• Confirm the modules, integrations, voice features or agents included in the proposed edition.
• Examine data-migration quality and matching rules.
• Obtain the hosting, backup, support and reversibility arrangements.

Capabilities announced for future agent-to-agent exchanges, post-quantum security or new interface modes belong to a roadmap until an available scope and technical evidence are published.

• Separate production, pilot and planned features.
• Define acceptance criteria before deployment.
• Put material commitments in the contract and its schedules.

Read the scope of a Junyr offer precisely

The useful proposition lies in combining the business foundation, MCP interface and support, provided that the commercial offer describes every component and the selected use cases are tested.

• The platform supplies the modules and access mechanisms included in the subscribed edition.
• Third-party assistants remain subject to their own accounts, terms, limits and costs.
• Human services cover only the migration, configuration or support stated in the quotation.
• Security, approval and operational responsibilities are allocated explicitly between the parties.

---

Start with a 30-minute assessment

Junyr’s published AI maturity audit is a free, no-commitment video call providing an initial position before any decision about training, consulting support or adopting Junyr Suite [6].

• Place the organisation on the Junyr Scale™.
• Identify the main blocker to the next level.
• Select the first project that makes sense in the observed context.
• Receive a one-page follow-up after the session.

Book the 30-minute AI maturity audit.

Continue the assessment

These resources extend the assessment across FinOps, agent governance and control of infrastructure.

• Token budgets and AI APIs: the FinOps guide for SMEs: build and monitor a usage budget.
• Junyr Agents™: delegating AI in your SME without losing control: define mandates, approvals and logs.
• The “All-Cloud” is dead: 5 risks that make strategic On-Premise essential: examine hosting and confidentiality options.

---

Junyr is a platform published within the Croissance & Transitions ecosystem.

Sources consulted on 6 September 2026

[1] Model Context Protocol, Introduction, official documentation. URL: https://modelcontextprotocol.io/docs/getting-started/intro; it defines MCP as an open standard connecting AI applications to external systems through capabilities including tools and resources.

[2] Anthropic, I subscribe to a paid Claude.ai plan. Why do I have to pay separately for API usage on Console?, official help article. URL: https://support.anthropic.com/en/articles/9876003-i-subscribe-to-a-paid-claude-ai-plan-why-do-i-have-to-pay-separately-for-api-usage-on-console; Claude.ai subscriptions and the Console API are separate products.

[3] Anthropic, Claude API pricing, official documentation. URL: https://platform.claude.com/docs/en/about-claude/pricing; prices vary by model and token type.

[4] OpenAI, API Pricing, official documentation. URL: https://developers.openai.com/api/docs/pricing; usage prices for API models and services.

[5] Google, Gemini Developer API pricing, official documentation. URL: https://ai.google.dev/gemini-api/docs/pricing; prices and tiers for the Gemini API.

[6] Junyr, Audit de maturité IA — 30 minutes. URL: https://junyr.eu/en/site/audit; the audit’s format, duration, deliverable and no-commitment terms.

[7] Croissance et Transitions, Mentions légales & identité de l’éditeur. URL: https://junyr.eu/fr/site/mentions-legales; Junyr Suite’s public positioning as an independent, sovereign tool hosted in Europe.

Article written by Paul-Antoine TUAL, AI Transformation Leader, creator of the Junyr Method™.