Skip to main content
Glama
OuterSpace Apizr

OuterSpace Apizr

Official

OuterSpace Apizr

Turn existing Python functions into REST APIs or MCP tools. Inspect training scripts and notebooks, record experiments, and compare their results.

Apizr 0.4.6 supports Python 3.11–3.15 on macOS and Linux.

PyPI CI Security Documentation Python License Apizr MCP server on Glama MCPLookup Trust Index

Install

With uv:

uv tool install outerspace-apizr==0.4.6
apizr --version

Install Apizr 0.4.6 with uv

Prefer pip or Homebrew? Follow the installation guide.

Related MCP server: molmcp

Try it

Save this as pricing.py:

def total(quantity: int, unit_price: float) -> float:
    return round(quantity * unit_price, 2)

Inspect the function, then generate its MCP server:

apizr inspect pricing.py
apizr generate mcp pricing.py --select total --output-dir dist/mcp

Apizr reads the function without running it. You choose which functions to expose. The generated server runs them when a client calls them.

Follow the Quickstart to start a server and make your first REST or MCP calls. The full walkthrough explains how this works across a project.

Work with experiments

Start with a training script or notebook you want to understand:

apizr experiment inspect train.py

The report shows the data, parameters and calculations found in the source. It does not train a model or invent scores.

You can then run trusted code, keep its history, compare results and share a selected prediction function. Start with the Data Scientist quickstart, or follow the Academy.

Go further

The core handles inspection and generation. Plugins are optional. Run generated services and experiments only with code and dependencies you trust.

Documentation · Release notes · Contributing · Report an issue

Available Tools

6 tools
apizr_analyzeAnalyze Python ProjectA
Read-onlyIdempotent

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.

Inputs: view, limit, module, offset, +2 more. Returns: object

apizr_experiment_diffCompare Experiment RunsA
Read-onlyIdempotent

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.

Inputs: run_a (required), run_b (required). Returns: object

apizr_experiment_listList Experiment RunsA
Read-onlyIdempotent

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.

Inputs: limit, source, status, capability. Returns: object

apizr_experiment_showShow Experiment EvidenceA
Read-onlyIdempotent

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.

Inputs: run_id (required). Returns: object

apizr_plan_exposurePlan Capability ExposureA
Read-onlyIdempotent

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.

Inputs: limit, offset, policy, expected_repository_digest. Returns: interfaces, capabilities, graph_digest, catalog_digest, +6 more

apizr_readinessAssess Repository ReadinessA
Read-onlyIdempotent

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.

Inputs: view, limit, module, offset, +2 more. Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.2/5.0

    Scored across 6 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count5/5

    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.

    Completeness4/5

    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.

    Maintenance

    ActivityActive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      B
      quality
      C
      maintenance
      A graph-based codebase capability discovery engine for LLM agents, exposing indexed code symbols, signatures, and relationships over MCP to enable agents to find and use tools without guessing names.
      9
      BSD 3-Clause
    • A
      license
      B
      quality
      C
      maintenance
      Convert plain Python modules into MCP servers without decorators or boilerplate, automatically exposing functions as schematized tools.
      5
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables users to turn any API, CLI, database, website, SDK, or codebase into a production-ready MCP server with secure, dynamically discoverable capabilities.
      MIT