pmq

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.1
Disambiguation5/5
All 11 tools target distinct aspects of Polymarket: account balances, portfolio, trades; market discovery, details, order books, and order preview; plus status and fee info. No two tools have overlapping purposes.
Naming Consistency4/5
Most tool names use lowercase underscore with a noun-verb or verb-noun pattern (e.g., account_collateral, find_markets, order_preview). A couple are single-word nouns (book, event) but the pattern is largely consistent and readable.
Tool Count5/5
With 11 tools, the surface covers market data, account info, and order preview without being overwhelming. Each tool serves a clear, non-redundant purpose for a prediction market query interface.
Completeness2/5
For a trading-related server, the lack of order placement, cancellation, or any execution tools is a significant gap. While the read-side is well-covered, agents cannot complete a trading workflow without these operations.
Average 4.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 73 commits in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the calculation formula and lists rates, which is transparent about its behavior. No annotations exist, so description carries full burden; it adequately discloses the fee computation but does not mention if it is read-only or has side effects.
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?
Concise single sentence plus a list of categories. The line break in the list is minor, but overall efficient with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple calculation and existence of output schema, the description covers the essential formula and category rates. But lacks explanation of what the output represents and any prerequisites or edge cases.
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?
With 0% schema coverage, description partially compensates: the formula explains price and shares as inputs (p and shares), and category is linked to rates. However, it does not specify units, ranges, or meaning for price and shares beyond the formula.
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?
Clearly states it computes the official Polymarket taker fee, provides the formula and lists categories with rates. Distinguishes from sibling tools which are about accounts, books, and markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool or when to avoid it. Only lists categories and rates without indicating alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses read-only nature, no order actions, and error handling for missing books. But it omits authentication requirements, rate limits, or behavior on invalid inputs.
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?
Extremely concise: two sentences with no wasted words. The first sentence immediately conveys the core purpose and read-only nature. Every sentence adds value.
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 simple tool with one parameter and an output schema, the description provides appropriate context: it's a snapshot, returns top-of-book per outcome, does not place orders. Minor gap: does not mention output schema exists or what fields are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'slug' with 0% schema description coverage. The description mentions 'resolve a market' implying slug is a market identifier, but does not explain what format or values it expects, leaving ambiguity.
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?
The description clearly states the tool is a read-only snapshot that resolves a market and returns the live top-of-book summary for each outcome. It explicitly distinguishes itself from order placement/preparation, and the verb 'resolve' combined with resource 'market' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (need a snapshot, not placing/preparing an order) and mentions that a missing book is reported per outcome. However, it does not explicitly compare to sibling tools like 'book' or provide alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits: Data API values lag the matching engine and are not exchange reconciliation truth. This adds transparency beyond the input schema. No annotations provided, so description carries full burden.
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 dense sentences, no wasted words. Front-loaded with core purpose, efficient in structure.
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?
Covers modes, wallet configuration, and data lag caveat. Output schema exists, so return values are documented elsewhere. Limit parameter omission is a gap, but overall sufficient for an agent given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the wallet parameter is partially explained (public wallet address for live mode). The limit parameter is not mentioned in the description; schema has 0% coverage, so the description fails to explain its purpose.
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 tool returns the current portfolio without placing an order, distinguishing it from order placement tools. However, it does not explicitly differentiate from sibling tools like account_collateral, though 'portfolio' implies a broader view.
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?
Provides clear guidance on when to use paper mode vs. live mode, and how to configure wallet address via parameter or environment variable. Lacks explicit when-not-to-use or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should explicitly indicate the tool is read-only. While 'collateral the CLOB sees' implies a query, it does not confirm non-destructive behavior or disclose any other behavioral traits like authentication or rate limits.
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?
Two sentences efficiently convey purpose and additional context (troubleshooting, paper mode) without fluff. Slightly more verbose than necessary but well-structured.
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?
Provides enough context for a parameterless tool with an output schema. Diagnostic info adds value, but could mention that output format is numeric (collateral value). Still, overall complete.
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?
No parameters exist, so baseline of 4 applies. Description adds context about output meaning but no parameter info needed.
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?
The description clearly states the tool retrieves collateral (pUSD/$) as seen by the CLOB for the configured account, distinguishing it from sibling tools like account_trades (trades) or market data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides diagnostic context (what to check if collateral is 0) and mentions paper mode behavior, but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses behavior: it only counts BUY fills for USD and fees, and explains paper mode semantics (shares are net of sells). It does not mention whether the operation is read-only or has side effects, but the verb 'totals' implies a read operation.
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 concise with three sentences covering purpose, usage guidance, and paper mode. It is front-loaded with the core function. However, it could be slightly more structured with bullet points or clearer separation between normal and paper mode semantics.
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?
Given the tool has 2 parameters (1 required) and an output schema (not shown but exists), the description sufficiently explains the return values and core behavior for both production and paper mode. It lacks details on the optional token_id parameter and potential side effects, but overall meets the needs for a reconciliation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its two parameters (condition_id, token_id). The description mentions 'on one market' which likely maps to condition_id but does not explicitly define either parameter or their usage. Token_id is not addressed, leaving ambiguity.
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?
The description clearly states the tool returns 'BUY-side totals of OUR account on one market' with specific fields (shares, usd, fee_estimate). It distinguishes the tool from siblings by emphasizing it is the 'reconciliation source' for post-uncertainty verification, setting it apart from local bookkeeping and other market tools like 'book' or 'market'.
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 description explicitly guides when to use: 'use it after any uncertainty instead of trusting local bookkeeping'. This provides clear context for appropriate usage, though it does not directly compare against sibling tools like 'account_collateral' or 'taker_fee'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states the tool is REAL-TIME and served by the matching engine, adding behavioral context beyond the schema. However, it does not disclose auth needs, rate limits, or any destructive behavior, which is acceptable for a read-only query tool but still leaves gaps.
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?
The description is two sentences long, efficiently front-loading the key outputs and adding a trustworthiness note. Every sentence adds value with no redundancy.
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?
Given the tool has 3 parameters, no annotations, and an output schema exists, the description covers the main outputs (best bid/ask, sizes, notional) and the depth range. It does not mention pagination or error handling, but for a simple order book snapshot, it is fairly complete.
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 0%, so the description must compensate. It explains the depth_lo and depth_hi parameters as defining the range for asks notional, and implies token_id as the outcome token identifier. However, it does not explain default values or units, leaving some meaning only partially clarified.
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?
The description clearly states it provides a real-time order book summary for one outcome token, including best bid/ask, sizes, and notional inside a depth range. It distinguishes itself from siblings by focusing on order book depth and live matching engine data.
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 description gives clear context that this endpoint is served by the matching engine and should be trusted over the trade tape for live decisions. It implicitly suggests when to use (for live decisions) and provides a comparison (trade tape), but lacks explicit when-not-to-use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies read-only behavior ('Discover') and explains the two operational modes. However, it does not explicitly declare non-destructiveness, auth requirements, or rate limits. For a search tool, the transparency is adequate but not fully explicit.
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?
The description is two sentences, front-loaded with the main purpose, and contains no superfluous words. Every sentence adds value.
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?
Given the tool has an output schema (so return values are documented externally), the description covers the essential usage context: search modes, result contents, and linkage to the sibling 'market' tool. It is complete for an agent to decide when and how to invoke it.
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 coverage is 0%, so the description must compensate. It explains the 'query' parameter through the two modes, but does not mention the 'limit' parameter (its meaning or default). This partial explanation is helpful but incomplete.
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?
The description uses a specific verb ('Discover') and resource ('Polymarket markets of ANY kind'), and distinguishes two modes (with/without query). It clearly differentiates from sibling tools like 'market' by mentioning the slug to pass to it.
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 description tells when to use with query (full-text search) vs without (most active by volume). It references the sibling 'market' tool for subsequent steps but does not explicitly state when not to use or provide alternatives beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description indicates it 'resolves' a market, which might imply a read operation, but does not explicitly state it is read-only or non-destructive. It adds context about expired markets but lacks information on auth needs or rate limits.
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?
The description is two sentences, each serving a distinct purpose: the first explains the action and scope, the second details the output and usage. There is zero wasted text, and the most critical information 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?
Given the tool has only one parameter and an output schema exists (though not shown), the description comprehensively covers the output fields (condition_id, token ids, close time, winner) and provides integration guidance with sibling tools. It is fully sufficient for the agent to understand and invoke the tool.
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?
The single parameter 'slug' has 0% schema description coverage, but the description explains it is a 'gamma slug' that works for any category, including expired short-lived markets. This adds meaning beyond the schema's title 'Slug', helping the agent understand the parameter's nature and scope.
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?
The description clearly states the tool resolves a Polymarket market by gamma slug, works for any category including expired short-lived markets. It specifies the returned data: condition_id, outcome names mapped to token ids, close time, and settled winner. This distinguishes it from siblings like 'find_markets' (search) and 'event' (event-level data).
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 description tells the agent to use the returned token ids with 'book' and trading tools, providing clear post-invocation guidance. It does not explicitly state when to choose this tool over alternatives like 'find_markets' or 'event', but the context of resolving by slug is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return structure (slug, outcome names, token ids, close time, settled winner) and that it returns multiple markets. It does not mention auth or rate limits, but for a read operation this is adequate.
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?
Three sentences front-load purpose, provide a usage hint, and detail return format. Every sentence earns its place without redundancy.
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 simple tool with one parameter and existing output schema, the description covers core behavior and return format. It lacks mention of error handling or limits but is largely complete.
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 has 0% coverage, but the description explains the 'slug' parameter's origin and purpose ('Use the event slug from find_markets'), adding significant meaning beyond the empty 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?
The description clearly states the tool retrieves all binary markets of a multi-outcome event, specifying 'All binary markets of one multi-outcome EVENT' and distinguishing from siblings like 'market' (single market) and 'find_markets' (search).
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?
Explicitly instructs to use the event slug from find_markets, providing a clear prerequisite. While it doesn't list when not to use, the sibling context implies alternatives for single markets or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all key behavioral traits: read-only, top-of-book FAK, no executor/order creation, no budget reservation, and fee estimation behavior. Since no annotations are provided, the description fully fulfills the transparency burden.
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?
The description is concise with four sentences, no redundant information, and front-loads the core purpose ('Read-only top-of-book FAK preview'). Every sentence contributes essential detail.
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 tool with 4 parameters, no schema descriptions, no annotations, and an output schema, the description covers the core semantics and behavior. It omits details about the output structure, but the presence of an output schema mitigates this need. A perfect score would require more explicit guidance on output fields.
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?
The description adds crucial meaning to the parameters by explaining how 'amount' and 'price_limit' differ based on the 'side' (BUY vs SELL). This is not available in the schema, which has 0% description coverage.
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?
The description clearly states the tool is a 'read-only top-of-book FAK preview' and explicitly distinguishes it from order-execution tools by stating it never creates an executor, sends an order, or reserves budget. This provides a clear verb+resource definition and differentiates it from siblings like order–related tools.
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 description indicates when to use the tool (to preview an order) and what it does not do (no order creation). However, it lacks explicit comparisons to sibling tools or conditions for not using it, which would raise the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: never constructs a signer, checks a live balance, or changes state. This provides clear transparency for a read-only status tool.
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 concise sentences front-loading the core purpose and constraints with no wasted words.
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 zero-parameter tool with an output schema, the description sufficiently covers what the tool does, its keyless nature, and what it avoids, making it complete for the agent.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter-specific info but reinforces the tool's keyless nature, which is relevant for usage context.
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?
The description clearly states it retrieves 'Operator-visible mode and safety-rail status' and explicitly distinguishes itself by being keyless and not performing state changes, which differentiates it from sibling tools that likely involve authentication or operations.
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 description implies safe usage without authentication ('keyless') and no state modification, but does not explicitly compare with alternatives or state when to use this tool over others. However, the context signals and sibling names allow inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pmq MCP server](https://glama.ai/mcp/servers/crp4222/pmq/badges/card.svg)](https://glama.ai/mcp/servers/crp4222/pmq)

Score Badge

Copy to your README.md:

[![pmq MCP server](https://glama.ai/mcp/servers/crp4222/pmq/badges/score.svg)](https://glama.ai/mcp/servers/crp4222/pmq)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/crp4222/pmq'

If you have feedback or need assistance with the MCP directory API, please join our Discord server