subjectsNavigate the database/subject tree. Root (empty path) lists databases ({dbid}). Drill into a database id to get folders (type "l") and tables (type "t", ".px" suffix).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Sub-path under /en/ (default empty = root database list). First segment is a database id, e.g. "20 Populatia si procesele demografice/POP010/POPro". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral details about the tree structure (dbid, type 'l' folders, type 't' tables with '.px' suffix) that are not present in the annotations, enriching the agent's understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word contributes meaning. It is concise without sacrificing key details about navigation and file type identifications.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only navigation tool with strong annotations and a detailed schema, the description covers all essential operational aspects. It explains what to expect at each path level, making it sufficient for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'path' parameter is thorough, covering default behavior and format with an example, giving 100% coverage. The tool description reinforces the same semantics but does not add new information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: navigating the database/subject tree. It specifies that the root lists databases, and drilling into a database id yields folders and tables, which distinguishes it from sibling tools like query_table or table_meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: start at the root to list databases, then navigate into a database id to explore folders and tables. It does not explicitly mention when not to use it or alternative tools, but the navigational intent is evident and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Multiple tools have overlapping purposes: ask_pipeworx, ask_pipeworx_beta, and ask_pipeworx_grounded are near-identical in scope, and the prediction-market tools (bet_research, polymarket_edges, polymarket_arbitrage, polymarket_fill_risk) share similar functions. While some tools are distinct, the boundaries between many are unclear.
Names mix product-like identifiers (ask_pipeworx, deep_research), descriptive nouns (entity_profile, subjects), and inconsistent verb forms (query_table, resolve_entity, scan_competitor_ai_presence). No consistent verb_noun pattern is maintained across the set.
With 34 tools, the server is overpopulated relative to its apparent purpose. The name 'Statbank Md' suggests a narrow statistical service, but only 3 tools are Statbank-specific; the rest form a sprawling general-purpose data toolkit. The count is far beyond what the core function needs.
For the Statbank subset, the surface is complete (browse subjects, get metadata, query data). As a general data research suite, it covers many domains (SEC, FDA, economics, prediction markets) but lacks execution/trading tools for prediction markets and has no bulk data export or analytics beyond excerpts. Notable gaps exist but many core workflows are covered.