verantis-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VERANTIS_API_BASE | No | Point the client at a different Verantis API. | https://api.verantis.ai |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_paid_serviceA | 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. Prefer verified=true before paying anyone. |
| get_serviceA | Full unified record for one service host: every settlement rail it accepts on, each with its own reputation, price, buyers, volume and history, plus coming-soon chains. Pass the host (domain). |
| directory_statsA | Index-level statistics: services, verification breakdown, data freshness. |
| check_walletA | Check a recipient wallet BEFORE your agent pays it — a pre-payment guard. Pass the pay-to address a service asked you to pay; returns whether Verantis knows the wallet, its EARNED reputation tier, and human-readable reasons. A wallet IS a settlement rail, so the reply names the rail it settles on ('rail': chain + protocols), its host, on-chain buyer retention (distinct buyers, repeat rate, distribution), and the host's OTHER rails ('also_settles_on'). If 'shared_wallet' is true the address fronts many services (a relay/treasury) so the reputation reflects the pool, not one service — treat with care. An unknown or low-reputation recipient is a reason to pause. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The four tools have distinct purposes: get_service retrieves a single service's unified record, find_paid_service searches the directory, directory_stats provides index-level statistics, and check_wallet is a pre-payment guard. There is slight overlap between get_service and find_paid_service (both return service records), but the descriptions clarify that one is for a specific host and the other is for search.
Tool names follow a consistent verb_noun pattern: get_service, find_paid_service, directory_stats, check_wallet. The pattern is mostly consistent, though directory_stats uses a noun_noun structure rather than a verb_noun one, which is a minor deviation.
With 4 tools, the server is well-scoped for its purpose of querying service reputation and wallet safety. The count is slightly on the lower end but each tool serves a distinct function, and the domain is narrow enough that 4 tools feel appropriate.
The tool surface covers the core workflows: searching services, getting detailed records, checking wallets, and viewing index stats. However, there are no tools for actions like registering a service, updating reputation, or managing verification, which could be gaps if the server is meant to support the full lifecycle. For a read-only query server, the coverage is adequate.