Skip to main content
Glama

List sites

list_sites
Read-onlyIdempotent

The sites the user holds on fivebar, as { sites, count }: each with its domain, which every other tool names a site by; its name as people read it, where that differs: the name its holders gave it, such as Give Food for givefood.org.uk, or for a domain in a script of its own, such as κουνησε.gr for xn--qxadimj0al.gr; its group, null for the user's first; the user's role on it: owner, editor or viewer, a viewer changing none of its settings but its group and their own email reports; its time zone, which its days are counted in; today, the date there now; and a link to its dashboard. Listed group by group, and by name or domain within one, at most 200, with count how many there are, and week_start, the day the user's weeks start on: for sunday, use the -sun ranges, and so on; group lists one group's sites alone. A public site of someone else's is never listed, but the other tools read it by its domain.

Input Schema

NameRequiredDescriptionDefault
groupNoOnly the sites in this group, by its name as list_sites gives it, ignoring case; None for the first group, whose name it gives as null. A group the user does not have is refused, naming those they do.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's job is to add operational context, which it does: a 200-site cap, sort order (group by group, then name or domain), the report of total count, and the week_start value that determines which -sun style ranges other tools expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is valuable but delivered as a single sprawling sentence with nested colons and parentheticals, so key facts (200-item cap, week_start semantics, -sun range implication) are buried mid-clause rather than front-loaded. It earns its length but not its structure.

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?

There is no output schema, and the description compensates fully: it explains the return envelope, every field per site, the ordering, the 200 cap with a total count, and the week_start value that other tools' range parameters depend on.

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% and the group parameter is already well documented in the schema, including the null-for-first-group and refusal behavior. The description restates the group filter ('group lists one group's sites alone') without adding syntax the schema lacks, so the baseline 3 is appropriate.

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 states the resource precisely (the sites the user holds, returned as { sites, count }) and enumerates every returned field, so an agent knows exactly what comes back. It does not name a sibling directly, but the line about public sites not being listed 'but the other tools read it by its domain' implicitly separates it from the per-site tools.

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: 'group lists one group's sites alone' and the note that other tools address public sites by domain hint at routing, but there is no explicit when-to-use-this-vs-alternative instruction (e.g. 'use this to discover site domains before calling get_site_summary').

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