Docs

MCP, API Surfaces, and Infrastructure as Code

How GAEZLA discovers supported API operations, reads current state, produces reviewable IaC, and separates discovery from execution authority.

GAEZLA uses MCP as a common operating surface across configured systems. For spec-backed integrations, an AI-assisted workflow can:

  1. search operations by intent;
  2. retrieve the exact operation schema and safety hints; and
  3. invoke the operation within the connection’s available scope and policy.

Semantic search with lexical fallback finds relevant operations. Exact schema retrieval then supplies parameters, request bodies, and safety hints, so the workflow works from the configured API contract rather than memorized syntax.

Configuration to IaC

This creates two practical starting points:

  • Existing configuration: read current state through the configured connection, inspect any existing repository files and history, and translate the intended state into complete IaC or configuration files.
  • New configuration: begin with an operator-defined outcome, discover the supported operations and schemas, model the prerequisites, and author the desired-state files from scratch.

Configured repositories provide bounded directory, file, code-search, and commit-history context. GAEZLA can prepare a proposal containing file creates, updates, or deletions; operator approval remains the gate before it opens the pull request.

Advanced cross-service configuration

A project can span several API domains while remaining one reviewed design. For example, an Entra ID, Azure, and Intune enrolment project can combine:

  • current directory, resource, and managed-device reads available to the configured tenant permissions;
  • operation and schema discovery for the relevant identity, resource, and device-management APIs;
  • repository context and existing IaC conventions;
  • a desired-state design, implementation files, prerequisites, and rollback; and
  • a clear list of any steps that require operator completion.

The result is one reviewed design built from the live API contracts, the configured estate, and the repository conventions—retained as code instead of lost in a console session.

Discovery and authority are separate

Finding an API operation does not grant permission to run it:

  • eligible reads execute only with the configured connection, tenant permission, target scope, and integration policy;
  • supported mutations materialize a durable action proposal rather than silently changing the external system;
  • changes use a durable proposal or the workflow’s governed execution path; and
  • generating IaC leaves deployment to the selected merge, pipeline, signed playbook, integration proposal, or app-runtime path.

Local runtime options

When a workflow needs a local engine, the appliance provides a consistent app lifecycle for schema-guided configuration, installation, reconciliation, ingress, and health. This keeps API discovery, configuration authoring, and the runtime that applies the work connected without treating them as the same permission boundary.