Skip to main content
Glama
Sign In

Azquo

by ai.azquo
OverviewDiscussionsAdmin

Apply structure

apply_structure
Idempotent

Add parent → child relations between names. Idempotent: existing links stay; new ones are added. With createMissing=true (default) names are auto-created if not found. Returns: applied, alreadyLinked, namesCreated (the names that didn't exist before), namesResolved (every child in input order with its resolved id — use to chain into edit_name_attributes).

═══ PROVENANCE — required on every write ═══ source: origin reference (file/URL/document/short note). Lands in the audit trail. agent: your AI agent name (e.g. "Claude"). Lands in the audit trail.

Input Schema

NameRequiredDescriptionDefault
agentYesAI agent name (e.g. "Claude"). REQUIRED.
sourceYesOrigin reference — file, URL, document, or short note. REQUIRED.
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.
databaseYesDatabase name
relationsYesNon-empty array of {parent, child} pairs
createMissingNoAuto-create names that don't exist (default: true)

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. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations cover the safety profile (idempotentHint, destructiveHint=false, readOnlyHint=false), and the description adds real side-effect detail beyond them: how idempotency actually behaves, that names get silently auto-created, and that source/agent land in an audit trail. It omits error modes and what happens with cycles or missing parents when createMissing=false.

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 action and idempotency, then a compact Returns block, then a clearly delimited PROVENANCE section. Slightly dense in the returns enumeration, but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 correctly supplies the return fields and their meaning. Provenance requirements for this write are spelled out. Missing only edge-case behavior (invalid parent with createMissing=false, error shape), which keeps it from full completeness.

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 description coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks — specifically that source and agent go into the audit trail and are mandatory on every write, which clarifies why they are required. It does not touch the business parameter, so it is not fully additive.

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: 'Add parent → child relations between names'. It also names the sibling it hands off to (edit_name_attributes), so the agent can distinguish this hierarchy-building tool from attribute-editing 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operative context: idempotent behavior, the createMissing default that changes what gets written, and the follow-up workflow via namesResolved → edit_name_attributes. It stops short of explicit when-not-to-use guidance or naming alternative tools for overlapping goals.

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