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

Name	Required	Description
`limit`	No	Max outcomes to return, 1-200. Above the ceiling is an invalid_request, never a silent truncation.
`since`	No	Return 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.
`offset`	No	Number 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_key`	No	API 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_id`	No	Filter to the outcomes reported against ONE hook (its id from list_hooks / a generate response). Omit for every hook.
`platform`	No	Filter to outcomes reported for one platform. Omit for all.

Output Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size actually applied.
`total`	No	Rows matching the filters ignoring paging.
`offset`	No	Offset this page started at.
`outcomes`	No	Each 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).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 10, 2026

changedInput schema / properties / platform / anyOf

Previous value: -[
-  {
-    "enum": [
-      "tiktok",
-      "instagram",
-      "youtube",
-      "x",
-      "other"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "tiktok",
+      "instagram",
+      "youtube",
+      "x",
+      "linkedin",
+      "other"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / platform / enum

Previous value: -[
-  "tiktok",
-  "instagram",
-  "youtube",
-  "x",
-  "other",
-  null
-]New value: +[
+  "tiktok",
+  "instagram",
+  "youtube",
+  "x",
+  "linkedin",
+  "other",
+  null
+]

Changed14 schema fields changedAug 2, 2026

addedInput schema / properties / api_key / description

Added value: +"API 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."

addedInput schema / properties / hook_id / description

Added value: +"Filter to the outcomes reported against ONE hook (its id from list_hooks / a generate response). Omit for every hook."

addedInput schema / properties / limit / description

Added value: +"Max outcomes to return, 1-200. Above the ceiling is an invalid_request, never a silent truncation."

addedInput schema / properties / limit / maximum
```
Added value: +200
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

addedInput schema / properties / offset / description

Added value: +"Number 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."

addedInput schema / properties / offset / maximum
```
Added value: +9223372036854776000
```
addedInput schema / properties / offset / minimum
```
Added value: +0
```

addedInput schema / properties / platform / description

Added value: +"Filter to outcomes reported for one platform. Omit for all."

addedInput schema / properties / platform / enum

Added value: +[
+  "tiktok",
+  "instagram",
+  "youtube",
+  "x",
+  "other",
+  null
+]

addedInput schema / properties / since / description

Added value: +"Return 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."

addedOutput schema / description

Added value: +"A page of the outcomes THIS account has reported, newest first. Free."

addedOutput schema / properties

Added value: +{
+  "limit": {
+    "description": "Page size actually applied.",
+    "type": [
+      "number",
+      "null"
+    ]
+  },
+  "offset": {
+    "description": "Offset this page started at.",
+    "type": [
+      "number",
+      "null"
+    ]
+  },
+  "outcomes": {
+    "description": "Each 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).",
+    "type": [
+      "array",
+      "null"
+    ]
+  },
+  "total": {
+    "description": "Rows matching the filters ignoring paging.",
+    "type": [
+      "number",
+      "null"
+    ]
+  }
+}

removedOutput schema / title

Removed value: -"list_outcomesDictOutput"

Changed1 schema field changedJul 20, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedJul 18, 2026

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 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.

Resources

Need Help?