Integration Create

ADK Integration Page Creator (integration-create)

This skill creates a new integration page for the

adk-docs repository. Integration pages

live under docs/integrations/ and are auto-discovered into a card catalog. The

output of this skill is a strong starting point, not a finished page: when done,

run the integration-review skill on it and test with mkdocs serve.

The real template is the set of existing shipping pages. Before drafting,

open the exemplar(s) for the chosen category and match their structure and

conventions:

• MCP tools: docs/integrations/github.md, docs/integrations/notion.md
• Observability: docs/integrations/phoenix.md, docs/integrations/arize-ax.md
• Plugins: docs/integrations/daytona.md, docs/integrations/goodmem.md

To find more similar pages, scan catalog_tags in one pass (`grep catalog_tags

docs/integrations/*.md`) and read the ones sharing the category's tag (e.g.

mcp, observability) or product domain in full. Match live pages and repo

conventions rather than inferring everything from the templates below.

See CONTRIBUTING.md (the "Integrations" section) for the human-facing

contract. For the full rulebook applied during review, see the

integration-review skill.

Step 1: Gather inputs

Ask the user for whatever is not already provided:

• Product / integration name (drives catalog_title and the H1).
• Category, which selects the template:
• MCP tool (an MCP server the agent connects to)
• Observability (tracing / metrics / evaluation exporter)
• Plugin (an installable package exposing tools or callbacks)
• Language support: Python only, or Python + TypeScript.
• Package name (PyPI / npm) and install command.
• Connection style for MCP: local (stdio) and/or remote (HTTP).
• Tools or methods the integration exposes (for the table).
• Links: product docs, GitHub repo, PyPI/npm, where to get an API key.
• Icon: confirm an asset will be added at

docs/integrations/assets/<slug>.png.

Step 2: Choose the filename

• Use a short, lowercase, hyphenated slug based on the product or technology

name.

• Avoid adk- or other prefixes that would float the card to the top of the

alphabetically sorted catalog.

• Create the file at docs/integrations/<slug>.md.

Step 3: Draft the page

Use the frontmatter and the category skeleton below. Fill each section by

reading the exemplar page(s) for the same category and adapting their prose and

code.

Do not add a mkdocs.yml nav entry; pages are auto-discovered by

render_catalog('integrations/*.md'). Add a redirect only if this page replaces

an existing URL, and never chain redirects.

Step 4: Hand off

Tell the user this is a draft, then:

• Remind them to add the icon asset at docs/integrations/assets/<slug>.png

(square, reasonably sized) and any screenshots.

• Recommend running the integration-review skill on the new page.
• Recommend mkdocs serve to confirm the card renders and the icon loads.

Frontmatter (all categories)

---
catalog_title: <Display Name>
catalog_description: <short verb-led phrase>
catalog_icon: /integrations/assets/<slug>.png
catalog_tags: ["<tag>", "<tag>"]
---

• catalog_description: short and verb-led, roughly 45 to 75 characters (about

6 to 11 words); keep it under ~80 so it does not wrap awkwardly on a card. Do

not repeat the product name (the title shows it). No verbose lists, no

overclaims.

• catalog_tags: use only tags that already exist in the catalog; never invent

one. Enumerate the valid tags in one pass with

grep catalog_tags docs/integrations/*.md. Tags combine. Any page that uses

MCP must include mcp.

• catalog_icon: /integrations/assets/<slug>.png (or .svg or .jpg). No

/adk-docs/ prefix.

H1 and language support tag (all categories)

# <Product> <type> for ADK

<type> is MCP tool, observability, or plugin per category. Immediately

after the H1, add the language support div (spans must be on a single line; drop

the TypeScript span if Python-only):

<div class="language-support-tag">
  <span class="lst-supported">Supported in ADK</span><span class="lst-python">Python</span><span class="lst-typescript">TypeScript</span>
</div>

Skeleton: MCP tool

## Use cases

- **<Use case>**: <what the user accomplishes>
- **<Use case>**: <...>

## Prerequisites

- <account, API key, or token, with a link to where to get it>

## Use with agent

=== "Python"

    === "Remote MCP Server"

from google.adk.agents import Agent

from google.adk.tools.mcp_tool import McpToolset

from google.adk.tools.mcp_tool.mcp_session_manager import StreamableHTTPConnectionParams

root_agent = Agent(

model="gemini-flash-latest",

name="<slug>_agent",

instruction="Help users get information from <Product>",

tools=[

McpToolset(

connection_params=StreamableHTTPConnectionParams(

url="<server url>",

headers={"Authorization": "Bearer YOUR_TOKEN"},

),

)

],

)

=== "TypeScript"

    === "Remote MCP Server"

import { LlmAgent, MCPToolset } from "@google/adk";

const rootAgent = new LlmAgent({

model: "gemini-flash-latest",

name: "<slug>_agent",

instruction: "Help users get information from <Product>",

tools: [

new MCPToolset({

type: "StreamableHTTPConnectionParams",

url: "<server url>",

}),

],

});

export { rootAgent };

## Available tools

Tool | Description
---- | -----------
`<tool>` | <what it does>

## Additional resources

- [<Product> Documentation](<url>)
- [<Product> Repository](<url>)

Include both Local MCP Server (stdio) and Remote MCP Server sub-tabs when

the server supports both. Add a ## Configuration section for optional headers

or environment variables.

Skeleton: Observability

<one-paragraph intro of what the platform provides for ADK>

## Overview

- **<Capability>**: <...>
- **<Capability>**: <...>

## Installation

pip install <package>

## Setup

<API keys, environment variables, and instrumentor initialization>

## Observe

<a complete, runnable ADK agent example that is traced end-to-end>

## Support and Resources

- [<Platform> Documentation](<url>)
- [<Platform> Repository](<url>)

A single copy-pasteable end-to-end code block is acceptable and often better

than splitting Setup and Observe.

Skeleton: Plugin

## Use cases

- **<Use case>**: <...>

## Prerequisites

- <account / API key with link>

## Installation

pip install <package>

## Use with agent

from <package> import <Plugin>

from google.adk.agents import Agent

root_agent = Agent(

model="gemini-flash-latest",

name="<slug>_agent",

instruction="<what the agent does>",

tools=<plugin>.get_tools(),

)

## Available tools

Tool | Description
---- | -----------
`<tool>` | <what it does>

## Additional resources

- [<Product> Documentation](<url>)
- [<Product> on PyPI](<url>)
- [<Product> on GitHub](<url>)

Add a ## Configuration section for environment variables when relevant.

Style rules to bake in

• Model strings should be gemini-flash-latest, gemini-pro-latest, or other

valid *-latest aliases in sample code rather than specific versioned model

strings, which increase the maintenance burden when new model versions are

released.

• Imports: from google.adk.agents import Agent; MCP uses

from google.adk.tools.mcp_tool import McpToolset. Agent variable is

root_agent (Python) / rootAgent (TypeScript, with export { rootAgent };).

• No em dashes or verbose AI-generated content: Use a colon in `term:

definition` bullets; split prose into sentences otherwise.

• When referring to ADK, use "ADK", never "Google ADK" or "The ADK".
• Do not start a sentence with an inline-code word.
• Internal ADK-docs links are site-relative (e.g. /sessions/memory/); external

links must resolve. Do not invent links.

• Verify all code samples against actual APIs and library code. The canonical

source repositories are listed in docs/community/contributing-guide.md.

• Confirm that the package exists on PyPI/npm, before presenting the draft.