Skip to main content
Glama

verantis-mcp

by io.github.m9labs-railscope

find_paid_service

Read-only

Search Verantis's verified directory of machine-payable services (x402, MPP). Results are UNIFIED per service (host): each carries its settlement rails ('rails': base / solana / tempo), and every rail has its OWN reputation, price, and buyer retention — never blended. Pass 'chain' and 'matched_rail' marks that chain's rail so you see the reputation for the rail you'll actually pay on. 'coming_soon' lists advertised chains not yet measured. Each rail's 'wallet_scope' says if its pay-to wallet is 'dedicated' (the buyers/payments/volume are this service's own) or 'shared' (a relay/treasury fronting 'wallet_services' services, so those figures are the pool's inbound, not this service alone). Prefer verified=true before paying anyone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
chainNosettlement network, e.g. base, solana, polygon, tempo
limitNomaximum number of results to return (default 10)
queryYeswhat you need, e.g. 'twitter data', 'web search', 'rpc ethereum'
protocolNorestrict to one payment protocol: x402 or mpp
min_scoreNominimum trust score 0-100 — set high (e.g. 85) for money-moving tasks
proven_onlyNoonly services that have EARNED reputation over time (excludes 'new' services and 'watch' services whose on-chain payments are concentrated / not yet broadly distributed). Reputation is earned via consistent history + on-chain buyer retention; a brand-new well-behaved service is verified but new, not top-trust.
max_price_usdNomax price per call in USD
require_freshNolive re-probe stale results before returning — use before paying real money; adds ~1s per stale service
verified_onlyNoonly services that passed the latest live probe
max_latency_msNoreject services slower than this (ms)
exclude_concentratedNoexclude services from operators with many listings under one registrable owner (a neutral concentration signal, not a fraud claim)

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit / description
      Added value: +"maximum number of results to return (default 10)"
    • addedInput schema / properties / protocol / description
      Added value: +"restrict to one payment protocol: x402 or mpp"
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses important result-shaping behaviors: unified per host, rails each with their own reputation/price/retention, wallet_scope semantics (dedicated vs shared), and coming_soon indicating unmeasured chains. This is substantial behavioral context that an agent cannot infer from annotations or the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: purpose, result structure, rail semantics, wallet_scope interpretation, and a usage warning. The description is dense with meaning but not bloated, and the most critical scoping information appears early.

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?

Given there is no output schema, the description does a strong job of explaining key result fields: rails, wallet_scope, coming_soon, and matched_rail. However, the phrasing 'Pass chain and matched_rail marks that chain's rail' is slightly ambiguous about whether matched_rail is an input or output field, which is a minor completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining how chain interacts with the output (matched_rail) and what wallet_scope means for interpreting payments/volume, which goes beyond the schema. It does not deeply explain every parameter, but the schema already handles those.

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 opens with a clear verb and resource: 'Search Verantis's verified directory of machine-payable services (x402, MPP)'. It further clarifies the result model (unified per service, per-rail data) and naturally distinguishes itself from siblings like check_wallet and directory_stats by focusing on the search/query behavior.

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

Usage Guidelines4/5

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

The description gives clear operational guidance: pass 'chain' to see rail-specific reputation, and 'Prefer verified=true before paying anyone' to signal high-stakes selection. However, it does not explicitly contrast with alternatives like get_service, so it stops short of full when-to-use versus when-not-to-use guidance.

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

All verantis-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct purpose: checking a specific wallet, searching the service directory, retrieving a full service record, and viewing index stats. There is no overlap or ambiguity; an agent can easily choose the right tool based on the task.

Naming Consistency4/5

Most tools follow the verb_noun pattern (check_wallet, find_paid_service, get_service), but directory_stats is a noun_noun which breaks the convention slightly. This is a minor deviation and the names remain clear and predictable.

Tool Count5/5

With only 4 tools, the server is tightly scoped to its purpose of verifying wallets and querying service directory information. Each tool earns its place, and the count is well within the ideal 3-15 range for a focused server.

Completeness5/5

The tool surface covers all essential operations for a read-only directory and reputation service: searching, retrieving details, checking a specific wallet, and getting summary stats. There are no obvious dead ends or missing actions within the stated domain.

Resources