Interline
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APV0_NETWORK | No | Network and asset facts; e.g., base-sepolia | |
| APV0_OPENROUTER_KEY | No | OpenRouter API key for real inference (optional) | |
| APV0_SELLER_ADDRESS | No | Seller address that receives payments | |
| APV0_FACILITATOR_URL | No | URL of the x402 facilitator (e.g., https://x402.org/facilitator) | |
| APV0_BUYER_PRIVATE_KEY | No | Buyer testnet private key (signs EIP-3009) |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| discover_payment_railsA | Probe a paid endpoint and report which payment rails it accepts + the price for each — WITHOUT paying. The neutral rail-discovery layer: one call tells your agent every way it could pay this endpoint, across whatever rails the endpoint offers. Use this before pay_for_resource to see the price/rails. |
| pay_for_resourceA | Pay for and fetch a paywalled resource, returning its content + a settlement receipt. Routes the payment through the rail the endpoint accepts; never pays more than max_price_usdc.
Uses the caller's OWN wallet key from APV0_BUYER_PRIVATE_KEY (non-custodial — this server never
holds or sees funds). |
| list_known_railsA | List EVERY agent-payment rail/protocol Interline knows about + how it relates to each — the neutral catalog. Separates rails Interline SETTLES natively (route_mode=native-settle: x402, AP2-via-adapter) from protocols it ROUTES you TO but does not settle (route_mode=handoff: Virtuals ACP's own on-chain escrow, OpenAI/Stripe ACP's card-only delegated payment). One call = the whole agent-payment landscape, including the rails we don't move funds on. Pair with discover_payment_rails (what a specific endpoint accepts). |
| payment_historyC | Return the most recent cross-rail settlement receipts — the unified ledger across every rail paid through. |
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
Each tool has a clearly distinct purpose: discovering endpoint-specific rails, listing all known rails, paying for a resource, and viewing payment history. No overlap or ambiguity.
Most tools follow a verb_noun pattern (discover_, list_, pay_), but 'payment_history' is a noun_noun pair, creating a minor inconsistency. Overall clear and predictable.
Four tools cover the essential operations for a payment rail server: discovery, listing, payment, and history. The count is well-scoped and appropriate.
Core workflows are covered: rail discovery (per-endpoint and global), payment, and history. Missing potential operations like refund or cancellation, but not critical for the stated purpose.