Skip to main content
Glama

AINumbers Fintech Intelligence Suite

by co.ainumbers
OverviewDiscussionsAdmin

Kernel VM

run_kernel_vm
Read-onlyIdempotent

Run a ChainGraph decision kernel's compute(policy_parameters) inside a sandboxed, deterministic, in-browser QuickJS-ng WebAssembly VM (ocg-deterministic-compute@2) and return its output_payload. Demo kernel set only -- for the full catalog, use the worker's compute kernels directly. Renders the interactive AINumbers tool as a widget; inputs are applied via the AIN Bridge and the tool runs client-side (zero PII, zero network). Output schema: call describe_tool("run_kernel_vm").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsNoMap of tool input element IDs to values (see manifest input_schema). Applied via AIN Bridge prefill.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "elapsed_ms": {
-      "type": "number"
-    },
-    "output_payload": {
-      "type": "object"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "elapsed_ms": {
+      "type": "number"
+    },
+    "output_payload": {
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations declaring readOnly, idempotent, and non-destructive, the description adds meaningful behavioral context: sandboxed WebAssembly execution, determinism, in-browser operation, zero network, zero PII, and a demo-only kernel limitation. It also proactively points to describe_tool for the output schema, which is valuable given no output schema is attached.

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 three information-dense sentences with no filler. The core action is front-loaded, followed by the key limitation and then the widget/bridge behavior; every clause earns its place.

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 one optional open-map parameter, rich annotations, and no output schema, the description covers the essential call context: what runs, where it runs, constraints, the demo limitation, the alternative for full kernels, and how to obtain the output schema. Nothing critical for an agent to invoke or avoid misusing this tool is missing.

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 the single 'inputs' parameter is already documented as a map of tool input element IDs applied via AIN Bridge prefill. The tool description mostly restates that same AIN Bridge mechanism, adding no substantial meaning beyond what the schema provides, so baseline 3 is appropriate.

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 and resource: 'Run a ChainGraph decision kernel's compute(policy_parameters) inside a sandboxed, deterministic, in-browser QuickJS-ng WebAssembly VM' and states the return value, output_payload. It also differentiates itself by noting it is demo-kernel-only and renders the AINumbers widget client-side, distinguishing it from worker-side compute and sibling run_chain-type tools.

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 explicitly scopes usage with 'Demo kernel set only -- for the full catalog, use the worker's compute kernels directly,' which acts as a when-not-to-use instruction and names an alternative. It also conveys relevant context (client-side, zero PII, zero network) for choosing this tool, though it does not fully enumerate conditions for selecting it over similar run_* siblings.

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

All AINumbers Fintech Intelligence Suite toolsInspect
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