Model Context Protocol

97 posts

figma2 min readCurated summary

The TL;DR on MCP: Why Context Matters and How to Put It to Work | Figma Blog

MCP (Model Context Protocol) connects AI tools to the design decisions and data stored in tools like Figma. Figma argues that giving coding agents structured access to components, tokens, and layout rules produces code that better matches the intended design and design system. It also creates a two-way workflow in which developers and designers can move between code and canvas without losing context. ## MCP Connects Design and Development - Product work is increasingly iterative rather than a linear design-to-development handoff. - MCP lets AI coding tools access Figma files as structured design sources, not merely as screenshots. - Figma’s MCP server helps bring design context into code, while code-to-canvas tools can bring working interfaces back into Figma. - This keeps the broader product team involved as designs and implementations evolve. ## Why Context Matters for AI-Generated Code - Without context, an AI tool may: - Choose a color that resembles the brand color but is not linked to the correct design token. - Recreate a card instead of reusing an established component. - Flatten a complex, nested form into a single basic element. - These seemingly minor deviations accumulate across screens and components. - MCP exposes the underlying components, tokens, and layout decisions that explain how a design was built. ## Designers: Files Directly Influence Production Code - Design systems now influence not only human implementation but also AI-generated code, from prototypes through production. - Well-structured, consistent Figma files can guide AI toward more reliable and on-brand results. - Poor organization or small inconsistencies can spread widely because AI reproduces them at scale. - MCP also lets designers review code-built interfaces in Figma, add missing states, refine details, and prepare work for production without starting over. ## Developers: Less Translation, More Building - AI coding tools can accelerate implementation, but their output is less accurate when design intent is unavailable. - MCP reduces the translation required between a visual design and working code by supplying the system and component context behind the design. - Developers can spend more time building instead of reconstructing design decisions from screenshots or incomplete handoffs. Figma’s practical recommendation is to treat design files and design systems as active inputs to AI workflows. The better the structure and context captured in those files, the more consistently AI can generate code that reflects the intended product.

Read original(opens in new tab)
github3 min readCurated summary

Hack the AI agent: Build agentic AI security skills with the GitHub Secure Code Game

Agentic AI tools can automate powerful tasks, but their autonomy creates new security risks, including prompt injection, tool misuse, memory poisoning, and compromised multi-agent workflows. GitHub’s Season 4 Secure Code Game teaches developers to recognize these threats by attacking and hardening ProdBot, a deliberately vulnerable terminal-based AI assistant. Its five levels progressively add capabilities—and corresponding attack surfaces—mirroring how real-world AI systems evolve. ## The Secure Code Game’s Evolution - The free, open-source, in-editor course teaches security by having players exploit and fix intentionally vulnerable code. - Earlier seasons covered: - General secure coding across JavaScript, Python, Go, and GitHub Actions. - LLM security, including malicious prompts and defensive techniques. - More than 10,000 developers from industry, academia, and open source have participated. - Season 4 shifts focus from AI that generates content to AI that independently browses, uses tools, calls APIs, and acts for users. ## Why Agentic AI Security Is Urgent - Agentic systems are moving rapidly from research projects into production environments. - The OWASP Top 10 for Agentic Applications identifies threats such as: - Goal hijacking - Tool misuse - Identity abuse - Memory poisoning - A Dark Reading poll found that 48% of cybersecurity professionals expect agentic AI to be the leading attack vector by the end of 2026. - Cisco reported that although 83% of organizations planned to deploy agentic AI, only 29% felt prepared to secure it. - The article argues that learning to think like an attacker is essential for closing this readiness gap. ## ProdBot: A Deliberately Vulnerable AI Assistant - ProdBot is a terminal-based productivity and coding assistant inspired by tools such as OpenClaw and GitHub Copilot CLI. - It can: - Convert natural-language requests into bash commands. - Browse a simulated web. - Connect to MCP servers. - Run organization-approved skills. - Store persistent memory. - Coordinate multiple agents. - Players’ objective is to use natural language to make ProdBot reveal the contents of `password.txt`. - No prior AI or coding experience is required; all interaction takes place through the CLI. ## Five Progressive Attack Surfaces - **Level 1: Shell execution** - ProdBot runs generated bash commands in a sandbox. - The challenge is to determine whether the sandbox can be escaped. - **Level 2: Web browsing** - ProdBot reads simulated news, finance, sports, and shopping sites. - Untrusted web content introduces risks such as instruction hijacking and prompt injection. - **Level 3: MCP integrations** - ProdBot gains access to external tool providers for stock quotes, browsing, and cloud backup. - Additional tools increase both functionality and opportunities for abuse. - **Level 4: Skills and memory** - Organization-approved plugins and persistent memory create layered trust relationships. - The level tests whether trusted skills and stored information are actually safe. - **Level 5: Multi-agent orchestration** - ProdBot combines six specialized agents, three MCP servers, three skills, and a simulated open-source project. - Claims that agents are sandboxed and data is pre-verified become assumptions to test rather than guarantees. ## Real-World Relevance - The game’s vulnerabilities reflect active security concerns in deployed autonomous AI systems rather than purely theoretical exercises. - The article cites CVE-2026-25253, known as “ClawBleed,” an OpenClaw vulnerability rated CVSS 8.8. - The flaw allowed attackers to steal authentication tokens through a malicious link and gain full control of an OpenClaw instance. - Season 4’s broader goal is to develop instincts for identifying similar weaknesses during architecture reviews, tool-integration audits, and production deployments. Developers working with AI agents should treat every new capability—shell access, browsing, plugins, memory, or collaboration—as a potential attack surface. Practicing these failure modes in a controlled environment like the Secure Code Game can help teams design safer agentic systems before deploying them.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Scaling MCP adoption: Our reference architecture for simpler, safer and cheaper enterprise deployments of MCP

Cloudflare argues that enterprise MCP adoption requires centralized governance rather than individually managed, locally hosted servers. Its reference architecture combines remote MCP servers, Cloudflare Access, MCP server portals, and AI security controls to improve visibility, authentication, policy enforcement, and performance. The company also introduces Code Mode with MCP server portals to reduce the token and context-window costs of exposing large APIs. ## Centralized Remote MCP Servers - MCP separates the AI application from corporate credentials and APIs: - The MCP client connects to the LLM or agent. - The MCP server mediates access to internal resources. - Cloudflare moved away from locally hosted MCP servers because they: - May use unvetted software and versions. - Increase supply-chain and tool-injection risks. - Are difficult for IT and security teams to administer. - A centralized team manages MCP infrastructure through a shared monorepo platform. - Approved teams can create governed MCP servers from templates, inheriting: - Default-deny write controls. - Audit logging. - Automated CI/CD pipelines. - Secrets management. - Servers are deployed remotely on Cloudflare’s developer platform and custom domains, providing centralized usage visibility and global low-latency access. ## Authentication with Cloudflare Access - Public MCP servers, such as documentation and Radar services, can remain openly accessible. - MCP servers connected to private corporate resources require employee authentication. - Cloudflare Access acts as the OAuth provider and identity layer. - It verifies: - Single sign-on. - Multifactor authentication. - IP address, location, and device-certificate context. - Access issues tokens that authorize users to reach protected resources. ## MCP Server Portals for Discovery and Governance - As the number of MCP servers grew, employees needed a central way to discover authorized services. - Users connect their MCP client to a portal, which exposes the internal and third-party MCP servers they are permitted to use. - Portals provide: - Centralized logging. - Consistent policy enforcement. - Data loss prevention controls. - Access policies for users and tools. - Administrators can restrict both portal access and the specific tools exposed by each server. - Finance users might receive only read-only repository tools. - Engineering users on corporate devices might receive read/write capabilities. - Portals support MCP servers hosted on Cloudflare as well as third-party servers. - Cloudflare emphasizes that the relevant security and networking components can run on the same physical machine in its global network, reducing latency and avoiding unnecessary traffic transit. ## Code Mode Reduces MCP Token Costs - The standard MCP design exposes every API operation as a separate tool. - For large platforms with thousands of endpoints, this exhaustive tool list consumes an agent’s context window and increases token costs. - Cloudflare presents Code Mode with MCP server portals as a way to address this scaling problem. - The provided article excerpt ends while introducing Cloudflare’s earlier use of server-side Code Mode for exposing large numbers of API endpoints. Cloudflare’s approach recommends treating MCP as enterprise infrastructure: centrally deployed, authenticated, discoverable, policy-controlled, and monitored. Organizations adopting MCP at scale should avoid unmanaged local servers and provide reusable platforms that make secure deployment the default.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Managed OAuth for Access: make internal apps agent-ready in one click

