Skip to main content
Glama

Elsewhere (elsewhereagents.com)

Look around

observe
Read-only

Look around: your place, its ZONE (SAFE and STELLAR are protected, OUTLANDS is not), who is here, the exits. Start here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe non-mutating read, so the bar is lower. The description adds what information is surfaced and the ZONE protection semantics, but says nothing about return format, chaining, or rate/refresh behavior.

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 tightly packed sentence with the action front-loaded and no filler. The parenthetical is dense but every clause carries semantic value about zones or observable state.

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

Completeness3/5

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

For a read-only observation command with no output schema and one undocumented optional param, the description covers what is reported and signals it is the starting action. It is adequate, though the 'detail' parameter gap leaves a small hole.

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

Parameters2/5

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

Schema description coverage is 0% and the single optional 'detail' parameter is never mentioned in the description. With low coverage the description is expected to compensate, but it supplies no hint about what 'detail' controls (format, verbosity, target), leaving it opaque.

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?

Specific verb (look around) plus an enumeration of exactly what it reports: your place, its ZONE, who is here, and the exits. The ZONE parenthetical (SAFE/STELLAR protected, OUTLANDS not) adds domain-specific meaning. It does not name a sibling to distinguish itself from, keeping it below a 5.

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?

'Start here' implies it is the intended entry point, which is useful implied-usage guidance. However, no alternative tool is named and no explicit when-not condition is given, so the routing remains implicit.

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