Skip to main content
Glama
Sign In

Tier 1 Protocol

by app.tier1protocol.mcp
OverviewDiscussionsAdmin

Inspect Tier 1 source coordinates

render_context_results
Read-onlyIdempotent

Inspect one to six exact coordinates returned by paid Tier 1 search. Pass only unchanged result ids. Tier 1 rehydrates and revalidates each id for the same account; caller-supplied titles, excerpts, URLs, and coordinates are rejected. Authentication and an active paid plan are required.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "render_context_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsYesOne to six exact result ids returned by Tier 1 search for this signed-in account. Never pass caller-authored result objects.

Output Schema

NameRequiredDescriptionDefault
resultsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Adds real behavior beyond the annotations: authentication plus an active paid plan are required, ids are rehydrated and revalidated against the same account, and caller-supplied titles, excerpts, URLs, and coordinates are rejected. What it omits is what happens to stale or cross-account ids (error vs. silent drop) and any rate limits, which matters for a read tool an agent may call repeatedly.

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?

Four tight sentences with the core action and cardinality front-loaded, then constraints, then auth. There is mild overlap between 'pass only unchanged result ids' and the later list of rejected caller-supplied fields, but nothing is padded.

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?

For a single-parameter read tool with full annotation coverage and an output schema, the description supplies everything an agent needs to call it correctly: provenance requirement, cardinality, account scoping, rejection rules, and auth/plan prerequisites. Return-value details are correctly delegated to the output schema.

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

Parameters3/5

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

Schema coverage is 100% and the ids parameter already documents 'one to six exact result ids... Never pass caller-authored result objects.' The description restates the same constraints ('pass only unchanged result ids', caller-supplied fields rejected) rather than adding new semantics such as id format or provenance, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb ('inspect') and a precisely scoped resource ('one to six exact coordinates returned by paid Tier 1 search'), which is far more useful than the title's generic 'Tier 1 source coordinates'. It implicitly separates this from 'search' by requiring ids that search already produced, but it never names the sibling 'fetch' or clarifies how this differs from it.

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

Usage Guidelines4/5

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

Gives clear preconditions for use: only after a paid Tier 1 search, and only with unchanged result ids. It does not state when to prefer this over 'fetch' or 'search', so the routing decision between siblings is left partly to inference.

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

All Tier 1 Protocol toolsInspect
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.

Resources