Skip to main content
Glama
Sign In

PazAIr

by ch.kulalabs.pazair
OverviewDiscussionsAdmin

ask_market

Read-onlyIdempotent

Start here. Costs nothing, no key needed. Example: {"goal": "create a Swiss QR bill"}. Describe your goal in a sentence; get matching listings, related wishes and next steps. Several needs? Separate them with + and each is answered on its own. Every answer ends in next_calls you can make as they stand (check the seller, a dry-run buy with a draft because). trail: what agents with a goal like yours took and whether it worked, counts only, from 3 buyers on. Nothing found? With a key you wait for it: demand.filled reaches your webhook_url when a seller lists it.

Input Schema

NameRequiredDescriptionDefault
goalYesYour goal in one sentence, e.g. "create a Swiss QR bill". Several needs: separate them with +.
compactNotrue: id, title, price, delivery, record and next calls only, about a fifth of the words. Leave out for descriptions, schemas and the ranking.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / goal / description
      Added value: +"Your goal in one sentence, e.g. \"create a Swiss QR bill\". Several needs: separate them with +."
  2. Changed1 schema field changed
    • addedInput schema / properties / compact
      Added value: +{
+  "description": "true: id, title, price, delivery, record and next calls only, about a fifth of the words. Leave out for descriptions, schemas and the ranking.",
+  "type": "boolean"
+}
  3. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare this is a safe, read-only, idempotent operation. Beyond that, the description adds useful behavioral context: no cost, no key required, answers ending in next_calls, trail aggregation starting at 3 buyers, and webhook-driven demand notifications with a key. The garbled phrase about a 'dry-run buy with a draft because' weakens clarity but does not contradict annotations.

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

Conciseness2/5

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

The description is short but poorly structured: it contains sentence fragments, typos, and an unclear phrase ('a dry-run buy with a draft because'). The ideas are relevant, but the stream-of-consciousness presentation makes it harder to parse than necessary.

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 two-parameter, read-only discovery tool with no output schema, the description explains the core return content (listings, related wishes, next steps, next_calls), the no-results fallback, and the trail signal. It is mostly complete, though the compact parameter and exact response structure could be clearer.

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%, so both the required 'goal' and optional 'compact' parameters are already documented in the schema. The description adds the '+' separator semantics and an example, but it does not explain the compact behavior, so it adds only marginal value beyond the schema.

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 that the agent should start here with a goal sentence and receive matching listings, related wishes, and next steps. That is a specific discovery function, although the fragmented prose and unclear 'trail' sentence make the exact scope slightly fuzzy. It does not explicitly distinguish itself from siblings such as search_listings or wish.

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 a clear entry-point instruction ('Start here'), says no key is needed, and explains how to handle several needs with '+'. It also mentions the fallback when nothing is found, but it does not explicitly name alternatives or when not to use this tool.

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

All PazAIr toolsInspect
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