<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Obot AI</title>
    <description>The latest articles on DEV Community by Obot AI (@obot_ai).</description>
    <link>https://dev.to/obot_ai</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3954698%2F868082a1-4259-4ada-8e83-e552c0d5d063.png</url>
      <title>DEV Community: Obot AI</title>
      <link>https://dev.to/obot_ai</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/obot_ai"/>
    <language>en</language>
    <item>
      <title>The Client Zoo Problem: Why Enterprise AI Needs Central Skills Management</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Thu, 11 Jun 2026 19:53:14 +0000</pubDate>
      <link>https://dev.to/obot_ai/the-client-zoo-problem-why-enterprise-ai-needs-central-skills-management-cf2</link>
      <guid>https://dev.to/obot_ai/the-client-zoo-problem-why-enterprise-ai-needs-central-skills-management-cf2</guid>
      <description>&lt;p&gt;&lt;em&gt;By Bill Maxwell, Solutions Architect - &lt;a href="https://obot.ai" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Your support team built a great "triage a ticket" skill for Claude Code. It took weeks to get right. Meanwhile your sales engineers — working in Cursor — built the same skill from scratch last month. Theirs isn't as good, and neither team knows the other's exists.&lt;/p&gt;

&lt;p&gt;This is where a lot of enterprise AI adoption has quietly landed. Multiple AI clients, duplicated workflows, no shared knowledge, no governance. The problem isn't that teams are using different tools — it's that reusable enterprise knowledge keeps getting trapped inside them.&lt;/p&gt;

&lt;p&gt;This post breaks down why central skills management is the missing piece, and what it actually looks like to govern and distribute AI skills across an organization.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Originally published on &lt;a href="https://obot.ai/blog/the-client-zoo-problem-why-enterprise-ai-needs-central-skills-management/" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>devtools</category>
      <category>productivity</category>
    </item>
    <item>
      <title>How to Build and Publish a Skill Your Whole Team Can Use</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Fri, 05 Jun 2026 13:42:00 +0000</pubDate>
      <link>https://dev.to/obot_ai/how-to-build-and-publish-a-skill-your-whole-team-can-use-2coe</link>
      <guid>https://dev.to/obot_ai/how-to-build-and-publish-a-skill-your-whole-team-can-use-2coe</guid>
      <description>&lt;p&gt;&lt;em&gt;By Craig Jellick, &lt;a href="https://obot.ai/" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;MCP servers get a lot of attention, but skills are where a lot of the day-to-day value lives for teams using AI agents. The problem is that most teams build skills in silos — one developer writes something useful, it lives on their machine, and nobody else benefits from it.&lt;/p&gt;

&lt;p&gt;This tutorial walks through how to build a skill, publish it to a centrally managed catalog with Git-based versioning and access controls, and make it installable across any AI client your team uses — Cursor, Claude Desktop, Copilot, and more.&lt;/p&gt;

&lt;p&gt;If you've been building with Obot or just exploring what centrally managed AI skills actually look like in practice, this is a good hands-on starting point.&lt;/p&gt;

&lt;p&gt;📓 &lt;a href="https://obot.ai/blog/how-to-build-and-publish-a-skill-your-whole-team-can-use/" rel="noopener noreferrer"&gt;Full tutorial&lt;/a&gt; · 🐙 &lt;a href="https://github.com/obot-platform/obot" rel="noopener noreferrer"&gt;GitHub&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Originally published on &lt;a href="https://obot.ai/blog/how-to-build-and-publish-a-skill-your-whole-team-can-use/" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>tutorial</category>
      <category>devtools</category>
      <category>opensource</category>
    </item>
    <item>
      <title>Who's Managing Your Team's AI Client Sprawl?</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Wed, 03 Jun 2026 17:04:37 +0000</pubDate>
      <link>https://dev.to/obot_ai/whos-managing-your-teams-ai-client-sprawl-17mk</link>
      <guid>https://dev.to/obot_ai/whos-managing-your-teams-ai-client-sprawl-17mk</guid>
      <description>&lt;p&gt;Something we keep running into in conversations with engineering and security teams: nobody really knows what AI clients and MCP servers are running on their developers' machines.&lt;/p&gt;

&lt;p&gt;It's not negligence — it happened fast. Six months ago it was one or two tools. Now it's Cursor, Claude Desktop, Copilot, Windsurf, and a handful of MCP servers someone installed from a GitHub README. Each with its own config, its own credentials, nobody with a full picture.&lt;/p&gt;

&lt;p&gt;We've been thinking hard about this problem at Obot AI and it's part of what drove our latest release. But we're curious where others are at — is fleet-wide visibility into AI clients and MCP servers on your radar yet, or is your team still figuring out more basic AI tooling questions first?&lt;/p&gt;

