Skip to main content
Glama

ABS Data (observed)

Fetch and analyse data by writing code

execute
Read-onlyIdempotent

Run JavaScript in an isolated sandbox whose only capability is abs, a client with the same four verbs as this server (searchTables, describeTable, searchOptions, getData) and the same guarantees: every selection is verified against ABS before fetching. Use it for multi-series or multi-table analysis — fetch several series, compute growth rates, rank capitals, join tables — and return only the computed result, so large payloads never reach the conversation. No network beyond abs. Budgets: 10s CPU, 50 calls, 25s wall clock, 200KB result. Your code runs inside an async function; use await; console.log is captured.

// The abs object available in execute(): interface Abs { searchTables(input: { query?: string; geography?: string; frequency?: "A"|"S"|"Q"|"M"|"W"|"D"; limit?: number }): Promise<{ results: TableSummary[]; total: number }>; describeTable(table: string): Promise<{ table: TableSummary; dimensions: { id: string; position: number; optionCount: number; options?: { code: string; label: string|null }[] }[]; keyFormat: string }>; searchOptions(input: { table: string; dimension: string; query: string; limit?: number }): Promise<{ options: { code: string; label: string|null; parent?: string|null }[]; total: number }>; getData(input: { table: string; select?: Record<string, string|string[]>; startPeriod?: string; endPeriod?: string; lastN?: number; firstN?: number; maxRows?: number }): Promise<{ key: string; rows: { series: string; period: string; value: number|null; unit?: string|null }[]; rowsReturned: number; truncated: boolean; seriesMatched: number; fullDataUrl: string }>; } interface TableSummary { id: string; name: string|null; seriesCount: number; frequencies: string[]; coverage: { from: string|null; to: string|null }; dimensions: string[]; family: string|null; geography: string|null; matchedOptions?: { dimension: string; code: string; label: string|null }[] } // getData throws an Error whose message is JSON: { reason, dimension, message, validOptions?, alternatives? } — catch it, read validOptions, correct and retry.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "execute"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYesJavaScript. `abs` is in scope. Must return a value.

Output Schema

NameRequiredDescriptionDefault
okYes
logsYes
errorNo
resultNo
truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Far beyond the annotations, it discloses hard limits (10s CPU, 50 calls, 25s wall clock, 200KB result), the isolation guarantee (no network beyond `abs`), the execution wrapper (async function, `await` required, console.log captured), and the failure contract (getData throws a JSON-formatted Error with validOptions/alternatives to catch and retry). These are exactly the constraints that determine whether an agent's generated code will succeed.

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?

Purpose, when-to-use, and constraints are front-loaded before the interface block, and every section is functional. It is long, and the prose sentence 'same four verbs as this server' partially duplicates the interface listing that follows, but the length is largely justified by the sandbox's complexity.

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 code-execution tool this is complete: capability boundary, budgets, execution semantics, error handling, and a full API contract are all present, and an output schema exists so return values need no further explanation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100% for the single `code` parameter, but the description adds substantial meaning the schema cannot: the in-scope `abs` API surface with full input/output shapes, the throw-and-retry error protocol, and the runtime constraints. That is genuine semantic enrichment rather than restatement.

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 first sentence names a specific verb and mechanism: run JavaScript in an isolated sandbox whose only capability is an `abs` client, and it enumerates exactly which four verbs that client exposes. Combined with the multi-series/multi-table framing, an agent can immediately tell this is the scripting/aggregation escape hatch rather than a one-shot query tool.

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?

It gives a clear selecting condition with concrete examples (fetch several series, compute growth rates, rank capitals, join tables) and states the benefit of choosing it: large payloads never reach the conversation. What it lacks is an explicit negative: it never says 'for a single series use get_data instead', leaving the boundary with the sibling tools to inference.

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.