Skip to main content
Glama

Import from URL

import_from_url
Destructive

Bulk-load a delimited-text or spreadsheet file into a database by URL. THE SERVER DOWNLOADS IT, so the file never passes through your context - this is the right tool for anything large.

Same import path as POST /api/importdata: the file needs a self-describing Azquo header row (see Azquo_Skills > Import), and the FILE NAME matters because import instructions are read from it. Returns the same validation summary including lines imported and values adjusted - check that against what you expected, a completed import is not proof of a correct one.

Use this instead of import_file for anything beyond a few KB. If the data exists only in your context and nowhere fetchable, either write it to a file and POST /api/importdata with a shell, or fall back to import_file and accept the cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYeshttp or https URL the SERVER can reach. Public addresses only.
databaseYesTarget database name
filenameNoOverride the file name used for the import. Defaults to the last path segment of the URL. Set this when the URL does not end in a sensible name, because import instructions are parsed out of the file name.
headingsNoThe self-describing Azquo header line to PREPEND to the downloaded file, e.g. `Ford;child of Manufacturer`\t`.Description`\t`Units;peers {Manufacturer, Month}`. Almost always needed: a file fetched from somewhere else will carry its own headings or none, not Azquo ones. Use the same delimiter as the file. Omit only if the file already has an Azquo header row.
replaceFirstLineNoDrop the file's own first line before prepending 'headings'. Set true when the source has its own header row that the Azquo headings replace; false (default) when the file is bare data.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag it as a non-readonly, destructive, open-world write, and the description adds material context beyond that: the server-side download (data never touches context), the header-row prerequisite, the filename-driven instruction parsing, and the caveat that a completed import is not proof of a correct one. This is unusually rich disclosure for a mutation tool.

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?

Front-loaded with the key value proposition and well-organized, but slightly long and repeats the 'same import path as POST /api/importdata' idea alongside the fallback mention. Nearly every sentence earns its place, with minor slack.

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

Completeness5/5

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

For a 5-param mutation tool with no output schema, the description covers the download mechanism, prerequisites (Azquo header, filename), and the validation-summary return, so nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description ties parameters into workflow rationale: it stresses why 'filename' matters (instructions are parsed from it) and frames 'headings' as almost always needed via the header-row requirement. It reinforces and connects parameters beyond the per-field schema text, though it adds no new syntax.

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 a specific verb and resource ('Bulk-load a delimited-text or spreadsheet file into a database by URL') and names the sibling it replaces ('Use this instead of import_file'). An agent can distinguish it from import_file and import_from_query without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('right tool for anything large', 'beyond a few KB'), the named alternative (import_file), and a fallback path (write to a file and POST /api/importdata) when the data isn't fetchable. The routing decision is fully determined.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources