Skip to main content
Glama

Check Safety

check_safety
Read-only

Check campgrounds for safety issues, community atmosphere, and active alerts.

Checks:

  • Greenbook community safety (vibe scores, discrimination reports, flag status)

  • Active campground alerts (closures, restrictions) from enriched data

  • Red flag detection (prevents recommending unsafe campgrounds)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
campground_idsYesList of campground CUIDs to check

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / campground_ids / description
      Added value: +"List of campground CUIDs to check"
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/openWorldHint/destructiveHint, so the safety profile is covered. The description adds real domain substance beyond that: greenbook vibe scores, discrimination reports, flag status, and closure/restriction alerts, which tells the agent what data surfaces in the result.

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 one-sentence summary is front-loaded and the three bullets are tight and non-redundant. Slightly list-heavy for a single-parameter tool, but every line carries information.

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?

Output schema exists, so return values need not be explained, and annotations cover the read-only safety profile. The main residual gap is that 'Greenbook' is unexplained niche terminology, though the parenthetical glosses mostly mitigate it.

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% with a single campground_ids array already described as 'List of campground CUIDs to check'. The description adds no format, batching, or ordering guidance for that parameter, so a baseline 3 is appropriate.

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?

States a specific verb (check) and resource (campgrounds) and enumerates the three things it assesses: safety issues, community atmosphere, and active alerts. No sibling tool overlaps this domain, so an agent can distinguish it immediately from search_campgrounds or get_campground_details.

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?

Usage is implied rather than stated: the red-flag line ('prevents recommending unsafe campgrounds') hints this is a screening step, but there is no explicit when-to-use, no prerequisites, and no named alternative. An agent must infer the workflow position.

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