Skip to main content
Glama

Read the quest file

list_quests
Read-onlyIdempotent

What there is to do for the GEO work, and where to resume it. Lists the quests of the account: moves the customer (or you, on their behalf) decided and recorded, open by default, newest first; status=done or dismissed reads the closed history, which answers with its quests, each one reopened with reopen_quest. Every project by default; scope to one project with project_id. Alongside the open file, pending carries the files the measurement is holding for review, each acted through its own tool: surfaces whose canon moved since their last alignment (list_surfaces, then tick_surface_checklist to verify the cells the new wording perished), keyword discoveries waiting on a tracker (list_keyword_discoveries, then accept_keyword_discovery or dismiss_keyword_discovery). Scoped to one project, pending also carries the corroboration candidates of that project, computed per project (list_corroboration_candidates, then create_corroboration or dismiss_corroboration_candidate). Each quest also carries journal_entries and last_entry_at, how many actions were recorded against it and when the last one happened: read them with get_logbook and the quest_id, record one with create_logbook_entry and the same quest_id. An empty file with the measurement running means there is nothing to correct today.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoWhich quests to list: "open" (the file, default), "done" or "dismissed" (the closed history).
project_idNoOnly the file of this project: the UUID of a project of the account (call list_projects). Omitted, the file covers every active project.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the bar is lower. The description adds substantial behavior context: default ordering (newest first), how status filters work, the `pending` concept, journal_entries and last_entry_at fields, and the interpretation of empty results. No contradiction with annotations and enriches the agent's understanding of behavior.

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

Conciseness2/5

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

The description is a dense, unstructured paragraph with multiple tangents about pending files, logbook entries, and related tools. While every sentence adds value, the length and lack of formatting (bullets, sections) make it hard to parse quickly. It is front-loaded with purpose but then becomes overly verbose, harming usability.

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 (status modes, scoping, pending sub-resources, logbook fields), the description is thorough and covers all relevant aspects an agent needs to call it correctly. It explains response contents (journal_entries, last_entry_at) and even the meaning of an empty file. No obvious gaps.

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%, providing baseline of 3. The description adds meaning beyond schemas: status default ('open by default'), the effect of status values (done/dismissed read closed history), and the implication of omitting project_id (covers every active project). This goes beyond simple field definitions.

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's purpose: 'Lists the quests of the account' with a specific verb and resource. It also distinguishes itself from sibling tools by mentioning alternatives (list_surfaces, list_keyword_discoveries, list_corroboration_candidates) and explaining how they relate. No ambiguity about what the tool does.

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?

Provides explicit guidance on when to use this tool: open default, status=done/dismissed for closed history, project_id scoping. It also directs the agent to siblings for pending items and logbook actions, clearly stating when to use alternatives. Exclusions and conditions are spelled out.

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