Aziel Runtime

Open one product

runtime_pull

Read-onlyIdempotent

Open one hub product card by slug (name, version, skill, download, ops) — not FragGate live/stub status. Use this when you already have a slug from GET /v1/software or fraggate_list and need the card, not exec. Do not use it for inspecting FragGate live/stub status or executing an op; use fraggate_describe or fraggate_call instead. Not exec — then use fraggate_call. Unknown slug throws unknown product (it does not invent a card and does not refuse FG-HALLUC-TOOL; that code is FragGate-only). Missing skill falls back to in-repo markdown. slug is required. product is an accepted alias of slug. Extra keys besides those two are ignored and are not an op payload. Returns one product card (name, version, skill, download, ops, skill_source).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`slug`	Yes	Required catalog slug from GET /v1/software or fraggate_list (for example foldlock). Alias: product. Not an exec path.
`product`	No	Alias of slug. Do not send two different values.

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No	FragGate or fabric code when present: FG-OK, FG-HALLUC-TOOL, FG-STUB, FG-LOCAL-ONLY, FG-UNKNOWN-OP, FG-GATE-REFUSE, FG-LAMB-REFUSE, or a module refuse such as MESH-* / AKM-*.
`door`	No	Door name. The public door is fraggate.
`ran_in`	No	Execution locale (for example aziel-runtime) when present.
`result`	No	One hub product card: name, version, skill markdown, download, ops, skill_source. Unknown slug is unknown product — not a FragGate FG-HALLUC-TOOL envelope.
`status`	No	HTTP-like status when present on wrappers (200 ok; 400+ error / refuse).
`display`	No	Human-facing envelope. Show title and summary, then take the next input.
`receipt`	No	Optional receipt, ledger tip, or TemporalLock/ForgeReceipts exit when the door stamped one.
`refusal`	No	Explicit refuse object, code, or message when the door or engine refused.
`engine_op`	No	Resolved engine op when present (often inside result).
`ledger_tip`	No	Ask/refuse ledger tip when the door stamped one.
`provenance`	No	Provenance / input packet when the pipeline attached one.
`session_id`	No	Raw session id when session plumbing was used. Hidden unless the user asked for the chain.
`engine_slug`	No	Resolved engine slug when present (often inside result).
`limitations`	No	Capability limitations or Remain-OFF notes when present.
`engine_digest`	No	64-hex engine_digest when a true in-process engine ran (often inside result).

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond that: unknown slug throws 'unknown product' rather than inventing a card or emitting FG-HALLUC-TOOL, and a missing skill falls back to in-repo markdown. It also clarifies extra keys are ignored and are not an op payload.

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

Conciseness3/5

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

The routing constraint is front-loaded, but the text is redundant: 'not FragGate live/stub status' and 'not exec' are each stated twice, and the return-field list duplicates the output schema. It earns its size only partially.

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 an output schema present and full annotation coverage, the description need not explain return values, yet it still covers the routing decision, error behavior, and fallback semantics. Nothing an agent needs to call it 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% and the schema already documents slug, the product alias, and that extra keys are ignored, so the baseline is 3. The description largely restates the alias/required semantics rather than adding new meaning, though the 'not an exec path' note is mildly useful.

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 ('Open one hub product card by slug') and enumerates the card fields (name, version, skill, download, ops). It explicitly contrasts itself with the FragGate status siblings and with exec, so an agent can distinguish it 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?

Gives an explicit trigger ('when you already have a slug from GET /v1/software or fraggate_list'), explicit exclusions (do not use for FragGate live/stub status or executing an op), and names the alternatives fraggate_describe and fraggate_call for those cases.

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

All Aziel Runtime 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.