One tool contract across two runtime dialects

You define a tool once with its name, description, schema, and execute function. The framework derives what the model receives and what an MCP client inspects from that single object, keeping YAML declarations aligned with the running code.

tools:
  - "web_search"
  - "web_extract"
  - "preload_memory"

A subagent declares tools by name in its tools list. The runtime skips unrecognized names with an explanatory warning and continues execution. You can also supply an mcp_server_url to discover and mount tools from an external server at runtime.

One contract derives both tool interfaces

You declare the contract once with defineTool. From it, toFunctionTool derives the model tool through toGeminiSchema and toMcpToolDefinition derives the MCP inputSchema through toStandardJsonSchema; both dialects cannot drift, and validation failures return to the model as text.

The web and X

These tools run web search and page reading through provider-native search capabilities where supported, falling back to client-side extraction for local models.

web_search

This tool performs web search through the model provider’s native grounding APIs, including Gemini grounding, Anthropic web_search, OpenAI web_search, and xAI live search. The runtime omits the tool with a warning when you execute agents on local models.

Runs on

Gemini, Claude, GPT, Grok. Omitted with a warning on local models.
web_extract

This tool fetches web pages directly and returns unsummarized text formatted as markdown. Use it after web_search or with known URLs to read full articles. Long documents return a head-and-tail window with an omission marker. It runs across all providers without keys.

Runs on

Every provider, including local models. No key.
x_api_search

This tool searches X posts from the past seven days using boolean keyword matching against the X API, requiring X_BEARER_TOKEN. It returns matching posts ordered by relevance with handles, dates, metrics, URLs, and image transcriptions. It executes across all model providers.

Runs on

Every provider.

Needs

X_BEARER_TOKEN on the server
x_search

This tool runs live searches over X posts through xAI Agent Tools. It operates exclusively on grok-* models. When assigned to subagents using other model providers, the tool executes as a no-op sentinel.

Runs on

Grok models only. A no-op on every other provider.
collections_search

This tool performs semantic search over hosted xAI Collections using Agent Tools on grok-* models. You specify the target document stores through XAI_COLLECTION_IDS. On non-Grok providers, invocations execute as a no-op sentinel.

Runs on

Grok models only.

Needs

XAI_COLLECTION_IDS
google_search

This tool provides ADK grounding support specifically for Gemini models, retained for backward compatibility. New syndicate configurations should declare web_search to maintain provider portability across models.

Runs on

Gemini only.

Images

The generator creates images from structured payloads, while the inspector conducts blind visual inventories without access to the generation specification.

generate_image

This tool generates an image from an approved structured payload specifying prompt, style, aspect ratio, and palette. It saves the resulting file to the outputs/ directory and returns the file path. It runs on Gemini image models and requires GOOGLE_GENAI_API_KEY.

Runs on

Gemini image models.

Needs

GOOGLE_GENAI_API_KEY
inspect_image

This tool conducts a blind visual inventory of a saved image using Gemini vision models, requiring GOOGLE_GENAI_API_KEY. It accepts only the file path returned by generate_image, recording counts, composition, lighting, palette, and artifacts without prior context to prevent primed observations.

Runs on

Gemini vision models.

Needs

GOOGLE_GENAI_API_KEY

Memory

Long-term memory stores user-siloed facts in Supabase pgvector, tracking dates, sources, active or superseded statuses, and named entities.

preload_memory

This ADK tool loads stored facts for a specific user into the model context before the initial turn begins. It reads records from Supabase pgvector, retrieving dates, sources, active or superseded statuses, and entity keys siloed by user_key across all providers.

Runs on

Every provider.

Needs

Supabase with the memory schema
load_memory

This ADK tool recalls user facts during conversation using hybrid search over Supabase pgvector. It combines vector similarity with in-process re-ranking across query entities and dates. Superseded facts remain visible under relabelled statuses, and CORRECTION records update previous entries across all providers.

Runs on

Every provider.

Needs

Supabase with the memory schema

The knowledge bundle

These tools expose a repository manual as a queryable knowledge bundle with a typed entity graph, which the framework runs on its own codebase.

wiki_map

This tool establishes orientation within the knowledge bundle by returning its purpose, directory structure, document census, and entity graph health. You invoke it at the start of a documentation task before issuing targeted queries with wiki_search, wiki_read, or wiki_dive.

Runs on

Every provider.
wiki_search

This tool performs lexical search across bundle titles, tags, headings, file paths, and body text. It returns ranked document paths with matching snippets so the agent can select specific paths to inspect with wiki_read. It runs across all providers.

Runs on

Every provider.
wiki_read

This tool reads a document or section from the knowledge bundle by path, such as /memory/schema.md. It returns the YAML frontmatter, markdown content, and incoming and outgoing links, allowing the agent to follow connected paths for broader context.

Runs on

Every provider.
wiki_links

This tool traverses the knowledge graph from a starting document out to a designated depth. It maps both incoming and outgoing links, surfacing structurally related concepts that lexical search queries miss. It runs across all model providers.

Runs on

Every provider.
wiki_dive

Given a specific task, this tool constructs an ordered reading plan within a defined word budget. It surfaces orientation indexes first, matches relevant concepts, and appends graph-linked context deterministically. You then inspect the recommended documents using wiki_read across any provider.

Runs on

Every provider.
wiki_graph

This tool queries the typed entity graph connecting agents, syndicates, models, providers, tools, MCP servers, tables, environment variables, scripts, and documents. It resolves relational questions across typed links such as uses_tool, imports, and reads_table across all model providers.

Runs on

Every provider.
wiki_relate

This tool records a single judgment relation derived from prose, such as depends_on, supersedes, or contradicts, requiring supporting citations or source paths. The runtime rejects automated structural relations like uses_tool or imports, which the build pipeline derives independently.

Runs on

Every provider.
wiki_save

This tool creates or updates a concept document with required YAML frontmatter. Validation gates enforce markdown formatting and linting rules before writing, while the index and change log update automatically. The system prohibits direct writes to reserved files like index.md and log.md.

Runs on

Every provider.
wiki_query MCP only

This tool answers natural language questions over MCP by running an internal agent across wiki_map, wiki_search, wiki_read, and wiki_links with bundle citations. It is served exclusively to external MCP clients such as Claude Code and cannot be declared in syndicate YAML files.

Runs on

MCP clients.
wiki_garden MCP only

This tool delegates documentation updates to a gardener agent over MCP. The agent inspects existing pages, writes additions through the validated wiki_save gate, and reports specific diffs. It is served exclusively to external MCP clients and cannot be declared in syndicate YAML files.

Runs on

MCP clients.