</description>
      <category>discuss</category>
      <category>mcp</category>
      <category>ai</category>
    </item>
    <item>
      <title>Obot Platform v0.22.0: Centrally Managed Skills, Fleet Scanning &amp; Enterprise Controls</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Wed, 03 Jun 2026 15:18:00 +0000</pubDate>
      <link>https://dev.to/obot_ai/obot-platform-v0220-centrally-managed-skills-fleet-scanning-enterprise-controls-4de0</link>
      <guid>https://dev.to/obot_ai/obot-platform-v0220-centrally-managed-skills-fleet-scanning-enterprise-controls-4de0</guid>
      <description>&lt;p&gt;&lt;em&gt;From the &lt;a href="https://obot.ai/?utm_source=website&amp;amp;utm_medium=post&amp;amp;utm_campaign=dev.to"&gt;Obot AI&lt;/a&gt; team&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;We've been building Obot as an MCP Gateway from the start. v0.22.0 is where we go bigger.&lt;/p&gt;

&lt;p&gt;The problem we kept hearing from teams: the "client zoo." Developers spread across Cursor, Claude Desktop, Copilot, Windsurf — each with its own config, its own local MCP servers, its own skill definitions. No standardization. No visibility for admins. Skills getting duplicated and inconsistently authored across every team.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;v0.22.0&lt;/strong&gt;, which shipped last week, tackles that directly with three new capabilities:&lt;/p&gt;

&lt;p&gt;→ &lt;strong&gt;Centrally managed skills&lt;/strong&gt; — admins publish a curated catalog; users install to any local AI client with a single command&lt;br&gt;
→ &lt;strong&gt;Fleet scanning&lt;/strong&gt; — &lt;code&gt;obot scan&lt;/code&gt; gives you a live inventory of every AI client, MCP server, and skill running across your org&lt;br&gt;
→ &lt;strong&gt;Enterprise MCP controls&lt;/strong&gt; — managed image pull secrets, external secret integration, OAuth inspector, user-defined headers&lt;/p&gt;

&lt;p&gt;This is the beginning of a broader vision: a control plane for your entire AI tooling stack, not just MCP.&lt;/p&gt;

&lt;p&gt;📓 &lt;a href="https://obot.ai/blog/announcing-obot-platform-v0-22-0-centrally-managed-skills-fleet-scanning-and-enterprise-controls-for-mcp/?utm_source=website&amp;amp;utm_medium=post&amp;amp;utm_campaign=dev.to"&gt;Full release notes&lt;/a&gt; · 🐙 &lt;a href="https://github.com/obot-platform/obot/releases" rel="noopener noreferrer"&gt;GitHub release&lt;/a&gt;&lt;/p&gt;

</description>
      <category>mcp</category>
      <category>opensource</category>
      <category>devtools</category>
      <category>ai</category>
    </item>
    <item>
      <title>Dangerous MCP OAuth Shortcuts are Ruining Security</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Mon, 01 Jun 2026 16:31:52 +0000</pubDate>
      <link>https://dev.to/obot_ai/dangerous-mcp-oauth-shortcuts-are-ruining-security-1ded</link>
      <guid>https://dev.to/obot_ai/dangerous-mcp-oauth-shortcuts-are-ruining-security-1ded</guid>
      <description>&lt;p&gt;&lt;em&gt;By Adrian Goins, &lt;a href="https://obot.ai/?utm_source=website&amp;amp;utm_medium=post&amp;amp;utm_campaign=dev.to"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;757 MCP servers compromised. 36% scored failing grades. Zero earned an A.&lt;/p&gt;

&lt;p&gt;Those aren't projections — that's what a recent audit of real-world MCP OAuth implementations found. And the culprit isn't sophisticated attacks. It's shortcuts: client secrets hardcoded in frontend code, redirect URIs left wide open, PKCE skipped because it seemed like overkill.&lt;/p&gt;

&lt;p&gt;OAuth is well understood at this point. So why are MCP implementations getting it so consistently wrong? Adrian Goins breaks down the specific patterns that are turning OAuth from a security control into a liability — and what a secure MCP OAuth implementation actually looks like.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Originally published on &lt;a href="https://obot.ai/blog/dangerous-mcp-oauth-shortcuts-are-ruining-security/?utm_source=website&amp;amp;utm_medium=post&amp;amp;utm_campaign=dev.to"&gt;Obot AI&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>mcp</category>
      <category>appsec</category>
      <category>oauth</category>
      <category>security</category>
    </item>
    <item>
      <title>Understanding the Model Context Protocol: A Beginner's Guide</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Sat, 30 May 2026 14:08:00 +0000</pubDate>
      <link>https://dev.to/obot_ai/understanding-the-model-context-protocol-a-beginners-guide-513p</link>
      <guid>https://dev.to/obot_ai/understanding-the-model-context-protocol-a-beginners-guide-513p</guid>
      <description>&lt;p&gt;&lt;em&gt;By Stein Ove Helset, &lt;a href="https://obot.ai" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;MCP (Model Context Protocol) keeps coming up everywhere in AI right now — but a lot of the explainers out there assume you already know what it is.&lt;/p&gt;

&lt;p&gt;This guide starts from scratch. What problem did MCP actually solve? Why did AI integrations become such a fragmented mess before it existed? And how does the protocol work under the hood?&lt;/p&gt;

&lt;p&gt;If you've been nodding along in conversations about MCP without fully following along — this one's for you.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Originally published on &lt;a href="https://obot.ai/blog/understanding-the-model-context-protocol-a-beginners-guide/" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;




</description>
      <category>mcp</category>
      <category>ai</category>
      <category>webdev</category>
    </item>
    <item>
      <title>MCP Security Has Gone Mainstream</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Fri, 29 May 2026 15:48:13 +0000</pubDate>
      <link>https://dev.to/obot_ai/mcp-security-has-gone-mainstream-4jn5</link>
      <guid>https://dev.to/obot_ai/mcp-security-has-gone-mainstream-4jn5</guid>
      <description>&lt;p&gt;&lt;em&gt;By Shannon Williams, President &amp;amp; Co-founder of &lt;a href="https://obot.ai" rel="noopener noreferrer"&gt;Obot AI&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;A few days ago our outside counsel forwarded me a risk explainer on MCP from a major law firm's technology transactions group. It was the third in a series they've been running on MCP — laying out a NIST-based control framework for deploying MCP connectors in regulated enterprises.&lt;/p&gt;

&lt;p&gt;That's not a developer audience. That's general counsel, CISOs, and procurement teams.&lt;/p&gt;

&lt;p&gt;A year ago, MCP was something you explained to enterprise architects from scratch. Now the questions have shifted from "what is this" to "we already have this in production, our auditors are asking, what's the control framework."&lt;/p&gt;

&lt;p&gt;MCP security has gone mainstream — and in this post I break down what that shift actually means and the four operational controls every organization deploying MCP needs to have in place.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;Originally published on &lt;a href="https://obot.ai/blog/mcp-security-has-gone-mainstream/" rel="noopener noreferrer"&gt;obot.ai&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;

</description>
      <category>security</category>
      <category>mcp</category>
      <category>ai</category>
    </item>
    <item>
      <title>Hello from us at Obot AI!</title>
      <dc:creator>Obot AI</dc:creator>
      <pubDate>Thu, 28 May 2026 15:26:10 +0000</pubDate>
      <link>https://dev.to/obot_ai/hello-from-us-at-obot-ai-59n0</link>
      <guid>https://dev.to/obot_ai/hello-from-us-at-obot-ai-59n0</guid>
      <description>&lt;p&gt;Hey dev.to 👋&lt;/p&gt;

&lt;p&gt;We're Obot — an open-source platform built for teams that want to connect AI agents to real tools without the security and governance headaches that come with it.&lt;/p&gt;

&lt;p&gt;We started as an MCP Gateway, and #MCP is still at the core of what we do. But we've grown beyond that. Our latest release (&lt;a href="https://obot.ai/blog/announcing-obot-platform-v0-22-0-centrally-managed-skills-fleet-scanning-and-enterprise-controls-for-mcp/" rel="noopener noreferrer"&gt;v0.22.0&lt;/a&gt;, just shipped May 27) gets at a problem we keep hearing from teams: the "client zoo." A single company has users spread across Cursor, Claude, Copilot, and a half-dozen other AI clients — each with its own config model, its own skills directory, its own way of attaching MCP servers. Nobody has visibility into what's actually running on employee machines, and skills get duplicated and inconsistently authored across every team.&lt;/p&gt;

&lt;p&gt;v0.22.0 adds centrally managed skills, fleet scanning across AI clients and coding agents, and stronger enterprise controls for MCP. It's the beginning of a broader vision: a control plane for the whole AI tooling stack, not just MCP.&lt;/p&gt;

&lt;p&gt;We'll be posting regularly on:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;MCP fundamentals (great if you're just getting started)&lt;/li&gt;
&lt;li&gt;Building and deploying MCP servers&lt;/li&gt;
&lt;li&gt;Security and access control for agentic AI&lt;/li&gt;
&lt;li&gt;Managing AI tooling at enterprise scale&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;We're developers first, sharing practical content — tutorials, explainers, and honest takes.&lt;/p&gt;

&lt;p&gt;If you're building with MCP or wrangling AI tooling across a team, follow along. And we'd genuinely love to know: &lt;strong&gt;what's the messiest part of managing AI tools across your org right now?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;— The Obot team&lt;/p&gt;

</description>
      <category>mcp</category>
      <category>ai</category>
      <category>agentskills</category>
      <category>opensource</category>
    </item>
  </channel>
</rss>
