Hermes Micro-Agent

by com.theworkpc.hermesmicroservice

Overview Discussions Admin

Get account credit balance

get_credit_balance

Read-onlyIdempotent

Read one sender's account credit balance in USDC cents.

Free to call, no authentication. Credits come from refunds that could not be sent on-chain.

Behavior: read-only, never raises. found=false and cents=0 when the address never held credit.

Parameters: the balance is tied to the sender address, not to a job key.

When to use: after refund_job, to see whether the refund landed on-chain or as credit.

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": {
      "sender": "<sender>"
    },
    "name": "get_credit_balance"
  }
}

Input Schema

Name	Required	Description	Default
`sender`	Yes	Base address (0x-prefixed) whose credit balance you want. Required.

Output Schema

Name	Required	Description
`cents`	Yes	credit balance in USDC cents
`found`	Yes	false when the sender has no credit record
`sender`	No
`updated_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on what they cannot: no authentication required, no cost, never raises, and the exact not-found shape (found=false, cents=0). It also explains where credits originate (refunds that could not be sent on-chain), which lets an agent reason about expected values.

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?

Front-loaded purpose sentence, then short labeled blocks for behavior, parameters, and when-to-use. Every line contributes a distinct fact; there is no restatement of the title or the schema.

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 single-parameter read with an output schema and full annotation coverage, nothing is missing. The description goes beyond the minimum by documenting the not-found return shape and the auth/cost profile.

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, but the description adds a genuinely useful disambiguation: the balance is keyed to the sender address, not a job key — a mistake an agent could plausibly make given the refund-related siblings. It does not add address format detail, which the schema already supplies.

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?

States a specific verb and resource — 'Read one sender's account credit balance' — and pins the unit (USDC cents), which no sibling does. An agent can distinguish this from refund_job or get_job_status from the first line alone.

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?

Gives an explicit trigger: 'When to use: after refund_job, to see whether the refund landed on-chain or as credit,' which ties the tool to a concrete workflow step. It stops short of naming a when-not condition or pointing to an alternative for related balance questions, so it is clear context rather than full routing guidance.

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

All Hermes Micro-Agent tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?