fix(queryPermissions): expose aclTag aliases for permission lookups

[binggg]

Signal

• Attribution: issue_mns3n0at_qt4xp0
• Duplicate signal: issue_mnoa2xj8_oz3hul
• Representative run: atomic-js-none-describe-nosql-acl/2026-04-09T23-18-40-93s367
• Related run: atomic-js-none-describe-storage-acl/2026-04-07T07-07-19-5yd57w
• Failure: evaluators expected RESULT.json to include aclTag/AclTag/acl_tag, but queryPermissions(getResourcePermission) only surfaced permissions[] and buried the canonical permission tag under Permission

Why this is actionable

• Relevant module: mcp/src/tools/permissions.ts
• Current behavior: getResourcePermission returns permissions[] plus raw, so models often copy the array and miss the top-level permission alias that tasks/evaluators look for
• Expected behavior: permission lookups should expose a direct acl tag summary and compatibility aliases while keeping the existing permissions payload intact

Proposed direction

• Add top-level permission summary fields for getResourcePermission, including aclTag / AclTag / acl_tag derived from the primary permission entry
• Expose requestId / totalCount directly for easier consumption
• Add focused tests and update tool docs so the model sees the canonical output shape

[github-actions]

🤖 AI Analysis

Classification

Bug / Missing field — the tool returns the right data but buries the canonical ACL tag inside permissions[].Permission, without exposing it at the top level where evaluators and models expect it. This is an output-shape gap, not a logic error.

Likely area

mcp/src/tools/permissions.ts:372-399 — the getResourcePermission action handler. The Manager SDK normalizes the Cloud API's AclTag into Permission inside each PermissionList entry, but the tool never promotes that value to a top-level summary field. Evaluators and downstream consumers look for aclTag / AclTag / acl_tag at the top of the response and fail to find it.

Key observation: the naming is fragmented across layers:

• Cloud API: AclTag
• Manager SDK (used by the tool): Permission in PermissionList[]
• Design docs / DOC.md: aclTag / AclTag
• Current tool output: only permissions[].Permission — no top-level alias

Suggested next step

This is a small, low-risk change — no spec needed. The fix:

1. Add top-level summary fields to the getResourcePermission return shape in permissions.ts, derived from the primary permission entry (the matched or first entry):

   • aclTag — the canonical permission tag value (e.g. "READONLY", "PRIVATE", "CUSTOM")
   • Keep the existing permissions[] array and raw intact (no breaking change)

2. Expose requestId and totalCount from the API response at the top level if present.

3. Update the test in permissions.test.ts — add assertions that aclTag is present and matches the primary entry's Permission value.

4. Update mcp/DOC.md to document the new top-level field.

The core change is roughly:

// After extracting permissions and finding the primary entry:
const primaryEntry = permissions.find(p => p.Resource === resourceId) || permissions[0];
const aclTag = primaryEntry?.Permission ?? null;

// Add to the returned data object:
aclTag,

This keeps backward compatibility while making the canonical tag discoverable at the top level.

Open questions

• Should we also add acl_tag (snake_case) as an alias for consistency with some evaluator expectations, or is aclTag alone sufficient? The issue mentions all three variants (aclTag / AclTag / acl_tag), but adding all three may be over-engineering — a single canonical aclTag with the Permission field still available in the array seems cleaner.
• Should listResourcePermissions also get the same treatment (top-level summary per resource), or is the fix scoped to getResourcePermission only?

---

Generated automatically by CodeBuddy CLI headless mode.