Azquo

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "database": "<database>",
      "url": "<url>"
    },
    "name": "import_from_url"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	http or https URL the SERVER can reach. Public addresses only.
`business`	No	Optional. The business this call is for, by name, e.g. "azquo" - it then runs there whatever business the session is in. Worth giving on writes when you work in more than one business: a new MCP session starts in the login's own business. list_businesses shows the names.
`database`	Yes	Target database name
`filename`	No	Override 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.
`headings`	No	The 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.
`replaceFirstLine`	No	Drop 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.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / business

Added value: +{
+  "description": "Optional. The business this call is for, by name, e.g. \"azquo\" - it then runs there whatever business the session is in. Worth giving on writes when you work in more than one business: a new MCP session starts in the login's own business. list_businesses shows the names.",
+  "type": "string"
+}

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the server performs the download, that the file name drives parsing of import instructions, that an Azquo header row is almost always required, and warns that a completed import is not proof of a correct one. For a destructive, non-idempotent write this is valuable extra context.

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-loads the core capability and the routing rule before the caveats. It is on the longer side, with a parenthetical aside about shells and MCP sessions, but nearly every sentence carries actionable information rather than filler.

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?

Without an output schema, the description still characterizes the return (a validation summary with lines imported and values adjusted). Combined with the annotations covering safety and world-access, an agent has everything needed to invoke this correctly.

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 schema already carries the parameter detail; the description nonetheless adds conceptual meaning by stressing that the file name determines import instructions, which explains why filename and headings matter. It stops short of per-parameter guidance, keeping it just above the baseline.

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 immediately clarifies the mechanism (the server downloads it, not your context). It draws a clear line against the sibling import_file.

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 routing rules: 'Use this instead of import_file for anything beyond a few KB,' plus a named fallback path (write to a file and POST /api/importdata, or fall back to import_file) for data that exists only in context. This is a genuine when/when-not decision tree.

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

All Azquo tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?