Skip to main content
Glama

SlotMaps

Full guide for a machine

get_full_guide

The complete SlotMaps guide: what to look for on the machine, the exact numbers to sit down at, risk and bankroll, plus the advantage-state photo when there is one. Free for 5 machines (list_free_guides); $1.99 per guide otherwise, paid through Stripe machine payments (MPP).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesSlug from search_machines

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose the key non-obvious trait: this is a paid operation billed through Stripe machine payments after a 5-machine free allowance. It omits payment failure behavior, auth requirements, and whether a charge is attempted on every call.

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?

Two sentences, no redundancy, with the content scope front-loaded and pricing second. Mildly promotional phrasing ('the exact numbers to sit down at') but it still conveys meaning efficiently.

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 single-parameter retrieval tool with no output schema, the description covers what is returned, what it costs, and where to get the free tier. The main gap is the absence of any statement about the result payload shape or failure modes, which matters given a payment step.

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?

One parameter at 100% schema description coverage; the schema already explains that slug comes from search_machines. The description adds no format, validation, or sourcing detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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 resource and enumerates its contents (machine observations, exact numbers, risk and bankroll, advantage-state photo), which clearly differentiates a 'full guide' from a bare overview. It does not explicitly contrast itself with get_machine_overview, but the word 'complete' does most of that work.

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?

Names the cost boundary that governs selection: free for 5 machines via list_free_guides, $1.99 per guide beyond that. This is actionable routing information, though it stops short of stating whether an agent should exhaust free guides before calling this.

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