Skip to main content
Glama

ToolRouter

by io.github.Humanleap

Credits Usage

credits_usage
Read-onlyIdempotent

Usage summary or history. Pass scope: "me" | "team" and detail: "tool" | "skill". Sorted by cost with _others rollup.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of top tools/skills to return. Remaining rolled into "_others". Default 10.
scopeNoWhose usage to show. "me" for personal, "team" for team-wide.
detailNoDetail level. "tool" groups by tool, "skill" adds per-skill breakdown.tool
offsetNoRecords to skip for pagination (history mode). Default 0.
periodNoTime period to summarize. 'all' covers the last 30 days (the maximum window).all

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

No contradiction with the annotations. The annotations already cover read-only, idempotent, non-destructive behavior, and the description adds useful behavioral context: results are sorted by cost, leftover items are rolled into _others, and output granularity changes with detail. This is meaningful context beyond the schema.

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 short sentences deliver the purpose, key parameters, and output ordering/rollup behavior without fluff or repetition. Every clause earns its place, and the opening sentence gives the domain immediately.

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 read-only reporting tool with a fully described schema, the description covers purpose, grouping, sorting, and rollup well enough. The main gap is that 'summary or history' is not fully disambiguated, especially since the schema's offset mentions 'history mode' without a clear mode parameter.

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% and each parameter already has a meaningful description, so the baseline is 3. The description repeats scope and detail hints but adds no new parameter semantics, which is acceptable given how thorough the schema already is.

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 identifies the resource as credit usage and states it returns a summary or history grouped by scope and detail, sorted by cost with an _others rollup. This goes beyond the name and title, though it lacks an explicit retrieval verb and does not call out the sibling credits_balance.

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

Usage Guidelines2/5

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

There is no explanation of when to choose this tool over credits_balance or top_up_credits, and no when-not-to-use guidance. 'Usage summary or history' states the domain but not a decision rule; the rest of the description mostly restates parameter usage.

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

All ToolRouter toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0
Disambiguation4/5

Tools are grouped by clear resource prefixes (account_, brain_, connector_, credential_, file_, job_, key_), and most actions have distinct purposes. A few boundaries overlap—brain_admin's lint action duplicates brain_lint, and account_preferences/setup/switch could momentarily confuse—but the descriptions resolve most ambiguity.

Naming Consistency3/5

The dominant pattern is resource_verb for actions (file_read, job_cancel, key_create) and resource_noun for state views (credits_balance, brain_settings, account_preferences), which is readable. However, exceptions like discover, use_tool, top_up_credits, and feedback_request_tool break the pattern, and the set is not consistently verb_noun.

Tool Count2/5

47 tools is well beyond the comfortable range; even though prefixes organize them, the agent faces a large selection surface with many narrowly scoped tools. A more consolidated set with action-based subcommands would be easier to navigate.

Completeness4/5

Core workflows are covered end-to-end: account setup and billing, connector and credential management, file CRUD, job polling, key lifecycle, brain knowledge management, and catalogue discovery/execution. Gaps are minor—outfit/persona/product/scene are list-only, connectors lack an update operation, and there is no explicit single-page brain get—but agents can generally work around them.

Resources