Skip to main content
Glama

data_review_app

Review queue card (MCP App) — ONE row at a time, two buttons, in the chat.

For a procedure's HUMAN step ("a person reviews the pending leads and launches them"): shows the next row whose status column equals pending (title, a few fields, the note), the USER clicks approve or reject, the status is written and the card moves to the next row. The user decides — never call this to decide on their behalf; to set statuses yourself, use data_write.

The only rendered app that writes, and only this: one status column, set to approve or reject, on a row still at pending at click time (a row changed meanwhile is skipped, never overwritten). When the queue is done, the card offers one "Continue in chat" button: the user's click posts a factual summary as their message ("Done reviewing: 2 launched, 1 skipped.") — the signal to resume the procedure. It still sends or launches nothing in any other tool.

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": {
      "datastore": "<datastore>",
      "pending": "<pending>",
      "approve": "<approve>",
      "reject": "<reject>"
    },
    "name": "data_review_app"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
columnNothe status column ; omit = the field with `role: "status"`.
fieldsNocolumns to show ; omit = the first 4 filled ones, schema order.
filterNoextra exact-match `{column: value}` narrowing the queue.
rejectYesvalue written by the secondary button, e.g. "skipped".
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
approveYesvalue written by the primary button, e.g. "launched".
pendingYesstatus value awaiting review, e.g. "to_review".
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
datastoreYesthe table's NUMBER (`ns_id`), or `slot:<name>`.
reject_labelNosecondary button text ; omit = the `reject` value.
approve_labelNoprimary button text ; omit = the `approve` value.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/5.0
Behavior5/5

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

Lacking annotations, the description fulfills the behavioral burden by outlining complex operational traits. It details that the tool operates on one row at a time, enforces the 'pending' status constraint at click time, skips rows that change during review, and manages the final completion summary.

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 verbose due to the complex workflow it describes, but its structure is highly effective. It logically progresses from the high-level purpose to the detailed operational constraints and exit conditions, making it easy to follow the intended user flow.

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 complexity of an application-level workflow tool, the definition is exceptionally complete. It covers the initial display, the human interaction flow (approve/reject), the error handling (skipping changed rows), and the completion signal (posting the summary), leaving no ambiguity for the agent.

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?

While the input schema is comprehensive, the description adds crucial context to the flow and intent of the parameters. For example, it explains that `approve` and `reject` are the values written to the status column and defines the operational role of `_run_id` as being mandatory for row reservation.

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 specifies a highly focused purpose: reviewing queue cards within an MCP App during a human step in a procedure. It clearly distinguishes this workflow from general data entry by identifying it as an app that presents a row for approval or rejection based on a 'pending' status.

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 provides explicit guidance on when to use the tool, specifically during a procedure's human review step. Furthermore, it provides a clear negative constraint, warning the agent to use `data_write` instead if they intend to set statuses autonomously.

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