Paper Nexus

Get usage

get_usage

Read-onlyIdempotent

How many calls this account has left. recommend_papers and list_citing_papers each spend one of the allowance; a call that fails or finds nothing is not counted. The other tools share a larger daily limit of lookups, and every tool a limit of calls a minute. Each window starts at its first call, not at midnight, so the two end at different times. Call it before a task that needs many calls, to plan within them.

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_usage"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`tier`	Yes
`used`	Yes
`limit`	Yes
`lookups`	Yes	The daily limit shared by the tools outside the allowance
`remaining`	Yes
`resets_at`	Yes	When the current window ends (UTC); null when none is open, and the next counted call opens one
`checked_at`	Yes	The time of this report (UTC)
`usage_period`	Yes
`counted_tools`	Yes
`calls_per_minute`	Yes	Calls of any tool an account may make a minute

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: failed or empty calls are not charged, a separate shared daily lookup limit exists, and windows are rolling from first call rather than midnight-resetting. The wording of the limits ("every tool a limit of calls a minute", "the two end at different times") is garbled enough to leave the exact quota structure partly unclear.

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 answer to the agent's question is front-loaded in sentence one, followed by quota mechanics and then the usage recommendation. It is somewhat longer than needed and contains a verbless clause ("every tool a limit of calls a minute") that costs a re-read, but no sentence is redundant.

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?

An output schema exists, so return values need no explanation, and the zero-param schema needs none either. What remains for the description to carry is quota accounting and window semantics, which it covers, though the exact numeric limits and their interaction stay fuzzy.

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 and there is nothing the description needs to compensate for. No parameter meaning is missing.

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 first sentence, "How many calls this account has left," names the exact resource returned and is unambiguous against siblings like search_papers or list_library. It is a noun phrase rather than a verb+resource, but the intent is clear within one sentence.

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?

"Call it before a task that needs many calls, to plan within them" gives explicit when-to-use guidance tied to a concrete situation. It also tells the agent which two tools consume the counted allowance, though it never states when *not* to call it (e.g., cheap single lookups).

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

All Paper Nexus 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.