query_tablePull data from a table. body is a PxWeb query object. Use the bare table path with no ".px" suffix.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | {query: [{code, selection: {filter, values}}], response: {format: "json-stat2"}} | |
| path | Yes | e.g. "OSP_PUB/POP/IR/IRS/IRS010" |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "body": {
+ "query": [
+ {
+ "code": "Gads",
+ "selection": {
+ "filter": "item",
+ "values": [
+ "1"
+ ]
+ }
+ }
+ ],
+ "response": {
+ "format": "json-stat2"
+ }
+ },
+ "path": "OSP_PUB/POP/IR/IRS/IRS010"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a specific behavioral constraint: the path must be provided without a '.px' suffix, which is not evident from the schema. It also identifies the body format as a PxWeb query object. These details go beyond the annotations and help avoid common usage errors.
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 primary purpose, and includes essential usage details without any filler. Every sentence adds value, making it highly concise and well-structured.
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?
Given the tool's moderate complexity, the provided annotations, and rich schema descriptions (including an example of the body structure), the description is largely complete. It covers the key operational detail (path format) and the body type, though it does not describe the response format, which is acceptable since there is no output schema and annotations indicate a safe read-only operation.
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 descriptions already cover 100% of parameters, providing examples for both path and body, so the baseline is 3. The description adds meaning by clarifying that 'body' is a PxWeb query object and by specifying the path format constraint (no '.px' suffix), which is not present in the schema. This adds practical value for correct invocation.
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 starts with 'Pull data from a table,' which is a specific verb+resource and clearly indicates the tool's function. It does not explicitly differentiate from sibling tools like table_meta, but the purpose is unambiguous. The mention of 'PxWeb query object' adds useful context about the query mechanism.
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?
There is no explicit guidance on when to use this tool versus alternatives, such as table_meta for metadata. However, it provides usage instructions for the path parameter ('Use the bare table path with no ".px" suffix') and indicates the body must be a PxWeb query object, which implies it is for data retrieval. This is implied usage context rather than explicit selection guidance.
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.
Several tools form overlapping families (ask_pipeworx/ask_pipeworx_beta/ask_pipeworx_grounded/deep_research, plus the six polymarket_* tools), and ask_pipeworx_beta is currently an exact behavioral duplicate. The long descriptions usually disambiguate them, but an agent could still struggle to quickly choose between similar research and edge-detection tools.
Names are uniformly snake_case and prefix families like pipeworx_* and polymarket_* help, but there is no consistent verb_noun pattern: subjects, table_meta, recent_alerts, and entity_profile are noun phrases while remember, generate_llms_txt, and compare_entities are action-first. The mixed conventions are readable but less predictable than a uniform pattern.
34 tools is well into the 'too many' range for a single tool set, even if each is individually documented. Several could plausibly be consolidated, such as ask_pipeworx_beta, the polymarket edge tools, and the AI-visibility pair.
For its broad stated purpose, the set covers the full lifecycle: lookup/research, entity profiles, comparisons, claim validation, prediction-market edge analysis, memory, subscriptions, and discovery. Minor gaps exist, such as no direct fetch-by-URI tool or subscription update path, but most workflows have a clear route.