run_14cf8d1b780a559a

input

{
  "request": "Triage Jira ticket MZCLD-3776: People-MCP: provide agents with limited, protected access to the Mozilla employee directory",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3776"
  ],
  "sourceContext": {
    "issue": "MZCLD-3776"
  }
}

summary

MZCLD-3776 is a Backlog-status epic-level ticket proposing to give agents a sanctioned, access-controlled way to read the Mozilla employee directory, replacing today's ad-hoc pattern of individuals scripting scrapes of people.mozilla.org. The ticket explicitly lists three unchosen candidate solutions (Confluence doc pointing at existing BigQuery directory data, an IAM-supplied feature, or a dedicated People API MCP server built on Runlayer/Google Agent Platform) and states that solution selection is part of the epic's own work, not a precondition for starting it. It has zero comments and no linked design doc/runbook was referenced, so there is nothing yet to triage against beyond the description. Note: attempts to pull the referenced related tickets (MZCLD-3564 prototype, MZCLD-3711 Runlayer, MZCLD-3703 Google Agent Platform) were blocked by run-scope policy, so this triage is based solely on MZCLD-3776's own content.

findings

• Ticket is well-formed for an epic: clear problem statement, goal, explicit candidate solutions, prior art link, and out-of-scope boundary — but is unestimated/untriaged (Backlog, no comments, no assignee/priority visible in the read).
• The ticket deliberately defers the build-vs-buy-vs-document decision (Confluence/BigQuery doc vs IAM feature vs People-MCP server) to future work under this epic, so triage should focus on sequencing/owner assignment rather than picking a solution now.
• There is directly relevant prior art (a People-MCP prototype from a MozCloud work week) already reparented under this epic, which should inform scoping and could shortcut discovery work.
• The epic has explicit dependency/boundary framing: it consumes agent-platform paving work from MZCLD-3703/3711/3724 rather than building that platform itself, which matters for sequencing and cross-team coordination.
• Could not retrieve MZCLD-3564, MZCLD-3711, or MZCLD-3703 for cross-referencing due to run-scope access policy restricting reads to the trigger ticket only; recommendation is based on MZCLD-3776 alone.

proposed actions

Triage note: This epic is well-scoped (problem, goal, three candidate solutions, prior art, explicit out-of-scope) but sits in Backlog with no comments/owner yet. Recommend: (1) Assign an owner/DRI to run a lightweight discovery spike comparing options (a) Confluence doc over existing BigQuery directory data, (b) IAM-supplied directory feature, and (c) a People API MCP server (potentially building on the MZCLD-3564 work-week prototype, atop Runlayer/MZCLD-3711 or Google Agent Platform/MZCLD-3703 once those paved paths land). (2) Start with option (a) as a cheap first pass / stopgap given it requires no new infra, while tracking whether it meets the 'protected/limited access' bar (row-level access control, PII scoping, audit logging) that agents need — if not, escalate to (b) or (c). (3) Explicitly track the dependency on MZCLD-3703/3711/3724 agent-platform work so this epic isn't started before a paved path exists for option (c), and set priority/estimate accordingly so it doesn't stall in Backlog.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3776"
    },
    "result": {
      "key": "MZCLD-3776",
      "summary": "People-MCP: provide agents with limited, protected access to the Mozilla employee directory",
      "status": "Backlog",
      "description_text": "Problem Agents have no sanctioned way to read the Mozilla employee directory. The current default is every person telling their agent to write a script that traverses people.mozilla.org \u2014 duplicated effort, no access control, and no way to reason about what directory data agents are consuming. Goal Have some way to allow agents to provide limited/protected access to an employee directory without everyone telling their agents to write a script that traverses people.mozilla.org. Candidate solutions (none chosen yet) (a) A Confluence page explaining how people/agents can use the directory data already in BigQuery (b) A feature within IAM that IT supplies (c) Deliver a People API MCP that the company can use \u2014 consider building it on Runlayer ( MZCLD-3711 ) or Google Agent Platform ( MZCLD-3703 ) Picking between these is part of the epic, not a precondition for it. Option (a) may be sufficient and is by far the cheapest; the epic should not assume we are building an MCP server. Prior art MZCLD-3564  \u2014 people-mcp prototype built during the MozCloud Work Week in Seattle (2026-07-22 to 07-24). Reparented under this epic. Out of scope Building the general agent platform itself (MZCLD-3703, MZCLD-3711, MZCLD-3724) \u2014 this epic consumes whatever paved path those establish rather than defining it.",
      "comment_count": 0,
      "comments": []
    }
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3564"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3564"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3711"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3711"
      }
    },
    "blocked": true
  },
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3703"
    },
    "result": {
      "error": "read blocked by policy: resource not in run subject",
      "args": {
        "key": "MZCLD-3703"
      }
    },
    "blocked": true
  }
]

log