Skip to main content
Glama

Dataset Fetch Hf

dataset_fetch_hf

Fetch a Hugging Face dataset at a pinned commit, map rows to a Tuner-compatible schema, and stage the dataset ID for training.

Instructions

Fetch a pinned Hugging Face split, map rows to a Tuner schema, stage a dataset ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / properties / request / properties / chosen_field
      Added value: +{
      +  "default": "chosen",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / request / properties / invalid_record_policy
      Added value: +{
      +  "default": "error",
      +  "description": "Fail on invalid rows, or skip them and report removal counts",
      +  "enum": [
      +    "error",
      +    "skip"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / request / properties / preference_prompt_field
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Row field for the shared preference prompt, e.g. 'instruction'"
      +}
    • addedInput schema / properties / request / properties / rejected_field
      Added value: +{
      +  "default": "rejected",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / request / properties / tool_calls_field
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Row field containing target function calls, including raw xLAM answers"
      +}
    • addedInput schema / properties / request / properties / tools_field
      Added value: +{
      +  "anyOf": [
      +    {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Row field containing OpenAI or raw function declarations, including JSON text"
      +}
  2. First observedv0.1.0

TDQS

C2.7/5.0
Behavior2/5

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

The only annotation is readOnlyHint:false, so the description must explain side effects. It says the tool 'stages a dataset ID,' which hints at mutation/persistence, but it does not clarify what staging means, whether it writes to the workspace, or whether it is idempotent. No auth, network, or rate-limit considerations are disclosed.

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 description is one concise sentence with no filler, and the main action is front-loaded. It earns its place, though it is arguably too terse for a tool with a complex nested request object and many configuration options.

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

Completeness2/5

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

Given the tool's complexity, minimal annotations, and 0% schema description coverage at the top level, the description is incomplete. It does not address the intended workflow context, important configuration policies such as invalid_record_policy and deduplicate, or what consuming the staged dataset ID implies. The output schema helps, but the operational context remains underspecified.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, but it only hints at 'pinned' and 'map rows' without explaining the many field-mapping parameters like user_field, assistant_field, tools_field, output_type, or invalid_record_policy. The high-level pipeline is stated, but parameter-level meaning is largely left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and resource ('pinned Hugging Face split'), then adds transformation and output context ('map rows to a Tuner schema', 'stage a dataset ID'). It is clearly distinguishable from siblings like dataset_search_hf and dataset_probe_hf, though it does not explicitly contrast itself with dataset_prepare.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool instead of the many sibling dataset tools, especially dataset_search_hf, dataset_probe_hf, or dataset_prepare. There are no exclusions, prerequisites, or alternative selection criteria, so the agent must infer usage from the name and brief description.

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