Skip to main content
Glama

List every product (bundle helper)

runtime_bundle
Read-onlyIdempotent

Get all product skill URLs and invoke prefixes in a single compact bootstrap. Use for one-shot client discovery of skill endpoints, avoiding Software-tab cards and hashed registry lookup.

Instructions

Read a compact bootstrap of every product skill URL and invoke prefix — not Software-tab cards and not the hashed registry. Use this when a client needs skill URLs in one shot. Do not use it for Software-tab refresh, hashed registry discovery, or exec; use Softwares, fraggate_list, or fraggate_call instead. Prefer GET /v1/software for hub Software tabs. This helper is URL bootstrap only. Returns compact product list with skill URLs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoFragGate 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-*.
doorNoDoor name. The public door is fraggate.
ran_inNoExecution locale (for example aziel-runtime) when present.
resultNoMachine payload. FragGate-style results commonly include ok, code, slug, op, status, engine_slug, engine_op, engine_digest, ran_in, provenance, refusal, limitations, and ledger_tip.
statusNoHTTP-like status when present on wrappers (200 ok; 400+ error / refuse).
displayNoHuman-facing envelope. Show title and summary, then take the next input.
receiptNoOptional receipt, ledger tip, or TemporalLock/ForgeReceipts exit when the door stamped one.
refusalNoExplicit refuse object, code, or message when the door or engine refused.
engine_opNoResolved engine op when present (often inside result).
ledger_tipNoAsk/refuse ledger tip when the door stamped one.
provenanceNoProvenance / input packet when the pipeline attached one.
session_idNoRaw session id when session plumbing was used. Hidden unless the user asked for the chain.
engine_slugNoResolved engine slug when present (often inside result).
limitationsNoCapability limitations or Remain-OFF notes when present.
engine_digestNo64-hex engine_digest when a true in-process engine ran (often inside result).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.6.2
    • changedInput schema / additionalProperties
      Previous value: -trueNew value: +false
    • addedInput schema / description
      Added value: +"No arguments. Send {}."
    • addedInput schema / properties
      Added value: +{}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "description": "Display envelope shown to the user (display.title / display.summary) plus the machine result. Extra engine fields may appear.",
      +  "properties": {
      +    "code": {
      +      "description": "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-*.",
      +      "type": "string"
      +    },
      +    "display": {
      +      "additionalProperties": true,
      +      "description": "Human-facing envelope. Show title and summary, then take the next input.",
      +      "properties": {
      +        "fields": {
      +          "description": "Optional labeled scalars copied from the result for display.",
      +          "items": {
      +            "additionalProperties": true,
      +            "properties": {
      +              "label": {
      +                "description": "Field label.",
      +                "type": "string"
      +              },
      +              "value": {
      +                "description": "Field value as text.",
      +                "type": "string"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "type": "array"
      +        },
      +        "next": {
      +          "description": "What the agent should do after showing this output.",
      +          "type": "string"
      +        },
      +        "summary": {
      +          "description": "One-line outcome or refuse reason.",
      +          "type": "string"
      +        },
      +        "title": {
      +          "description": "Short result title for the AI client.",
      +          "type": "string"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "door": {
      +      "description": "Door name. The public door is fraggate.",
      +      "type": "string"
      +    },
      +    "engine_digest": {
      +      "description": "64-hex engine_digest when a true in-process engine ran (often inside result).",
      +      "type": "string"
      +    },
      +    "engine_op": {
      +      "description": "Resolved engine op when present (often inside result).",
      +      "type": "string"
      +    },
      +    "engine_slug": {
      +      "description": "Resolved engine slug when present (often inside result).",
      +      "type": "string"
      +    },
      +    "ledger_tip": {
      +      "description": "Ask/refuse ledger tip when the door stamped one."
      +    },
      +    "limitations": {
      +      "description": "Capability limitations or Remain-OFF notes when present."
      +    },
      +    "provenance": {
      +      "description": "Provenance / input packet when the pipeline attached one."
      +    },
      +    "ran_in": {
      +      "description": "Execution locale (for example aziel-runtime) when present.",
      +      "type": "string"
      +    },
      +    "receipt": {
      +      "description": "Optional receipt, ledger tip, or TemporalLock/ForgeReceipts exit when the door stamped one."
      +    },
      +    "refusal": {
      +      "description": "Explicit refuse object, code, or message when the door or engine refused."
      +    },
      +    "result": {
      +      "description": "Machine payload. FragGate-style results commonly include ok, code, slug, op, status, engine_slug, engine_op, engine_digest, ran_in, provenance, refusal, limitations, and ledger_tip."
      +    },
      +    "session_id": {
      +      "description": "Raw session id when session plumbing was used. Hidden unless the user asked for the chain.",
      +      "type": "string"
      +    },
      +    "status": {
      +      "description": "HTTP-like status when present on wrappers (200 ok; 400+ error / refuse).",
      +      "type": "integer"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observedv1.5.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the bar is lower. The description adds behavioral context by calling the output a 'compact bootstrap' and 'URL bootstrap only,' clarifying scope boundaries and the nature of the response beyond what annotations express.

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?

The description is dense and front-loaded, leading with the core behavior and exclusions before routing to alternatives. Minor redundancy exists between 'URL bootstrap only' and the later 'Returns compact product list with skill URLs,' but every sentence still contributes useful guidance.

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?

For a zero-argument, read-only tool with an output schema and robust annotations, the description covers what it does, when to use it, when not to use it, and what it returns. Nothing essential for an agent to select and invoke it correctly is missing.

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?

There are zero parameters and the input schema already states 'No arguments. Send {}.' With no parameters to document, the description need not add parameter detail. The baseline of 4 for zero-parameter tools applies, and the description's 'in one shot' phrasing reinforces that no further inputs are required.

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?

The description names a specific verb and resource: 'Read a compact bootstrap of every product skill URL and invoke prefix.' It also explicitly excludes nearby concepts ('not Software-tab cards and not the hashed registry') and states the returned payload, so an agent can distinguish runtime_bundle from Softwares, fraggate_list, and fraggate_call.

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?

The description gives an explicit trigger condition ('when a client needs skill URLs in one shot'), explicit negative conditions ('Do not use it for Software-tab refresh, hashed registry discovery, or exec'), and names the alternatives (Softwares, fraggate_list, fraggate_call). It even recommends GET /v1/software for hub Software tabs. This is model usage guidance.

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