Cloudflare’s managed OAuth makes internal apps behind Cloudflare Access usable by AI agents without modifying the apps themselves. By exposing standard OAuth discovery and authorization flows, agents can authenticate on behalf of the human user rather than relying on static service accounts. The result is immediate agent compatibility for legacy websites, APIs, and other internal tools. ## The Problem: Access Worked for Humans, Not Agents - Cloudflare protects thousands of internal and self-hosted applications with Cloudflare Access. - Humans can follow Access’s login-page redirect, but agents generally cannot interact with browser-based authentication flows. - Cloudflare initially addressed this internally by modifying OpenCode’s web fetch tool to use `cloudflared` to obtain a JWT and attach it to requests. ## Managed OAuth for Access Applications - Managed OAuth is now available in open beta for every Access application. - Enabling it requires one click and no application code changes. - Access acts as the OAuth authorization server and advertises authentication details through: - The `WWW-Authenticate` response header - `/.well-known/oauth-authorization-server` - OAuth-capable agents can then: - Dynamically register as clients using RFC 7591. - Send the user through a PKCE authorization flow using RFC 7636. - Receive a token representing the user’s authorization. - The same pattern supports web pages, web applications, REST APIs, and MCP servers. ## Making Legacy Internal Apps Agent-Ready - Retrofitting every internal application with APIs, CLIs, MCP servers, and new agent standards is impractical. - Many applications can already provide useful value when agents treat them as ordinary websites. - For example, an internal wiki may only need Markdown-for-Agents support and managed OAuth. - Putting Cloudflare Access in front of existing applications provides immediate agent compatibility without rebuilding them. ## User-Based Authorization Instead of Service Accounts - Static service accounts and tokens can be useful for simple integrations, but they weaken attribution and fine-grained access control. - Actions performed through shared credentials may appear in audit logs as originating from the agent or service account rather than the responsible human. - They can also create confused-deputy risks, where an agent gains authority beyond what its user should have. - OAuth preserves the user–agent relationship: - Tokens are scoped to the user’s identity and permissions. - Existing access policies continue to apply. - Audit logs can attribute actions to the initiating user. ## RFC 9728 and Agent Web Fetching - RFC 9728 standardizes how clients discover OAuth authentication requirements. - MCP has adopted the standard, but Cloudflare argues that general-purpose agents should use it for protected websites and REST APIs as well. - Most agent web-fetch tools currently ignore `WWW-Authenticate` headers and do not automatically: - Locate the OAuth authorization-server metadata. - Register as an OAuth client. - Complete the authorization flow. - Cloudflare has drafted changes to OpenCode’s web-fetch tool demonstrating how tools could check for existing credentials and initiate OAuth when necessary. Cloudflare’s recommendation is to enable managed OAuth for Access-protected applications and encourage agent developers to implement RFC 9728. This offers a practical path to agent adoption while retaining user-level permissions, accountability, and compatibility with existing internal software.

Read original(opens in new tab)
github3 min readCurated summary

GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI

GitHub Copilot CLI brings Copilot’s agentic coding capabilities directly into the terminal, allowing developers to inspect projects, generate code, run tests, and correct errors without switching tools. The post introduces the tool, explains installation and authentication, and demonstrates how to use it for project overviews, coding tasks, and delegated work. Its central message is that Copilot CLI can preserve development flow while supporting increasingly autonomous coding workflows. ## What GitHub Copilot CLI Does - Runs Copilot from a command-line interface with context from the current repository. - Can autonomously: - Build or modify code - Run tests - Detect and correct errors - Explore project files and documentation - Lets developers review results and request follow-up changes directly in the terminal. - Can delegate well-defined tasks to the Copilot cloud agent. ## Installing Copilot CLI - The primary cross-platform installation method, assuming Node.js is available, is: ```bash npm install -g @github/copilot ``` - Users can also install it through package managers such as Homebrew or WinGet. ## First-Time Setup - Launch the tool by entering `Copilot` in the terminal. - Authenticate with GitHub using: ```plaintext /login ``` - Authentication connects the CLI to the user’s Copilot account and the read-only GitHub MCP server. - Copilot must be granted permission to access the current folder so it can inspect or modify files. - Folder permissions can apply only to the current session or be saved for future sessions. ## Common Development Tasks - **Understand an existing project** - Prompt Copilot with: ```plaintext Give me an overview of this project ``` - It examines important files and summarizes the project structure and purpose. - **Generate new code** - For example: ```plaintext Let’s add a new endpoint to return all categories ``` - Copilot reviews existing conventions, documentation, and examples before proposing or creating files. - It requests permission before making changes. - **Delegate work to the cloud agent** - A task can be sent using: ```plaintext /delegate Let’s deal with issue #14 to add the rest of the CRUD endpoints to games ``` - The cloud agent retains the current context, creates a branch, opens a draft pull request, and performs the work in the background for later review. ## What Comes Next The broader beginner series will cover interactive mode, non-interactive mode using the `-p` flag, slash commands, and MCP server integration. These features expand Copilot CLI from an interactive coding assistant into a flexible terminal-based automation tool. Copilot CLI is recommended for developers who want AI assistance without leaving the shell: install it with npm, authenticate, grant project permissions, and begin with exploratory prompts before assigning code changes or delegated tasks.

Read original(opens in new tab)
github3 min readCurated summary

Agent-driven development in Copilot Applied Science

The post describes how Tyler McGoffin used GitHub Copilot to automate the intellectual work of analyzing coding-agent evaluation trajectories. This led to `eval-agents`, a tool designed to let researchers create, share, and run specialized agents. By making coding agents the primary contributors, the team rapidly added 11 agents, four skills, and workflow support while learning new approaches to prompting, architecture, and collaboration. ## The Motivation: Automating Evaluation Analysis - McGoffin analyzes coding-agent performance using benchmarks such as TerminalBench2 and SWEBench-Pro. - Each benchmark task produces a trajectory: a large JSON record of the agent’s thoughts and actions. - Reviewing hundreds or thousands of trajectories can involve hundreds of thousands of lines of data. - Copilot initially helped identify patterns, reducing the amount of material requiring manual inspection from hundreds of thousands of lines to a few hundred. - The repetitive nature of this process inspired `eval-agents`, which automates parts of the analysis itself. ## Project Goals The project was designed around three objectives: - Make agents easy for others to share and use. - Make authoring new agents straightforward. - Make coding agents the primary mechanism for contributing to the project. The third goal had the greatest architectural impact. Using Copilot to build the tool also made the repository easier for teammates to understand, extend, and collaborate on. ## An Agent-First Development Setup McGoffin’s development environment consisted of: - Copilot CLI as the coding agent. - Claude Opus 4.6 as the model. - VS Code as the IDE. - The Copilot SDK for creating agents, registering tools and skills, and accessing existing MCP servers. This setup allowed the project to reuse Copilot’s existing agent infrastructure instead of implementing those capabilities from scratch. ## Prompting Strategies - Agents perform best when treated like capable engineers rather than simple code generators. - Effective prompts are conversational, detailed, and explicit about assumptions. - Planning mode should be used before implementation mode, especially for complex tasks. - McGoffin used stream-of-consciousness descriptions to explain problems and collaborate with Copilot on possible solutions. - For example, a discussion about preventing agents from weakening regression tests led to protected test areas and human-controlled contract-test-like guardrails. - The broader lesson is that agents benefit from many of the same practices as human engineers: context, dialogue, planning, and clear constraints. ## Architectural Strategies An agent-first codebase makes maintainability work especially valuable: - Refactoring names and file structures improves the repository’s understandability. - Documentation gives agents the context needed to implement features consistently. - Additional tests expose and prevent recurring mistakes. - Removing dead code helps keep agents from copying outdated or irrelevant patterns. - Work that was traditionally postponed—cleanup, documentation, and test improvements—becomes foundational when agents are responsible for much of the implementation. ## Rapid Team Collaboration Applying these principles enabled substantial development in a short period: - Five people contributed to the project for the first time. - The team created 11 agents and four skills. - They introduced eval-agent workflows for structured streams of scientific reasoning. - In under three days, the changes amounted to approximately 28,858 added and 2,884 removed lines across 345 files. ## Practical Recommendation Teams adopting agent-driven development should invest first in clear architecture, documentation, tests, and conversational planning practices. Agents become substantially more effective when the repository provides strong context and guardrails, allowing developers to focus less on repetitive implementation and more on directing, reviewing, and improving the overall system.

Read original(opens in new tab)
figma3 min readCurated summary

Agents, Meet the Figma Canvas | Figma Blog

Figma is opening its canvas to AI agents, allowing tools such as Claude Code and Codex to create and modify designs directly in Figma files. Through the `use_figma` tool and customizable skills, agents can use a team’s components, variables, design decisions, and workflows instead of producing generic designs. The feature is free during beta but is expected to become usage-based and paid. ## Agents Work Directly on the Figma Canvas - Figma’s MCP integration lets agents read and write Figma files through the `use_figma` tool. - Agents can create or update: - Design assets - Components - Files based on existing design systems - Designs linked to established variables and conventions - Teams can move between code, the command line, and Figma while keeping design context shared. - Figma positions the canvas as the place where product decisions become visible and refined. ## Working Across Code and Canvas - The existing `generate_figma_design` tool converts HTML from live apps and websites into editable Figma layers. - The new `use_figma` tool operates directly on the canvas, using existing components and variables. - The tools are intended to work together: - `generate_figma_design` brings current implementation details into Figma. - `use_figma` edits those designs or creates new system-aligned assets. ## Skills Encode Design Intent - Skills are Markdown-based instructions that tell agents: - Which workflow steps to follow - What sequence to use - Which team conventions to respect - What quality standards and specialized knowledge to apply - Anyone can author a skill without building a plugin or writing traditional code. - The foundational `/figma-use` skill teaches agents Figma’s structure and core principles. - Teams can customize that foundation to reflect their own design systems and working methods. ## Example Skills and Workflows Figma highlights skills for tasks such as: - Generating component libraries from code - Creating designs from existing components and variables - Producing accessibility specifications for VoiceOver, TalkBack, and ARIA - Creating components from structured JSON contracts - Applying design systems to existing designs - Managing spacing through variables and fallbacks - Synchronizing design tokens between code and Figma - Running parallel, multi-agent design workflows ## More Predictable and Self-Correcting Output - Skills make AI behavior more consistent by encoding repeatable instructions and implementation rules. - Agents can use screenshots to identify mismatches and iteratively refine generated screens. - Because agents work with real Figma structure—components, variables, and auto layout—corrections affect the underlying design system rather than only the visual appearance. - Team conventions become active rules that agents apply during creation, rather than static documentation they merely reference. Figma’s agent workflow is most useful when teams invest in well-defined components, variables, and skills. During the beta, teams can experiment with `use_figma` and community skills to automate design work while preserving their existing design intent and system standards.

Read original(opens in new tab)
figma2 min readCurated summary

Issue no.15: The State of Design | Figma Blog

AI is reshaping design by blurring the boundary between code and canvas, while expanding—not eliminating—the need for designers. Figma’s research suggests designers are adapting to new expectations by strengthening both AI-related capabilities and enduring creative fundamentals. The future favors people who can move fluidly across tools, teams, and stages of product development. ## AI’s impact on design work - 91% of surveyed designers say AI tools are helping them improve their work. - “Better design” means different things to different designers, including: - Visual polish - More thoughtful problem-solving - More intuitive user experiences - These differing priorities influence how designers understand and experience their jobs. - Design is increasingly defined by outcomes and problem-solving rather than by a single medium. ## Design hiring remains strong - AI is not reducing demand for designers according to Figma’s research. - 82% of surveyed hiring managers say their need for designers has either remained stable or increased. - Demand is growing beyond technology companies. - Organizations are seeking designers who can help translate new AI capabilities into useful products and experiences. ## Skills for the AI era - Designers are exploring emerging practices such as: - Prompting - MCP-related workflows - Connecting AI tools and processes - Translating between design, engineering, product, and other teams - AI-specific skills complement rather than replace foundational design abilities. - Communication, judgment, craft, and the ability to understand user and business needs remain essential. - The strongest designers are likely to combine technical fluency with human-centered thinking. ## Product teams are prototyping earlier - Product managers are using Figma Make to explore ideas and build conviction more quickly. - Teams at ServiceNow, Ticketmaster, and Affirm use prototypes to: - Communicate complex product behaviors - Test and develop ideas - Make better roadmap decisions - Prototyping is becoming accessible beyond traditional design roles. ## Code and canvas converge - Ideas can begin in code, visual design, or anywhere in between. - Figma presents the future of design as a continuous movement between code and canvas. - This shift makes designers less defined by their tools and more by their ability to shape ideas across mediums. Designers should treat AI as an extension of their creative and problem-solving toolkit, while continuing to develop core design judgment, communication, and craft. The most valuable practitioners will be those who can connect AI-enabled workflows with strong product thinking and cross-functional collaboration.

Read original(opens in new tab)
github2 min readCurated summary

The era of “AI as text” is over. Execution is the new interface.

The post argues that AI is moving beyond text-based question-and-answer interactions toward embedded execution. The GitHub Copilot SDK lets applications use Copilot’s planning, tool use, file modification, command execution, and error recovery capabilities directly. This enables teams to build adaptable AI workflows without creating their own orchestration infrastructure. ## Delegating Multi-Step Work to Agents - Applications can express intent and constraints instead of hard-coding every workflow step. - For a task such as “Prepare this repository for release,” an agent can: - Explore the repository - Plan the necessary work - Modify files - Run commands - Recover and adapt when failures occur - This approach is more flexible than scripts, which become brittle when workflows depend on changing context or unexpected errors. - Teams can use agentic execution while maintaining defined boundaries and observability. ## Using Structured Runtime Context - Relying on prompts to contain system logic makes workflows difficult to test, maintain, and evolve. - The Copilot SDK supports structured, composable context through: - Domain-specific tools and agent skills - Model Context Protocol (MCP) - Runtime retrieval of relevant data - Agents can directly access systems such as: - Service ownership records - Historical decisions - Dependency graphs - Internal APIs - Permissioned tools and real-time data provide more reliable grounding than embedding organizational knowledge in prompts. ## Embedding Agents Beyond the IDE - Agentic capabilities can be integrated into: - Desktop applications - Internal operational tools - Background services - SaaS products - Event-driven systems - Applications can invoke Copilot in response to events such as file changes, deployments, or user actions. - Execution happens within the product itself rather than in a separate IDE or terminal interface. - This turns AI from an auxiliary developer tool into application infrastructure available wherever the software operates. ## Execution as a New Interface - Agentic workflows are programmable planning-and-execution loops that: - Integrate with real systems - Operate under constraints - Adapt during runtime - Use tools to complete tasks - The Copilot SDK provides this execution layer so teams can focus on defining outcomes instead of rebuilding orchestration systems. The practical recommendation is to treat AI as an executable application capability rather than merely a text interface. Teams can start by identifying multi-step workflows or event-driven tasks where structured tools, runtime context, and adaptive execution would provide more value than fixed scripts.

Read original(opens in new tab)
github3 min readCurated summary

Under the hood: Security architecture of GitHub Agentic Workflows

GitHub Agentic Workflows are designed to bring autonomous agents into CI/CD without giving them unrestricted access to repositories, secrets, or the internet. Because agents can be prompt-injected and behave unpredictably, GitHub treats them as untrusted components and compiles workflows into constrained GitHub Actions. The architecture relies on layered isolation, controlled communication, staged writes, and comprehensive auditing. ## Threat Model - Agents reason over repository state and act autonomously, so they cannot be trusted by default. - GitHub Actions normally place components in one permissive trust domain with broad access to: - Repository contents - Authentication secrets - MCP servers - Arbitrary network destinations - A malicious webpage, issue, or repository file could prompt an agent to: - Read credentials from files, environment variables, logs, or `/proc` - Upload secrets externally - Embed secrets in issues, pull requests, or comments - Make unwanted repository changes - Strict mode follows four principles: - Defense in depth - Never trust agents with secrets - Stage and vet writes - Log everything ## Layered Security Architecture GitHub Agentic Workflows use three complementary layers: - **Substrate layer** - Runs on a GitHub Actions runner VM. - Uses trusted containers, Docker isolation, network controls, and kernel-enforced boundaries. - Separates components and mediates privileged operations and system calls. - Is intended to contain damage even if an untrusted component is compromised. - **Configuration layer** - Defines which components run and how they connect. - Controls communication channels, privileges, firewall policies, Docker images, and MCP configuration. - Determines which tokens are loaded into which containers. - Converts declarative workflow configuration into a secure runtime structure. - **Planning layer** - Controls which components are active and how data moves between them over time. - Creates staged workflows with explicit data exchanges. - Uses the Safe Outputs subsystem to govern potentially dangerous operations. ## Keeping Secrets Away from Agents - In ordinary GitHub Actions, secrets may be visible through environment variables and configuration files across the shared runner trust domain. - This creates a major prompt-injection risk: an agent with shell access could discover credentials and exfiltrate them. - Agentic Workflows instead place the agent in a dedicated container with: - Firewalled internet access - MCP access through a trusted gateway - LLM communication through an API proxy - A private network connects the agent only to approved services. - The trusted MCP gateway launches MCP servers and exclusively handles MCP authentication material. - LLM authentication tokens are kept in the isolated API proxy rather than exposed directly inside the agent container. ## Controlled Execution and Writes - Open-ended workflow authoring is separated from governed execution. - Workflows are compiled into GitHub Actions with explicit constraints covering: - Permissions - Outputs - Network access - Auditability - The planning and Safe Outputs systems are intended to mediate GitHub write operations and apply controls such as call filtering, volume limits, secret removal, and moderation. GitHub’s approach is to treat agents as untrusted CI/CD components rather than granting them normal workflow privileges. Organizations adopting agentic automation should isolate agents, broker access to tools and credentials, restrict network connectivity, stage all writes for review, and maintain detailed logs.

Read original(opens in new tab)
gitlab3 min readCurated summary

Extend GitLab Duo Agent Platform: Connect any tool with MCP

GitLab Duo Agent Platform can connect to Jira and other MCP-compatible tools, allowing developers to manage project data through natural-language requests inside their IDE. The post explains how to configure Atlassian OAuth, register Jira as an MCP server, and verify the connection in GitLab and VS Code. It concludes with practical workflows for backlog planning and creating or triaging issues directly from code context. ## MCP Architecture - GitLab Duo Agent Platform operates as the MCP client. - The Atlassian MCP server: - Authenticates users - Converts natural-language requests into Jira API calls - Returns structured results to GitLab Duo - Maintains security and audit controls - This integration reduces context switching between Jira, GitLab, and the IDE. ## Configure the Jira OAuth Application - Create an OAuth 2.0 integration in the Atlassian Developer Console. - Add Jira API permissions: - `read:jira-work` for issues, projects, and boards - `write:jira-work` for creating and updating issues - `read:jira-user` for user information - Configure the callback URL: - `https://gitlab.com/oauth/callback` - Copy the generated Client ID and Client Secret and store them securely. ## Configure GitLab Duo MCP - Create `.gitlab/duo/mcp.json` in the GitLab project. - Register the Atlassian MCP endpoint at: `https://mcp.atlassian.com/v1/mcp` - Configure OAuth authorization and token URLs: - `https://auth.atlassian.com/oauth/authorize` - `https://auth.atlassian.com/oauth/token` - Replace the placeholder credentials with the Jira OAuth values. - Enable **Allow external MCP tools** under **Group Settings → GitLab Duo → Configuration**. ## Verify the Connection - Ask GitLab Duo: - “What MCP tools do you have access to?” - “Test the MCP JIRA configuration in this project” - Approve access on the Atlassian MCP website and select the relevant Jira instance. - Use **GitLab: Show MCP Dashboard** from the VS Code or VSCodium Command Palette to inspect: - MCP server connection status - Available tools such as `jira_get_issue` and `jira_create_issue` - Real-time server logs and tool calls ## Planning and Backlog Prioritization - Query Jira from the GitLab Duo chat without leaving the IDE. - Find unassigned issues in a project. - Ask the assistant to: - Recommend the top issues to prioritize - Summarize their context - Assign selected issues to the current user - This supports sprint planning by combining Jira data with AI-generated prioritization. ## Issue Triage and Creation from Code - Developers can investigate bugs while reviewing code and interact with Jira conversationally. - Example workflows include: - Searching for an existing bug related to a code-level error - Creating a Jira issue if no matching ticket exists - Including relevant code context in the issue - Identifying possible blockers - Linking the issue to the current branch The integration is most useful when teams want Jira actions, planning, and issue management available directly within their development environment. Teams should configure OAuth scopes carefully, protect client credentials, and use the MCP Dashboard to monitor connections and tool activity.

Read original(opens in new tab)
figma2 min readCurated summary

Building Frontend UIs with Codex and Figma | Figma Blog

Figma’s Codex integration creates a two-way workflow between coding and visual design. Using the Figma MCP server, developers can turn Figma designs into implementation context for Codex, then bring running interfaces back into editable Figma files. The result is a faster cycle for building, comparing, refining, and collaborating on frontend experiences. ## Starting an Application from a Design - Developers can select frames or nodes in Figma Design, Figma Make, or FigJam. - They copy a direct selection link by right-clicking a frame and choosing **Copy as → Copy link to selection**. - The link is provided to Codex with an implementation prompt, such as using existing design-system components. - Codex calls the MCP server’s `get_design_context` tool to retrieve: - Layout information - Styles and visual properties - Component details - Other design context needed for code generation - The MCP server supports additional tools and prompts for extracting information from Figma files. ## Bringing Code Back to the Canvas After iterating on the implementation, developers can import the live interface into Figma rather than recreating it manually. - The application must be rendered locally or on a publicly accessible web server. - Codex uses the `generate_figma_design` tool to convert the running UI into editable Figma frames. - Codex guides users through: 1. Creating or selecting a Figma file 2. Choosing a workspace 3. Setting up the application for capture 4. Opening the application in a browser session - The capture toolbar supports: - **Entire screen:** Captures the currently displayed screen - **Select element:** Captures a specific UI component - **Open file:** Opens the resulting Figma design for inspection ## Iterating Between Code and Design Once the interface is in Figma, teams can use the canvas to explore and refine the product. - Add design-system components. - Convert styles, fonts, and colors into variables. - Adjust layouts and add annotations. - Design interactions, empty states, and alternative flows. - Collaborate on multiple visual directions. - Send the refined design back to Codex through the same MCP workflow. The article presents this round trip as a continuous loop: design informs code, code produces a working interface, and the interface returns to Figma for further exploration. This lets teams begin from either a design or an implementation while preserving context and reducing the friction between developers and designers.

Read original(opens in new tab)
toss4 min readCurated summary

The Software 3.0

The post argues that teams using the same LLM can achieve very different results because individual knowledge of context engineering varies widely. Claude Code’s plugins and marketplace could help turn personal LLM techniques into shared, executable team workflows, raising the organization’s productivity floor. The author presents this as a forward-looking hypothesis rather than a proven success story. ## The Frictionless Harness - LLM adoption loses effectiveness when developers must switch between terminals, browsers, and chat tools. - Claude Code’s terminal-based TUI reduces context switching by combining natural-language instructions and code in the developer’s existing environment. - This low-friction experience makes it easier to distribute standardized workflows across a team. ## Executable Single Source of Truth - Wikis and Notion pages become outdated because they are designed primarily for human reading. - Claude Code plugins can serve as “executable SSOT”: - Humans can read them as guidelines and manuals. - LLMs can interpret them as precise system instructions. - Updating a plugin can immediately change how team agents behave, keeping operational knowledge aligned with current practices. ## Raising the Team’s Productivity Floor - Teams have significant differences in LLM literacy, independent of coding ability. - Generic open-source plugins can provide shared best practices, but they lack company- and domain-specific context. - Each domain needs its own rules for: - Tasks the AI can perform autonomously. - Tasks requiring human approval through HITL processes. - The goal is to minimize human intervention while preserving approval at critical points. ## Extending Platform Engineering into Software 3.0 - AI workflows resemble traditional internal platform components such as authentication, logging, and payment libraries. - The analogy is: - Common software modules → AI workflow plugins - Library distribution → Marketplace publishing - The implementation changes from traditional code to prompts and agent logic. - AI workflows should receive the same quality practices as software modules, including review, optimization, and feedback on token usage and failure cases. - Marketplace-based collaboration could turn individual prompting techniques into shared organizational intelligence. ## Why Use a Marketplace Instead of Only RAG? - RAG systems can make it difficult to predict which context will be retrieved due to search, reranking, and indexing behavior. - Plugins provide more explicit and controllable instructions and code. - Developers can modify and test workflows locally in the TUI without deploying a server. - With the Claude Agent SDK, workflows validated locally could also run in server environments, improving development-production parity. - The marketplace could become the shared source of truth between experimentation and production. ## Marketplace as a Workflow Distribution Platform - Teams could package coding conventions, Git strategies, lint rules, and testing policies into private plugins or registries. - Hooks could actively correct behavior rather than merely reject violations—for example, preventing commits on `main` and creating a `feature/` branch instead. - Slash commands could distribute the best engineer’s workflow to everyone: - `/new-feature` gathers requirements. - Creates a Jira issue and branch. - Produces an implementation plan for approval. - Implements the feature and opens a pull request. - This allows less experienced users to follow a reliable, high-quality process without reproducing it manually. ## Layered Context Architecture The author proposes separating plugin knowledge into three layers: - **Global layer:** Organization-wide security rules and coding standards. - **Domain layer:** Business-specific knowledge for areas such as payments, settlement, or membership. - **Local layer:** Repository-specific implementation details and conventions. This structure avoids overwhelming the LLM with irrelevant information and creates a “living knowledge base” made of maintainable prompts and code rather than static documents. ## The Data Flywheel Hypothesis - Standardized plugins could generate high-quality instruction-tuning data. - Accumulated workflow data might eventually support domain-specific model fine-tuning. - Existing workflows could also provide evaluation criteria for those models. - Success would require sustained data collection, quality controls, and long-term organizational investment. - The proposed flywheel is: more usage creates more data, better data improves models, and better models encourage further usage. The practical recommendation is to treat LLM expertise as an organizational system rather than an individual skill. Teams should begin packaging their implicit knowledge, approval rules, and proven workflows into versioned, domain-aware plugins that can be tested, reviewed, and distributed through a marketplace or private registry.

