Skip to main content
Glama
Sign In

Azquo

by ai.azquo
OverviewDiscussionsAdmin

Create database

create_database

Create a new, empty Azquo database in the current business (see current_business). Use it to start a new model from scratch; to start from a ready-made one use copy_from_library, and to experiment on an existing database use try_on_copy. Needs an administrator or developer; the creator becomes its owner.

The name is cleaned: spaces become underscores and anything other than letters, digits and underscores is dropped ("Sales 2026!" becomes Sales_2026). Fails with database_create_failed if a database of that name already exists in the business - check list_databases first.

databaseServerId: usually left out - the database then goes on the default server, the one the admin site's New database offers first. Give it only to choose a particular server; an unknown id fails with unknown_databaseServerId and the error lists the valid ids.

Returns the new database record: id, name (as cleaned), persistenceName, databaseServerId and its counts (all zero). Next steps are usually apply_structure or import_file, then persist_database.

Input Schema

NameRequiredDescriptionDefault
nameYesName for the new database, e.g. Sales_Forecast. Letters, digits and underscores; spaces become underscores
businessNoOptional. 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.
databaseServerIdNoOptional. Integer id of the database server, as a string, e.g. "0". Leave out to use the default server

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / databaseServerId / description
      Previous value: -"Integer id of the database server, as a string, e.g. \"0\". Only needed when more than one server exists - the error then lists the valid ids"New value: +"Optional. Integer id of the database server, as a string, e.g. \"0\". Leave out to use the default server"
  3. Changed2 schema fields changed
    • changedInput schema / properties / databaseServerId / description
      Previous value: -"Database server ID — only needed if multiple servers exist"New value: +"Integer id of the database server, as a string, e.g. \"0\". Only needed when more than one server exists - the error then lists the valid ids"
    • changedInput schema / properties / name / description
      Previous value: -"Name for the new database"New value: +"Name for the new database, e.g. Sales_Forecast. Letters, digits and underscores; spaces become underscores"
  4. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: role requirement, ownership effect, name-sanitization rules with a worked example, two named failure modes, and the default-server behavior. Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, but the failure semantics go well beyond them. It stops short of saying whether creation is reversible or what happens to the caller's session 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?

Well front-loaded — purpose then alternatives then parameter notes then return value, in a predictable order. It runs long (~190 words) and repeats some name-cleaning detail already in the schema, but each paragraph carries usable information.

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?

No output schema exists, and the description compensates by naming the returned fields (id, name, persistenceName, databaseServerId, zero counts) and suggesting next steps (apply_structure, import_file, persist_database). For a 3-parameter creation tool, an agent has everything needed to call it correctly.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: databaseServerId is 'usually left out', resolves to the default the admin site offers first, and an unknown id fails with a listing of valid ids. The name-cleaning example ('Sales 2026!' becomes Sales_2026) also clarifies the transform beyond the schema's one-liner.

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?

Opens with a specific verb + resource + scope ('Create a new, empty Azquo database in the current business') and immediately contrasts with the two relevant siblings, copy_from_library and try_on_copy. An agent can distinguish this from all 38 siblings 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 routing ('start a new model from scratch' vs 'ready-made one' vs 'experiment on an existing database'), plus a prerequisite (check list_databases first to avoid the create_failed collision) and a permissions condition (administrator or developer). Nothing is left to inference.

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
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