Tag: AI Coding Agents

  • Microsoft Ships the Dataverse Plugin to OpenAI’s Codex Marketplace

    Microsoft Ships the Dataverse Plugin to OpenAI’s Codex Marketplace

    Dataverse plugin Codex marketplace expansion showing a coding agent querying live schema

    On 28 July 2026, Microsoft shipped the Dataverse plugin for coding agents to the OpenAI and Codex marketplaces. The announcement is short, but the Dataverse plugin Codex marketplace expansion means any agent built on OpenAI’s coding stack can now query live Dataverse schema, table metadata, and real data instead of guessing column names from two-year-old tutorial content in its training set.

    I wrote about the Cursor marketplace drop when it happened. That felt like a test balloon. This is the follow-through, and it tells you something about where Microsoft thinks the moat actually sits.

    What a Codex Agent Gets: Live Schema, Metadata, and Query Tools

    The plugin gives a Codex-based agent the same tool surface the Copilot and Cursor versions get. It can list tables in a connected environment, inspect column logical names, walk relationships, read option set values, and run queries against real records. That sounds mundane until you have watched a coding agent confidently generate a plugin against new_customer_id when the actual column is cr7a2_customerid. Without live metadata, the output looks correct and fails on deploy. With it, the code is diffable against reality.

    The hallucination problem I described when the plugin first shipped was never a model quality problem. It was a missing context layer at build time. Codex agents had no sanctioned way to see your schema, so they interpolated from public tutorials. This closes that gap for anyone whose org standardized on OpenAI’s tooling.

    The Codex Marketplace Expansion Signals Dataverse Is the Moat

    Think about what Microsoft is doing here. They are distributing a first-party grounding tool into a direct competitor’s agent ecosystem. GitHub Copilot competes with Codex. Microsoft shipped there anyway.

    That only makes sense if you believe the coding assistant is interchangeable and the data platform is not. Microsoft is betting that developers will switch agents every eighteen months but their organisations will keep business data in Dataverse for a decade. Agent-neutral distribution is the correct call under that assumption. Cursor was proof of concept. OpenAI and Codex confirm the pattern: follow the developers, do not try to pull them back into VS Code.

    There is a quieter governance win too. Developers were already wiring community MCP servers from random GitHub repos into their agents, and platform teams had zero visibility into any of it. A first-party plugin installed from a known marketplace leaves an auditable trail. That matters more inside a large enterprise than any individual feature. If you want to understand the protocol underneath tools like this, How MCP Actually Works Under the Hood When an Agent Calls a Tool walks through the JSON-RPC handshake and capability negotiation in detail.

    Pro-Code Teams on Non-Microsoft Agents Are the Real Audience

    This is not a citizen dev feature. The audience is teams writing Dataverse plugins, custom APIs, PCF controls, and complex flows in source control, whose org happened to standardize on OpenAI’s agent stack instead of GitHub Copilot. Those teams were previously stuck choosing between an ungrounded agent or an unsanctioned community tool. Now they get the first-party path without changing editors.

    Two honest caveats. First, the setup mistake I keep seeing has not gone away: people connect the plugin with System Administrator credentials pointed at production. The sane configuration is still a dedicated app user with a least-privilege role scoped to a dev environment. The marketplace install being one click makes the lazy setup faster too.

    Second, this closes the hallucination gap and nothing else. Environment permissions, DLP policies, and security roles behave exactly as they did before. The plugin does not grant the agent any access your app user does not have, and it does not stop you from misconfiguring that app user. In my experience, the teams that get burned are the ones who treat schema grounding as a security boundary. It is not. It is a correctness tool. Schema grounding also sits inside a broader cost and measurement story — The Model Is the Cheapest Part of Every Enterprise AI Agent makes the case that grounding data and connector governance are where the real budget and hours go.

    If your team builds against Dataverse from Codex today, install this and you get real hallucination reduction on schema-dependent code. If your governance story is not sorted, you also get one more thing to register and scope. Both are true.

    The coding agents will keep changing names. The platforms that ship their grounding everywhere are the ones planning to still be here when they do.

    Source: Dataverse Plugin for Coding Agents: OpenAI and Codex Marketplace Expansion (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 Plugin for Coding Agents Now Available on OpenAI and Codex Marketplaces

    Dataverse Plugin for Coding Agents Now Available on OpenAI and Codex Marketplaces

    Dataverse plugin OpenAI Codex marketplace expansion for coding agents

    Microsoft shipped the Dataverse plugin for coding agents to OpenAI and Codex marketplaces on July 28, 2026. Same plugin story we saw hit Cursor a few weeks back. The dataverse plugin openai codex marketplace expansion is the interesting signal here, not the individual drop.

    If you write Dataverse code with a coding agent, the excuse for hallucinated table and column names is gone. I want to wire this into a real internal repo this week.

    What actually shipped

    The Dataverse plugin is now installable directly from the OpenAI and Codex marketplaces. Single-click install, same as the Cursor drop earlier this month. The plugin itself is unchanged in behavior. It grounds the coding agent in live environment metadata so the model queries your actual column logical names like cr123_customerid instead of guessing based on tutorial data from training.

    Setup story is also unchanged. You point the plugin at a Dataverse environment through an app user with a scoped security role. Not System Administrator. Not production. A dedicated app user in a dev environment with least privilege. Same rule I have been repeating since the first drop.

    What is new is the reach. The plugin now lives inside three of the coding agent surfaces where pro devs actually work. Cursor, OpenAI, and Codex. That covers a real slice of the market I see on LinkedIn when people share their editor screenshots.

    Why this expansion matters more than the Cursor drop did

    The Cursor drop was the proof of concept. It showed Microsoft was willing to follow developers out of VS Code and the maker studio into competing tools. Fine. Interesting signal.

    This expansion is the follow-through. And follow-through is what tells you whether a strategy is real or a one-off gesture.

    Three marketplaces in a few weeks means Microsoft is treating the coding agent surface as a distribution channel, not a partnership. That changes the math for platform teams. When developers install Dataverse tooling from a first-party plugin in a known marketplace, you have an auditable trail. When they pull an MCP server from a random GitHub repo, you have nothing. Marketplace distribution is a governance win before it is a productivity win. The Dataverse July 2026 update actually spells out exactly where Microsoft is taking this with certified partner MCPs and enterprise MCP governance, which is worth reading alongside this drop.

    The second thing this signals is that the pro-code path into Dataverse is now considered permanent strategy. Not a side project. Not a preview experiment. Microsoft is investing in meeting devs where they already work, and that pulls the low/no-code and pro-code stories closer together than they have been in years.

    The third thing, and the one I care about most, is that hallucinated schema is officially not an acceptable failure mode anymore. If you have a coding agent generating Dataverse code and it is still inventing column names, that is a tooling choice now, not a limitation. The grounding layer exists in the tools you already use.

    What I would wire up this week

    I have a plugin project sitting in a dev environment that I want to point this at. Here is the plan.

    First, spin up a dedicated app user in the dev environment with a scoped security role. Read on the tables the plugin project actually touches. Nothing more. This is the part most people skip and regret later when the audit conversation starts.

    Second, install the plugin from the OpenAI marketplace into my coding agent. Point it at the dev environment. Verify it can read metadata. Confirm it cannot see production.

    Third, take an existing plugin file with real custom table references and ask the agent to extend it. The test is not whether the code compiles. The test is whether the generated code uses the actual logical names from my environment or hallucinates something plausible. If it grounds correctly, this becomes part of my normal flow. If it drifts, I want to know exactly where. The failure modes I am watching for here are the same ones I covered in Why Do AI Agents Fail in Production When They Worked Fine in Testing, and schema drift is near the top of that list.

    Fourth, run the same prompt against a Codex install to see if there is any behavior difference across the two marketplaces. My guess is no. The plugin is the same. But I want to confirm.

    The bigger question I am sitting with is what happens when every coding agent has grounded access to your Dataverse schema. The Power Platform pro-dev story has been fragmented for years. If the plugin holds up across three marketplaces, that fragmentation starts to close.

    I will report back on what breaks.

    Source: Dataverse Plugin for Coding Agents: OpenAI and Codex Marketplace Expansion (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 Plugin for Coding Agents Is Now in the Cursor Marketplace

    Dataverse Plugin for Coding Agents Is Now in the Cursor Marketplace

    Dataverse plugin cursor marketplace listing shown inside the Cursor editor

    Microsoft shipped the Dataverse plugin for coding agents to the Cursor Marketplace on July 21. That is the dataverse plugin cursor marketplace listing I have been waiting for since the plugin first landed for GitHub Copilot. Cursor is where a lot of developers I talk to actually spend their day, and now they can query, generate, and reason about Dataverse from inside that editor without switching windows.

    I am going to install this today. Here is what it does, why the distribution channel matters more than the feature list, and what I am pointing it at this week.

    What the dataverse plugin cursor marketplace listing actually does

    The plugin exposes Dataverse to Cursor’s agent as a tool surface. It reads live metadata from a connected environment, so when you ask the agent to generate a plugin, a custom API, a PCF control, or a complex Power Automate expression, it grounds the output in the actual table schema, column logical names, and relationships that exist in your target environment.

    That is the same grounding story I wrote about when the plugin first landed for coding agents. The model is not guessing at new_customerid versus cr123_customerid based on training data from tutorials. It is querying your environment and diffing against what is really there.

    Practically, in Cursor that means:

    • Ask the agent to scaffold a plugin registration and it uses your real entity metadata.
    • Ask it to write a fetchXML query and it validates against columns that exist.
    • Ask it to generate a TypeScript client for a custom API and the signatures match your published definitions.

    You connect it with an app user in a dev environment. Not System Administrator on prod. That was the wrong setup for the Copilot version and it is still the wrong setup here.

    Why the Cursor Marketplace channel matters

    The feature itself is not new. The distribution is. Microsoft meeting developers inside Cursor is a signal, and I think it is the more interesting story than the plugin capabilities.

    Cursor is not a Microsoft product. Two years ago I would not have expected the Power Platform team to ship a first-party plugin into a competing editor’s marketplace. That they did says the pro-code path into Dataverse is now considered strategic enough to follow developers wherever they already are, rather than trying to pull them back into VS Code or the maker studio.

    Marketplace distribution also changes the adoption math. Installing a plugin from a marketplace with a single click is a completely different friction curve than cloning a repo, running a setup script, and fighting with auth. I have watched pro devs skip the Dataverse story entirely because the tooling did not meet them where they work. This removes that excuse.

    There is a governance angle too. When your devs are pulling MCP-style tools from random community repos, your platform team has no view into what is connected. A first-party plugin in a known marketplace is auditable. It is the same trust-signal argument I made about certified MCPs in the July Dataverse update, just applied to the coding surface instead of the runtime surface.

    What I would do with it this week

    I have a dev environment with a solution I have been slowly refactoring. Custom tables, a few plugins, one custom API that needs a proper TypeScript client, and a PCF control that is still half-configured. That is my test bed.

    My plan for the week:

    • Install the plugin from the Cursor Marketplace and connect a least-privilege app user scoped only to the dev environment.
    • Point Cursor’s agent at the custom API and have it generate a typed client. Diff the output against what I would have written by hand.
    • Ask it to write a plugin that reacts to a specific message on a custom table and check whether it correctly uses my column logical names, not invented ones.
    • Try a deliberately ambiguous prompt (“add validation to the account form”) and see whether it grounds the answer in real metadata or hallucinates a JavaScript path.
    • Compare the same prompts side by side in Cursor and in the GitHub Copilot version to see if the tool responses diverge. The new Dataverse MCP server tool shape splits metadata inspection and querying into cleaner boundaries, so I am curious whether that distinction surfaces differently across editors.

    I will write up what I find. My prior from building things internally is that grounding fixes maybe 70 percent of the hallucination problem on Dataverse code, and the remaining 30 percent is prompt discipline and knowing when to stop trusting the agent. Curious to see whether Cursor’s agent loop changes that ratio in either direction. If you want a framework for thinking about where that remaining cost lands, the useful work per dollar measurement approach I laid out for Power Platform agents applies here too.

    If you live in Cursor, install it today and try it against a real solution, not a demo one.

    Source: Dataverse Plugin for Coding Agents Now Available in Cursor Marketplace (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