ripar-skills

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, which already conveys safety. The description adds context about the specific Algorand TestNet app, the newest-first ordering, and that specs/results stay offchain. This goes beyond annotations without contradicting them, though it doesn't describe return formatting or pagination.
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?
The description is two sentences: the first front-loads the action and filters, the second adds useful context about offchain storage. No fluff or redundancy; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple list operation with no output schema, and the description does not specify the structure of returned job objects. While it gives useful context (app ID, hash commitment, offchain storage), the absence of return-format details leaves the description not fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters with meaningful details (e.g., status enum and the 'disputed' clarification, agentId scope). The tool description's mention of filtering is redundant with the schema, adding no new parameter-level meaning, so the baseline of 3 is appropriate.
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 uses the specific verb 'List' and clearly identifies the resource ('jobs on the ValidationRegistry'), including ordering ('newest first') and filter options. It differentiates from siblings like ripar_post_job (create) and ripar_search_agents (search agents) by focusing on job listing.
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 provides clear context for when to use this tool: to list jobs with optional filters by status or agent. It does not explicitly mention alternatives or exclusions, but the verb and resource make the use case unambiguous, so it misses the explicit 'when-not' guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral context: it returns live registry records and fails if the chain is unreachable, rather than guessing. It also clarifies matching semantics, which goes beyond the annotation.
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?
The description is two sentences, front-loaded with the main purpose and then providing matching details and failure behavior. Every sentence earns its place with no redundancy or filler.
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?
The description covers the core purpose, matching criteria, live behavior, and failure mode. It lacks output format details, but no output schema exists, and the schema provides parameter constraints. Complete enough for a registry search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all three parameters with descriptions, so the description adds little semantic value for parameters. It reinforces the query matching behavior but does not introduce new parameter details; baseline 3 is appropriate given 100% schema coverage.
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 clearly states the tool's function: 'List or search agents in the on-chain IdentityRegistry' and details matching criteria (domain substring, exact agent id, Algorand address). This distinguishes it from sibling tools like ripar_get_agent, making the purpose unambiguous.
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 provides clear context for when to use the tool—listing or searching agents in the registry—and implies its scope. It does not explicitly name alternatives or exclusions, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and openWorldHint annotations already cover the safety profile and that it queries external state. The description adds valuable context beyond that: it explains the source is the Algorand indexer, each item includes a counted flag, and that counted:false indicates earned but uncredited reputation. It also highlights that this requires reading both transfer logs and registry boxes, giving insight into the underlying computation.
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?
The description is two sentences, completely free of filler. The first sentence states what it does, the second explains the meaning of the key flag and why it matters. It is front-loaded and every phrase earns its place.
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?
With no output schema, the description carries the burden of explaining what will be returned. It clearly states it lists transfers and each is marked with counted true/false, and interprets the counted:false case. It could have mentioned additional fields like amount, sender, or timestamp, but these are implied by 'USDC transfers'. For a listing tool, it provides sufficient context to understand the output shape and the purpose of the data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (limit, address, agentId) already has useful descriptions in the schema. The tool description does not add extra parameter-level semantics, but it does clarify the concept of 'for an agent' which maps to agentId/address. Per calibration, baseline 3 is appropriate when the schema handles the heavy lifting.
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 clearly states the tool lists real USDC transfers for an agent from the Algorand indexer, with a specific twist: each transfer is marked as counted or not by the ReputationRegistry. This distinguishes it from sibling tools like ripar_get_reputation (which presumably fetches current reputation) and ripar_list_jobs (which lists jobs), making it immediately clear what unique data this tool provides.
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 implies when to use this tool: to see the reputation gap between actual transfers and what was credited. It explains the gap is only visible by reading the transfer log together with registry boxes, which tells the agent why this tool exists. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable insight about the 'not found' behavior: returns found:false with reason, and the literal 0 representation. This goes beyond annotations and correctly explains absence is not an error.
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?
The description is two sentences, front-loaded with the main purpose and immediately followed by a crucial edge-case explanation. No unnecessary words or redundancy.
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?
The description covers the core fetch behavior and not-found semantics, but leaves ambiguity about optional identifier precedence (e.g., if multiple identifiers are passed) and response shape affected by includeJobs/includeReputation. Still, schema descriptions fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive text for each parameter. The description references id/domain/address but does not add new parameter-level meaning beyond schema descriptions. Baseline 3 applies.
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 clearly states the tool fetches a single agent record from the IdentityRegistry by id, domain, or Algorand address. The verb 'Fetch' combined with 'single' distinguishes it from sibling search tool ripar_search_agents.
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 indicates usage for retrieving one specific agent via unique identifiers, contrasting with search. It does not explicitly name alternatives or state when not to use, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it makes a request, interprets HTTP 402 challenges, and reports the cheapest acceptable payment. It also explicitly discloses the edge case where a 200 response is treated as 'free' rather than an error, which is valuable and not indicated by the read-only annotation.
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?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It is concise without being under-specified, covering the request behavior, output fields, and an important edge case.
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?
With no output schema, the description adequately explains the return information (amount, asset, network, payee) and handles the special case of 200 responses. It could be more complete by addressing other non-402 statuses or potential errors, but given the tool's simplicity and the annotations, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters (url, body, method, headers) with 100% coverage. The description does not add additional parameter-level details beyond the schema, but it does explain the overall output (amount, asset, network, payee), which is return-value information rather than parameter semantics. Baseline of 3 is appropriate.
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 clearly states the tool's purpose: 'Ask a paid endpoint what it charges, without paying' and details the specific behavior of reading an HTTP 402 challenge and reporting the cheapest payment. This distinguishes it from the sibling ripar_call_endpoint, which actually executes a paid call.
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 clearly communicates the use case: querying a paid endpoint for its price before committing to payment. It implies this should be used instead of ripar_call_endpoint when the user wants a quote only, but it does not explicitly name the alternative or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint: false, destructiveHint: false, idempotentHint: true), the description discloses concrete behavioral details: the output is unsigned base64 msgpack, no key is used/held, nothing is submitted, and the spec is committed by hash to prevent changes. This adds significant context beyond the annotations alone and contains no contradiction.
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?
The description is two sentences long, front-loads the primary action and output, and every sentence adds meaningful detail (output format, signing authority, immutability). There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction composer with no output schema and no nested objects, the description adequately covers what the tool returns (unsigned base64 msgpack plus plain-language summary), the safety model (no submission/key), and the commitment property of specHash. It is complete for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter descriptions, so the baseline is 3. The description adds a contextual note that 'the spec is committed by hash' which reinforces the role of specHash, but does not add new format or syntax details for the parameters. Thus it does not exceed the schema's coverage.
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 'Compose a ValidationRegistry post_job call and return it UNSIGNED as base64 msgpack', naming a specific verb (compose), resource (ValidationRegistry post_job), and distinguishing output format. This clearly differentiates it from sibling tools like ripar_search_agents or ripar_get_agent, which are read-only queries.
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 states that 'Nothing is submitted and no key is used or held: a human or wallet signs and broadcasts,' which tells the agent when to use this tool (to prepare an unsigned transaction) and what it will not do (submit). It does not explicitly name alternative tools, but the sibling list contains no other transaction composer, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, but the description adds crucial behavioral context: credits are keyed to payment IDs and the contract refuses duplicates but does not verify real transfers, so scores are claims not proofs. It also explains the 'never credited' vs 'scored zero' distinction, going well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but packs vital caveats and usage guidance without fluff. It could be split for readability, but every sentence contributes meaning, making it appropriately concise for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully describes what the read operation returns (payments credited, total USDC volume, validator verdicts), covers limitations (no real transfer verification), and explains edge cases (no score box). It provides all necessary context for an agent to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter with a clear description ('Registry id of the agent'). The tool description does not add further semantic detail about the parameter, so the baseline of 3 is appropriate since the schema carries the explanation.
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 uses a specific verb ('Read') and names the exact resource ('ReputationRegistry' app 768559198) and the data returned (payments, USDC volume, verdicts). It distinguishes itself from siblings by explicitly contrasting with ripar_settlements, making its purpose clear and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool ('Read an agent's score') and when not to trust it blindly, instructing the agent to call ripar_settlements to verify against the indexer before relying on the number. It also clarifies the meaning of a missing score box, giving clear guidance on interpreting results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, etc., but the description adds valuable behavioral details: the server cannot pay (no private key), 402 responses yield a payment challenge, and paymentHeader is forwarded untouched as X-PAYMENT. This goes beyond the schema and annotations, informing the agent of important limitations.
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?
Two sentences, front-loaded with the primary action, then concise conditions and payment guidance. No filler or redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic endpoint caller with 5 params, nested objects, and no output schema, the description covers the essential behavioral context: success returns the response, 402 returns a payment challenge, and the server's inability to pay. This is sufficient given the tool's open-ended nature.
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?
Schema coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that paymentHeader is forwarded as X-PAYMENT and clarifying the 402 flow, which is not fully captured in the schema's parameter descriptions. This enriches understanding of how the paymentHeader parameter functions.
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 clearly states 'Call an endpoint and return its response' with a specific verb and resource. It distinguishes this from sibling tools (agent search, reputation, jobs, settlements) by focusing on generic endpoint invocation with x402 payment handling.
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?
It provides clear context for use: call any endpoint, with special handling for 402 payment challenges. While it doesn't explicitly mention alternatives or when-not-to-use, the purpose is self-evident given sibling tools are domain-specific. The payment guidance adds practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ripar-skills MCP server](https://glama.ai/mcp/servers/nickthelegend/ripar-skills/badges/card.svg)](https://glama.ai/mcp/servers/nickthelegend/ripar-skills)

Score Badge

Copy to your README.md:

[![ripar-skills MCP server](https://glama.ai/mcp/servers/nickthelegend/ripar-skills/badges/score.svg)](https://glama.ai/mcp/servers/nickthelegend/ripar-skills)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nickthelegend/ripar-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server