Skip to main content
Glama

Verify or set aside checklist cells of a surface

tick_surface_checklist
Idempotent

Record what a surface actually carries, cell by cell, as many moves as you want in one call. The items are listed by list_surfaces as checklist.items: the template of the surface type (stable keys such as title_tag or llms_txt), then the checks the customer added of their own (add_surface_check), which tick here exactly like the rest, at their key. Most of them are yours to check (a title tag, JSON-LD, an llms.txt all read with a simple fetch). Three moves per cell. VERIFY (done true, or nothing): the item is constated on the page; an item of canon kind (checklist.kinds) is stamped with the current canon version and wording, so its verification stays fresh until the wording moves, and needs the canon set first. SET ASIDE (dismissed true plus a short reason): the item does not apply on THIS surface (an author bio, a field the platform does not offer); durable across canon revisions, reversible, never hidden from the counts. CLEAR (done false, or dismissed false): the cell returns to blank. A site-wide item (checklist.site_items: the llms.txt, one file at the root of the site, written in the canonical language of the project) is one cell for the whole site, without a language. Only the cells you send change; an unknown item or language, a set-aside without reason or a contradictory move refuses the whole batch and says what exists. The ALIGNED status derives from the cells listed in checklist.required, the canon items plus the checks of the customer: verifying the last one aligns the surface and dates it in the journal. The goal is a surface with no required cell left undecided: work every one of them to a verdict, verified when the page carries it or set aside with a reason when the item does not apply here. Leaving a cell untouched is not a neutral skip, it holds the surface in needs_update and hides whether the page was ever checked, so go through the whole checklist and not only the cells easy to confirm. And setting aside the LAST canon cell is refused, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ticksYesThe cell moves. Nothing else on the checklist changes.
surface_idYesThe UUID of the surface: call list_surfaces to find it.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations state readOnly=false and idempotent=true, and the description aligns with these while adding extensive behavioral context: batch rejection on unknown items, canon stamping requirements, site-wide item semantics, refusal to set aside the last canon cell, and the impact on ALIGNED status. It clearly discloses error conditions and side effects beyond the 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 lengthy but every sentence carries operational meaning. It is front-loaded with the core action and then details moves, constraints, and edge cases. It could be better structured with paragraphs or bullets, but it avoids redundancy and earns its length.

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?

For a mutation tool with no output schema, the description thoroughly covers input semantics, failure modes, and side effects on checklist state and ALIGNED status. It does not explicitly describe the return value (e.g., what the updated checklist looks like), but given the idempotent, batch-oriented nature, the absence is not critical. The context provided is enough to invoke the tool correctly.

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

Parameters4/5

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

Schema coverage is 100% and the schema already describes each parameter well. The description adds higher-level semantics: the three moves (verify/set aside/clear), the meaning of omitted done/dismissed, the requirement of reason when dismissed, and the language handling for per-language vs site-wide items. This goes beyond what the schema alone provides.

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 opens with a specific verb and resource: 'Record what a surface actually carries, cell by cell, as many moves as you want in one call.' It clearly distinguishes this tool from siblings like add_surface_check and update_surface_check by focusing on ticking checklist cells rather than defining checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the workflow: items come from list_surfaces, customer checks are added via add_surface_check, and this tool records verdicts. It gives guidance on when to verify, set aside, or clear, and warns against leaving cells untouched. However, it does not explicitly name alternative tools for when to use them instead, such as updating a check definition.

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