Azquo

List import templates

list_import_templates

Read-only

List every import template in the current business. An import template is a workbook of rules that tells Azquo how to interpret incoming data files - which columns become which names and values. Read-only, no parameters. Use it to check what templates exist before import_file or import_from_query, or to find the id for delete_import_template. For the template one database uses, use list_database_sheets; to read a template's rules, read_workbook.

Returns an array of templates: id, templateName, filename, notes, user (who uploaded it) and dateCreated. Empty when the business has none. Not paginated.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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.

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.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, yet the description still adds genuinely new behavioral facts: empty array when the business has none and that results are not paginated. That pagination/empty-result disclosure is exactly the sort of thing annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, followed by definition, behavior, routing guidance, and return shape in a tight sequence. Each sentence carries distinct information with no filler or repetition.

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?

With no output schema, the description compensates by enumerating returned fields (id, templateName, filename, notes, user, dateCreated) and edge cases (empty, unpaginated). Nothing needed to select or invoke this tool correctly is missing.

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%, so the optional 'business' parameter is fully documented in the schema and the description need not repeat it. The description's phrase 'no parameters' is imprecise given that optional business argument exists, but it does not contradict any structured field; baseline 3 applies since the schema does the work.

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+resource ('List every import template in the current business') and immediately defines what a template actually is, so an agent knows the domain concept rather than just the name. It explicitly distinguishes itself from list_database_sheets and read_workbook, which an agent could otherwise confuse with it.

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?

Gives explicit when-to-use: before import_file or import_from_query, and to find the id for delete_import_template. It also names the alternatives for adjacent needs (list_database_sheets for per-database templates, read_workbook to read rules), so the agent can route correctly without trial and error.

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

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

Need Help?