Genkit 2.0 GA: Firebase AI, MCP, and Cloud Run

Genkit is Google's open-source framework for building AI-powered and agentic applications across TypeScript, Go, Python preview, and Dart preview. The reason it matters in 2026 is not just "another agent SDK." It sits close to Firebase, Google Cloud, Cloud Run, Gemini, Vertex AI, and the MCP tooling wave that is turning agent systems into callable infrastructure.

Effloow Lab ran a local sandbox PoC for the TypeScript MCP path on 2026-05-27. The result: the current genkit and @genkit-ai/mcp packages installed, TypeScript compiled, a Genkit-defined tool was exposed through MCP over stdio, and a real MCP client discovered and called it. The full evidence note is in data/lab-runs/google-genkit-2-0-firebase-ai-developer-guide-2026.md.

This article keeps the evidence line strict. We verified the local MCP plugin path. We did not deploy to Cloud Run, configure Firebase Monitoring, create a Cloud Trace screenshot, or call Gemini. Those production steps are covered from official documentation, but they are not claimed as lab-tested here.

What the sandbox proved

The PoC created a temporary Node project in /tmp/effloow-genkit-mcp-poc, installed the current packages, defined a deterministic Genkit tool, started a Genkit MCP server, then used the official MCP SDK as a client.

The installed versions were:

Package	Version verified
genkit	1.35.0
@genkit-ai/mcp	1.35.0
@modelcontextprotocol/sdk	1.29.0
Node.js	v25.9.0
npm	11.12.1

The tool was intentionally boring: estimate_prompt_window counts characters and words, then recommends whether to summarize or send directly. That was deliberate. A deterministic local tool proves the framework and MCP wiring without requiring API keys, model calls, or cloud credentials.

The MCP client output was:

TOOLS
[
  "estimate_prompt_window"
]
CALL_RESULT
[
  {
    "type": "text",
    "text": "{\"characters\":46,\"words\":8,\"withinLimit\":false,\"recommendation\":\"Summarize or chunk before sending to the model.\"}"
  }
]

That is enough to say: a Genkit TypeScript app can expose a typed local tool through the Genkit MCP plugin, and a real MCP client can discover and invoke it.

The minimal MCP server

The core server was short:

import { createMcpServer } from '@genkit-ai/mcp';
import { genkit, z } from 'genkit/beta';

const ai = genkit({});

ai.defineTool(
  {
    name: 'estimate_prompt_window',
    description:
      'Estimate prompt size and suggest whether the input should be summarized before sending to an LLM.',
    inputSchema: z.object({
      text: z.string(),
      maxCharacters: z.number().int().positive().default(1200),
    }),
    outputSchema: z.object({
      characters: z.number(),
      words: z.number(),
      withinLimit: z.boolean(),
      recommendation: z.string(),
    }),
  },
  async ({ text, maxCharacters }) => {
    const words = text.trim().length === 0 ? 0 : text.trim().split(/\s+/).length;
    const withinLimit = text.length <= maxCharacters;

    return {
      characters: text.length,
      words,
      withinLimit,
      recommendation: withinLimit
        ? 'Send directly.'
        : 'Summarize or chunk before sending to the model.',
    };
  },
);

const server = createMcpServer(ai, {
  name: 'effloow-genkit-mcp-poc',
  version: '0.1.0',
});

server.start();

The official Genkit MCP docs describe two important surfaces. One is the @genkit-ai/mcp plugin path, which can consume MCP tools or expose Genkit tools and prompts as an MCP server. The other is the separate Genkit MCP Server for AI-assisted development, which exposes project-level capabilities such as flow discovery, flow execution, trace lookup, and documentation lookup to MCP-aware tools. The docs label that developer-assistant server as experimental. This PoC tested the application plugin path, not a production claim about every MCP surface.

For background on the wider protocol, see Effloow's Model Context Protocol explainer and the MCP roadmap guide.

Why Genkit is different from a plain MCP server

A plain MCP server can expose tools. Genkit adds an opinionated AI application layer around those tools: schemas, prompts, flows, model providers, local development UI, deployment hooks, observability, and cloud integration.

