Skip to main content
Glama

Find, list and read templates

super_templates
Read-only

With request: rank installed templates by content similarity; matches carry band (high: build from it; possible: judge it), why and unscored stats. scope: marketplace: released public templates, ranked by request or else the top by sort; sort, limit and the facets apply only here. Neither: the installed list. slug: one template in full, with its installPrompt; history: its changelog; feedback: its artifacts' comments as themes. mine: your published templates, with counts. Reading only: installing, rating and rolling back are super_template_action.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "super_templates"
  }
}

Input Schema

NameRequiredDescriptionDefault
costNofill: you send a document; write: you write the page; build: page and policy.
jobsNoAny of.
kindNoA label, not a capability.
mineNo
slugNo
sortNoDefault relevance with `request`, else rating.
tierNoMarketplace trust tier: Official, Verified or Community.
limitNoDefault 5.
needsNoAll of. `["runtime"]`: ships code.
scopeNoDefault installed.
trustNoDeprecated alias of `tier`.
historyNo
requestNoWhat the person asked for, in their words.
versionNoDefault: the released one.
audienceNoAny of.
categoryNoDeprecated; read as `jobs` when `jobs` is absent.
feedbackNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / tier / description
      Added value: +"Marketplace trust tier: Official, Verified or Community."
    • addedInput schema / properties / trust / description
      Added value: +"Deprecated alias of `tier`."
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare this a non-destructive read, so the description spends its budget on behaviors annotations can't express: matches return `band` (high/possible), `why`, and unscored stats, and `sort`/`limit`/facets are scoped to marketplace only. This is return-shape and scoping context that would otherwise be invisible given there is no output schema.

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?

Highly compressed, front-loaded with the most common mode (`request`), and no sentence is filler. The telegraphic semicolon style and fragments like 'Neither: the installed list' demand careful parsing but are decodable against the schema's `scope` enum.

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

Completeness4/5

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

For a 17-parameter, zero-required dispatch tool with no output schema, the description covers the mode routing and the returned ranking fields well. The gap is the marketplace filter facets, which are only gestured at as 'the facets' and never defined, though schema coverage at 76% partly compensates.

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?

With 76% schema coverage the baseline is 3, and the description earns above that by explaining the mode-switching parameters the schema leaves bare or ambiguous: `slug`, `history`, `feedback`, `mine`, and the conditional application of `sort`/`limit`. It says nothing about the filter facets (`cost`, `jobs`, `kind`, `tier`, `audience`, `needs`, `version`), leaving those entirely to the schema.

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?

The description states a specific resource (templates) and enumerates the exact read modes: similarity ranking via `request`, marketplace browsing with `scope: marketplace`, the plain installed list, and single-template reads via `slug`/`history`/`feedback`/`mine`. It explicitly draws the boundary against the sibling: 'Reading only: installing, rating and rolling back are super_template_action.'

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?

Every parameter combination is paired with its outcome ('With `request`: rank installed templates...', 'Neither: the installed list', '`slug`: one template in full'), which functions as an explicit when-to-use map. It also names the alternative tool for the mutating cases and tells the agent where the facets do and do not apply.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources