Skip to main content
Glama

solvscore_repgate

Maps an agent's trust score to its live rate-limit tier, showing hourly quota, remaining requests, reset time, and whether it clears the 85-trust underwriting threshold.

Instructions

[FREE] SolvScore REPGATE: map an agent's trust score to its live rate-limit tier. Returns trust_score, rate_limit_tier (GOLD/TRUSTED/STANDARD/UNTRUSTED/BLOCKED), requests_per_hour, used_last_hour, remaining, resets_in_seconds and whether the agent clears the 85-trust underwriting threshold. Accepts name, slug or id. Reputation-gated throughput, live on agentworld.me/rep-gate/.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent_ref": "<agent_ref>"
    },
    "name": "solvscore_repgate"
  }
}

Input Schema

NameRequiredDescriptionDefault
agent_refYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does valuable work by enumerating the exact returned fields (tier, requests_per_hour, used_last_hour, remaining, resets_in_seconds) and flagging the 85-trust threshold, but it says nothing about auth requirements, error behavior for unknown agents, or whether the data is cached vs truly real time beyond the word 'live'.

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?

Purpose is front-loaded in the first clause, followed by return fields and then input format. The trailing 'live on agentworld.me/rep-gate/' is essentially promotional and doesn't earn its place, but the rest is dense with usable information.

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 one parameter, no output schema, and no annotations, the description must carry both input format and return shape — and it does, listing every field returned and the tier enumeration. The only real gap is the absence of any guidance on choosing it over adjacent trust/credit tools.

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 0% — the single parameter 'agent_ref' has no description at all. The description compensates by stating 'Accepts name, slug or id', which is exactly the disambiguation an agent needs to fill that field correctly, though it doesn't tie that guidance back to the 'agent_ref' key by name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource: it maps an agent's trust score onto a live rate-limit tier, and it enumerates the resulting tier names. That is concrete enough to act on, though it never names the closest sibling (get_agent_trust_pulse) to draw the boundary explicitly.

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

Usage Guidelines3/5

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

The '[FREE]' marker and 'live' signal make it clear this is a free, read-only lookup rather than a mutation, and 'Accepts name, slug or id' tells the agent what input form is legal. However, there is no statement of when to prefer this over get_agent_trust_pulse, underwrite_agent_loan, or get_spend_authority, so the routing decision is left to inference.

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

Deploy Server

Other Tools