Skip to main content
Glama
Sign In
aimarket-mcp

aimarket-mcp

by alexar76
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

metis_verify

Read-only

Get a machine-checkable confidence score and verdict for an answer before acting on it. Returns the answer plus verified=true/false so you can gate decisions.

Instructions

Answer a question with Metis and get its own verdict on that answer: the answer text followed by a line [verify_score=0..1 status=… route=… verified=true|false]. Use it when you must decide whether to act on an answer and want a machine-checkable confidence gate; act only when verified=true. For live web facts use web_search; do not route Metis through market_invoke. Read-only. On failure the call errors with JSON {error: metis_verify_failed, reason: timeout|http_status|connection|invalid_response, url, status_code, hint} and never a guessed answer — treat that as unverified. Calls can take up to 200 s on the council and agent routes.

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": {
      "input": "<input>"
    },
    "name": "metis_verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYesThe full question or claim, self-contained (Metis sees nothing else from the conversation), e.g. 'Is the MIT license compatible with GPLv3 for distribution?'
routeNoHow hard Metis works: fast (one pass, seconds), thinking (deeper single model), council (several models cross-check, default, best verify_score), agent (uses tools for questions that need lookups; slowest).council

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.4

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint, non-idempotent), it discloses the exact failure contract — a JSON error with error/reason/url/status_code/hint rather than a guessed answer — how to treat that case, and latency up to 200 s on council/agent routes. That is materially more than the structured fields carry.

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?

Front-loaded with what the tool does and the output contract, then usage, then failure behavior — a logical progression with no filler. It is dense but slightly overpacked with sibling-routing rules that could be tighter.

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?

With an output schema present, the description needn't restate return structure, yet it usefully describes the verdict line and the failure path. The one remaining gap is guidance on interpreting verify_score values between 0 and 1, since only the boolean verified flag is given a rule.

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%, so the route enum is already documented; the description adds the trade-off dimension by tying council/agent routes to the 200 s latency. It does not explain how verify_score maps to the route or what score threshold to trust, but the description still adds value beyond the schema.

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 ('Answer a question with Metis and get its own verdict on that answer') and spells out the shape of the result ('[verify_score=0..1 status=… route=… verified=true|false]'), which no sibling offers. An agent can distinguish this from web_search and market_invoke from the description alone.

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?

Gives an explicit trigger ('when you must decide whether to act on an answer and want a machine-checkable confidence gate'), a decision rule ('act only when verified=true'), and named alternatives/exclusions ('For live web facts use web_search; do not route Metis through market_invoke'). Nothing about when-not-to-use is left to inference.

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