Skip to main content
Glama

Azquo

by ai.azquo
OverviewDiscussionsAdmin

import_from_query

Run SQL against a configured external database connection and import the result into an Azquo database. THE SERVER CONNECTS AND FETCHES - the rows never pass through your context, and the credentials are held server-side, so you never see or supply them.

This is the right tool for a business's own internal database. Use list_external_connections to see what is configured; if the source you need is not there, ask an administrator to add it in azquo-admin rather than looking for another route.

TWO WAYS TO SAY WHAT THE COLUMNS MEAN, and you need one of them: Supply 'headings' - a tab-separated Azquo header line matching the SELECT order. The source's own column names are discarded. Right for a one-off load. Omit 'headings' - the source's column names are kept as the header row, and the target database's IMPORT TEMPLATE interprets them. Right for a recurring feed, because the mapping then lives server-side instead of being restated on every run. Check list_import_templates for the database first.

Imported by the same path as POST /api/importdata, so the usual header grammar applies (see Azquo_Skills > Import). Check 'values adjusted' in the result against what you expected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sqlYesSQL to run against that connection. Read-only queries only - this is an import.
databaseYesTarget Azquo database name
filenameNoFile name to import under. Import instructions are parsed from it, so it matters. Defaults to <connection>_query.tsv
headingsNoOPTIONAL. Tab-separated Azquo header line, one heading per selected column in the order the SQL returns them. SUPPLY IT for a one-off load: the source's own column names are then discarded and yours are used. OMIT IT for a recurring feed that the target database has an IMPORT TEMPLATE for: the source's column names are kept as the header row and the template interprets them. One or the other is needed - with neither, the import has nothing to tell it what the columns mean.
connectionYesName of the external database connection, from list_external_connections

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses key behaviors: the server connects and fetches, credentials are held server-side and never exposed, rows never pass through context, and only read-only queries are allowed. It also advises checking 'values adjusted' in the result. It omits error handling, rate limits, and sync/async details, so it is not a perfect 5.

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 purpose and safety, then structured with clear guidance. However, the multi-paragraph heading explanation duplicates the schema's parameter description, which reduces conciseness. The framing as 'two ways to say what the columns mean' does earn its place as a decision aid.

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?

Given no annotations and no output schema, the description is complete enough: it covers the safety profile, prerequisites, import path, and a result validation step. It fully equips an agent to select and invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents all five parameters, including a detailed description of the headings semantics that covers one-off versus recurring use. The description's explanation of headings largely restates that schema text, so it adds no new parameter meaning beyond 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 (import) and resource (SQL result into an Azquo database) and distinguishes itself from other import routes by specifying a configured external database connection. An agent can immediately tell this is for querying external DBs, not for files or URLs.

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?

Explicitly states the right use case (a business's own internal database) and what to do if the connection is missing (ask an administrator rather than looking for another route). It also names prerequisite helpers like list_external_connections and list_import_templates, effectively routing the agent without ambiguity.

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

All Azquo toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources