Genkit's most useful 2026 story is not that Google has another AI framework. It is that a TypeScript team can define typed AI actions locally, expose them through Model Context Protocol, and then move the same application shape toward Cloud Run, Secret Manager, IAM, and production telemetry.
Effloow Lab ran the local part of that path on 2026-05-28. The sandbox installed current genkit and @genkit-ai/mcp packages, defined one deterministic deployment-risk tool, exposed it with createMcpServer, connected with the official MCP SDK client, listed the tool, and called it successfully. The evidence note is in data/lab-runs/genkit-2-mcp-server-cloud-run-sandbox-poc-2026.md.
The boundary matters. This was a local MCP server PoC, not a Cloud Run deployment. No Google Cloud project, billing account, Secret Manager secret, Cloud Trace screenshot, Gemini call, or public endpoint was used. The Cloud Run and observability sections below are based on Google's current documentation, not on a live Effloow deployment.
Why This Matters
MCP makes tools discoverable to agents. Genkit makes those tools part of a broader AI application surface: schemas, flows, prompts, model providers, local development, deployment, middleware, and telemetry. That combination is useful when the tool is not a toy add(a, b) function, but a business workflow that must be typed, audited, and deployed behind a real platform boundary.
Google's Genkit docs describe the framework as open source and built for full-stack AI-powered and agentic applications across TypeScript, Go, Dart preview, and Python preview. The Genkit MCP plugin docs say the same package can consume MCP servers as a client or expose Genkit tools and prompts as an MCP server using createMcpServer. The Cloud Run deployment docs then explain how Genkit flows can become HTTPS endpoints on Cloud Run, with explicit attention to start scripts, credentials, and authorization.
That is the production-shaped idea: local typed agent tools first, then deployment and monitoring after the behavior is small enough to verify.
What Effloow Lab Verified
The sandbox used /tmp/effloow-genkit-mcp-poc and installed:
genkit@1.36.0
@genkit-ai/mcp@1.36.0
@modelcontextprotocol/sdk@1.29.0
Node.js v25.9.0
npm 11.12.1
The local server defined one tool called riskScore. It accepts changed file paths and two booleans, then returns a deterministic risk score, label, and reason list. This deliberately avoided any model call. A model-backed demo would have added API-key and output-variance questions before proving the MCP wiring.
The verification client output was:
tools: riskScore
riskScore result: [{"type":"text","text":"{\"score\":75,\"label\":\"high\",\"reasons\":[\"authentication surface changed\",\"database migration present\"]}"}]
That output supports one narrow claim: a Genkit-defined TypeScript tool can be exposed through the Genkit MCP plugin and invoked by a real MCP SDK client over stdio in a local sandbox.
The Minimal Server Shape
The important code path is short:
import { createMcpServer } from '@genkit-ai/mcp';
import { genkit, z } from 'genkit/beta';
const ai = genkit({});
ai.defineTool(
{
name: 'riskScore',
description: 'Classify a deployment change by deterministic risk rules.',
inputSchema: z.object({
changedFiles: z.array(z.string()),
touchesAuth: z.boolean().default(false),
touchesBilling: z.boolean().default(false),
}),
},
async ({ changedFiles, touchesAuth, touchesBilling }) => {
let score = Math.min(changedFiles.length * 10, 40);
if (touchesAuth) score += 35;
if (touchesBilling) score += 30;
if (changedFiles.some((file) => file.includes('migration'))) score += 20;
const capped = Math.min(score, 100);
return {
score: capped,
label: capped >= 70 ? 'high' : capped >= 35 ? 'medium' : 'low',
};
},
);
const server = createMcpServer(ai, {
name: 'effloow_genkit_mcp_poc',
version: '0.0.1',
});
server.start();
The Genkit docs show the same core pattern: define tools or prompts on a Genkit instance, call createMcpServer, and start the server. By default, the server uses stdio transport. That makes it easy to wire into local agent tools before deciding whether the production interface should become Streamable HTTP, an HTTPS flow endpoint, or a narrower internal service.
Local PoC Results
The good news: the current package set installed cleanly and the MCP call worked on the first run after the server and verifier files were written.
The less comfortable news: npm audit --omit=dev reported 23 vulnerabilities in the installed dependency tree, including 7 high-severity items. That is not proof that this local demo exposes a vulnerable route. It is a concrete signal that production teams should pin versions, review transitive dependency paths, and keep Genkit apps in the same dependency-review loop as any other internet-facing Node service.
The dependency count was also large: npm reported 486 total dependencies when optional and peer dependencies were included. That is normal for a cloud-integrated AI framework, but it changes the maintenance profile compared with a tiny hand-written MCP server.
Where Cloud Run Fits
Google's Cloud Run deployment guide for Genkit says Genkit flows can be deployed as HTTPS endpoints using Cloud Run. The guide expects a Node project with a start script and, for TypeScript projects, usually a build script. It also shows startFlowServer from @genkit-ai/express as the path for serving flows as web endpoints.
The production checklist is not just "run deploy":
1. Keep the local tool or flow deterministic enough to test.
2. Add Node start/build scripts for Cloud Run.
3. Serve selected flows through startFlowServer.
4. Decide whether the model provider uses Gemini API keys or Vertex AI.
5. Put Gemini API keys in Secret Manager if using Google AI.
6. Use IAM or an application-level authorization policy.
7. Deploy with gcloud run deploy.
8. Test with an authenticated request.
9. Inspect logs, metrics, and traces before calling it production.
The official docs warn that deployed flows should require authorization because unauthenticated generative endpoints can become expensive public invocation surfaces. That warning should be treated as a design requirement, not a footnote.
MCP Server vs Flow Endpoint
There are two related but different deployment decisions.
An MCP server is best when an agent client needs to discover and call tools, prompts, or resources. Locally, stdio is convenient because the host can launch the process. Remotely, the transport and authorization model become part of the product design.
A Genkit flow endpoint is best when an application or service calls a known workflow over HTTPS. Cloud Run fits this route well because it gives teams a managed container boundary, IAM options, environment configuration, and Google Cloud observability.
For many teams, the practical path is to start with MCP locally, then expose the production workflow as an authenticated Genkit flow endpoint. Do not publish a broad remote MCP surface unless you have a clear client, a narrow authorization policy, and a way to audit tool calls.
Observability Is Not Optional
Genkit Monitoring docs describe production telemetry for latency, errors, token usage, trace inspection, and exporting traces for evals. The docs also say setup requires both code changes and Google Cloud Console work, and that telemetry relies on Google Cloud Logging, Metrics, and Trace.
For an agent tool, that matters more than a normal API route. If a tool call causes the wrong side effect, you need to know which input schema arrived, what context was attached, which model or middleware touched the request, and whether the output was blocked, transformed, or passed through.
The lab run did not create Cloud Trace evidence. A production-ready follow-up should include a real Cloud Run request, the service URL, the authenticated curl command, and a trace or monitoring record that proves the deployed endpoint was actually invoked.
Middleware and Policy Boundaries
Google's May 2026 Genkit Middleware announcement describes middleware as a way to intercept, extend, and harden agentic apps. That fits the exact risks that appear when MCP tools move from local demos to production: input validation, model fallback, retries, logging, redaction, policy gates, and tool-call review.
Middleware should not replace platform security. Use it as an application control point. Authentication belongs in IAM, app auth, or a well-tested authorization layer. Secret access belongs in Secret Manager or provider IAM. Tool-specific safety belongs in narrow schemas and business logic. Middleware is where you can add cross-cutting checks and traces without scattering that code through every flow.
| Layer | Use It For | Do Not Use It For |
|---|---|---|
| Typed Genkit tool | Business-specific action with schema validation | Generic shell or broad database access |
| MCP stdio server | Local agent integration and development workflow | Public production access |
| Cloud Run flow endpoint | Authenticated production workflow behind platform controls | Unbounded anonymous model calls |
| Genkit Monitoring | Trace, latency, error, and token visibility | A substitute for tests or authorization |
How to Build the First Production Candidate
Start with one tool that has a business name. riskScore, classifyRefundRequest, or normalizeInvoiceLine is easier to govern than runCommand.
Make the tool deterministic before adding a model. If the schema, MCP discovery, and client call do not work without a model, adding Gemini will make the failure harder to diagnose.
Add model calls only after the interface is stable. Genkit supports multiple providers, but provider flexibility does not help if the product contract is vague.
Move to Cloud Run only after local behavior is boring. At deployment time, the real work is IAM, secrets, authorization, telemetry, and rollback. The function body should already be the least surprising part of the system.
Common Mistakes
The first mistake is claiming Cloud Run readiness from a local MCP server. A local stdio server proves wiring, not deployment.
The second mistake is exposing too much tool surface. MCP makes tools easier for agents to call, so broad tools become broad risk.
The third mistake is treating observability as a later enhancement. Agent failures often require trace-level evidence, not just an application log line.
The fourth mistake is ignoring npm audit because a demo worked. The sandbox's audit output does not mean Genkit is unusable, but it does mean production dependency review is mandatory.
FAQ
Q: Can Genkit expose a TypeScript tool as an MCP server?
Yes. The Genkit MCP plugin supports exposing Genkit tools and prompts as an MCP server with createMcpServer. Effloow Lab verified one local tool with a real MCP SDK client.
Q: Did Effloow Lab deploy this Genkit MCP server to Cloud Run?
No. The lab run stayed local. Cloud Run deployment, Secret Manager setup, IAM policy, and Cloud Trace inspection still need a real Google Cloud project.
Q: Should production use MCP or HTTPS flow endpoints?
Use MCP when agent clients need tool discovery. Use authenticated HTTPS flow endpoints when your application already knows the workflow it wants to call. For many production teams, the endpoint path is easier to govern.
Q: Is Genkit only for Firebase?
No. Genkit is closely aligned with Firebase and Google Cloud, but the docs present it as an open-source framework for AI-powered and agentic apps across multiple providers and deployment targets.
Key Takeaways
Genkit's TypeScript MCP path works locally with the current packages. The sandbox exposed a typed tool, listed it through the MCP SDK, and called it successfully without secrets or model APIs.
The production story is promising but stricter: Cloud Run requires real project setup, credentials, authorization, deployment verification, and observability evidence. Until those steps are run, the honest claim is local MCP validation plus a documented Cloud Run path.
For a team building AI infrastructure, that is still useful. Start with a narrow typed tool, verify MCP locally, treat dependency audit output seriously, then graduate only the smallest stable workflow into an authenticated Cloud Run service.
