Agentery

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 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.

Disable access to a custom benchmark. Keeps only a minimal audit record; no underlying Agentery data is touched. Pass `benchmark_id`.

Inspect searches by external callers in the last 90 days that found no provider or only weak matches (best relevance below 0.62), shown as generalised job labels and 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 there is insufficient qualifying evidence (status insufficient_evidence + next_step) — it is never filled from search popularity, page views or trending queries.

Use when someone asks what a kind of product typically costs or who competes in a space, e.g. 'what should I charge for lead-generation automation' or 'tools that monitor competitor pricing'. Maps the task to its market (the nearest providers by meaning, no fixed categories) and returns the market label, 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. For market plus shortlist in one call use research_capability.

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.

Use to check what a product of a given kind typically costs: give a task or product type (or a group_id from the group price league) and get its product group's fair price for each buyer tier (individual, pro, team / small business, enterprise) — the median entry monthly price in that tier with its typical range — plus which payment models the group typically uses (free, subscription, usage, one-time, contact sales), usage and one-time medians where at least 3 listings publish them, and the group's price-index change over 90 days. Groups are built from what products do, not from price. Medians of current published prices only; individual listings are not returned — use search_providers for candidates.

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 like-for-like index of observed agent and MCP pricing (base 100 = 29 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). 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.

Use to show how AI agent and MCP prices have moved over time: the dated Agent Economy Price Index series, the same chained like-for-like series agentery.com/aepi charts. Points are index levels (base 100), never prices. 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 gap flags). 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.

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.

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.

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.

Use when a seller or investor asks which tasks people look for that few paid products serve. Clusters requests seen on this MCP server by meaning and returns those far from any paid provider: 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.

Deep-dive ONE market before building or investing — the market is the semantic neighbourhood of your natural-language query (nearest providers by text embedding, NO fixed category). Every field is MEASURED: the observed-pricing benchmark separated by provider type and buyer tier (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 providers already competing there with their observed price and relevance. Pass `query` (a natural-language capability or market, e.g. 'customer support chatbot'). For market + pricing + a ready shortlist in one call, use research_capability.

Use to judge 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. Comparables are the products closest in what they do (no fixed categories). 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 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.

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 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.

Use for a quick first overview of a buying task in one call: the closest-matching listings (matched on what they do, no fixed categories), the 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 for compare_providers. Also returns suggested_alternatives. It does not run the comparison. For careful selection prefer search_providers → get_provider_profile → compare_providers. Accepts `task` (aliases: query, q).

Use when someone wants to find or shortlist AI products, AI agents, MCP servers or APIs for a task, e.g. 'AI tool that transcribes sales calls' or 'MCP server to reply to Zendesk tickets'. Returns ranked candidates with what each 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 to check: open strong ones with get_provider_profile and compare finalists with compare_providers. Thin coverage returns no_match, never padding.

Stop watching a research job (the result stays retrievable with get_research).

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).

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`.