Entalpa Requirements MCP

Suggestions Review Get

suggestions_review_get

Read-onlyIdempotent

Read one batch of suggestions as the review view shows it: each item beside its target as it is now, and what accepting it now would do. The view calls it to refresh itself; to read suggestions, use suggestions_list. Uses no AI and no credits.

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": {
      "project_id": "<project_id>",
      "batch_id": "<batch_id>"
    },
    "name": "suggestions_review_get"
  }
}

Input Schema

Name	Required	Description	Default
`batch_id`	Yes	Suggestion batch UUID, from a run's saved_suggestions or from suggestions_list.
`project_id`	Yes	Project UUID (database id).

Output Schema

Name	Required	Description	Default
`batch`	Yes
`other_batches_waiting`	Yes	Other batches with items waiting for review. suggestions_list gives their ids.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds context annotations cannot: this is a joined, point-in-time view (targets "as it is now", effects of accepting "now") and that it consumes no AI and no credits, which matters for cost-sensitive loops.

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

Conciseness5/5

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

Two tightly written sentences: the first defines the content and shape of the result, the second covers invocation context, the alternative tool, and cost. Nothing is redundant and the key differentiator is front-loaded.

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?

For a two-parameter read tool with full schema coverage, an output schema, and rich annotations, the description covers what remains: the semantics of the joined view, the sibling routing, and the no-AI/no-credit behavior. No information an agent needs to call it correctly is missing.

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 description coverage is 100%: batch_id already documents its provenance (a run's saved_suggestions or suggestions_list) and project_id documents the database id. The description adds no further meaning about either parameter, so the baseline 3 applies.

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?

States a specific verb and resource ("Read one batch of suggestions") plus the distinctive shape of the payload: each item beside its current target and the projected effect of accepting it. It explicitly contrasts itself with the sibling suggestions_list, so an agent can choose between them without opening either schema.

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 view calls it to refresh itself; to read suggestions, use suggestions_list" names the alternative and the condition that selects it. It does not explicitly state when an agent (rather than the UI view) should prefer this enriched view over suggestions_list plus a target lookup, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Entalpa Requirements MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?