Skip to main content
Glama

VHGENGINE

by app.railway.up.engine-production-3bdc

export_usage

Read-only

Export ledger, hook, instance, lineage, outcome, profile, and retained-job data. Free; run BEFORE delete_account. Same JSON body as GET /v1/usage/export; CSV has events. UNBOUNDED: prefer paged reads on big accounts. Email is masked without admin scope. Returns account/email/count, ledger, hooks, instances, lineage, outcomes, jobs, profiles, source_evidence, and corrupt markers. Jobs and profiles retain their bounded receipts. Source evidence includes metrics, retractions, and separate research/extraction results. Filters narrow ledger events only; all retained data categories stay complete. Errors: unauthorized, forbidden (key lacks read scope), rate_limited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoFilter to rows carrying EXACTLY this fleet tag (exact match, not a substring). Omit for every tag.
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.
key_prefixNoNarrow the LEDGER to charges made with ONE api key, identified by the 12-char prefix from list_keys. `hooks`, `hook_instances`, `hook_lineage`, `outcomes`, `jobs`, `creator_profiles`, and `source_evidence` are always the full set and are NOT narrowed by this. Omit for every key.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobsNoEvery currently retained async job, including exact commission snapshots, including schema-v2 capture-only intent when supplied, bounded request metadata, results, errors, and corruption markers. Rolling v1 execution views and worker charge identities are not presented as the accepted snapshot.
countNoNumber of usage-ledger rows in events after event filters.
emailNoContact email in full for an admin-scoped key and masked for a read-only key.
hooksNoEvery currently retained hook, not narrowed by event filters.
eventsNoUsage-ledger rows, oldest first, narrowed by event filters.
outcomesNoEvery retained outcome, not narrowed by event filters.
account_idNoThe exporting account id.
hook_lineageNoNon-prose per-hook minimum occurrence counts retained until account deletion so expired or rolling-version rows cannot become falsely exact.
corrupt_fieldsNoBounded markers for retained event, hook, or outcome JSON fields that could not be decoded safely. Raw malformed values and row identifiers are not echoed.
hook_instancesNoEvery immutable served-hook occurrence currently retained, including non-prose profile/version lineage when one was used. Unreferenced instances follow the hook TTL; every retained instance for a hook with any outcome remains so historical ambiguity cannot become false exactness.
source_evidenceNoImmutable source observations, bounded exact extracts, and candidate-to-served lineage. Corrupt parent chains are suppressed without echoing raw values.
creator_profilesNoEvery retained creator-profile version and consent event, plus bounded retraction markers for profiles whose direct declarations were erased.

TDQS

A4.6/5.0
Behavior5/5

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

Discloses many non-obvious behaviors—unbounded output, email masking without admin scope, filters only narrow ledger events while other categories remain complete, and error conditions. Annotations only mark readOnlyHint, so this description carries the burden and exceeds it.

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 description is long but information-dense; every sentence delivers a distinct caveat or clarification. It opens with the primary action and front-loads key facts (free, before delete_account) before detailed return categories. Slight redundancy between the first sentence's data list and later 'Returns...' list, but not enough to be wasteful.

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 high-complexity export tool with optional filters and a rich result set, the description covers behavior, scoping, auth, errors, and return composition. Since an output schema is present, return-value details are bonus; the operational caveats are the critical missing context and are included.

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 already describes tag/key_prefix fully (100% coverage). Description adds critical cross-parameter semantics: 'Filters narrow ledger events only; all retained data categories stay complete,' which clarifies that key_prefix/tag do not limit hooks, jobs, profiles, etc. It also notes error cases tied to auth.

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?

Description opens with specific verb 'Export' and enumerates exact data categories (ledger, hooks, instances, lineage, outcomes, profiles, retained jobs). It distinguishes this from lighter paged reads by warning 'UNBOUNDED: prefer paged reads on big accounts' and by tying it to the pre-delete_account snapshot use case.

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?

States clear usage conditions: free, run before delete_account, not suitable for large accounts ('prefer paged reads'). It does not name specific sibling alternatives but gives enough contextual guidance to choose export vs paged reads.

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

All VHGENGINE 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

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