Public agent and MCP server launch

Move your agent from a demo to something customers can actually use.

Host the MCP server, configure sign-in so every user connects with their own account, and limit each data connection to the agreed scope. Test the agent, record its activity and prepare the required listing documentation. Submission and platform approval remain separate.

What you get: A configured MCP service with scoped connections, authorization tests, evaluation records and operating documentation.
How it starts: A free scope call. The price is fixed in writing before anyone is given access.
When it is done: Agreed access and tool tests pass and the handover is complete. Marketplace submission does not guarantee platform approval.

Price the agent launch Review scope & terms

Illustrative sample · constructed example

The tool must check whose data the request can reach.

Constructed tool request · project lookup

Selected check

Does a request for an unrelated project return data?

Agent tools / authorization testsIllustrative

Constructed tool request · project lookup

PILOT CONTEXTCaller identityThe signed-in user has an agreed project permission.

RELATED CONTROL / ACTORTool boundaryRequest validation checks identity, scope and requested action.

SEPARATE CHECKActivity recordAllowed and denied requests keep a safe trace reference.

Deny the request. Results apply to the named sample checks below.

Agent tools / authorization tests: constructed inspection record
Test case	Expected behavior	Sample review
Signed-in caller	Establish the identity used for this request.	Sample caller identified
Unrelated project	Return no project content outside the approved scope.	Request denied
Authorized project	Return only the read permitted for that caller.	Not the selected request
Write operation	Require its own authorization and approval rule.	No write authorized

Constructed requests, no live data. Sign-in alone does not establish authorization at every downstream system.

Reference guidance: connecting an agent to an MCP server (Copilot Studio docs)

Evidence: Sample caller requests a project outside the approved access scope.
Decision: Deny the request
Next action: Return a bounded error and record the denial without exposing project content.

Illustrative sample with no live data. Launch does not imply marketplace approval, identity delegation or unrestricted tool access.

Why now

The work starts here.

The agent works in a demo, and now it has to be reachable by customers: hosted, signed in to, connected to real data, and ready to list.

Scope at a glance

One agent, one hosted server
Per-user sign-in, not a shared key
You own the model and its behavior

If nobody acts

What waiting costs

An agent that only runs in a demo cannot be sold, so the work already spent building it returns nothing until the hosting, the sign-in and the documentation exist.
Enterprise buyers ask the security questions before the commercial ones. With no sign-in path and nothing written down about how data is reached, the conversation can end before price is discussed.
Catalog and certification routes carry their own requirements and their own queues. Starting them late can add weeks, and those weeks land after the date somebody already promised a customer.
An agent connected to business data without an identity boundary can return whatever the connection can reach, rather than what the person asking is entitled to see.

Check your own environment

Sounds like you?

It runs from one machine, or from one account, and stops when that machine does
It authenticates with a key that everyone on the team shares
Nobody can say what data it could reach if somebody asked it the right question

Save yourself the call

Not for you if

The agent is internal only and will never leave your own tenant
You already have a platform team hosting MCP servers and a sign-in pattern they apply
What the agent does is still changing every week and has not settled

The work

What is different when we hand over

The MCP server is built and hosted somewhere it stays up, rather than on a laptop or a personal subscription.
Your APIs and business data are connected through it, and each connection is scoped to what the agent actually needs rather than to everything it could reach.
Sign-in uses OAuth, with Microsoft Entra ID as the identity provider, so the agent answers as the person asking rather than as itself.
It is connected to the agent platform the business is standardizing on (Copilot Studio or Microsoft Foundry). Generative orchestration is switched on where that platform requires it.
Evaluation and telemetry are turned on against an agreed test set, so what the agent returns can be measured rather than assumed.
The documentation a public listing or certification asks for is written, and the submission is prepared for you to send.

Acceptance

Checks before handover

Done when a test user signs in with their own account, the agent returns only what that account could already reach, and the listing submission is ready to send.

The MCP server is reachable at its agreed address and comes back after a restart
A test user signs in with their own account and the agent returns only what that user could already reach
Every connected API and data source is listed with the permission it was granted
Evaluation runs produce a recorded score against the agreed test set
The documentation pack is complete and the listing submission is ready for you to send

A fair question

Can we not just host it ourselves? It is only a server.

Often yes, and where a platform team is already doing it that is the right answer. Hosting is not the part that takes the time. The sign-in path an enterprise security review will accept, scoping each data connection so the agent cannot reach past the person asking, and the documentation a catalog wants before it will list anything are the parts that come back as questions weeks later if they were skipped.

Price and calendar

Scope, price and project calendar

Engagement price

Price fixed after a short scope call.

The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:

What determines the scope

How many APIs and data sources the agent connects to
Whether it is going into a public catalog or staying inside your own tenant
How much of the evaluation and telemetry has to be built rather than switched on
Whether the hosting has to meet a customer requirement about where it runs
How much of the security documentation already exists

Delivery calendar

The proposal names the start date, the change windows and the completion date before anything is agreed.

How engagements work

Scope & responsibilities

What is and is not included

The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.

Exclusions

Building, training or tuning the model itself
Writing the agent prompts or deciding how it should behave
Any promise that a catalog or certification review will approve the listing, which is the reviewer decision and not one AZ can make
Running the server after handover, unless that is agreed separately

What we need from you

Own the agent behavior, the prompts and the model choice
Provide the APIs and data the agent connects to, and say who may reach each one
Name the person who approves the security position before anything is published
Provide the tenant and the licensing the hosting and sign-in require

Change and rollback method

The server runs somewhere non-production first, and the sign-in path is tested with a real account before anything is published.
Data connections are added one at a time, and what each one can reach is checked before the next is added.
Nothing is submitted to a public catalog until the documentation and the security position have been approved on your side.

What you keep at handover

A System guide: the configuration as delivered, the checks that were run and the unresolved list
The hosted MCP server and its configuration, written down
The connection list, with the permission granted to each one
The sign-in test results, per test account
The evaluation scores against the agreed test set
The documentation pack, ready to submit

Access, acceptance and support arrangements

How you know the work is good

Judge it by what you can inspect.

The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.

How a project runs: A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.
How we work
What is checked: Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.
See sample deliverables
What you keep: A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.

Next step

Start with a free scope call.

Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.

Price the agent launch

Or write to info@azinnovations.io