Tag: MCP Server

  • Power Apps MCP Server Now Has Closed-Loop Learning Capabilities

    Power Apps MCP Server Now Has Closed-Loop Learning Capabilities

    Power Apps MCP server closed-loop learning diagram for enterprise agents

    Microsoft dropped the June 2026 Power Platform feature update on June 11, and the headline for me is Power Apps MCP server closed-loop learning for enterprise agents. Not a UX refresh. Not another connector. A real change in how agents get better after you ship them.

    The rest of the update is worth reading too, but this is the one I want to test against a real internal agent this week.

    What shipped on June 11

    The Power Apps MCP server now supports closed-loop learning. In practice that means the agent can adjust its grounding and skill selection based on how it is actually being used, without a developer manually rewriting prompts or retraining anything.

    Before this, teaching an agent your org meant one of two paths. Either you fed it documents and custom instructions and hoped the retrieval was good enough, or you stood up a data science workflow to run evaluation and optimization cycles yourself. Both paths break down at maintenance time. Docs go stale. Nobody wants to rerun eval jobs every quarter.

    Closed-loop learning changes the shape of that problem. Outcome signals from real usage flow back into the agent’s behavior at runtime.

    What Power Apps MCP server closed-loop learning actually does

    To be precise about what is and is not happening here: the underlying model is not being fine-tuned. What is being updated is the agent’s grounding layer and its skill selection policy, based on outcome data that lands in Dataverse.

    I wrote about this separation before in my post on the MCP server as the feedback layer. Skills are the policy layer. The MCP server signals are the feedback layer. Keep those two straight and the mental model holds up.

    The technical surface, as far as I can read from the docs and the Power Platform learn pages, looks like this. When a user interacts with the agent, outcomes get captured. Not just accept or reject clicks, but structured signals about what worked and what did not. Those signals feed a learning loop that updates how the agent grounds itself and which skills it reaches for in a given context. The Dataverse MCP server tool shape update that split metadata inspection, querying, and search into cleaner boundaries is part of what makes this grounding layer more precise.

    That is closer to how a good colleague gets better at their job than how a model gets fine-tuned. Which is the point.

    Why this changes the agent maintenance story

    Most internal agents I see, and most I hear about from people at other organisations, are frozen at deploy time. They make the same mistake in month four that they made in week one, until someone finally opens a ticket and a developer patches the prompt. That is not maintenance. That is triage. It is also exactly the kind of failure pattern I covered in why AI agents fail in production when they worked fine in testing.

    Closed-loop learning breaks that pattern if you set it up carefully. The agent adapts to how the process actually runs, not how the process was documented eighteen months ago when the SOP was last updated. Process drift stops being invisible.

    The trade-off is real though. Runtime learning means the audit story gets harder. Version history now has to cover learned behavior, not just authored skills. If a policy owner asks why the agent behaved differently in July than it did in May, someone has to be able to answer that from data, not from memory. Microsoft has not fully answered that governance question yet, and I want to see how the audit surface actually looks in a live environment.

    The other risk is signal quality. If your team treats every user click as positive feedback, you are teaching the agent that fatigue clicks and correct clicks mean the same thing. They do not. The learning loop is only as good as the signals you decide to trust.

    What I would do with it this week

    I have an internal agent in mind that has been quietly degrading for a few months. Not broken, just noticeably less useful than at launch. Perfect candidate.

    The plan looks like this. First, turn on closed-loop learning in a non-production copy and run it against a shadow traffic sample for a few days. Second, define the outcome signals I actually trust ahead of time, before I look at any data. Accept-without-edit is one signal. Accept-with-edit is another and it means something different. Explicit thumbs down is the cleanest. Fatigue clicks I want to filter out entirely.

    Third, set a review cadence. Not because I do not trust the loop, but because I want to see what it learns and whether the changes match the policy the skill owner would have made themselves. Having a clear way to measure whether the agent is actually improving is where a framework like measuring useful work per dollar for Power Platform AI agents becomes useful alongside the learning loop.

    If the learned behavior lines up with what a human policy owner would do, the loop is doing its job. If it drifts somewhere I did not expect, that is the interesting part.

    This is the first update in a while where I closed the browser tab and immediately opened a new one to start planning a test. I cannot wait to see how it holds up on a real workload.

    Source: What’s new in Power Platform: June 2026 feature update (Microsoft Power Platform Blog).

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

  • Dataverse MCP Server Got a New Tool Shape and the Metadata Inspection Story Is What Stands Out

    Dataverse MCP Server Got a New Tool Shape and the Metadata Inspection Story Is What Stands Out

    Dataverse MCP server tool shape diagram showing metadata inspection and query tools

    Microsoft published a new post on June 8, 2026 walking through the updated Dataverse MCP server tool shape. The headline is that agents can now inspect metadata, query records, and search across structured and unstructured data through cleaner, well-defined tool boundaries. You can read the original write-up on the Power Platform blog.

    This is not a feature dump. It is a redesign of how the agent talks to Dataverse. And that is more interesting than it sounds.

    What it actually does

    The old tool surface gave agents a handful of broad tools and expected them to figure out the rest from context. In practice, that meant the agent would call a query tool, get back something it could not interpret, call again with different parameters, fail, and burn tokens guessing at column logical names. I have watched this happen in traces. It is not pretty.

    The new shape breaks the surface into clearer categories. Metadata inspection is its own thing now. The agent can ask what tables exist, what columns a table has, what the relationships look like, before it tries to query anything. Record querying sits next to that with predictable inputs. Search across structured and unstructured data is its own tool boundary, so the agent does not have to invent a strategy for whether to hit the relational side or the knowledge side.

    The practical effect: fewer wasted tool calls, less prompt bloat from stuffing schema hints into the system prompt, and more predictable agent behavior when it hits a Dataverse environment cold.

    Why it matters

    This connects directly to a pattern I keep hitting. When you wire an agent to business data, the model is rarely the problem. The friction is the discovery loop. The agent does not know your schema. It does not know your naming conventions. It does not know that your account table has a custom column called cr1a3_segment that nobody documented.

    The old answer was to dump schema into the system prompt. That works until your prompt crosses a few hundred tokens and agent reliability starts degrading. I wrote about this in the context of business skills in Dataverse, and the same logic applies here. Pushing knowledge into a managed, queryable surface beats stuffing it into a prompt every time.

    The new tool shape gives the agent a path to discover the schema on demand instead of carrying it around. That is the architectural shift. It is the same lesson I keep seeing play out across the agent stack: tighter tool boundaries beat broader ones, because they shrink the search space the model has to reason about.

    It also pairs well with the low-latency Dataverse to Fabric sync story. If your agent can inspect metadata cleanly on the operational side and pull near real-time analytical data on the Fabric side, the data path behind the agent finally starts feeling coherent instead of stitched together.

    What I am skeptical about: tool shape changes are easy to undo if the team gets feedback that agents want more flexibility. I hope Microsoft holds the line on the boundaries. Broad, do-everything tools are how you end up back where you started.

    What I would do with it this week

    First, point an agent at a non-production Dataverse environment with the updated MCP server and watch the tool call traces. Not the chat output. The traces. That is where you see whether the new shape actually reduces wasted calls or just renames them.

    Second, strip schema hints out of system prompts on any existing Copilot Studio agent wired to Dataverse, and let the metadata inspection tool do the work. Compare reliability before and after. I expect the shorter prompt wins, based on what I have seen building internally and on what I keep reading from peers at other organisations. The Dataverse plugin for coding agents that Microsoft shipped at Build 2026 is worth reading alongside this, because it tackles the same hallucination-from-missing-schema problem from a different angle. You can also check the Power Platform docs for the current setup steps.

    Third, write down which tool should handle which question type for your agent and treat that as a contract. If the agent starts calling the search tool for things that should hit the query tool, that is a sign your boundary is wrong, not that the tool is wrong. I have been writing about these patterns on LinkedIn for a while now, and the discipline of writing the contract down before deployment saves you a month-six cleanup project.

    If the new tool shape holds up under real workloads, this becomes the default way agents talk to business data on the Microsoft stack.

    Source: Dataverse MCP Server: Understanding the New Tool Shape (Microsoft Power Platform Blog).

    About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn