Skip to main content
Glama

VHGENGINE

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

list_outcomes

Read-only

List the posted outcomes THIS account has reported, newest first. Free (WP-LIFE).

    Retrieve submitted telemetry in bulk. Args: platform
    (tiktok|instagram|youtube|x|linkedin|other), since (ISO timestamp), hook_id,
    limit (1-200, default 50), offset (>=0), api_key. Rows include the feature snapshot.
    Returns {outcomes:[...], limit, offset, total}. Errors: unauthorized,
    invalid_request, rate_limited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax outcomes to return, 1-200. Above the ceiling is an invalid_request, never a silent truncation.
sinceNoReturn only rows created at or after this UTC timestamp. Compared LEXICALLY against stored 'YYYY-MM-DDTHH:MM:SSZ' values, so pass that exact format (a date-only string or a unix epoch silently selects the wrong window). Omit for no lower bound.
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.
hook_idNoFilter to the outcomes reported against ONE hook (its id from list_hooks / a generate response). Omit for every hook.
platformNoFilter to outcomes reported for one platform. Omit for all.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size actually applied.
totalNoRows matching the filters ignoring paging.
offsetNoOffset this page started at.
outcomesNoEach row is the reported outcome plus a snapshot of the hook at report time (hook_text, topic, mode, archetype, claim_type, score_total, score_source, prompt_version, tags).

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description adds useful behavioral details: results are ordered newest first, scoped to the current account, include the feature snapshot, and return {outcomes, limit, offset, total}. It also discloses error conditions (unauthorized, invalid_request, rate_limited), which is valuable context for invocation.

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 front-loaded with a strong one-sentence purpose, followed by a structured block of args, return, and errors. It is slightly redundant ('List' versus 'Retrieve submitted telemetry') and includes the unclear 'Free (WP-LIFE)', so it isn't perfect, but it remains compact and organized for a tool with six parameters.

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 tool's complexity (six optional parameters, pagination, output schema), the description covers the essential operational context: account scope, ordering, bulk retrieval, return shape, authentication via api_key/headers/env var, and error cases. The presence of an output schema means detailed return field documentation is not required in the description.

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 covers all parameters with rich descriptions, so the baseline is 3. The description lists the parameters and some constraints (platform enum, since ISO timestamp, limit 1-200, offset >=0), but this largely repeats schema information without adding significant new meaning.

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 a specific verb+resource+scope: 'List the posted outcomes THIS account has reported, newest first.' This clearly identifies the operation and its account-specific scope, and it distinguishes list_outcomes from sibling list tools like list_hooks or list_runs.

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?

The description gives clear context for use ('Retrieve submitted telemetry in bulk') and notes the tool is free. It does not explicitly name alternatives or exclusion criteria, but the purpose is sufficiently clear that an agent can infer when to use it versus other listing tools.

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