Skip to main content
Glama
Sign In
@ainize/mcp

@ainize/mcp

Official
by ainblockchain
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Quote a knowledge

quote
Read-only

Retrieve a knowledge item's total cost, verification status, required base stack, and remaining session budget before buying; returns the ID required to proceed.

Instructions

What a knowledge really costs before anything moves: its price, whether it is verified and sellable, whether this node already bought it, the base stack it needs and the honest total with those bases, and how much session budget is left. Free and side-effect-light. This is the ONLY way to get a quote_id, and buy cannot be called without one.

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": {
      "id": "<id>"
    },
    "name": "quote"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
dry_runNotrue = price it from the catalogue only; no 402 handshake, so nothing at all is reserved upstream
include_basesNoprice the base stack this knowledge needs to be loadable

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Beyond readOnlyHint/openWorldHint, it discloses that the call is free, that no upstream reservation occurs on dry_run (implying the normal path performs a 402 handshake and may hold value upstream), and that session budget remaining is reported. This is meaningful behavioral context an agent would not get from annotations alone. It does not describe failure modes such as an exhausted budget or unverified items.

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?

Cost and scope are front-loaded in the first clause, the gating constraint is saved for the punchline at the end, and every sentence carries information. The enumeration is long but each item is a distinct output field, so nothing is filler.

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 no output schema, the description correctly takes on the burden of explaining what comes back (price, verified/sellable flags, already-owned state, base stack and total, budget left), which makes the return value predictable. The remaining gap is the semantics of the required `id` argument and any error behavior around the 402 handshake.

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?

The description maps to the optional parameters by explaining that the base stack and the 'honest total with those bases' are priced, which adds meaning beyond include_bases' schema text. However, the required `id` parameter is never characterized (what identifiers count, where to get them), and schema coverage is only 67%, so the description only partially compensates.

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 names a specific verb and resource (quoting a knowledge item) and enumerates exactly what the quote contains: price, verification/sellability status, prior purchase, base stack, total, and remaining session budget. It is clearly distinguishable from retrieval siblings like get_knowledge or search_knowledge, though it never names a sibling explicitly to draw that contrast.

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?

Usage is stated concretely: this is the only source of a quote_id, and `buy` cannot be called without one, so the agent knows it is a mandatory precondition step. The dry_run parameter effectively documents a no-commitment variant. It lacks an explicit when-not to use it, but for a gating tool the guidance is strong.

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