Expose APIView functionality to tools/mcp agents

[AlitzelMendez]

Issue: #10413

This PR implements APIView functionality exposure through both MCP tools and CLI commands, enabling conversational AI and command-line access to APIView services.

What's Exposed

MCP Tool (for AI agents)

• azsdk_apiview_get_comments - Get comments for a specific APIView revision using an APIView URL

CLI Commands (for command-line users)

Both commands are under the `apiview` command group:

apiview get-comments

• Get comments for a specific APIView revision
• Options: `--url` (APIView URL), `--environment` (production/staging/local)
• Example: `azsdk apiview get-comments --url "https://apiview.dev/review/123?activeApiRevisionId=abc\" --environment staging`

apiview get-content

• Get revision content (token file data) for debugging purposes
• Options: `--url` (APIView URL), `--environment`, `--output-file`, `--content-return-type` (text/codefile)
• Example: `azsdk apiview get-content --url "https://apiview.dev/review/123?activeApiRevisionId=abc\" --output-file output.txt`

Why get-content is CLI-only

The get-content command returns large token files (API surface representation data) which can be hundreds of KB in size. This is useful for debugging APIView issues but not practical for conversational AI interactions due to token/context limitations. Therefore, it's intentionally excluded from MCP tools.

[Copilot]

Pull Request Overview

This PR implements APIView functionality exposure through both MCP (Model Context Protocol) tools and CLI commands, allowing conversational AI and command-line access to APIView services. The implementation provides authentication management, HTTP service abstraction, and structured response handling for APIView operations.

• Adds MCP tools for getting comments, listing review versions, and checking authentication status
• Creates CLI commands for revision content retrieval with optional diff functionality
• Implements comprehensive authentication service supporting GitHub tokens and Azure credentials

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
APIViewTool.cs	Main tool class implementing both MCP and CLI interfaces for APIView operations
ServiceRegistrations.cs	Registers new APIView services in dependency injection container
APIViewService.cs	Core service orchestrating APIView operations and data retrieval
APIViewHttpService.cs	HTTP client service handling authenticated requests to APIView endpoints
APIViewConfiguration.cs	Configuration constants for APIView environments and authentication scopes
APIViewAuthenticationService.cs	Authentication service supporting GitHub tokens and Azure credentials
APIViewResponse.cs	Response model for APIView operations with success/error handling
SharedOptions.cs	Adds APIViewTool to registered tools list
SharedCommandGroups.cs	Defines APIView command group for CLI organization
ReviewListModels.cs	Adds RevisionResponseModel for structured revision data
ReviewsHybridAuthController.cs	New controller supporting both token and cookie authentication
ReviewsController.cs	Refactors existing controller by moving content endpoint to hybrid auth controller
APIRevisionsTokenAuthController.cs	Adds endpoint for retrieving review versions with filtering

[tjprescott]

One topic mentioned in the original issue but not addressed here is diff functionality. I want to discuss what we should return for diffs, as we'll probably need a new endpoint. I've split that effort into a separate task.

Yes, for the PR, I think it's sufficient to expose getComments.

[tjprescott]

Left some comments on the APIView API side. I'll defer to @praveenkuttappan on the MCP-specific parts.

[maririos]

I am a little concern with the structure of the PR where you are modifying 2 tools, that have a dependency and get released on different timelines and infrastructure.

I would prefer to have the APIView changes in it's own PR so you can merge and test on staging, and have a PR for the mcp, so when APIView is deployed to prod, you can merge the PR.
Otherwise the mcp will be broken until the deployment of APIView

[AlitzelMendez]

I am a little concern with the structure of the PR where you are modifying 2 tools, that have a dependency and get released on different timelines and infrastructure.

I would prefer to have the APIView changes in it's own PR so you can merge and test on staging, and have a PR for the mcp, so when APIView is deployed to prod, you can merge the PR. Otherwise the mcp will be broken until the deployment of APIView

oh this makes sense, let me explit the pr :)