datasetShow full metadata for one Greece Open Data dataset by id or name (from search_datasets), including all resources and their resource_ids.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Dataset id or name (from search_datasets). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context by specifying that it returns 'full metadata including all resources and their resource_ids', going beyond annotations. No contradictions.
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?
A single sentence conveys the tool's purpose, scope, and relationship to a sibling tool. No extraneous words. Perfectly concise and structured for an agent.
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 simple tool (1 parameter, no output schema), the description is complete enough to guide an agent. It covers what the tool does, what it returns, and where to get the identifier. Minor omissions like error handling do not detract significantly.
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?
Schema coverage is 100% with a single parameter 'id' described as 'Dataset id or name (from search_datasets)'. The description essentially restates this, adding no new semantic meaning. Baseline 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 action 'Show full metadata' and the specific resource 'one Greece Open Data dataset by id or name'. It specifies the scope and includes details about what is returned (all resources and resource_ids), distinguishing it from sibling tools like search_datasets.
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 explicitly mentions that the id/name comes from search_datasets, providing context for when to use this tool. While it doesn't explicitly state when not to use it or list alternatives, the guidance is clear for a typical use case.
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.
Most tools have clearly distinct purposes, but there is some overlap among the meta-querying tools like ask_pipeworx, ask_pipeworx_grounded, deep_research, and discover_tools, which could cause confusion for an agent deciding which to use.
Tool names use a mix of verb_noun and noun patterns, with snake_case throughout but no single consistent structure (e.g., ask_pipeworx vs. bet_research vs. dataset). The naming is readable but not uniform.
At 33 tools, the count is on the higher side but justifiable given the broad scope of the Pipeworx platform, covering data querying, entity analysis, prediction markets, memory, subscriptions, and feedback.
The toolset covers a wide range of data sources and operations, including querying, entity profiling, comparisons, prediction market analysis, and monitoring. Minor gaps exist (e.g., no direct SEC filing viewer), but the meta-tools handle these adequately.