What is the Agentery remote MCP server?
The Agentery remote MCP server is a hosted Model Context Protocol endpoint at https://agentery.com/api/mcp, so AI assistants can connect to it without installing or running anything locally.
Agentery MCP ServerVerifiedFeatured
@ntlgnc
Basic information
Transport
Streamable HTTP
Authentication
None
Last updated
Category
AI & Agents
Author
ntlgnc
Submitted by
Agentery
About Agentery MCP Server
Free MCP for live and historical pricing for 13,000+ agents and MCPs. Never knowingly pay too much... or charge too little. Know the going rate. https://agentery.com.
Connection details
https://agentery.com/api/mcpSetup
claude mcp add agentery --transport http https://agentery.com/api/mcpAgentery MCP Server tools
23Gives a one-call first overview of a buying task: market prices, a short priced shortlist and alternatives together. Use this when you want a quick picture: the closest listings (matched on what they do, no fixed categories), price range and median for comparable products (with n), and a shortlist with observed prices, market_position (below / in line / above market) and handles in compare_ready, plus suggested_alternatives. It does not run the comparison. Use search_providers → get_provider_profile → compare_providers instead for careful selection; price_benchmark to judge one price. Accepts `task` (aliases: query, q).
Finds products (AI products, AI agents, MCP servers or APIs) that do a task and returns a ranked shortlist; start here to choose a product. Use this when someone wants candidates, e.g. 'MCP server to reply to Zendesk tickets'. Each result has what it does, a fit label (match / partial / weak, naming any mismatch), delivery type, price status (known / free / contact_sales / unknown; unknown is never free) and links. Requirements in the wording are checked per result; unverified ones are marked unknown. Results are candidates: open strong ones with get_provider_profile, compare finalists with compare_providers. Thin coverage returns no_match, never padding. Use research_capability instead for a one-call overview with prices; price_benchmark, find_market or get_group_fair_price when the question is cost.
Maps a task to its market: who competes there, how many are priced, and the price level per buyer tier. Use this when someone asks who competes in a space or what a kind of product costs, e.g. 'tools that monitor competitor pricing'. Returns the market label (nearest providers by meaning, no fixed categories), provider and priced counts, the nearest providers with observed prices, and pricing_by_tier (median, p25/p75, range and n per buyer tier). When nothing is close it returns no_match or thin_coverage and withholds pricing rather than invent a market. Use market_report instead for the full measured breakdown; research_capability for market plus shortlist in one call; price_benchmark to judge a specific price.
Use to compare 2–6 shortlisted listings side by side — plan-level prices (e.g. the Pro tier), capabilities, deployment, licence and how to connect — or to check a quote against alternatives. Inputs resolve to real listings by exact handle, then exact name, never a silent fuzzy swap: unknown inputs come back in unresolved_inputs with suggested_matches and a corrected_call; if only one input is real it is compared with its nearest market peers (comparison_status says so); if none resolve, comparison_status is insufficient_valid_providers. Mixed delivery types are flagged: a hosted agent and an MCP server are not directly equivalent, so compare hosted prices with hosted prices. Over-budget or weak matches get suggested_alternatives. Returns a concise decision view by default (fit, observed plans and prices with source and date, job cost, requirement verdicts, unknowns); pass detail:"full" for every field. Accepts `provider_ids` (aliases: handles, ids, or a comma-separated string).
Use when asked whether prices of AI agents, tools or MCP servers are rising or falling overall. Returns the current Agent Economy Price Index (AEPI), a chained quoted-price index of observed agent and MCP pricing in US dollars (changes in the publicly quoted price of the same product and offer; base 100 = 30 Jun 2026; an index level, not a price), with 1-, 7- and 30-day change, plus the same for the four buyer tiers (Individual, Pro, Team/SME, Enterprise). Every response names its release_id, reference_currency and methodology_revision; response_mode=full adds fx_attribution (exact native-price and exchange-rate contributions per window: log changes add, level factors multiply) and currency_evidence. provider_type=agent|mcp gives the standalone index for that delivery type; tier narrows to one tier. For the trend over time use get_price_index_history; for what a particular kind of product costs use get_group_fair_price or price_benchmark.
Judges a specific price or quote against the closest comparable products by what they do (no fixed categories), in the buyer's tier and pricing unit. Use this when asked whether a price is fair or what a capability typically costs, e.g. 'Is $49/month reasonable for an AI SDR for a small team?'. Pass the capability as `query` (aliases: task, niche). Returns observed prices of comparable products — median, p25/p75, range, mean, stdev and n — split by delivery type (agent | mcp) and buyer tier (individual / pro / team_sme / enterprise), never blended across incompatible pricing units. A benchmark describes an observed sample; it is not a quote and not evidence of willingness to pay. Set provider_type and buyer_tier when known. If nothing priced is close it returns resolved:false with a note, never an invented figure. Use get_group_fair_price instead for a broad group-wide guide; find_market for who competes.
Use when a buying decision hinges on one specific fact about one listing that its profile does not settle, e.g. {"provider_id":"flux_operator","requirement":"Is there a Helm chart for Kubernetes?"} or 'Does the Business plan go to checkout or to contact sales?'. Agentery reads the vendor's own pages, its code repository (read, never run) and the pricing page's buttons, and answers yes / no / partly / unknown with quotes, URLs and observation dates. Usually answered in this response within about 15 s; otherwise call get_research with the job_id after poll_after_seconds. Identical questions share one job. A found statement is the vendor's own claim, not independent verification.
Status and result of a research job created by request_research. status: queued / running / answered / partly_answered / still_unknown / failed; phase: queued | running | retry_scheduled | completed_answer | completed_unknown | failed. Poll no more often than poll_after_seconds — polling is free and never repeats the work. result: answer (yes/no/partly/unknown), short_answer, evidence per claim (quote, URL, observed date; file path and revision for repositories; element for pricing-page buttons), facts assessed separately (e.g. Dockerfile vs published image vs Helm chart), conflicts and what remains unresolved.
Stop watching a research job (the result stays retrievable with get_research).
Use when an earlier search_providers or research_capability answer missed what was meant: pass its request_ref and the correction in plain words (e.g. 'must integrate with Slack', 'budget is $20/month', 'data must stay in the EU'). Agentery re-runs the search with the changed constraints (the others are kept) and returns the new answer plus what changed. source: 'human' (the user's words), 'agent' (your assessment, default) or 'follow_up'. Agentery sees only the request and correction you send, never your wider conversation. Task answers (search_providers, compare_providers, research_capability, price_benchmark, market_report) carry ONE request_ref plus a 'conversation' block: the facts remembered for the task, any optional clarification questions (at most two, one round) and the exact refine_results call to continue. Answer with plain words, 'unknown' or 'skip'; source is one of human, agent, follow_up. Pass the same request_ref to another task tool to continue the task there. References expire 24 h after the last turn.
Gives the broad group-wide fair price for a kind of product: the median entry monthly price per buyer tier across its whole product group. Use this when you want a general price guide: give a task or product type (or a group_id from the group price league) and get the fair price for each buyer tier (individual, pro, team / small business, enterprise) with its typical range, the group's typical payment models (free, subscription, usage, one-time, contact sales), usage and one-time medians where at least 3 listings publish them, and the group's 90-day price-index change. Groups are built from what products do, not from price. Medians of current published prices only; individual listings are not returned. Call with no arguments to list group IDs. Use price_benchmark instead to check a specific quote against the closest comparables; search_providers for candidates.
Use to show how AI agent and MCP prices have moved over time: the dated Agent Economy Price Index series, the same chained quoted-price series (US dollars, base 100 = 30 Jun 2026) agentery.com/aepi charts. Points are index levels, never prices; calendar days with no published observation are listed in gaps with their reason, never interpolated. Whole-economy series by default; `tier` for one buyer tier; provider_type agent|mcp for one delivery type (own base 100); `period` 30d (default) / 90d / all; response_mode summary (default) or full (adds per-day native / FX / combined components and the window's exact attribution). Thin data returns insufficient_history, never an invented series. For what one capability costs use price_benchmark or market_report. Also reads a private custom benchmark's history via benchmark_id.
Finds jobs callers ask for that few paid products serve: requests seen on this MCP server, clustered by meaning, that sit far from any paid provider. Use this when a seller or investor asks where under-served opportunities are. Returns the request phrasing, distinct_callers, raw_requests, the nearest paid provider and its similarity (low = under-served). headline = jobs asked by two or more callers; weak_leads = one caller; information_requests = questions about a named product. These are research leads from limited traffic, not buyer counts or proof of a market-wide gap; few or none is normal while volume is low. Marked test traffic is excluded. No arguments needed. Use demand_signals instead when you want searches that returned no or only weak results.
Find related alternatives to a known provider, ranked by text-embedding nearness to that provider's OWN profile (NO category lookup), each with observed price, endpoint liveness, community upvotes and how_to_connect (website, docs, mcp endpoint). For cheaper_only, inspect whether the reference price and candidate prices support a valid comparison: an empty response may reflect a missing or incompatible reference price rather than the absence of alternatives (the response says which). Accepts `agent_id` (aliases: handle, id). These substitutes are also surfaced inside research_capability and compare_providers. Each alternative also carries `deployment` (evidenced model) and how_to_connect.install / repository (1.10.0).
Lists searches that found nothing good: queries by external callers in the last 90 days that returned no provider or only weak matches (best relevance below 0.62). Use this when you want searches Agentery could not answer well, as generalised job labels ranked by distinct callers. Most entries come from a single caller: treat those as leads. These are limited coverage signals from Agentery's own callers — not proof that a product does not exist, and not proof that a market has paying demand. Not a prerequisite for choosing a product. Empty args ({}) return the current list; an empty response means insufficient qualifying evidence (status insufficient_evidence + next_step) — it is never filled from search popularity, page views or trending queries. Use market_gaps instead for jobs that few paid products serve.
Report the result of ACTUALLY USING a listed provider for a task. Testing Agentery's connection or retrieval does not establish that the listed provider worked — do not report those. Reports are self-reported evidence subject to eligibility checks: they are correlated with your recent retrievals, improve ranking accuracy, and unlock higher rate limits for contributors. Only reports we can match to one of YOUR retrievals (search_providers / get_provider_profile / compare_providers / suggest_alternatives naming that provider, last 48h) carry weight; unmatched reports are stored but unweighted. Aggregates surface as `reported_success` on profile/comparison cards once 5+ distinct reporters exist (90-day window). Callers with 5+ correlated reports in 30 days get a doubled per-minute rate limit. Send an x-agentery-key header to keep one reporter identity across IPs (it is stored only as a hash).
Use to check one specific listing before recommending or connecting it: plans and prices with billing units, what it does, integrations, deployment (hosted / self_hosted / both / unknown, with evidence), licence (named licence only), liveness and how to connect (website, docs, MCP endpoint with a copy-paste config_snippet, A2A agent card, API, install). Fields are null when the vendor publishes nothing; nothing is guessed. price_applies_to flags a stored price that belongs to the vendor's platform rather than this connector. product_group names the listing's product group with its fair price per buyer tier and 90-day price-index change. reported_success stays null until 5+ distinct reporters in 90 days; after actually using a listing, call report_outcome.
For buying decisions prefer get_provider_profile (prices, deployment, evidence); use this only for the short public directory card of one provider by handle or registration number: bio, source URLs, X-verification status, entity type, community rating and structured profile when available.
Measures ONE market in depth before building or investing: the full observed price distribution by provider type and buyer tier, and the providers competing there. Use this when you need detailed market numbers, not a quick map. The market is the semantic neighbourhood of your query (nearest providers by text embedding, NO fixed category). Every field is MEASURED: the observed-pricing benchmark (median, mean, stdev, p25/p75, min–max range and n via the canonical pricing engine), how many providers are in the neighbourhood and how many are priced, and the top competing providers with observed price and relevance. Pass `query` (e.g. 'customer support chatbot'). Use find_market instead for a quick market map; research_capability for market + pricing + a ready shortlist in one call; search_providers to pick a product.
Use when someone wants to keep watching the prices of products they choose (e.g. five named writing tools). Creates a PRIVATE custom benchmark (a saved, calculated peer cohort) over Agentery's data — no account needed. Two modes: (A) explicit members: pass `members` (a list of exact handles; product names/domains resolve where unambiguous). (B) fork a market: pass `base_niche` (its slug) plus optional `remove`/`add`. Returns a one-time secret `benchmark_id` (cb_… token) — store it; it's your only key. Use it later in get/update/delete and in market_report/get_price_index/get_price_index_history. Ambiguous names are returned as candidates, never silently resolved; unresolved inputs block creation unless allow_partial:true. All prices/history are computed from Agentery's immutable observations; canonical market data is never changed.
Get a private custom benchmark's current report: members, current stats (headline median/quartiles only when ≥3 comparable priced members — monthly, per-seat and per-call prices are never blended), buyer-tier / provider-type / pricing-unit cohorts, historical index, and data coverage. Pass `benchmark_id` (your cb_ token) as an ARGUMENT.
Add/remove members or rename a custom benchmark. Creates a NEW immutable version (the previous version stays fully reproducible) and returns the exact change-impact on the median/quartiles/index. Pass `benchmark_id`.
Disable access to a custom benchmark. Keeps only a minimal audit record; no underlying Agentery data is touched. Pass `benchmark_id`.
Overview
Agentery is a market-intelligence MCP that turns "what does this cost?" into structured, normalized data for commercial AI agents, MCP servers, and agent APIs. It tracks thousands of listings with observed pricing, so your assistant can research a market, compare providers on value, and monitor price movement — all through one public, no-auth endpoint.
What it does
- Map a task to its niche —
find_niche,research_capability(one-call procurement). - Compare normalized prices by buyer tier and billing unit (monthly / per-seat /
per-call, FX-adjusted) —
price_benchmark,compare_agents,search_agents. - Read the Agent Economy Price Index (AEPI) and its history —
get_price_index,get_price_index_history. - Build private custom benchmarks — your own peer cohort with a secret token, historical reconstruction, and change-impact analysis.
- Find gaps & demand —
market_gaps,demand_signals,niche_report.
19 tools, read-only except reporting your own outcomes. No API key required.
Connect
{ "mcpServers": { "agentery": { "type": "http", "url": "https://agentery.com/api/mcp" } } }
Frequently asked questions
How do I connect to the Agentery MCP server?
Add the endpoint https://agentery.com/api/mcp to any MCP-compatible client such as Claude Code, Cursor, or VS Code. The setup snippets on this page configure each client in one step.
Does the Agentery MCP server require authentication?
No. Agentery's MCP server does not require authentication — you can connect directly with the endpoint URL.
Which transport does the Agentery MCP server use?
Agentery exposes a Streamable HTTP endpoint, the transport used by remote MCP servers and supported by all major MCP clients.
More remote MCP servers
A
APIR Agent Verification
APIR is the evidence record for AI agents
AI Trading Signals
Live crypto trading signals via API. Full trade setups with entry, stop-loss, take-profit, leverage, and automated verification. Built for Claude Code, OpenAI Codex, and 30+ AI agents.
1
1cent
Production remote MCP server with 35 safe web-intelligence tools: 32 paid x402 URL operations plus 3 free discovery/demo tools. Base Mainnet USDC, no account or API key; SSRF protection, strict schemas and idempotent set
ARVX
ARVX™ reads client relationship health using the science of why partnerships last. It models two people, factors in what's influencing each of them, and reads their relationship across five areas, with what moved since t
A
Aayat AI
Pay-per-use data and tools for AI agents: crypto token safety and rug checks, web search with cited answers, page-to-Markdown, up-to-date library docs, package safety, company research and UK/EU open data. 160 tools, 20
Comments