OuterSpace Apizr
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| apizr_analyzeA | Discover static capability identities, source evidence and relationships when you need to find what to inspect. Does not execute project code. Choose full, summary or exact capability/module detail. Retain a capability ID and the returned repository digest for optional expected_repository_digest pinning; next inspect readiness or test an exposure plan. Evidence is assessed afresh and is not cached for later calls. This tool grants no execution or exposure authority. |
| apizr_readinessA | Assess whether and under what conditions capabilities satisfy the startup readiness policy. Choose this for limitations, uncertainty and execution/control compatibility, rather than discovering identities or testing an exposure proposal. Use full, summary or exact capability/module detail, optionally pinned to a repository digest. Analysis can help find exact IDs but is not required. exit_code: 1 with isError: false is valid business evidence. Does not execute project code and does not authorize exposure. Next, use sufficient evidence to choose an explicit capability/policy for an exposure plan. |
| apizr_plan_exposureA | Test an exposure proposal when you know which capabilities to expose. Evaluates explicit selection, interfaces and execution constraints against current static evidence/readiness; uses a supplied policy or the startup exposure policy. Returns proposed capability/interface/execution combinations. Does not generate a server, execute a function, change project configuration, publish anything or create operator authorization. For exposure_refused, inspect structured diagnostics/actions and revise the proposal or its evidence before trying again. |
| apizr_experiment_listA | List verified local experiment Runs, including CLI, SDK and Jupyter captures, with recorded parameters and metrics. Requires an explicit history.read operator grant for the configured project's store. Filters and limit only affect presentation: every retained record is validated. No execution, exposure or store mutation; next use show or diff with returned Run identities. |
| apizr_experiment_showA | Read one verified recorded Run and its intended Plan using an exact digest or unique prefix. Includes producer and capture evidence when retained; unknown provenance stays unknown. Requires the configured project's history.read grant. Does not execute project code, load the producing provider, expose capabilities or mutate the store; compare two identities with diff. |
| apizr_experiment_diffA | Compare two verified local Runs directionally from A to B using canonical experiment comparison. Returns recorded changes, unknown evidence and finite numeric deltas, never causal conclusions. Requires the configured project's history.read grant. Does not execute, retrain, expose or mutate records; inspect show for the original evidence behind differences. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct phase: discovery (analyze), policy assessment (readiness), proposal testing (plan_exposure), and experiment history (list/show/diff). Boundaries are explicitly spelled out in the descriptions, though analyze and readiness both inspect the same capability space, which could cause occasional selection confusion.
All names share a clean apizr_ prefix and snake_case, but the verb/no-un structure is mixed: single verbs (analyze), nouns (readiness), and noun_verb compounds (plan_exposure, experiment_list, experiment_show). Mostly consistent with minor deviation in the base convention.
Six tools is well-scoped for the server's purpose, covering discovery, readiness, exposure planning, and an experiment list/show/diff trio. Each tool clearly earns its place with no redundancy.
The static-analysis-to-exposure-planning workflow (analyze -> readiness -> plan_exposure) and experiment inspection (list/show/diff) appear well covered. Gaps are minor, since exposure execution and server generation are intentionally out of scope for this read-only/inspection surface.