Skip to main content
Glama

list_runs

Read-only

Every call this account was charged for, newest first. Free read.

    Recover a lost response in two calls, never re-charged: list_runs(request_id=...)
    for the receipt, then follow `hooks_url` for the hooks it produced. Page with
    `cursor` (one pass total) or `offset`; stop only when `exhausted` is true, never
    on a short page. Same composed read GET /v1/runs makes, so the two can never
    disagree. Errors: unauthorized, invalid_request, rate_limited.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax runs to return, 1-200. Above the ceiling is an invalid_request, never a silent truncation.
cursorNoLedger position to resume scanning from (see `next_cursor` on a prior page); not a run count, not an opaque token. Leave at 0 and follow `next_cursor` to walk your whole history in bounded reads.
offsetNoNumber of rows to skip for paging, 0-9223372036854775807. Page with offset += the limit you actually requested; `total` in the response is the unpaged count. The ceiling is SQLite's largest bindable integer: above it the read could only ever have been a 500, so it is a typed invalid_request instead.
api_keyNoAPI key for this call. Omit to fall back to the Authorization: Bearer / X-API-Key request header (streamable-HTTP only), then the VHGENGINE_API_KEY env var (the stdio default). No key resolvable -> unauthorized.
operationNoReturn only runs of this operation: generate_hooks, generate_hooks_batch, remix_hook, score_hook, score_hooks_batch, add_credits. An unknown value returns an empty page, never an error.
request_idNoReturn only the run with this X-Request-Id (the response header on every call, including errors). This is the lookup for a lost response whose id you still have.
charged_onlyNotrue (default): only calls that COST credits. false: also include grants and zero-cost calls.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
runsNoThis page: {request_id, operation, created_at, credits_delta, credits_charged, balance_after, key_prefix, topic, topics, platform, mode, hooks_returned, tags, hooks_url, usage_url, metadata}. hooks_url is set only for a hook-producing operation and follows the SAME id.
limitNoPage size actually applied.
totalNoRows matching the filters WITHIN the scanned window (see `scanned`), not over all history unless `exhausted` is also true.
offsetNoOffset this page started at.
scannedNoLedger rows examined to build this page.
has_moreNotrue when this page is not the whole remainder. Follow `next_cursor` (preferred) or `next_offset`; never infer 'that was all' from a short page.
exhaustedNotrue only when the read reached the END of your ledger. `total` is the COMPLETE count only when this is true.
scan_limitNoLedger rows one page may examine, however many reads that takes.
next_cursorNoPass as `cursor` for the next page (leave offset at 0); null when nothing follows. PREFER this over next_offset for a full walk: it resumes exactly where this page stopped instead of re-scanning from the newest row.
next_offsetNoPass as `offset` for the next page; null when nothing follows.
credits_remainingNoYour balance right now.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses free/no-charge behavior ('Free read', 'never re-charged'), ordering ('newest first'), pagination semantics ('stop only when exhausted is true, never on a short page'), and consistency with the composed GET /v1/runs. It even lists error types. This is rich behavioral context above structured annotations.

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?

The description is compact yet information-dense: opening with the core purpose, then a practical recovery flow, paging rule, consistency guarantee, and error list. Every sentence serves a distinct role with no filler or repetition.

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?

Given the 7 parameters are fully explained in the schema and an output schema exists, the description covers all necessary behavioral context: purpose, safety (free read), paging, error types, and a recovery workflow. It leaves no critical ambiguity for invocation or interpretation.

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?

The input schema already contains detailed descriptions for all 7 parameters, so the baseline is 3. The description adds a bit by tying request_id to the lost-response recovery flow and cursor/offset to paging, but it does not add significant meaning beyond what the schema provides.

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?

The description opens with 'Every call this account was charged for, newest first' — a specific verb+resource+scope that clearly distinguishes this from list_hooks or list_billing_events. It also states 'Free read' and the primary use case (recovering lost responses), making the tool's purpose unambiguous.

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?

Provides a concrete use case: 'Recover a lost response in two calls... list_runs(request_id=...) for the receipt, then follow hooks_url'. Also gives paging instructions with cursor/offset and the exhausting condition. However, it does not explicitly contrast with sibling tools like list_hooks or list_billing_events, nor state when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct resource and action, e.g., signup vs. delete_account, create_key vs. revoke_key, generate_hooks vs. score_hook. Even similar tools like generate_hooks and generate_hooks_batch are clearly differentiated by single vs. batch operation.

Naming Consistency5/5

All 32 tools use a consistent verb_noun snake_case pattern (e.g., add_credits, create_checkout, revoke_key, list_outcomes) with no mixing of camelCase or other conventions.

Tool Count4/5

32 tools is slightly above the typical 15-tool range, but the domain is broad (account, keys, webhooks, generation, scoring, jobs, outcomes), and each tool has a specific purpose. No tools seem redundant.

Completeness4/5

The tool surface covers most lifecycle operations: CRUD for accounts/keys/webhooks, generation/scoring with batch and async variants, outcomes reporting, and auxiliary tools. Missing explicit delete for hooks (expire automatically) and some update operations, but no critical gaps.

Resources