Azquo

Try changes on a copy

try_on_copy

Try changes on a throwaway copy of a database before making them for real. action=start makes an in-memory copy of the database. From then on EVERY call in this session on that database - reads and writes - goes to the copy, and each result begins 'TRIAL COPY of ...'. Nothing on the copy is ever saved. Check the outcome (query_aql, describe_set, get_report_data ...). Then action=discard to throw the copy away and return to the real database. To keep the changes, make the same calls again after discarding - there is no commit. action=status lists this session's trials. While any trial is on, tools whose effects would reach beyond the copy are refused: imports, create/delete database, delete report/import template, library copies, upload links, and the name history tools. Use it for a risky restructure, a bulk edit:, or a first attempt at an unfamiliar write. A copy holds the whole database in server memory - start warns when the database is large - so discard it as soon as you are done. A copy unused for 2 hours is discarded by the server; calls then fail loudly until you discard the trial here. A trial belongs to this MCP session only; another agent on the same key keeps working on the real database.

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": {
      "action": "<action>"
    },
    "name": "try_on_copy"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	start, discard or status
`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`	No	Database name - required for start and discard

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, disclosing that all reads and writes redirect to an in-memory copy, results are prefixed 'TRIAL COPY of ...', nothing persists, copies idle 2 hours are server-discarded, and trials are session-scoped so other agents keep hitting the real database. These are exactly the behavioral facts an agent needs and none contradict the annotation flags.

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 core concept and organized into logical sentences, each carrying useful information. It is somewhat long for a three-action tool and has a minor typo ('bulk edit:,'), but nothing is wasted.

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?

Covers memory implications (whole database in server memory, start warns on large databases), the 2-hour idle timeout, session scoping, the refusal list, and the result-format marker. With no output schema, the description still tells the agent what to expect back.

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 adds real meaning: it explains what each action value does (start copies, discard returns, status lists trials) and that database is required for start and discard. It does not elaborate on the business parameter, keeping this just below a 5.

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 ('Try changes on a throwaway copy of a database') and immediately frames how it differs from the write siblings like aql_write and apply_structure by making changes provisional. An agent can tell this apart from direct-write tools 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?

Explicitly names when to use it ('a risky restructure, a bulk edit, or a first attempt at an unfamiliar write'), describes the discard-then-reapply workflow in place of a commit, and lists the tools that are refused while a trial is active. This is a complete when/when-not/alternatives picture.

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?