AgentsPrice
Server Details
Verified best price across crypto, retail, tools & Rx generics — real sellers, never fabricated.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 4 of 4 tools scored. Lowest: 4/5.
Tools are mostly distinct: best_price returns best price by category, quote is a raw query entrypoint, list_live_deals is a public feed, and reference_price is for anchoring deals. There is some overlap between best_price and quote, but the descriptions clarify different use cases.
Naming conventions are mixed: best_price and reference_price use adjective_noun, list_live_deals uses verb_noun, and quote is a single word. While readable, the lack of a consistent pattern may cause slight confusion.
Four tools is reasonable for a price comparison server. It covers the core functionalities without being overly numerous or sparse.
The tool set covers key operations: getting best prices by category and query, viewing live deals, and anchoring reference prices. Minor gaps exist (e.g., no tool to search across multiple categories or manually refresh deals) but the surface is largely complete for the domain.
Available Tools
5 toolsbest_priceAInspect
Verified genuine best price for a product category across real sellers: returns the lowest price, the venue offering it, how many sellers were compared, the savings vs the most expensive seller, and a live link to buy. Prices are never fabricated. Categories: electronics, gaming, home, fashion, crypto, travel, clearance, all. Needs an AgentsPrice API key (get one at https://agentsprice.com), passed as api_key. For a no-key sample of what is live now, use list_live_deals.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| api_key | No | ||
| category | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavior: returns low price, venue, seller count, savings, link; states prices are never fabricated. No annotations, but description carries full burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: two sentences, front-loaded with purpose, then details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, categories, API key requirement, and alternative. Output fields listed despite no output schema. Complete for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning for api_key (explains necessity) and category (lists valid values), but query parameter is not explained (default empty). Schema coverage 0%, but description compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool finds the lowest price for a product category across real sellers, listing output fields. Distinguishes from sibling tools list_live_deals and reference_price by mentioning alternative for sample.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (to find best price) and provides context: needs API key, categories listed, and alternative for no-key sample (list_live_deals).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_live_dealsAInspect
AgentsPrice public live-deals feed (electronics, gaming, home, fashion), cached about 10 minutes, containing only real sourced deals with live buy links. No API key required. Use for a quick read of what is genuinely on sale right now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses caching behavior (≈10 minutes), data authenticity (only real sourced deals), and access requirement (no API key). No annotations exist, so description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and key attributes. Every phrase adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: purpose, data freshness, authenticity, access. Lacks explicit contrast with sibling tools (best_price, reference_price) but still sufficient for a simple tool with no parameters or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; description adds no parameter info beyond schema, but baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists public live-deals feed with specified categories (electronics, gaming, home, fashion), and highlights it contains only real deals with live buy links. Distinguishes from siblings by emphasizing browsing current deals vs. price lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for a quick read of what is genuinely on sale right now.' Specifies no API key required, implying ease of use. Does not explicitly state when not to use or contrast with alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_pulseInspect
The AgentsPrice hive-mind pulse — a FREE, no-key, real-time aggregate of what agents are doing across the network right now: trending searches, the steepest live discounts found, open buy-side wants, and active marketplace listings. Real data only, never fabricated; richer the more agents use it. Use it to see demand, spot deals, or find what to list. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
quoteAInspect
One-stop best price for ANY query — the lowest-friction entrypoint. Pass a raw query (e.g. "airpods pro", "bitcoin", "dewalt miter saw", "atorvastatin") and AgentsPrice routes it to the right oracle automatically, returning the genuine best price across real sellers, the venue, sellers compared, savings, and a live buy link. Prices are never fabricated. No category needed. Needs an AgentsPrice API key (https://agentsprice.com), passed as api_key — or pay per call via x402 (see /.well-known/x402). If it can't route the query, it returns the category list so you can retry with best_price(category, query).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| api_key | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses key behaviors: prices never fabricated, routing logic, authentication needs (API key or x402), and what happens on failure (returns category list).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded with the main purpose, followed by examples, behavioral details, and fallback. Every sentence adds value, though slightly lengthy for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains return values (best price, venue, savings, live link) and fallback. Covers all behavioral aspects lacking annotations, making the tool fully comprehensible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates: explains 'query' with diverse examples (e.g., 'airpods pro', 'bitcoin') and 'api_key' by stating its role and the alternative x402 payment method.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it as a one-stop best price tool for any query, with explicit examples. It distinguishes from sibling tools like best_price by describing its routing behavior and fallback mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use as lowest-friction entrypoint, provides examples, and instructs to fall back to best_price if routing fails. Also covers authentication requirements and alternative payment via x402.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reference_priceAInspect
Verified reference price for a SINGLE item, to anchor an agent-to-agent deal. Returns one verified price across real sellers, the venue, sellers compared, the spread, a live buy link and a freshness flag, or an honest stale/unavailable status. Never returns demo/sample data as verified. Pass a nonce to bind the result to your negotiation. purpose: reference or deal_anchor. Categories: electronics, gaming, home, fashion, crypto, all. Needs an AgentsPrice API key (https://agentsprice.com).
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | ||
| nonce | No | ||
| api_key | No | ||
| purpose | No | deal_anchor | |
| category | No | ||
| max_age_seconds | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it returns verified price across real sellers, venue, sellers compared, spread, live buy link, freshness flag, or stale/unavailable status. It also mentions API key requirement and intention to be honest. However, it does not cover rate limits, error behavior, or mutability (clearly read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about four sentences, front-loading the core purpose and then adding details. It is concise but could be more structured (e.g., bullet points for return values). No wasted words, but some info is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 6 parameters with 0% schema coverage, the description is fairly complete. It covers purpose, parameters partially, return values, and authenticity. However, it lacks explanation of max_age_seconds, error states, and example outputs, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains purpose (reference/deal_anchor), category (electronics, etc.), nonce (binds result), and api_key (via mention of API key). However, max_age_seconds is not described, and item is only indirectly clear. Coverage is good but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Verified reference price for a SINGLE item, to anchor an agent-to-agent deal.' This specifies the verb (get verified reference price), resource (single item), and purpose (anchor a deal), distinguishing it from sibling tools like best_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the use case 'to anchor an agent-to-agent deal.' It also mentions what it does not return ('Never returns demo/sample data as verified'), but does not explicitly compare to sibling tools or provide when-not-to-use guidance, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!