Google just open-sourced a repository that shows how a cloud vendor packages domain knowledge for agent consumption. The Skills repo contains MCP servers for Google Cloud, Firebase, BigQuery, and other products. Each skill wraps documentation and best practices into a callable interface that agents can invoke without custom SDK integration.
This is not a new API. It is a structured way to expose existing product knowledge so agents can reason about Google Cloud without hallucinating or requiring developers to manually embed docs in prompts.
What Skills Actually Are
A skill is an MCP server that exposes product documentation, recipes, and architectural guidance as tools. Each skill lives in its own directory with:
- A Markdown file containing the knowledge base (product features, CLI commands, configuration patterns)
- A manifest that declares what the skill does and how agents should invoke it
- Optional code to transform queries into structured responses
The repository includes skills for:
- Product basics: Gemini API, AlloyDB, BigQuery, Cloud Run, Cloud SQL, Firebase, GKE
- Recipes: Onboarding flows, authentication patterns, network observability
- Well-Architected Framework: Security, reliability, cost optimization, operational excellence, performance, sustainability
Each skill is a separate MCP server. You install them via npx skills add google/skills, which suggests a registry-based distribution model where skills are versioned artifacts, not just cloned files.
Manifest Structure and Tool Boundaries
The key design question is what gets exposed as a callable tool versus what stays in context. MCP servers can:
- Provide context: Inject documentation into the agent’s prompt so it can reason about the product
- Expose tools: Offer callable functions that return structured data or perform actions
Google’s Skills lean toward the first model. The Markdown files are knowledge bases, not imperative APIs. When an agent asks “How do I set up Cloud Run?”, the skill returns relevant sections of the documentation rather than executing a gcloud run deploy command.
This is a deliberate trade-off:
| Approach | Pros | Cons |
|---|---|---|
| Context injection | No execution risk, agent retains control, easy to audit | Token-heavy, requires agent to parse and synthesize, no validation |
| Callable tools | Structured output, can validate inputs, lower token cost | Requires execution boundary, harder to version, security surface |
Google chose context injection for most skills because the goal is to help agents reason about Google Cloud, not to automate it. The Well-Architected Framework skills are pure guidance: they return checklists and design principles, not API calls.
Deployment Model
The npx skills add command installs skills locally. This means:
- Client-side execution: The MCP server runs in the same environment as the agent (your laptop, a CI runner, a cloud function)
- No hosted service: Google is not running a centralized skill registry or execution layer
- Agent framework integration: The agent framework (Claude Desktop, LangChain, custom orchestrator) manages the MCP connection
This is a pull model, not a push model. You declare which skills your agent needs, and the framework loads them at runtime. The skills themselves are stateless: they read Markdown files and return text.
The registry-based installation suggests a versioning story, but the repository does not yet expose a schema evolution mechanism. If Google updates the BigQuery Basics skill to add new features, agents that depend on the old schema will see new content without warning. MCP does not have a built-in version negotiation protocol, so you must handle this in your agent’s prompt or tool selection logic.
Example: BigQuery Basics Skill
The BigQuery Basics skill is a single Markdown file with sections on:
- What BigQuery is and when to use it
- How to create datasets and tables
- Query syntax and optimization patterns
- Cost management and slot allocation
When an agent invokes this skill, the MCP server returns the full Markdown or a filtered subset based on the query. The agent then synthesizes the response into an answer.
Here is how you would wire this into a custom agent:
from mcp import MCPClient
client = MCPClient()
client.add_skill("google/skills/cloud/bigquery-basics")
# Agent asks: "How do I partition a BigQuery table?"
response = client.query_skill(
skill="bigquery-basics",
query="table partitioning"
)
# response contains Markdown sections on partitioning strategies
# Agent synthesizes this into a user-facing answerThe skill does not execute queries or create tables. It provides the knowledge an agent needs to generate correct bq commands or SQL statements.
Recipes vs. Product Skills
The repository distinguishes between product skills (BigQuery, Cloud Run) and recipes (onboarding, authentication). Recipes are multi-product workflows that combine several skills.
For example, the Onboarding recipe covers:
- Creating a Google Cloud project
- Enabling billing
- Setting up IAM roles
- Installing the
gcloudCLI
This is not a single API call. It is a sequence of steps that an agent must orchestrate. The recipe skill provides the checklist and decision tree, but the agent must decide which steps to execute and in what order.
This is where MCP’s statelessness becomes a constraint. The skill cannot track which steps the user has completed or maintain session state across invocations. The agent must handle that in its own state machine.
Security and Observability Gaps
Because skills run client-side, there is no centralized audit log. If an agent queries the Security Well-Architected Framework skill and then misconfigures a firewall rule, you cannot trace the decision back to the skill invocation unless your agent framework logs MCP calls.
You also cannot enforce access control at the skill level. If a skill is installed, any agent in that environment can invoke it. This is fine for documentation skills but risky if skills evolve to include executable tools (e.g., a skill that provisions Cloud Run services).
Google has not yet published guidance on:
- How to version skills without breaking agents
- How to audit skill invocations in production
- How to sandbox skills that perform actions vs. return context
These are open questions for the MCP ecosystem, not just Google’s implementation.
When Skills Make Sense
Skills work well when:
- Documentation is stable: Product APIs change slowly, so the knowledge base does not churn
- Agents need broad context: You want the agent to reason about trade-offs, not just execute commands
- You control the agent environment: You can install skills locally and manage versions
Skills are a poor fit when:
- You need real-time data: Skills are static Markdown files, not live API wrappers
- You want execution guarantees: Skills do not validate inputs or enforce constraints
- You need centralized governance: Client-side execution makes it hard to audit or revoke access
Technical Verdict
Google Skills is a pragmatic way to package product documentation for agent consumption without building custom SDKs. The MCP server model keeps the implementation simple (Markdown files, no execution layer), but it pushes complexity to the agent framework (state management, version handling, observability).
Use this pattern when:
- You have stable documentation that agents need to reference frequently
- You want agents to reason about your product, not automate it
- You can tolerate client-side execution and local skill management
Avoid this pattern when:
- You need real-time API integration or stateful workflows
- You require centralized audit logs or access control
- Your documentation changes frequently and agents need schema evolution guarantees
The repository is under active development, so expect the manifest structure and distribution model to evolve. Watch for how Google handles versioning, observability, and the transition from context injection to callable tools.