Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ScalpStream MCP What's the cheapest gas in Paris?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that buys small, factual datasets at call time with your own wallet, over x402 — roughly $0.01 a call, no account, no subscription, no API key anywhere in the flow.
Most MCP servers wrap an API you already hold a key for. This one pays as it goes. The seller holds no keys either: settlement runs through a facilitator that sponsors gas, so the only key in the system is yours, held in memory for the lifetime of the process and never written anywhere.
It is useful before you fund anything. With no key configured, every paid tool returns the free preview and the exact quoted price, so you can see what you would be buying before deciding to buy it.
Tool | What you get |
| Ranked short-term US equity options candidates with the observed metrics behind each ranking. Impersonal research data — no trade plan, sizing, or verdict. |
| Federally tax-exempt municipal bond funds and muni CEFs, with tax-equivalent yields for the 24/32/37% brackets. |
| Ranked cryptocurrency candidates: technical signals plus a Fear & Greed and news-sentiment overlay. |
| Where to earn interest on crypto: DeFi staking APY, stablecoin lending, liquidity-pool yields across CeFi and DeFi, risk-adjusted by TVL. |
| Cheapest fuel by location and grade. Station-level for Spain, France, Italy; official regional averages for the US. |
| Current AQI and pollutants anywhere in the world, an EPA-based verdict on exercising outdoors, and the cleanest window ahead. |
| US ports of entry ranked by all-in time — drive plus current CBP wait — per lane type. The nearest crossing is often not the fastest. |
| What's configured, what's been spent. Makes no network call and costs nothing. |
Related MCP server: Paid Business Data MCP Server
go install github.com/DV1-321/scalpstream-mcp/cmd/scalpmcp@latestClaude Desktop (claude_desktop_config.json), Claude Code, or any MCP client:
{
"mcpServers": {
"scalpstream": {
"command": "scalpmcp",
"env": {
"EVM_BASE_PRIVATE_KEY": "0x...",
"SCALPMCP_MAX_PRICE_USD": "0.10",
"SCALPMCP_BUDGET_USD": "2.00"
}
}
}
}Omit env entirely to run in preview-only mode.
Variable | Default | Meaning |
| (unset) | Base-mainnet key holding a little USDC. Unset = preview-only. |
|
| Refuse any single call quoted above this. |
|
| Refuse once the process has spent this much in total. |
Real money moves, so the design refuses rather than overspends:
Both limits are checked before anything is signed. A refusal costs nothing and never reaches the network.
An unset limit means the default, never "unlimited." A missing config line must not become unbounded spending.
Spend is recorded only when the data is actually delivered. If a paid request then fails, the error says settlement state is unknown rather than implying nothing moved — you may need to reconcile against the chain.
Gas is sponsored by the facilitator, so the wallet needs USDC and no ETH.
Use a throwaway key funded with a dollar or two. Never one holding balances you care about.
Sellers accept USDC on Base, Arbitrum and Polygon, and XRP or RLUSD on the XRP Ledger. This client pays USDC on Base, preferring it over other EVM rails regardless of the order the server lists them in.
The financial tools return impersonal, general-circulation research data, identical for every buyer. They are not investment advice, not personalised, and carry no trade plan, position sizing, or buy/sell verdict. The operator trades securities that appear in these feeds. Every response carries its own disclaimer and source attribution; read them.
Current US AQI and pollutant breakdown for any coordinates worldwide, an EPA-based verdict on whether it is safe to exercise outdoors, and the cleanest contiguous window in the forecast ahead for a session of a given length. Modelled data (Copernicus CAMS), not a sensor at the exact spot.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude in decimal degrees. | |
| lon | Yes | Longitude in decimal degrees. | |
| hours | No | How far ahead to search for a clean window, in hours. Default 24, maximum 168. | |
| place | No | Optional label for the location, used in the summary text. | |
| duration | No | How long you want to be outside, in hours; the window returned is a contiguous block this long. Default 1, maximum 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It transparently discloses the data source (Copernicus CAMS), the use of US AQI standards worldwide, the EPA-based verdict, and the forecast-window behavior. It does not mention rate limits or response structure, but the key limitations are well covered.
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 two sentences, front-loading the core outputs and ending with a necessary caveat about data quality. No filler words; every clause contributes meaningful information.
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 there is no output schema, the description explains the main result categories (AQI, pollutants, EPA verdict, clean window) and the window-finding behavior. It could specify how the window is computed or whether AQI is instantaneous versus averaged, but the essential functionality is clearly conveyed.
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 100%, so the baseline is 3. The description reinforces the roles of 'hours' and 'duration' in finding the cleanest window, but the schema already provides clear descriptions for each parameter, so the description adds limited additional semantic value.
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 enumerates specific deliverables: current US AQI, pollutant breakdown, EPA-based exercise safety verdict, and the cleanest contiguous window. It distinguishes itself from the unrelated sibling tools by focusing on air quality and outdoor activity planning.
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 implies the main use case (assessing air quality for outdoor exercise) and offers a 'when not' by noting the data is modelled and not from a sensor at the exact spot, which cautions against use when precise local measurements are required. However, it does not explicitly name alternative tools or provide formal 'use this when' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks US ports of entry by ALL-IN time — the drive there plus the current CBP wait once there — for passenger, commercial or pedestrian traffic, honouring which lanes the traveller may actually use. The nearest crossing is frequently not the fastest. Live CBP data across all 85 US ports of entry.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Latitude of the starting point, decimal degrees. | |
| lon | Yes | Longitude of the starting point, decimal degrees. | |
| lanes | No | Comma-separated lanes the traveller is eligible for, e.g. 'standard,SENTRI/NEXUS,Ready,FAST'. Defaults to standard only — trusted-traveller lanes are opt-in, since claiming one the traveller cannot use returns a wait they cannot have. | |
| limit | No | How many crossings to return. Default 5. | |
| place | No | Optional label for the starting point, used in the summary text. | |
| radius | No | Limit the search to crossings within this many km. 0 or omitted means no limit. | |
| vehicle | No | Traffic type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explains the ranking methodology (all-in time), the data source (live CBP data across 85 ports), and the lane eligibility consideration. It does not cover error handling or data freshness, but the core behavioral aspects are transparent.
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 concise and front-loaded. Two sentences convey the purpose, scope, and a key insight without any wasted words. It is easy to scan and understand.
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 the 7 parameters and no output schema, the description covers the essential aspects: what is ranked, by what metric, for which traffic types, and with live data. It does not explain the return format or error conditions, but the ranking behavior is sufficiently described for a tool of this 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?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the all-in time metric and lane honoring, which helps interpret the parameters, but it does not add specific parameter-level details beyond the schema.
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 the tool ranks US ports of entry by all-in time (drive + wait), covering passenger, commercial, and pedestrian traffic. It distinguishes itself from the sibling tools (which are unrelated) and the note about nearest not being fastest adds a specific behavioral insight.
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 provides clear context on when to use the tool: to find the fastest border crossing by all-in time, explicitly contrasting with the nearest crossing. It does not explicitly mention when not to use it or alternatives, but the usage scenario is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheapest fuel for a location and grade. Station-level pricing where governments publish open data (Spain, France, Italy); official regional averages for the US via EIA. With smart=true the ranking weighs the pump price against the fuel and time spent on the detour, so the cheapest sign is not always the cheapest tank.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in decimal degrees. Required for station-level countries (ES/FR/IT). | |
| lon | No | Longitude in decimal degrees. Required for station-level countries. | |
| grade | No | Fuel grade. | |
| smart | No | Rank by all-in cost (pump price plus the fuel and time of the detour) rather than pump price alone. | |
| region | No | US state code, e.g. CA. Used instead of lat/lon when country=US. | |
| country | Yes | ISO-3166 alpha-2 country code. ES/FR/IT give station-level prices; US gives a regional average. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It truthfully discloses that US results are only official regional averages, not station-level prices, and it reveals the smart=true caveat that the cheapest sign is not always the cheapest tank. This adds meaningful behavioral nuance beyond the input schema, though it does not mention request limits or exact response format.
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 compact at two sentences, with the primary purpose front-loaded. The second sentence earns its place by explaining a critical behavioral nuance (smart=true) that would otherwise be ambiguous. No filler or repetition exists.
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 the tool's medium complexity and lack of output schema, the description adequately covers key selection factors: country-specific data granularity, required location inputs, and smart mode semantics. It does not explicitly state the return format (e.g., whether a list or a single result is returned), but the description is sufficient for an agent to decide when to invoke it and with what parameters.
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?
The input schema already provides 100% parameter coverage, including descriptions for lat/lon (required for station-level countries), region (US state code), and country (ES/FR/IT station-level vs US regional). The description's added detail about data sources and smart=true behavior is useful but largely paraphrases or reinforces what the schema already documents, so it only marginally raises the baseline.
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 opens with 'Cheapest fuel for a location and grade,' a specific verb+resource statement that clearly identifies the tool's function. It further differentiates station-level pricing (Spain, France, Italy) from regional averages (US), and introduces the smart=true refinement, making it distinct from any other possible fuel-related tool.
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 provides clear context on when station-level versus regional pricing applies, and explicitly explains what smart=true does ('weighs the pump price against the fuel and time spent on the detour'). It stops short of naming alternative tools or saying 'when not to use,' but the sibling tools are unrelated, so the lack of explicit alternatives is not a major gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked cryptocurrency candidates using the same technical signals as the equity feed (RSI, ATR, VWAP, momentum) plus a macro overlay from the Fear & Greed index and news sentiment. Impersonal research data, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not explicitly state that the tool is read-only or free of side effects, though 'Impersonal research data, not advice' implies a non-actionable output. It adds some behavioral context by explaining the macro overlay, but omits details like data freshness or any limitations.
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 two sentences, front-loaded with the core purpose and methodology, followed by a helpful disclaimer. Every sentence earns its place with no wasted words.
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 the tool's simplicity (no parameters, no output schema), the description fully covers what the user can expect: a ranked list of crypto candidates with the technical and macro factors considered. The disclaimer adds a necessary caveat about its non-advice nature.
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?
The tool has zero parameters and an empty input schema, so there is nothing to explain. Per the baseline for 0-parameter tools, the score is 4. The description adds context about the methodology but does not need to specify parameter details.
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 the tool produces ranked cryptocurrency candidates and specifies the exact signals used (RSI, ATR, VWAP, momentum, Fear & Greed, news sentiment). It distinguishes itself from sibling tools like crypto_yields and options_research by focusing on general crypto research rather than yields or options.
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 usage context is implied through the description – it is for cryptocurrency research based on technical and sentiment signals. However, it does not explicitly state when to use this tool over siblings or mention any exclusions, so it lacks direct guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where to earn interest or staking rewards on crypto and stablecoins: DeFi staking APY, stablecoin lending and savings rates, and liquidity-pool yields across CeFi platforms and DeFi protocols, risk-adjusted by pool depth (TVL) and base-versus-emission share, with A/B/C ratings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It adds useful context about the risk-adjustment method (TVL, base vs emission share) and the A/B/C rating scale, which sets expectations about output. However, it omits data sources, update frequency, and any access or rate limitations, leaving notable gaps.
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 a single long sentence that front-loads the core purpose ('Where to earn interest or staking rewards') and then packs in categories, risk-adjustment details, and ratings. Each clause adds value, though splitting it into two sentences would improve readability.
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 there is no output schema and no parameters, the description provides a solid overview: yield types, platforms, risk-adjustment metrics, and rating scale. It does not detail the exact return format beyond ratings, but for a no-param research tool, it is adequately complete.
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?
The input schema has zero parameters, so schema coverage is trivially 100% and the baseline is 4. The description does not need to explain parameters; it provides enough context about the tool's scope and methodology to make the lack of parameters obvious.
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 the tool's purpose: finding where to earn interest or staking rewards on crypto and stablecoins. It enumerates specific categories (DeFi staking APY, stablecoin lending, liquidity-pool yields) and platforms (CeFi/DeFi), and the A/B/C rating system distinguishes it from generic crypto research tools like sibling crypto_research.
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 implies usage: use when you want to compare crypto yield opportunities. However, it does not explicitly state when not to use it, mention prerequisites, or reference alternatives among sibling tools. Guidance is implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Municipal bond funds and muni closed-end funds whose distributions are exempt from US federal income tax, ranked, with tax-equivalent yields computed for the 24%, 32% and 37% brackets, current yield, distribution frequency, growth streak and years without a cut. Impersonal research data, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the research nature and adds the 'not advice' disclaimer, plus the computed metrics. However, it doesn't describe the response format, update cadence, or any limitations. For a read-only data tool, this is adequate but not rich.
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 two sentences: the first is dense with specific metrics (tax-equivalent yields, brackets, distribution frequency, growth streak, years without a cut) and the second sets expectations ('Impersonal research data, not advice'). Every phrase earns its place, and it's well front-loaded with the subject.
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 the simple zero-parameter nature and no output schema, the description is mostly complete: it explains what the tool returns and the key data points. It could specify the exact output format (e.g., a ranked table), but for a research list tool this is sufficient.
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?
The tool has zero parameters, so the baseline is 4 per the rubric. The description doesn't need to explain parameters and doesn't attempt to; it instead focuses on the returned data, which is appropriate.
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 identifies the tool's domain (tax-exempt municipal bond funds) and the outputs (ranked list with yields, frequency, etc.). It distinguishes itself from siblings like crypto_research and cheapest_fuel by topic. However, it lacks an explicit verb like 'list' or 'research,' making the action slightly implicit.
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?
Usage context is implied through the description: if the user needs municipal income fund data, this is the tool. But there is no explicit when-to-use guidance or mention of alternatives, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranked short-term US equity options candidates with the observed metrics behind each ranking (signal strength, score, ATR%, relative volume, RSI, VWAP distance, ATM IV, daily trend, momentum) and an illustrative contract. Impersonal research data, identical for every buyer — not advice, and it carries no trade plan, position sizing, or buy/sell verdict.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that data is deterministic ('identical for every buyer'), impersonal, and excludes trade plans or verdicts. It lists the metrics provided, offering transparency about what the output includes, though it omits operational details like data freshness or limitations.
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 two sentences with no wasted words. The first sentence efficiently lists the core purpose and metrics, while the second sentence is essential for setting expectations about non-advice. Both sentences earn their place.
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?
For a no-parameter tool with no output schema, the description is quite complete. It explains what is returned (ranked candidates with metrics and illustrative contract) and what is not (advice or trade plan). It lacks details on interpretation or data source, but this is sufficient for basic tool selection.
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?
The tool has zero parameters, so the baseline of 4 applies. The description adds value by enumerating the metrics that appear in the output (signal strength, ATR%, RSI, etc.), which helps the agent anticipate the result even without parameters.
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 the tool provides ranked short-term US equity options candidates with specific metrics. It uses a specific verb ('ranked') and resource ('options candidates'), distinguishing it from sibling tools like crypto_research or municipal_income by focusing on US equity options.
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 implies use for obtaining research data, but does not explicitly say when to use it versus alternatives. It does clarify what it is not (advice, trade plan, buy/sell verdict), which helps set expectations, but lacks direct comparison to sibling tools or explicit use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports whether paid calls are enabled, how much this session has spent, the price per call, and which payment rails the services accept. Makes no network request and costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a good job by clearly stating that the tool makes no network request and costs nothing, signaling a non-mutating, safe operation. It also lists the exact data reported. It could mention authentication needs or response format, but the provided behavioral details are strong.
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 two sentences, front-loaded with specific, useful data points and no wasted words. The second sentence adds a valuable safety note without bloat.
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?
For a zero-parameter tool with no output schema, the description covers the essential information: what it reports and that it is free/non-network. A minor gap is the lack of response shape or units, but the tool's low complexity means this is not a significant omission.
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?
The input schema has zero parameters and 100% coverage, so the baseline is 4. The description adds no parameter-specific meaning, but none is needed because there are no parameters to document.
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 uses a specific verb ('Reports') and resource ('payment status') while enumerating concrete outputs: whether paid calls are enabled, session spend, price per call, and accepted payment rails. This makes the tool's purpose unmistakable and distinguishes it from the unrelated sibling research tools.
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?
No explicit when-to-use guidance or exclusions are provided. The line 'Makes no network request and costs nothing' implies safe, cost-free usage, but it does not state specific situations such as 'check before making paid calls' or compare to alternatives. For a simple status tool, this is adequate but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0air_qualityborder_crossingscheapest_fuelcrypto_researchcrypto_yieldsmunicipal_incomeoptions_researchpayment_statusScored across 8 tools
Each tool targets a distinctly different domain: options, municipal bonds, crypto research, crypto yields, fuel prices, air quality, border crossings, and payment status. Even the two crypto tools are clearly separated by purpose (research versus yields). No two tools overlap in function.
All tool names use lowercase snake_case and follow a consistent noun-phrase pattern (e.g., options_research, municipal_income, border_crossings). There is no mixing of styles or verbs, making the naming predictable and uniform.
With 8 tools, the count is within the typical well-scoped range. However, the breadth of topics suggests the server may be trying to cover too many unrelated domains for a single service, which slightly reduces appropriateness from an ideal focused set.
Given the name 'ScalpStream,' the server implies a focus on short-term trading, yet it lacks tools for real-time quotes, trade execution, or even general stock research. The unrelated tools (fuel, air quality, border crossings) do not fill this gap, leaving the core trading surface significantly incomplete.
33 pay-per-call market and news data tools over MCP with free discovery and x402 payments.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Pay-per-action access to APIs and MCP tools over Lightning L402 and Base USDC x402.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