Read original(opens in new tab)
github2 min readCurated summary

Multi-agent workflows often fail. Here’s how to engineer ones that don’t.

Multi-agent workflows often fail because agents make implicit assumptions about state, ordering, and intended actions. The post argues that these systems should be engineered like distributed software rather than treated as chat interfaces. Typed schemas, explicit action definitions, and MCP-enforced interfaces make agent behavior more predictable and failures easier to contain. ## Typed Schemas Prevent Data Drift - Natural-language exchanges and inconsistent JSON lead to changing field names, mismatched types, and ambiguous payloads. - Typed interfaces define machine-checkable contracts, such as a `UserProfile` with fixed fields and allowed plan values. - Schema violations can fail fast, triggering retries, repairs, or escalation before invalid state spreads. - Debugging becomes contract-based instead of dependent on inspecting logs and guessing. ## Action Schemas Clarify Intent - Agents cannot reliably infer what “take action” means; they may assign, close, escalate, or do nothing. - Action schemas restrict outcomes to explicit, valid choices such as: - Requesting more information - Assigning an issue - Closing an issue as a duplicate - Taking no action - A discriminated union or similar structure ensures every agent returns one recognized action. - Invalid or ambiguous actions can be rejected, retried, or escalated. ## MCP Enforces Agent Interfaces - Schemas and action definitions are only conventions unless consistently enforced. - Model Context Protocol (MCP) provides explicit input and output schemas for tools and resources. - Calls are validated before execution, preventing agents from inventing fields, omitting required inputs, or drifting between interfaces. - MCP therefore acts as the enforcement layer for both data structure and intended behavior. Reliable multi-agent systems require explicit contracts at every boundary. Engineers should treat agents like code components: define their data and actions precisely, enforce interfaces with mechanisms such as MCP, and prevent invalid state from propagating.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Code Mode: give agents an entire API in 1,000 tokens

Code Mode addresses a central MCP problem: giving agents broad tool access without overwhelming their context windows. Instead of exposing thousands of individually described tools, it provides a typed SDK and lets agents write sandboxed JavaScript to search specifications and execute API calls. Cloudflare’s new MCP server applies this approach to its entire API using only `search()` and `execute()`, reducing context usage by 99.9% to roughly 1,000 tokens. ## The Context-Window Problem - MCP makes external tools available to AI agents, but each tool’s description consumes model context. - Large APIs can require enormous token budgets merely to describe their endpoints. - A conventional MCP server for the Cloudflare API would consume approximately 1.17 million tokens. - This can exceed the context window of even advanced foundation models. ## Code Mode as a Compact API Interface - Agents write code against a typed SDK rather than selecting from thousands of separate tools. - Generated code serves as a compact, composable plan. - Agents can: - Explore available operations. - Chain multiple API calls. - Handle pagination and errors. - Return only the data needed for the task. - The tool footprint remains fixed as the underlying API grows. ## Cloudflare’s Two-Tool MCP Server - The server exposes only: - `search()` — searches the Cloudflare OpenAPI specification. - `execute()` — runs JavaScript against the Cloudflare API. - The full OpenAPI specification stays outside the model context. - `$refs` are pre-resolved, allowing agents to inspect endpoint metadata directly through code. - Agents can filter endpoints by product, path, tags, or other metadata. ## Sandboxed Execution - Both tools execute code inside a Dynamic Worker isolate based on lightweight V8 sandboxes. - The environment has: - No filesystem access. - No environment variables exposed to generated code. - External fetches disabled by default. - Outbound requests can be explicitly enabled through controlled fetch handlers. ## Example: Finding DDoS Protection Endpoints - For a request to protect an origin from DDoS attacks, an agent can first consult documentation or skills. - It then uses `search()` to inspect the OpenAPI specification. - A JavaScript query can locate zone endpoints related to WAF and rulesets. - The search narrows more than 2,500 Cloudflare endpoints to relevant operations such as: - Listing and updating WAF packages and rules. - Listing and creating zone rulesets. - Reading and updating entry-point rulesets. - Creating and updating rules within a ruleset. - Once the relevant endpoints are identified, `execute()` can perform coordinated API requests in one sandboxed run. ## SDK Availability - Cloudflare is open-sourcing a Code Mode SDK as part of the Cloudflare Agents SDK. - The same pattern can be used to build more context-efficient MCP servers and AI agents. Code Mode is most useful for large, evolving APIs: expose a small, stable tool surface, let agents discover capabilities programmatically, and execute only the focused operations required for each task.

Read original(opens in new tab)