Skip to main content
Glama
Sign In

Anry

by io.anry.mcp
OverviewDiscussionsAdmin

Get site status

get_site_status
Read-onlyIdempotent

Whether a site is set up and sending data, as facts with timestamps: when the tracker first sent an event and whether it sent any in the last 24 hours, when the first purchase event arrived, onboarding, the declared platform, the primary goal, each ad platform connection (status, last sync, error, and over the last 7 days its clicks next to the visits that carried its campaign or ad id) and the store integrations. Call it before reading analytics on a site that looks empty, whenever asked whether something is connected or working, and when paid spend shows no attributed visits. It reports no score and no verdict.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site_id": "<site_id>"
    },
    "name": "get_site_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
site_idYesSite id from list_sites (UUID)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the description doesn't need to restate safety. Instead it adds real behavioral context: facts carry timestamps, ad platform figures cover a rolling 7-day window, and it explicitly reports no score or verdict. It stops short of saying how much data comes back or how large a site's connection list might be.

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?

It is front-loaded with the core answer, then usage triggers, then a short caveat about no score or verdict. The middle sentence is a long dense list, but every item maps to a returned fact, so the density is justified rather than padded.

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?

No output schema exists, so the description carries the full burden of describing return values, and it does so field by field with the comparison structure (clicks vs. attributed visits) spelled out. An agent knows exactly what it will get back and what it will not get (a verdict).

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?

There is a single parameter and the schema documents it fully, including UUID format and its origin in list_sites. The description adds nothing about site_id semantics, which is acceptable given 100% schema coverage but earns only the baseline.

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?

The description names a specific resource and the exact facts returned: tracker first event, 24-hour activity, first purchase, onboarding, platform, primary goal, ad platform connections and store integrations. That level of enumeration clearly separates it from the analytics, spend, and session tools in the sibling list.

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?

Three concrete call conditions are given — before reading analytics on an empty-looking site, whenever asked whether something is connected or working, and when paid spend shows no attributed visits. The first one also implicitly routes the agent away from get_analytics_overview until this check passes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Anry toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources