Control Plane

Browse Template Catalog

browse_templates

Read-onlyIdempotent

Find templates in the Control Plane Template Catalog: databases, caches, queues, search, storage, gateways, AI, analytics, auth, security, automation, observability, developer tools, and self-hosted products. Pass query naming the capability or product needed ("vector database for RAG", "uptime monitoring with status page", "self-hosted Google Analytics"); when the user describes a goal or problem instead, decide the capability it needs and search for that. Results are ranked, each with a confidence, what must exist before install, and the template to pick instead for other needs. Omit query to list the catalog or one category. An app the user asks you to build, such as a blog, wiki, or shop, is built (plan_app) unless they name a template. Then pass the pick as name for its prerequisites, README notes, and the EXAMPLE values.yaml to copy for install_template. Postgres, MySQL, MariaDB, MongoDB, and Redis install with add_database unless they need a setting it does not take, such as backups.

Input Schema

Name	Required	Description
`name`	No	A template from the results: returns its detail and example values instead of searching.
`limit`	No	Most templates to return (1 to 20; default 5 with query, all without).
`query`	No	The capability or product needed, in plain words; turn a goal or problem into the capability first. Omit to list the catalog.
`version`	No	With `name`: the version to show. Omit for the latest.
`category`	No	One catalog category, such as database, cache, messaging, ai, or apps; the list without a query names them all.
`readmeSection`	No	With `name`: one README section instead of the detail, such as prerequisites or configuration.

Output Schema

Name	Required	Description
`ok`	Yes
`data`	No	The full result. Read this, not only the summary.
`details`	No
`summary`	Yes
`nextSteps`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 22, 2026

addedInput schema / properties / category

Added value: +{
+  "description": "One catalog category, such as database, cache, messaging, ai, or apps; the list without a query names them all.",
+  "type": "string"
+}

removedInput schema / properties / filter

Removed value: -{
-  "description": "Optional case-insensitive substring to narrow by name, category, or description (e.g. \"database\", \"redis\").",
-  "type": "string"
-}

addedInput schema / properties / limit

Added value: +{
+  "description": "Most templates to return (1 to 20; default 5 with query, all without).",
+  "maximum": 20,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / name

Added value: +{
+  "description": "A template from the results: returns its detail and example values instead of searching.",
+  "type": "string"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "The capability or product needed, in plain words; turn a goal or problem into the capability first. Omit to list the catalog.",
+  "type": "string"
+}

addedInput schema / properties / readmeSection

Added value: +{
+  "description": "With `name`: one README section instead of the detail, such as prerequisites or configuration.",
+  "type": "string"
+}

addedInput schema / properties / version

Added value: +{
+  "description": "With `name`: the version to show. Omit for the latest.",
+  "type": "string"
+}

Changed10 schema fields changedSep 30, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / filter / maxLength
```
Removed value: -120
```

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / properties / data / description

Previous value: -"The full machine-readable result — list rows, the resource object, query results. Read THIS, not just the summary."New value: +"The full result. Read this, not only the summary."

addedOutput schema / properties / details
```
Added value: +{
+  "type": "string"
+}
```

removedOutput schema / properties / nextSteps / description

Removed value: -"Recommended follow-up actions for this task, in order."

removedOutput schema / properties / ok / description
```
Removed value: -"Whether the call succeeded."
```
removedOutput schema / properties / summary / description
```
Removed value: -"One-line summary of the result."
```

First observedJun 28, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a safe read-only, idempotent, non-open-world lookup, so the description does not need to restate safety. It adds substantive behavior beyond them: results are ranked, each carries a confidence and install prerequisites, alternatives are suggested for other needs, and detail mode returns README notes and an example values.yaml to copy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and category coverage, then the query/name/category modes, then routing to plan_app, install_template, and add_database, so every part has a role. It runs long across several sentences, but the length comes from useful routing detail rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety, the description still covers the modes (search, list, detail), the decision between goal and capability, and the handoffs to plan_app, install_template, and add_database. Nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: `query` should hold a capability or product rather than a raw goal, `name` switches from search to detail mode, and `category` scopes a listing when no query is given. That clarifies how the optional parameters interact, which the schema alone does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Find templates in the Control Plane Template Catalog') and enumerates the catalog's coverage. It explicitly distinguishes itself from siblings plan_app, install_template, and add_database, so an agent can tell which tool applies without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use rules: name the capability in `query` if the user names one, derive the capability first if they describe a goal, omit `query` to list the catalog or one `category`, and use `name` for detail instead of searching. It also names the alternatives and the conditions that select them: build requests go to plan_app, and Postgres/MySQL/MariaDB/MongoDB/Redis go to add_database unless a setting such as backups is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Control Plane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.