Skip to main content
Glama

Politician Trades

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Ask Pipeworx Beta

ask_pipeworx_beta
Read-onlyIdempotent

Beta version of ask_pipeworx: identical universal router (same 7,167 tools, same arguments, same response shape) with candidate routing improvements enabled live whenever one is under test. No candidate is active right now (the last was retired on outcome evidence 2026-07-26), so this currently matches ask_pipeworx exactly. Use it exactly like ask_pipeworx when you want the newest routing; results are compared against the stable router to decide what merges. Falls back to nothing — this IS a full working router, just the experimental edge.

Input Schema

NameRequiredDescriptionDefault
qNoAlias for question.
askNoAlias for question.
textNoAlias for question.
inputNoAlias for question.
packsNoOPTIONAL. Restrict routing to these pack slugs (e.g. ["sec-form-d","sec-13f"]) — the router then picks only from tools in those packs. Omit for the default full-catalog routing. Slugs come from list_packs / search_packs / https://pipeworx.io/directory; unlisted or unknown slugs are ignored and named in _meta.pack_scope.ignored, and if none of them resolves the question is routed across the whole catalog with _meta.pack_scope.full_catalog:true (never an empty answer).
queryNoAlias for question.
promptNoAlias for question.
messageNoAlias for question.
questionYesYour question or request in natural language. Accepts query, q, prompt, text, input, ask, message as aliases.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / packs
      Added value: +{
+  "description": "OPTIONAL. Restrict routing to these pack slugs (e.g. [\"sec-form-d\",\"sec-13f\"]) — the router then picks only from tools in those packs. Omit for the default full-catalog routing. Slugs come from list_packs / search_packs / https://pipeworx.io/directory; unlisted or unknown slugs are ignored and named in _meta.pack_scope.ignored, and if none of them resolves the question is routed across the whole catalog with _meta.pack_scope.full_catalog:true (never an empty answer).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, open-world, non-destructive. Beyond them the description discloses the experimental lifecycle (candidates enabled live, compared against the stable router, last retired on outcome evidence), current operational state, and that it never falls back to a degraded mode. It doesn't describe latency, rate limits, or cost of the comparison path, so a 4 rather than 5.

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 core identity and usage rule are front-loaded in the first sentence. There is mild padding — the dated retirement aside and the emphatic "Falls back to nothing — this IS a full working router" — but each clause carries real information about routing behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still pins down the response contract by reference ("same response shape" as ask_pipeworx) and confirms it always returns a routed answer, including pack-scope fallback. Combined with rich annotations and fully covered parameters, nothing essential for a correct call 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 every parameter is documented in-schema, including the alias set and the packs scoping/fallback semantics with _meta.pack_scope fields. The description adds nothing parameter-specific beyond "same arguments as ask_pipeworx", so the baseline 3 applies.

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?

States precisely what it is: the experimental twin of ask_pipeworx, a universal router over 7,167 tools with identical arguments and response shape. An agent can distinguish it from ask_pipeworx and ask_pipeworx_grounded without opening any schema, and the scope (full working router, not a fallback shell) is unambiguous.

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?

"Use it exactly like ask_pipeworx when you want the newest routing" gives an explicit selection rule against the named sibling, and the note that no candidate is currently active tells the agent the choice is presently a coin flip. It stops short of an explicit when-not rule (e.g. prefer ask_pipeworx for stable production routing), leaving that inference to the agent.

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

All Politician Trades 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