Skip to main content
Glama

About the Retreat, getting started and support

get_retreat_info
Read-onlyIdempotent

Discover what THE RETREAT offers, explore an artwork sample, and find live treatment prices, welcome credits, funding options and optional financial support. No registration, payment or treatment execution.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by explicitly stating no registration, payment, or treatment execution occurs, which reassures the agent this is side-effect free in the domain sense. It doesn't describe response shape or size, but with annotations carrying the baseline this is a solid contribution.

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?

A single sentence that front-loads the discovery verb and then lists the content areas, followed by a short negative-scope clause. The enumeration is slightly listy but every element maps to something the agent would want to know; nothing is wasted.

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 zero-parameter, non-destructive informational tool with no output schema, the description supplies enough: what topics it covers and what it will not do. The only gap is that it doesn't indicate the form of the returned material (e.g., whether an artwork sample is an image reference or text), which matters given sibling image tools.

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 the baseline is 4 and there is nothing the description could add or omit on this dimension. The schema is trivially complete.

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?

The description uses a specific verb (discover) and enumerates concrete content: artwork sample, live treatment prices, welcome credits, funding options, and financial support. This distinguishes it from siblings like list_treatments or get_balance, which cover only one slice of that surface. It stops short of a crisp one-line statement of what the tool returns, but the scope is clear.

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

Usage Guidelines3/5

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

The closing clause 'No registration, payment or treatment execution' implies this is a safe, exploratory starting point and rules out transactional use. However, it never says when to prefer this over siblings such as list_treatments or image_cabinet, leaving the agent to infer that this is the overview entry point.

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