That makes Genkit more attractive when the MCP server is part of a larger AI feature rather than a small standalone utility. A customer support assistant, document workflow, RAG endpoint, or developer automation service usually needs more than a function list. It needs typed inputs, policy boundaries, traceable execution, model provider choice, and a path from local development to production hosting.

The tradeoff is dependency weight. The sandbox install added 490 packages. npm audit --omit=dev --audit-level=high reported 23 vulnerabilities, including 7 high-severity findings in transitive OpenTelemetry and Google Cloud dependency chains, with npm reporting no fix available for the highlighted OpenTelemetry chain at the time of the run. That does not mean every Genkit app exposes the vulnerable code path. It does mean production teams should audit their actual deployment, disable unnecessary telemetry exposure, and pin versions consciously.

Local setup that worked

The local setup was:

mkdir -p /tmp/effloow-genkit-mcp-poc/src
cd /tmp/effloow-genkit-mcp-poc
npm init -y
npm install genkit@1.35.0 @genkit-ai/mcp@1.35.0 @modelcontextprotocol/sdk@1.29.0 typescript@latest tsx@latest

Two operational details mattered.

First, the initial npm install failed because the local npm cache had a missing cached object while fetching TypeScript. npm cache verify repaired the cache and garbage-collected stale content.

Second, @genkit-ai/mcp@1.35.0 requires @modelcontextprotocol/sdk@^1.29.0. Installing an older SDK version produced a peer dependency failure. If your team already pins MCP SDK versions for other servers, check that constraint before adding Genkit to the same workspace.

The strict TypeScript build passed:

npm run build

Output:

> effloow-genkit-mcp-poc@1.0.0 build
> tsc --noEmit

Where Cloud Run fits

The backlog topic asked for Genkit, MCP Server, and Cloud Run. The local PoC stops before Cloud Run because that step requires real Google Cloud project setup, billing, credentials, and Secret Manager. Instead of faking a deployment, here is the documented production path.

The official Genkit Cloud Run guide says JavaScript flows can be deployed as HTTPS endpoints using Cloud Run. The deployment path expects a Node project with a start script and optionally a build script. For TypeScript, the docs show the usual node lib/index.js start command and tsc build command. The app then calls startFlowServer from @genkit-ai/express so flows become web endpoints.

The same guide is explicit about credentials. If the deployed flow uses Gemini through Google AI, the docs route the API key through Secret Manager. If the flow uses Vertex AI, the docs route access through project and IAM configuration. It also warns that deployed flows should require authorization; otherwise, a generative AI endpoint can become an expensive public invocation surface.

For a real deployment, the checklist should look like this:

1. Build and test the flow locally.
2. Add start/build scripts for Cloud Run.
3. Serve flows through startFlowServer.
4. Choose Gemini API key via Secret Manager or Vertex AI via IAM.
5. Add authorization before public traffic.
6. Deploy with gcloud run deploy.
7. Test with an authenticated curl request.
8. Enable monitoring and inspect traces.

Effloow Lab did steps 1 and the local MCP equivalent of tool invocation. It did not do steps 2 through 8 in Google Cloud.

Observability is part of the product story

Genkit's production pitch is stronger when you include monitoring. The official monitoring guide says Genkit Monitoring can show quantitative metrics such as latency, errors, and token usage; inspect traces for steps, inputs, and outputs; and export production traces for evals. It also notes that setup requires both codebase changes and Google Cloud Console work, and that telemetry relies on Google Cloud Logging, Metrics, and Trace, which are paid services with their own pricing and free-tier details.

That matters because agent systems fail in non-obvious ways. A user complaint like "the assistant gave a bad answer" is rarely enough. You need to know which tool was called, what input schema was passed, what the model saw, whether retrieval returned weak context, whether a middleware layer blocked or rewrote a request, and where latency accumulated.

For small local tools, console logs may be enough. For a Cloud Run service handling real customer traffic, traces and eval-ready records become part of the engineering requirement.

Middleware and policy boundaries

Google's May 2026 Genkit Middleware announcement frames middleware as a way to intercept, extend, and harden agentic apps. That direction fits the production concerns developers already have: prompt filtering, input transformation, output validation, tool-call policy, trace enrichment, and safety gates.

Do not treat middleware as a magic security layer. Treat it as a programmable control point. A useful Genkit production design should decide where each responsibility lives:

Concern	Better home
Request authentication	Cloud Run IAM, app auth, or authorization policy
Tool input validation	Zod schema plus application checks
Expensive model guardrails	Middleware and quota policy
Prompt/context shaping	Middleware or flow code
Audit trail	Genkit traces plus platform logs
External side effects	Explicit tools with confirmation or narrow credentials

This is the main reason Genkit is worth watching for Firebase and Google Cloud teams. It offers a path where agent logic, deployment, observability, and policy are not separate afterthoughts.

What developers should build first

Start with a local tool-first PoC, not a full agent. Define one typed Genkit tool that solves a real backend problem: summarize a document chunk, classify a support request, normalize a CRM record, or estimate whether a prompt needs compression. Expose it through MCP and call it from an MCP client. Confirm the schema, output format, failure behavior, and dependency footprint.

Then add a model call. Keep the model provider swappable until the interface settles. Genkit supports multiple model providers, but your product code should still avoid spreading provider-specific assumptions across every flow.

Then deploy one authenticated endpoint. Cloud Run is the right next step if your team already uses Google Cloud or Firebase. Do not expose unauthenticated generative endpoints unless the endpoint is intentionally public, rate-limited, and cheap enough to be abused.

Finally, turn on observability before calling the service production. A trace is more valuable before the first incident than after the first incident.

Common mistakes

The first mistake is confusing the two MCP stories. Genkit can expose app tools through @genkit-ai/mcp, and Genkit also has a developer-assistant MCP server that helps AI tools inspect and run Genkit projects. They are related, but not the same production surface.

The second mistake is claiming Cloud Run readiness from a local server boot. Cloud Run adds build scripts, service configuration, secrets, IAM, authorization, and deployment behavior. If you did not run gcloud run deploy, you did not test Cloud Run.

The third mistake is ignoring dependency review because the local demo worked. The sandbox succeeded functionally, but npm audit reported real transitive issues. A production Genkit service needs the same dependency review you would apply to any internet-facing Node service.

The fourth mistake is letting agents call broad tools. A tool named run_shell_command is easy to demo and hard to govern. Prefer narrow, typed tools with business-specific names and constrained parameters.

FAQ

Q: Is Genkit only for Firebase apps?

No. The Genkit homepage describes it as Google's open-source framework for full-stack AI-powered and agentic applications, and the docs cover multiple deployment targets and model providers. Firebase and Google Cloud integrations are a major advantage, but the local TypeScript package can run outside Firebase.

Q: Can Genkit expose MCP tools?

Yes. The Genkit MCP plugin can expose Genkit tools and prompts as an MCP server with createMcpServer. Effloow Lab verified one local typed tool over MCP stdio with a real MCP SDK client.

Q: Did Effloow Lab deploy this to Cloud Run?

No. The lab run stayed local and used no secrets. Cloud Run deployment is documented by Google, but it was not executed in this run.

Q: Should I use Genkit or write a plain MCP server?

Use a plain MCP server when you only need a small tool bridge. Use Genkit when the tool is part of an AI application that also needs flows, model calls, prompts, observability, middleware, and a deployment path.

Key takeaways

Genkit's MCP story is practical enough to test locally today. The TypeScript package exposes typed Genkit tools through MCP, and the local PoC showed a real client invoking one successfully.

The bigger production story is not "MCP server in a weekend." It is a Google-aligned path from local AI logic to Cloud Run endpoints, Firebase/Google Cloud observability, and middleware-based policy controls. That path is useful, but only if teams keep the boundaries honest: local MCP worked, cloud deployment still needs real credentials and verification, and dependency audit findings deserve production attention.

Sources: Genkit overview, Genkit MCP plugin docs, Genkit MCP Server docs, Genkit Cloud Run deployment docs, Genkit Monitoring docs, Google Developers Blog on Genkit Middleware, and npm package metadata checked on 2026-05-27.