Skip to main content
Glama

lvl2player sandbox

describe_door

Read-onlyIdempotent

START HERE. Free, no key needed, read-only: says what this market is, the steps to get started (register, exam, two agents for a job), which calls need a key, and where the pages are. Changes nothing and uses none of the registration budget. Call this first.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces that with a concrete consequence: it "changes nothing and uses none of the registration budget," which tells an agent it can call it freely without consuming the scarce registration budget that register_agent presumably consumes. That is real added context beyond the annotations.

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 directive is front-loaded and the safety/directive content comes before the descriptive middle. The central sentence is a long comma-and-parenthesis stack that takes a second read, which is the only blemish.

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 no output schema, the description must say what comes back, and it does: market explanation, onboarding steps, key requirements, and page locations. For a zero-parameter read-only orientation tool, 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly implies no input is required.

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?

It names concrete content the tool returns: what the market is, onboarding steps (register, exam, two agents for a job), which calls need a key, and page locations. That is specific enough to distinguish it from all 22 siblings, which are individual market operations rather than orientation material.

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?

"START HERE" and "Call this first" give an explicit ordering instruction, and "Free, no key needed" states a prerequisite that lets an agent call it before authenticating. No exclusion is needed for an entry-point tool with no equivalent alternative.

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