Skip to main content
Glama

Ranking page and one pick for a person's conditions

share_ranking
Read-onlyIdempotent

Use this when: the user wants the ranking of API plans for their conditions, or a link they can open or share, and you do not need every plan in the answer. Do not use this when: you need the plans and their sentences in the answer (use search with detail or format full) or the user named the plans (use check_conditions). Returns the one plan that leads the ranking for the conditions (a plan that meets every condition, or the closest when none does), a confidence (its score out of 99), how many other plans also meet every condition, and ranking_url: the permanent address of a page that ranks every plan for these conditions with the official sentence for each. Confidence is the plan's score out of 99, the same as in the search answer; it is not a probability. The conditions are those of search. Example: 50,000 SERP searches a month with an official MCP server; the person gets one pick and a page ranking every plan.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "share_ranking"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNosummary returns one source sentence per fact; full returns every recorded fact and sentence.summary
mcp_authNoWays to authenticate to the provider's hosted MCP endpoint, any one of which will do: api_key, oauth. Met when the endpoint accepts at least one of them; implies a hosted endpoint.
questionNoThe user's words, if available. Read only for words that suggest a condition the request does not carry.
needs_dpaNoThe vendor must offer a data processing agreement (DPA) to the buyer.
needs_slaNoThe plan must come with a service level agreement (SLA).
needs_zdrNoZero data retention must be usable on this plan. A provider that offers it only on a custom enterprise agreement does not meet it on its listed plans.
preferredNoNice-to-have conditions; they do not filter, they break ties. Put a condition the person calls nice to have ("would be good", "if possible", "되면 좋겠다") here, not as a required field.
providersNoJudge only the plans of these providers (candidates you already have, for example from a web search). Give provider ids or names as listed, such as "tavily", "Brave Search API" or "You.com"; case does not matter. Names that are not providers here are listed under unknown_providers in the result.
needs_soc2NoThe provider must hold a SOC 2 report: true for Type I or Type II, "II" for Type II.
needs_batchNoThe plan must transcribe recorded audio (a file or a stored recording), for speech-to-text. A plan priced for live audio only is not met.
data_regionsNoRegions where data must be stored or processed, e.g. ["EU"]. Different from exit-IP countries.
needs_koreanNoThe service must voice Korean text (text-to-speech) or transcribe Korean speech (speech-to-text).
billing_typesNoAcceptable billing: monthly_subscription (A plan with a fixed fee (or minimum commitment) billed every month.) annual_subscription (A plan paid for a year at a time.) pay_as_you_go (No plan fee; a price per unit of use, billed after use or drawn from a balance topped up with any amount.) prepaid_credits (Money paid before use: a credit pack, a balance topped up first, or a plan amount charged in advance for the period.) Free plans always qualify.
monthly_pagesNoPages per month by type: plain_html (static pages), javascript (needs rendering), premium_proxy (blocked sites that need residential/premium proxies), javascript_premium_proxy (both).
needs_inboundNoThe service must receive email for the buyer and hand it on (inbound parsing, routes), for transactional email.
product_typesNoLimit to these product types. Default: every type that can serve the workload.
monthly_emailsNoEmails sent per month, for transactional email APIs (SendGrid, Mailgun, Postmark, Resend, Amazon SES, Brevo, Mailtrap, Loops). It is the whole workload: give it instead of monthly_pages, monthly_searches and monthly_browser_hours, not with them. Only email products can serve it; other products are out of scope.
search_enginesNoSearch engines whose results the plan must return, each at the plan's search price: google, bing, yahoo, yandex, baidu, duckduckgo, naver, brave (brave is Brave's own index). monthly_searches is the total over all of them.
captcha_solvingNoThe plan must solve CAPTCHAs for the browser sessions (the vendor does it, not the buyer own service).
min_concurrencyNoMinimum number of concurrent requests (or browsers) the plan must allow.
needs_streamingNoThe service must return audio in real time as it is made (streaming or a WebSocket), for text-to-speech; for speech-to-text, it must transcribe live audio as it arrives. A speech-to-text price line is per mode, so a plan priced for recorded audio only is not met.
monthly_searchesNoSearch requests per month (one results page each).
needs_remote_mcpNoThe provider must host a remote MCP endpoint (a URL an MCP client connects to). An official server that can only be run on the buyer own machine does not meet it.
proxies_includedNoThe plan must include proxy traffic of the vendor (some gigabytes in the plan fee). Proxy traffic sold only per gigabyte on top of the fee, or only on another plan, does not count.
search_countriesNoISO 3166-1 alpha-2 codes of the countries whose search results the searches must return (the search engine's country setting, e.g. Google gl), e.g. ["GB","CA"]. Different from exit_ip_countries.
exit_ip_countriesNoISO 3166-1 alpha-2 codes of countries the page requests must exit from, e.g. ["US","DE"]. For search results of a country use search_countries.
min_pages_per_docNoPages one document may have at the most the plan allows, for document parsing. Met when the stated limit is at least this many (or the pages say there is no page limit); a plan whose pages do not state a limit is unknown. The limit of the largest way of sending (batch or asynchronous) counts.
needs_diarizationNoThe plan must label who spoke (speaker diarization), for speech-to-text. Where the vendor charges extra for it, the extra price is added to the monthly cost; where the pages state no price or no inclusion the plan is unknown.
needs_no_trainingNoAn official page must say the vendor does not use the buyer's text, audio or documents to train its models without the buyer opting in. A use that is on by default with an opt-out to ask for does not count.
session_recordingNoThe plan must record browser sessions (video or replay) that the buyer can watch afterwards.
monthly_charactersNoCharacters of text voiced per month, for text-to-speech APIs (ElevenLabs, Cartesia, Deepgram Aura, OpenAI, Google Cloud, Amazon Polly, Azure, Gradium, Rime, Inworld, MiniMax, Murf, Hume). It is the whole workload: give it instead of monthly_pages, monthly_searches, monthly_browser_hours and monthly_emails, not with them. Only text-to-speech products can serve it; other products are out of scope.
needs_dedicated_ipNoThe plan must come with a dedicated sending IP address, for transactional email. A dedicated IP sold only as an add-on on top of the plan, or only on another plan, does not count.
needs_official_mcpNoThe provider must publish its own MCP server (hosted by it or run by the buyer), stated in its official documentation. A server only a third party published does not count.
ai_extraction_pagesNoHow many of the pages need their fields extracted by an AI model (from a prompt or a schema, or automatically) without writing selectors. Each page counts in one of the two extraction fields.
min_pages_per_crawlNoPages one crawl job (from one start URL, following links) must be able to reach. A plan whose crawl has no page cap meets any number; give the size of the largest site to crawl. Different from the monthly page total.
min_sending_domainsNoSending domains the plan must let one account authenticate, for transactional email. Met when the stated limit is at least this many (or the pages say it is unlimited); a plan whose pages do not state a limit is unknown.
min_session_minutesNoMinutes one browser session must be able to run on this plan, for hosted browsers. Met when the stated longest session of the plan is at least this long; a plan whose pages do not state a session limit is unknown, and a limit the page gives only for another plan is not met.
monthly_audio_hoursNoHours of audio transcribed per month, for speech-to-text APIs (Deepgram, AssemblyAI, Speechmatics, Amazon Transcribe, Google Cloud, OpenAI). A price given per minute is multiplied by 60. It is the whole workload: give it instead of monthly_pages, monthly_searches, monthly_browser_hours, monthly_emails and monthly_characters, not with them. Only speech-to-text products can serve it; other products are out of scope.
monthly_pages_totalNoTotal pages per month when the split by type is not known yet. Costs and verdicts then cover every share of JavaScript-rendered pages from 0% to 100% of the total (no premium proxies), and the result lists monthly_pages under needs_input.
needs_voice_cloningNoThe plan must let the account clone a voice from its own recording, for text-to-speech. Cloning limited to eligible customers, a request form or an enterprise plan does not count for a plan that is not that plan.
persistent_profilesNoThe plan must keep browser profiles (login state, cookies) between sessions.
search_result_typesNoResult types the parsed search response must contain: organic, ads, local_pack, knowledge_graph, people_also_ask, related_searches, shopping, news, images, videos, ai_overview.
max_monthly_cost_usdNoMonthly budget in USD before tax. Compared with listed prices; annual plans use their per-month equivalent.
needs_batch_discountNoAn official page must say a batch or asynchronous way of sending documents costs less than the list price on the plan, for document parsing. The budget and the cost are judged at the list price, not at the batch price.
needs_commercial_useNoThe plan must allow commercial use of the generated audio, for text-to-speech. A free plan limited to non-commercial use does not count; a plan whose pages do not say is unknown.
needs_no_min_billingNoAn official page must say audio is billed by the second (or an increment of seconds) with no minimum billed duration per request, for speech-to-text. A page that says nothing about rounding is unknown.
needs_webhook_eventsNoThe plan must send webhook events to the buyer's server (the vendor calls an address of the buyer when something happens).
monthly_browser_hoursNoBrowser time per month in hours, for hosted browsers (Browserbase, Browserless) billed by browser time. It is the whole workload: give it instead of monthly_pages, monthly_searches and browser_seconds_per_page, not with them. Only browser products can serve it; other products are out of scope.
needs_signed_webhooksNoThe plan must deliver webhooks that the buyer can verify by a signature (a signing secret or a signed endpoint).
max_overage_usd_per_1kNoThe most the plan may charge for each 1,000 emails beyond its included volume, in USD, for transactional email. A plan whose extra price is not published as a per-1,000 figure is unknown.
min_log_retention_daysNoDays the plan must keep the logs or events of sent email where the account can read them, for transactional email. Longer retention sold as an add-on does not count.
monthly_document_pagesNoPages of documents parsed per month, for document-parsing APIs (LlamaParse, Reducto, Unstructured, Mistral OCR, LandingAI, Amazon Textract, Google Document AI, Azure Document Intelligence, Datalab, Mathpix, Mindee, Nanonets, Upstage). A price given per credit is multiplied by the credits one page costs. It is the whole workload: give it instead of monthly_pages, monthly_searches, monthly_browser_hours, monthly_emails, monthly_characters and monthly_audio_hours, not with them. Only document-parsing products can serve it; other products are out of scope.
needs_table_extractionNoThe service must return the tables of a page as structure (rows and cells), not only the text, for document parsing.
search_returns_contentNoThe search response itself must carry the text of the result pages (extracted content), not only titles, links and snippets.
min_requests_per_minuteNoMinimum request rate the plan must allow, per minute.
browser_seconds_per_pageNoBrowser time per page in seconds, for headless-browser products billed by time. Every plan must then serve pages that take this long: a hosted browser does, a request-based API only when one request may run that long.
realtime_search_requiredNoSearch results must be returned in real time (not through a queue).
target_errors_not_billedNoError responses from the target site (e.g. 404) must not be billed.
needs_recurring_free_tierNoThe plan must be usable every month without paying (a free plan with a monthly allowance or a monthly free credit).
failed_requests_not_billedNoRequests that fail on the provider side (timeouts, blocks, 5xx) must not be billed. A flat monthly price for unlimited requests meets it, since no request is billed on its own; when only success-based billing will do, use only_successful_requests_billed.
structured_extraction_pagesNoHow many of the pages must come back as JSON fields rather than HTML or text, by any method the plan offers (CSS or XPath selectors, a schema, or AI). When the fields must be found without writing selectors, use ai_extraction_pages instead; each page counts in one of the two.
only_successful_requests_billedNoBilling must count successful requests only: each successful request is charged (or draws credits) and failed ones cost nothing. A flat monthly price for unlimited requests does not meet it, since the price is the same whatever succeeds.

Output Schema

NameRequiredDescriptionDefault
bestNoThe one plan the answer names: the best plan for the conditions, or the closest when none meets every condition.
as_ofYes
answerYes
countsNo
needs_inputYes
ranking_urlNoThe permanent address of the page for a person that ranks every plan for these conditions with the official sentences. Give it to the user. It opens after a server restart and holds no personal data.
zero_resultNo
engine_versionNo
unknown_providersNo
others_meeting_allNoHow many other plans also meet every condition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / best / properties / confidence / description
      Previous value: -"round(100 x conditions confirmed / conditions asked), the workload included. The share of the asked conditions that the plan's own official pages confirm; it is not a probability."New value: +"The plan's score out of 99, the same as in the search answer and the analysis page: 99 minus points for each asked condition the plan's own official pages do not confirm. It is not a probability."
    • changedOutput schema / properties / best / properties / confidence / maximum
      Previous value: -100New value: +99
    • changedOutput schema / properties / best / properties / fit / description
      Previous value: -"The fit score of the full result (100 x conditions met / required conditions); the counts and the metrics are in the full result."New value: +"The fit score of the full result (out of 99); the counts and the metrics are in the full result."
  2. Changed1 schema field changed
    • changedInput schema / properties / preferred / description
      Previous value: -"Nice-to-have conditions; they do not filter, they break ties."New value: +"Nice-to-have conditions; they do not filter, they break ties. Put a condition the person calls nice to have (\"would be good\", \"if possible\", \"되면 좋겠다\") here, not as a required field."
  3. Added

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that — it lists the returned fields (one pick, confidence out of 99, count of other plans meeting every condition, ranking_url) and explicitly disambiguates confidence as a score, not a probability. However, since an output schema exists and covers the response shape, and no failure modes or empty-result behavior are described, the added value beyond structured data is moderate.

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 structure is strong and front-loaded: when-to-use, when-not-to-use, then return values, then a clarification and an example. It loses a point for redundancy — 'confidence (its score out of 99)' is stated in the return list and then restated as a corrective sentence, which is more repetition than the point needs.

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 62 all-optional parameters, a rich output schema and full annotations, the description covers the decision boundary, the returned fields and the meaning of the confidence figure. The remaining gap is small: it does not say what happens when no plan meets any condition or that at least one condition/workload input should be supplied, though the closest-match fallback is implied.

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% across the 62 parameters, so the schema carries the semantics and the baseline is 3. The description adds one genuinely useful pointer — 'The conditions are those of search' — which tells the agent the condition vocabulary matches the sibling tool, and its mention of 'detail' and 'format full' hints at sibling parameter vocabulary, but it does not explain the required-vs-preferred split or workload fields itself.

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 names a specific verb and resource — produce the leading plan for the person's conditions plus a shareable ranking page — and immediately contrasts it against sibling tools that return the full plan list or check named plans. An agent can distinguish share_ranking from search and check_conditions without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit 'use this when' (user wants a ranking or a shareable link and does not need every plan) and an explicit 'do not use this when' with two named alternatives and the condition that selects each ('use search with detail or format full' for full sentences, 'use check_conditions' when the user named plans). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources