Ronald van der Plas · Jul 22, 2026
Content Insights Tip #81 | Connect Your AI Coding Agent to Vercel with MCP
Vercel has released an official MCP server that connects supported AI tools directly to your Vercel projects. It is currently available in beta on all Vercel plans and supports tools including Claude Code, Codex CLI, Cursor, ChatGPT and VS Code with GitHub Copilot. What does Vercel MCP do? MCP stands for Model Context Protocol. It allows AI assistants to connect to external tools and data sources. Vercel MCP uses OAuth to grant your AI assistant access to the Vercel projects associated with your account. Once connected, your agent can: Search the Vercel documentation List and inspect projects View recent deployments Retrieve failed build logs Search runtime logs Investigate production and preview errors The runtime log tools can filter by environment, log level, status code, source and time range. You could, for example, ask: Find the latest failed deployment for this project and analyse the build logs. Or: Show me the production errors from the last hour and identify the most likely cause. How is this different from the Vercel Plugin? The Vercel Plugin and Vercel MCP complement each other, but they solve different parts of the same problem. The plugin mainly improves what your AI coding agent knows about Vercel. It adds platform-specific context, skills, specialist agents and commands for areas such as Next.js, deployments, caching, performance and environment variables. Vercel MCP goes a step further by connecting the agent to your actual Vercel environment. Instead of only understanding how the platform works, the agent can retrieve information about your projects, deployments and logs. In other words, the plugin helps your agent understand Vercel, while MCP enables it to work with the Vercel environment you use. For SitecoreAI projects with a Next.js frontend, combining both could be particularly useful. The plugin helps the agent understand the frontend platform, while MCP provides information about what is happening after that frontend has been deployed. Connecting your coding agent Vercel provides a general installer that detects supported AI coding tools: npx add-mcp https://mcp.vercel.com For Codex CLI, you can add it directly: codex mcp add vercel --url https://mcp.vercel.com The client will open an OAuth flow in your browser, where you authorise access to your Vercel account. Keep access in mind The connected AI system receives the same level of Vercel access as the user who authorises it. That makes the authentication step more than a simple technical formality, because the permissions granted to the agent determine what it can inspect and potentially change. For that reason, Vercel recommends keeping human confirmation enabled for tool execution. This allows the developer to review an action before the agent carries it out, which is especially important when working with production environments. A sensible way to begin is by using Vercel MCP for read-oriented tasks. Let the agent investigate failed deployments, analyse build and runtime logs, inspect project configuration and search the Vercel documentation. These scenarios already provide considerable value without immediately giving the agent responsibility for making changes. My thoughts Vercel MCP looks like a useful addition to the AI-assisted development workflow. Giving an agent direct access to deployment information, runtime logs and project configuration removes a great deal of manual context gathering. It allows the assistant to work with what is actually happening in your Vercel environment, rather than relying only on the code and information you provide manually. At the same time, that convenience makes it important to think carefully about access. An agent can only be as safe as the permissions it has been given. So human confirmation should remain enabled, particularly when production environments are involved. When security is a primary concern, it may be worth authorising the MCP connection through a dedicated Vercel account with fewer privileges. That account could be limited to the projects and actions the agent genuinely needs. This follows the principle of least privilege and reduces the potential impact if the tooling behaves unexpectedly or is influenced by untrusted input. Vercel MCP has the potential to become a valuable part of the development toolkit, but it should be introduced with the same care as any other integration that receives access to your environments. Source: Use Vercel's MCP server
Read post →Ronald van der Plas · Jul 14, 2026
Content Insights Tip #80 | Give your AI coding agent better Next.js knowledge for SitecoreAI
When building a SitecoreAI headless frontend with Next.js, your AI coding agent needs to understand more than just React and TypeScript. Vercel has released an official plugin that provides coding agents with Vercel and Next.js-specific context, skills, specialist agents and slash commands. Install it with: npx plugins add vercel/vercel-plugin The plugin currently supports tools including Claude Code, OpenAI Codex, Cursor, GitHub Copilot, Grok Build and Kimi Code. It adds 28 skills covering subjects such as: Next.js App Router and Server Components React and Next.js performance Caching and cache invalidation Environment variables Deployment and CI/CD Vercel Functions Security and firewall configuration AI SDK and AI Gateway For example, you can explicitly activate the Next.js knowledge using: /vercel-plugin:nextjs The plugin is lightweight by default, automatically adding session context only in empty directories or detected Vercel and Next.js projects. Although it does not teach your agent how SitecoreAI works, it can significantly improve its understanding of the surrounding Next.js frontend. Combined with project-specific instructions and SitecoreAI skills, this creates a much stronger baseline for AI-assisted Sitecore development. More information is available in the Vercel Plugin documentation. Happy Codin'!
Read post →Ronald van der Plas · Jul 6, 2026
Automatically transcribing Sitecore Content Hub videos with Azure AI Video Indexer
Video accessibility is one of those topics that sounds simple until you need to support it at scale. For a single video, creating subtitles manually is manageable. For a larger video library, the process quickly becomes repetitive and error-prone. Someone needs to download the video, send it to a transcription service, wait for the results, upload the subtitle file, add the correct metadata, link it to the original video, and make sure it is ready for publishing. That is exactly the kind of process I like to automate. In this post, I want to walk through an architecture for automatically transcribing videos from Sitecore Content Hub with Azure AI Video Indexer. The implementation started with a Sitecore-provided (by Jeroen Feyaerts of Sitecore Professional Service) C# coding sample. That sample demonstrated the core integration flow. I then refactored and extended it into a more production-oriented implementation with Azure Functions, queue-based throttling, callback handling and a clearer separation between Content Hub, Azure AI Video Indexer and the integration layer. The goal is simple: Take a video asset from Sitecore Content Hub, generate subtitles with Azure AI Video Indexer, and store the generated subtitle back in Content Hub as a managed asset related to the original video. This is not AI for the sake of AI. It is a practical DAM automation that improves accessibility and removes manual work from the content process. The problem Sitecore Content Hub is a great place to manage video assets, metadata, renditions, relations and publishing workflows. But subtitles often still end up as a separate process. That separation creates a few problems. The challenge is that manual subtitle creation does not scale well. Someone has to manage the transcription process outside of the DAM, which already introduces extra work and coordination. On top of that, different people may create and upload subtitles in different ways, using different naming conventions, metadata structures and storage locations. That may be manageable for a handful of videos, but once you are dealing with hundreds or thousands of existing assets, the process quickly becomes inconsistent, hard to govern and difficult to maintain. The solution The solution starts with a simple idea: use Content Hub as the starting point, let Azure AI Video Indexer do the transcription work, and bring the generated SRT file back into Content Hub as a managed asset. A video in Content Hub already has metadata, renditions, lifecycle state and relationships to other assets or content. If subtitles are generated outside of that model and stored somewhere else, the result is disconnected from the DAM. That is what I wanted to avoid. The Azure Function acts as the orchestration layer between Content Hub and Azure AI Video Indexer. It finds the video in Content Hub, submits it for transcription, and handles the result when Video Indexer is done. When a video needs subtitles, the Function looks for the MP4 rendition. That rendition is used deliberately. The original video file can be very large, and sending that file to Azure AI Video Indexer would increase data transfer, processing time, and potentially cost. The MP4 rendition provides a more controlled version of the video that is still suitable for analysis. Azure AI Video Indexer downloads the MP4 rendition and uses both the audio and visual information to generate the transcription. The Function only passes the rendition URL, so it does not need to temporarily download, store and re-upload the video itself. Because video indexing can take time, the process is asynchronous. After submission, the workflow continues when Azure AI Video Indexer calls the configured callback endpoint. From that callback, the Function uses the original Content Hub asset identifier to connect the result back to the source video, downloads the generated SRT file, and uploads it into Content Hub as a related subtitle asset. The value is in closing the loop: the video starts in Content Hub, Azure AI Video Indexer generates the transcription, and the resulting SRT returns to the managed asset model. Two lanes: bulk and priority For bulk processing, the integration uses an Azure Storage Queue. Existing video libraries can contain hundreds or thousands of assets, so sending everything directly to Azure AI Video Indexer would be risky. The queue gives control over throughput, and a scheduled Azure Function can process the work at a safe pace. Single assets can take a different path. When an editor needs subtitles for a video that is about to be published, that asset should not have to wait behind a large archive backfill. For that scenario, the integration supports a priority lane that submits the video directly to Azure AI Video Indexer. The queue is the safe path for bulk processing. The priority lane is the fast path for urgent single-asset processing. It may bypass the waiting queue, but it should never bypass validation, logging, duplicate detection or state tracking. Important caveat: idempotency One important production caveat is idempotency. A queue helps to control throughput, but it does not automatically prevent duplicate work. The same video can still be triggered multiple times through bulk processing, manual actions or retries. To handle that, the integration should keep a small technical job state outside of Content Hub. In this case, Azure Table Storage is a good fit: it is simple, fast and enough to track whether a transcription job already exists for a specific asset, language and indexing preset. That gives the integration a quick decision point before adding work to the queue or submitting a video to Azure AI Video Indexer. The queue remains responsible for transport and throttling, while Table Storage helps prevent duplicate processing. Do not turn Content Hub into a workflow log The job state is important, but that does not mean every technical status update should be written back to Content Hub. During a large backfill, constantly updating assets with statuses like queued, submitted, processing or retrying would create unnecessary API traffic. It would also make Content Hub responsible for the technical orchestration state, which is not the role I want it to play in this architecture. Content Hub should be updated when there is a meaningful content outcome: the generated SRT asset is created, related to the original video and moved into the right lifecycle state. The detailed processing state belongs in Azure Table Storage and Application Insights. Content Hub should contain the managed result, not every internal step of the integration. Closing thoughts The core API flow is only one part of this solution. The real architectural value is in the operational choices around it: how to process large video libraries safely, how to let urgent assets jump the queue, how to prevent duplicate work, and how to avoid unnecessary pressure on Content Hub. That separation of responsibilities is what makes the architecture practical. Content Hub manages the assets, metadata, lifecycle and relations. Azure AI Video Indexer generates the transcription. Azure Functions orchestrate the workflow. Azure Storage Queue controls bulk throughput. Azure Table Storage helps with idempotency and fast decision-making. At the same time, Content Hub users should still have visibility. For a bulk transcription run, the Azure Function could create a Content Hub task that shows the functional progress to editors and asset managers. That task is for visibility only. The actual orchestration remains in Azure, where the queue, Table Storage and Functions control the workflow. That is where a simple API integration becomes a reliable content workflow: practical, targeted and useful. Not a generic AI demo, but a focused automation that improves accessibility, reduces manual work and fits naturally into the Sitecore Content Hub ecosystem.
Read post →