ripar-skills
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RIPAR_ALGOD | No | Algod API endpoint. | https://testnet-api.algonode.cloud |
| RIPAR_INDEXER | No | Indexer API endpoint. | https://testnet-idx.algonode.cloud |
| RIPAR_NETWORK | No | The network to use. The registries only exist on TestNet today. | testnet |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ripar_search_agentsA | List or search agents in the on-chain IdentityRegistry (Algorand TestNet app 768547159). Matches a substring of the agent's domain, or an exact agent id or Algorand address. Returns live registry records — if the chain is unreachable this fails rather than guessing. |
| ripar_get_agentA | Fetch a single agent record from the IdentityRegistry by id, domain, or Algorand address. Returns found:false with the reason when the registry has no such agent — the contract's 'not found' value is a literal 0, so an absent agent is a real answer, not an error. |
| ripar_get_reputationA | Read an agent's score from the ReputationRegistry (Algorand TestNet app 768559198): payments credited to it, total USDC volume, and validator verdicts. Each credit is keyed to a payment transaction id and the contract refuses to count the same id twice, but it does NOT verify that the id names a real transfer — so treat a score as a claim recorded on chain, not one proven by it, and call ripar_settlements to check it against the indexer before trusting a number. An agent with no score box has never been credited at all, which is different from having been paid and scored zero. |
| ripar_list_jobsA | List jobs on the ValidationRegistry (Algorand TestNet app 768547172), newest first, optionally filtered by status or by the agent serving or validating them. Each job commits to its spec by hash; the spec and the result themselves stay offchain. |
| ripar_settlementsA | List real USDC transfers for an agent from the Algorand indexer, each marked with whether the ReputationRegistry has already counted it. Inbound payments marked counted:false are reputation the agent earned but was never credited for — a gap that is only visible because the transfer log and the registry's |
| ripar_quote_endpointA | Ask a paid endpoint what it charges, without paying. Makes the request, reads the HTTP 402 challenge, and reports the cheapest acceptable payment: amount, asset, network, and payee. An endpoint that answers 200 is reported as free rather than as an error. |
| ripar_call_endpointA | Call an endpoint and return its response. If it answers 402, you get the payment challenge back instead of a result — this server holds no private key and CANNOT pay. To complete a paid call, have a wallet sign the payment and pass the resulting header as paymentHeader; it is forwarded untouched as X-PAYMENT. |
| ripar_post_jobA | Compose a ValidationRegistry post_job call and return it UNSIGNED as base64 msgpack, with a plain-language summary of what signing it would do. Nothing is submitted and no key is used or held: a human or wallet signs and broadcasts. The spec is committed by hash so it cannot be changed after the job is open. |
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 8 tools
Each tool targets a distinct resource and action: search vs. get for agents, get for reputation, list vs. post for jobs, quote vs. call for endpoints, and settlements as a separate verification tool. There is no meaningful overlap that would confuse an agent.
All tool names follow the same pattern: ripar_<verb>_<noun>. Verbs are consistent (search, get, list, quote, call, post) and lower_snake_case is used throughout. This creates a predictable and readable API surface.
8 tools is well-scoped for the server's purpose, covering agent discovery, reputation, jobs, settlements, and endpoint interactions without unnecessary bloat or redundancy. Each tool earns its place.
The set covers the core workflows: reading identities and reputation, listing and creating jobs, verifying payments, and interacting with paid endpoints. Minor gaps exist (e.g., no get_job by id, no on-chain update actions), but these are acceptable given the server's read-only and transaction-construction role.