Skip to main content
Glama
coz-a

severally

by coz-a
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get consultation status or result

consult_get
Read-only

Waits for or polls a consultation job or group, then returns advice, status, comparison data, and selected answer points for verification and recording.

Instructions

Wait for job_id or group_id (default 45000 ms; wait_ms: 0 polls). Repeat while running; progress is sent every 15 s. completed has advice; failed has failure.kind and no advice. A group includes statuses and comparison.by_target: actual model, stance, points/grounds and truncation markers. Read grounds already present. For missing/shortened deciding points use job_id + ids: ["f2", "u1"]; job_id alone gets one whole answer. detail: full adds the brief/question. Check deciding claims, batch checked entries in consult_record, then report; unchecked points stay unverified.

Input Schema

NameRequiredDescriptionDefault
idsNowith job_id: return only these points of the finished answer (f1, u1, c1 ...), each whole with its grounds and, under `recorded`, the verdict you wrote
detailNo
job_idNo
wait_msNo
group_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.6.1
    • addedInput schema / properties / detail
      Added value: +{
+  "enum": [
+    "full"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / ids
      Added value: +{
+  "description": "with job_id: return only these points of the finished answer (f1, u1, c1 ...), each whole with its grounds and, under `recorded`, the verdict you wrote",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}
  2. Changed1 schema field changedv1.4.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv1.1.0

TDQS

A4.2/5.0
Behavior4/5

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

The description adds substantial behavior beyond the read-only/open-world annotations: default wait time, 45s cap, 15s progress updates, completed vs failed payload differences, group comparison fields, truncation markers, and detail mode behavior. It is strong for a polling tool, though it does not cover error behavior or invalid-id handling.

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 compact and front-loads the polling behavior before covering result shapes and follow-up workflow. It is dense and somewhat telegraphic, with several fragmented clauses, but most sentences earn their place and give actionable information.

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 five-parameter polling/result tool with no output schema and low schema description coverage, the description covers the main states, result fields, waiting behavior, detail mode, and follow-up workflow. It is nearly complete, with minor gaps around error cases, combining job_id and group_id, and fallback behavior for invalid inputs.

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 description coverage is only 20%, so the description carries most of the burden and does so effectively. It explains wait_ms defaults and polling with 0, the job_id vs group_id distinction, the detail: full option, and the ids behavior including job_id + ids versus job_id alone. This meaningfully compensates for the sparse schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the core operation: waiting/polling on a job_id or group_id until completion, then returning consultation status or results. It distinguishes job and group result shapes and mentions specific states like completed and failed. It does not explicitly contrast itself with sibling tools such as consult_list, which keeps it from a 5.

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?

It gives practical usage guidance: repeat while running, use wait_ms: 0 to poll, check deciding claims, batch checked entries in consult_record, and report afterward. It also explains how to retrieve missing or shortened deciding points with job_id plus ids. The main gap is that it does not say when to choose this tool over consult_list or other alternatives.

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

Deploy Server

Other Tools