Skip to content

account_or_zone has no enum or description in openapi.forge.json #59

Closed

Description

@mattzcarey

81 operations in openapi.forge.json sit under a merged path like /{account_or_zone}/{account_or_zone_id}/access/apps, most of them Access. The spec types account_or_zone as a plain required string. Nothing says it has to be accounts or zones, and account_or_zone_id is described as "Identifier."

So everything that reads the spec hard-codes the rule itself:

  • cf hides both parameters. It sends zones and the zone ID when you pass --zone, and accounts with the profile's account otherwise. Compare cf zero-trust access applications list --dry-run with and without -z.
  • cloudflare/mcp splits every merged path back into its /accounts/{account_id}/… and /zones/{zone_id}/… routes before Code Mode sees the spec, in feat(spec): read the OpenAPI document from the latest Forge release mcp#297. Without the split the model has to guess the value, and our scope step-up asks zone calls for the account scope. The generated direct tools in feat(mcp): serve forge-generated direct tools at ?forge=true mcp#300 add the enum themselves and fill in the account.
  • The API site and Terraform docs in this repo map the SDKs' /{accounts_or_zones}/… paths onto the merged one in packages/cloudflare-api-site/src/terraform.ts.

That's three copies of one rule, and the next generator will write a fourth. I'd rather the spec carried it. The smallest fix is an enum and a description on the merged parameter:

{ "name": "account_or_zone", "in": "path", "required": true,
  "schema": { "type": "string", "enum": ["accounts", "zones"] },
  "description": "Whether account_or_zone_id is an account ID (`accounts`) or a zone ID (`zones`)." }

That's enough for a model or any OpenAPI client to build the right URL. An extension mapping each value to its ID parameter would go further. With something like x-forge-account-or-zone: { "accounts": "account_id", "zones": "zone_id" }, generators could expand the path into both routes, or fill it from context like cf does, without knowing the rule up front. I made that name up, so pick whatever fits.

Once the spec has the enum, cloudflare/mcp can delete its split and most of the account-or-zone code in its forge tools.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions