[Feature Request] Owner Type Abstraction and Discovery for ProjectV2 Tools

[joaodotwork]

Description

Current ProjectV2 tools (e.g., list_projects, list_project_fields) require an explicit owner_type (either user or org). This creates significant friction for autonomous agents and users managing mixed personal and organization-owned projects.

The Problem

When an agent tries to audit metadata across projects, it is currently forced into a trial-and-error pattern. For example, calling list_projects with owner_type: org returns a 404 if the handle belongs to a user, requiring the agent to "backwards-associate" the infrastructure and try again with user.

For users with large numbers of repositories and complex project histories, this strict requirement to specify owner type before discovery is counter-intuitive. If the agent has the necessary permissions, it should be able to resolve the owner type or search across both scopes automatically.

Proposed Improvement

1. Owner Type Abstraction: Make owner_type optional. The server should be able to determine if a handle is a user or an organization automatically.
2. Unified Discovery: Provide a tool to list all accessible ProjectV2 projects for the authenticated user, regardless of whether they are personal or organizational.
3. Contextual Intelligence: If a project URL or Project Number is provided, the server should be able to infer the owner context rather than requiring the caller to manually bridge that gap.

Agent Affinities & Interface Guidelines

The friction encountered varies by the agent's 'personality' and underlying model architecture:

• Gemini (Technical Deep-Dive): In our recent session, Gemini was able to bypass rigid/blocked 'list' tools by pivoting entirely to a custom GraphQL workflow. It 'unlocked' a legacy project audit by treating the API as a queryable graph rather than a set of fixed commands.
• Claude (Intent & Orchestration): Models like Claude often excel when the mapping between user intent and tool execution is transparent. When tools require internal infrastructure knowledge (like specific GitHub Owner Types), it can cause the agent to hesitate or over-prompt the user, breaking the 'flow' of autonomous development.
• The Goal: The GitHub MCP should serve as a high-level abstraction that bridges these model behaviors. By abstracting 'Owner Type' and providing better discovery, we enable Gemini to be more precise and Claude to be more autonomous without requiring either to understand the user's internal account configuration beforehand.

Rationale

The value of an MCP is to enable fluid, agentic workflows. Forcing a developer to manually define the "infrastructure scope" for a basic listing operation limits the server's effectiveness. Developers who are not operating as an organization shouldn't be forced into organizational patterns just to access metadata tools.

[SamMorrowDrums]

Thanks for this report @joaodotwork I am inclined to agree, we have been discussing a bunch of changes we'd like to make to projects tools internally and ill add this feedback to the conversation.

[SamMorrowDrums]

This also came up #1745