Your API Gateway Governs Traffic. Naftiko Makes It AI-Consumable.

Every enterprise has an API gateway. Some have more than one. Apigee, MuleSoft Anypoint, Azure API Management, Kong, Tyk, NGINX, AWS API Gateway — the list is long and the investments are real. These gateways govern traffic, enforce policy, manage developer access, and produce the analytics that tell you how your APIs are actually used.

What they do not do is make those governed APIs consumable by AI agents.

That is the gap Naftiko capabilities fill.

What the Gateway Does Well

An API gateway is a traffic control plane. It sits between your upstream services and your consumers, enforcing rate limits, authentication, transformations, and routing. The gateway knows every API call that happens in your organization.

Modern gateways go further: API catalogs, developer portals, spec storage, shadow API detection, analytics pipelines. Apigee has API Hub. MuleSoft has Anypoint Exchange. Azure APIM has its developer portal. These are rich governance platforms, not just traffic routers.

The investment you have made in your gateway is your API foundation. It is the authoritative record of what APIs exist, how they are governed, and how they are consumed.

What AI Agents Actually Need

AI agents need to call APIs to do useful work. When an agent needs to retrieve data, trigger a workflow, or query the state of a system, it reaches for a tool. That tool needs to be:

• Discoverable — the agent needs to know the tool exists
• Structured — typed inputs and outputs the agent can reason about
• Callable — a deterministic invocation surface, not a documentation page
• Governed — inspectable, versioned, and aligned with organizational policy

Developer portals are built for human developers who read documentation. AI agents cannot consume a developer portal. They need tool definitions: MCP tools, Agent Skills, or governed REST endpoints with explicit schemas.

Your gateway governs the APIs. Naftiko capabilities turn those governed APIs into AI-consumable tools.

The Naftiko Capability Pattern

A Naftiko capability is a YAML specification with two sides: what it consumes and what it exposes.

naftiko: "1.0.0-alpha1"

capability:
  consumes:
    - namespace: gateway
      type: http
      baseUri: https://your-gateway-api.example.com/v1
      authentication:
        type: bearer
        token: ""
      resources:
        - name: apis
          path: "/apis"
          operations:
            - name: listApis
              method: GET

  exposes:
    - type: mcp
      address: "0.0.0.0"
      port: 9100
      namespace: gateway-tools
      tools:
        - name: list-apis
          description: "List all APIs registered in the gateway"
          hints:
            readOnly: true
          call: gateway.listApis
          outputParameters:
            - type: array
              mapping: "$."
              items:
                type: object

    - type: rest
      port: 8100
      namespace: gateway-rest
      resources:
        - path: "/apis"
          name: apis
          operations:
            - method: GET
              call: gateway.listApis
              outputParameters:
                - type: array
                  mapping: "$."
                  items:
                    type: object

The Naftiko engine reads this file at runtime and serves live MCP tools and REST endpoints — no code generation, no build step, no drift between specification and behavior. The spec is the integration.

Capabilities Across the Gateway Landscape

The Naftiko Fleet is an open-source collection of capability specifications for the gateways enterprises actually run:

Each capability follows the same pattern: consumes the gateway’s management API, exposes MCP tools and REST endpoints, injects credentials via environment variables. Drop the YAML file, run the Naftiko engine, and your gateway inventory is immediately available as structured tools for AI agents. New gateway capabilities are added to the fleet continuously — fork the repo for your gateway and contribute your own.

From Gateway Investment to AI Capability

The question is not whether to build AI-powered workflows on top of your API infrastructure. That work is already underway in every enterprise. The question is whether you do it with or without a governed capability layer.

Without the layer: every team writes its own glue code. Authentication is scattered. Output schemas are inconsistent. There is no governance surface — no inspectable specification, no version history, no shared catalog.

With the capability layer: the specification is the integration. Gateway investments become AI-consumable tools without touching the gateway itself. The governance posture you established for API traffic extends to AI consumption.

Your gateway is not the problem. The missing layer between the gateway and the AI agents is. Start with the capability set for your gateway in the Naftiko Fleet and have MCP tools running against your infrastructure in minutes.