Skip to main content
Glama
Sign In
humanpen-mcp

humanpen-mcp

Official
by humanpen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check the credit balance

get_credit_balance
Read-only

Check remaining account credits before processing large documents to estimate humanization, citation-fix, condensing, or translation costs.

Instructions

How many credits the account has. Per 1,000 words processed: humanize 100 credits, citation fixes 5, condensing 20, translation 10, with a 10-credit minimum per job. Worth checking before a large document.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_credit_balance"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

readOnlyHint=true already covers the safety profile, so the description's value-add is the cost model: per-1,000-word rates for humanize/citation/condense/translate plus a 10-credit per-job minimum. That is genuinely useful planning context not present in any structured field. It stops short of describing the response shape or whether the balance is account- or workspace-scoped.

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?

Three tight sentences: identity first, pricing second, usage recommendation last. Every clause carries information an agent would actually use, with no restatement of the title or name.

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?

For a zero-parameter read with no output schema, the description covers what it does, what things cost, and when to call it. The only gap is what the returned balance actually looks like (remaining vs. total, units), which an agent must infer.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The added per-unit cost detail is helpful orientation rather than parameter semantics.

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 opening sentence states exactly what is returned — the account's credit count — which is unambiguous against siblings like check_job or read_detection_report. The verb is implicit (phrased as a question) rather than an explicit 'retrieve', which keeps it just short of a 5.

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?

'Worth checking before a large document' gives a concrete trigger condition, and the cost table lets the agent decide whether a job is affordable. No other balance-related sibling exists, so no exclusions are needed, but it never states what to do if the balance is insufficient.

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