Skip to main content
Glama

List the surfaces of a project

list_surfaces
Read-onlyIdempotent

The surface registry of a project: the pages about the brand where the customer has the FINAL SAY (website, GitHub, LinkedIn, X, YouTube, Wikidata, directories, app stores...). The split with corroborations is control, never who wrote the page: a page the customer can change is a surface, a page where someone else has the final say is a corroboration (list_corroborations). Each surface carries its type, url, label, languages, notes, its checklist and a status DERIVED from the checklist CELLS that hold it: checklist.required lists exactly those, the canon items of the template plus every check the customer added of their own. checklist.kinds answers a different question, what PERISHES a tick: "canon" items restate the canon, so their verification perishes when the wording moves; "presence" ones, such as site_link, hold. A check of the customer holds the status whatever its kind, so read checklist.required and deduce nothing from checklist.kinds. checklist.custom lists those checks, each with its key, label, scope and restates_canon, and the ones taken out with deleted true, which restore_surface_check brings back; add_surface_check is how a new one is posed. Each cell is verified (dated, stamped with the canon version whose WORDING it restated: it stays fresh until the wording moves, and a revision that touches no wording, such as declaring the canonical language, perishes nothing) or set aside with its reason (the item does not apply on THIS surface). Three statuses, never a fourth: aligned when every required cell not set aside is verified at the current wording; needs_update when some verification is missing or stale; never_aligned when none exists. There is no state for a page the canon does not apply to, because setting aside the LAST canon cell is refused with not_a_surface, because a page that carries none of the canon is not a surface: turn it into a corroboration if someone else has the final say on it, or take it out of the registry. checklist.state keeps the flat view of verified items; checklist.progress counts done, total and dismissed, the set-aside cells out of the denominator but never hidden. Each surface also carries domain_authority, what the AIs grant the DOMAIN the page sits on, read from the Atlas: domain is the registrable domain that was measured, engines its AI Authority on each AI over the last 30 days, source_id its entry on the map (read it with get_source). The unit is the domain, so the figure says that PLACE is read, and list_sources reads the very same one. An engine absent from engines has not cited the domain lately, which is not a zero, and a source_id of null means the domain is not on the map of this account, which carries the sources the surveys of this account surfaced and grows as it measures more. Start here to find a surface id. Set deleted to "only" to read the trash of the registry instead of it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOrder of the registry. "registry", the default, is the order of the binder, by shown name, the one where a known line is found again. "authority" orders by the measured authority of the DOMAIN of each line, the most read first, so the work follows a measured fact rather than the tidiness of a checkbox. It orders and never filters: every surface stays listed, the domains off the map closing the list, and a page nobody cites yet is sometimes exactly the one to work on.
deletedNoSet to "only" for the surfaces taken out of the registry (delete_surface), most recently taken out first, each with its deleted_at. Omitted, the registry is listed.
project_idYesUUID of the project: call list_projects to find it.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds deep behavioral context: the derived statuses, the checklist semantics (required, kinds, custom, set-aside), the domain authority sourcing, and the meaning of null source_id. It explains edge cases (no zero for absent engines, deletion semantics) without contradicting annotations.

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 description is very long but dense and logically structured: it starts with the core definition, then checklist mechanics, statuses, domain authority, and finally parameters. It front-loads the most critical concept (surface vs corroboration) and each section builds on the previous. Some sentences are verbose and could be tightened, but the complexity justifies the length.

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?

Given the tool's complexity and lack of output schema, the description fully explains what each surface carries (type, url, label, etc.), the checklist fields, derived statuses, domain authority sourcing, and both parameters. It covers all aspects an agent needs to invoke the tool correctly, including edge cases and exclusions.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3. The description adds substantial meaning beyond schema: sort explains the difference between registry order and authority order, and emphasizes it never filters; deleted explains the trash view and ordering. It also clarifies project_id via reference to list_projects. This elevates the parameter understanding well beyond the schema's enums.

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 clearly states the tool lists the surfaces of a project, defines what a surface is (pages with final say by the customer), and explicitly distinguishes it from corroborations via list_corroborations. It covers the core resource and purpose without ambiguity.

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?

It explicitly explains when to use this tool versus list_corroborations based on the control criterion, and says 'Start here to find a surface id,' providing clear context. The parameter descriptions for sort and deleted also give usage guidance, including that sort never filters and deleted='only' accesses trash.

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.

TDQS

A4/5.0
Disambiguation4/5

Each tool maps to a distinct resource and action, and the descriptions go out of their way to separate near-neighbor concepts like surfaces vs corroborations and score series vs raw responses. A few related pairs (get_results/get_responses, get_credits/get_usage, create_surface/create_corroboration) could still be confused at a glance, so it is not a perfect 5.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun snake_case pattern across all 67 tools, with clear families like create_, update_, get_, list_, archive_, restore_, and delete_. Minor quirks such as topup_credits as one word do not break the overall uniformity.

Tool Count1/5

67 tools is an extreme count for a single MCP server, even for a broad brand-monitoring domain. The surface is bloated with lifecycle variants per entity, and the sheer number makes the server hard to navigate and prompt against.

Completeness5/5

The server covers full lifecycles for projects, trackers, surfaces, corroborations, quests, logbook entries, keyword discoveries, competitor scans, link targets, sources, support, and billing. Archive/restore and soft-delete paths prevent dead ends, and nearly every obvious workflow has a corresponding tool.

Resources