Skip to main content

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.

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

Public Agent & MCP Launch

The MCP server is hosted and reachable, sign-in runs through Entra, each data connection is scoped to what the agent needs, evaluation and telemetry record what it does, and the documentation a listing requires is written and ready to submit.

No access to your tenant (your Microsoft 365 environment), no credentials, and no sensitive files are requested through this website.

One agent, one hosted serverEntra sign-in, not a shared keyYou own the model and its behavior

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

What is going wrong

The agent itself works when somebody runs it. What does not exist is everything around it. There is nowhere it is hosted that stays up, no sign-in path an enterprise security review would accept, no record of what it returned or how well it did, and none of the documentation a catalog asks for before it will list anything. Each of those is a different specialism, and none of them is the thing the team that built the agent set out to build.

Signs you can check yourself

  • 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

Sources: Microsoft: connect your agent to an existing MCP server, Microsoft: create a new MCP server

What waiting affects

  • 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.

What AZ changes

Not findings. These are the things that are different afterwards.

  1. 1The MCP server is built and hosted somewhere it stays up, rather than on a laptop or a personal subscription.
  2. 2Your 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.
  3. 3Sign-in goes through Entra using OAuth, so the agent answers as the person asking rather than as itself.
  4. 4It is wired into Copilot Studio or Microsoft Foundry, whichever the business is standardizing on, with generative orchestration switched on as that path requires.
  5. 5Evaluation and telemetry are turned on against an agreed test set, so what the agent returns can be measured rather than assumed.
  6. 6The documentation a public listing or certification asks for is written, and the submission is prepared for you to send.

How you know the job is finished

The engagement ends when all of these are true and demonstrable.

  • The MCP server is reachable at its agreed address and comes back after a restart
  • A test user signs in through Entra 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

What moves the price

The figure comes from what is actually in the environment. Headcount is one input among several, and rarely the one that matters most.

  • 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

You may not need this engagement

  • 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

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.

The full scope

Everything this engagement commits to, in detail. None of it is a surprise on the last day.

What is not included

Stated so the scope means the same thing to both sides on the last day as it did on the first.

  • 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 you provide

Named up front, because these are the things that stall an engagement when nobody owns them.

  • 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
How changes are made, and how they are undone

Work on live systems carries risk. This is the method, not a reassurance.

  • 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 get at the end

Yours to keep whatever happens next, including handing it to your own team or another provider.

  • 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
The questions a careful buyer should ask

Does this work with Copilot Studio, or only with Foundry?

Both. Copilot Studio connects an agent to an existing MCP server through its own onboarding, and supports OAuth 2.0 as an authentication type, which is what makes an Entra sign-in path possible. It also requires generative orchestration to be turned on. Foundry is the alternative where the business is standardizing there instead. The choice is made on what you already run, not on preference.

What stops the agent returning something the person asking should not see?

Two things, and they are checked rather than assumed. Sign-in runs through Entra so the agent acts as the person asking rather than as itself, and every data connection is scoped to what it needs and listed with the permission it was given. The completion test is a real test user signing in and getting back only what that account could already reach.

Can you guarantee the listing gets approved?

No, and anyone who says otherwise is selling you something they do not control. The submission is prepared to the published requirements and the documentation is complete. The decision belongs to the reviewer.

Plan the Agent Launch

Describe what is happening, what has to be working differently, and any deadline behind it. A reply comes within one business day with the most direct next step, or a clear answer that AZ Innovations is not the right fit.

Plan the Agent Launch →