-
Notifications
You must be signed in to change notification settings - Fork 302
Update build pipeline to support server.json #1104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds support for publishing MCP server metadata to the official MCP repository registry. The changes introduce server.json files containing package metadata, update build scripts to use these files, and add deployment infrastructure.
- Adds server.json files for Azure and Fabric MCP servers with registry metadata
- Refactors packaging scripts to copy existing server.json files instead of generating them dynamically
- Implements Deploy-ServerJson.ps1 script for publishing to the MCP registry
- Updates version management to synchronize server.json versions with package versions
Reviewed Changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| servers/Fabric.Mcp.Server/src/Fabric.Mcp.Server.csproj | Adds ServerJsonPath and commented McpRepositoryName properties for Fabric server |
| servers/Fabric.Mcp.Server/server.json | New server metadata file with placeholder values for description and package identifier |
| servers/Azure.Mcp.Server/src/Azure.Mcp.Server.csproj | Adds ServerJsonPath and McpRepositoryName properties for Azure server |
| servers/Azure.Mcp.Server/server.json | New server metadata file with complete Azure MCP server configuration for NuGet and npm packages |
| servers/Azure.Mcp.Server/README.md | Adds MCPRepositoryMetadata insertion point for package processing |
| eng/scripts/Update-Version.ps1 | Extends version update logic to synchronize versions in server.json files |
| eng/scripts/Pack-Nuget.ps1 | Replaces dynamic server.json generation with file copy, adds MCPRepositoryMetadata to README processing |
| eng/scripts/Pack-Npm.ps1 | Adds mcpName field to npm package.json from server properties |
| eng/scripts/Get-ProjectProperties.ps1 | Adds ServerJsonPath and McpRepositoryName to list of extracted project properties |
| eng/scripts/Deploy-ServerJson.ps1 | New script implementing MCP registry authentication and publication using Azure Key Vault and Go-based publisher tool |
| eng/pipelines/templates/jobs/update-mcp-repository.yml | New pipeline job template for building MCP publisher and updating registry |
| eng/pipelines/templates/jobs/release.yml | Integrates MCP repository update job into release pipeline |
| -TemporaryDirectory '$(Pipeline.TemporaryDirectory)' | ||
| -ReleaseType '${{ parameters.ReleaseType }}' | ||
| -KeyVaultName 'kv-azuresdk-codesign' | ||
| -KeyVaultKeyName '' |
Copilot
AI
Nov 6, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The KeyVaultKeyName parameter is set to an empty string. This is required for the Azure Key Vault authentication in the Deploy-ServerJson.ps1 script and should be set to a valid key name.
|
@joelverhagen PTAL too thanks |
| <PackageIcon>$(MSBuildThisFileDirectory)../azureicon.png</PackageIcon> | ||
|
|
||
| <!-- Official MCP repository settings --> | ||
| <McpRepositoryName>com.microsoft/azure-mcp</McpRepositoryName> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| <McpRepositoryName>com.microsoft/azure-mcp</McpRepositoryName> | |
| <McpRepositoryName>com.microsoft/azure</McpRepositoryName> |
I would argue mcp is redundant in this context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@joshfree I have no opinions. If the wider team is OK with this name... the shorter the better. :D
servers/Azure.Mcp.Server/server.json
Outdated
| "$schema": "https://static.modelcontextprotocol.io/schemas/2025-10-17/server.schema.json", | ||
| "name": "com.microsoft/azure-mcp", | ||
| "description": "All Azure MCP tools to create a seamless connection between AI agents and Azure services.", | ||
| "version": "2.0.0-beta.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want icons? Probably yes, for parity with the existing.
It might be worth checking with Toby on how these icon URLs will be used for GitHub MCP Registry (direct linked, replicated, etc).
See modelcontextprotocol/registry#277 (comment) for issues...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could supply icon in a future release, if you want to move fast.
servers/Azure.Mcp.Server/server.json
Outdated
| { | ||
| "registryType": "nuget", | ||
| "identifier": "Azure.Mcp", | ||
| "version": "2.0.0-beta.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think it would be worth putting explicit placeholder values here? So is someone wonders "hmm ... this looks old" they will rest assured something else will fix it up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. We could have placeholder values
2613183 to
9cb4b8b
Compare
|
@chidozieononiwu, can you check the server.json content to make sure it's correct for npx packaging? |
|
Can you update |
9036a2b to
48b9c51
Compare
…tegration to push to staging
| -BuildInfoPath '$(Pipeline.Workspace)/build_info/build_info.json' | ||
| -NpmRegistry '${{ parameters.NpmRegistry }}' | ||
| - template: /eng/pipelines/templates/jobs/update-mcp-repository.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean we'll be publishing prerelease updates to the official registry pointing to internal/public package feeds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Integration in this repo should have been called "Release Unofficial" or "Release Internal". It doesn't do the same jobs as Integration in the sdk repos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh makes sense. I realise that staging.mcp. only performs the check against the official NuGet.org repo.. so it doesn't make sense since we don't host our own internal mcp repo. Let me remove this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nm. I see the staging repo work in Deploy-ServerJson.ps1
| Write-Host "Installing Microsoft Go and building MCP publishing tool..." | ||
|
|
||
| # This go-install.ps1 script could be checked into your source repository | ||
| $goInstallScriptPath = "$PSScriptRoot/Install-Go.ps1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've opened an issue to see if all of this is really necessary. I suspect the publisher tool is just making an authenticated API call with either a token minted using our private key or with a body signed using our key. Either way, it could be all powershell with no git clone in the middle of a deployment step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #1256
|
|
||
| <# | ||
| .SYNOPSIS | ||
| Verifies the NuGet package for the specified server is available on nuget.org. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any chance dotnet package search --exact-match would handle this for us reliably?
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-package-search
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach was documented because it checks the same artifact (embedded package README) that the MCP Registry uses. dotnet package search --exact-match checks the NuGet.org package metadata endpoint. There is certainly a relationship between these two things (NuGet.org publishes README strictly before search availability) but for a general purpose script it helps avoid false positives when a package has forgotten to embed the README.
It is not a bad suggestion, I'm just providing the context.
| <Description>Azure MCP Server - Model Context Protocol implementation for Azure</Description> | ||
| <ReadmeUrl>https://github.com/Microsoft/mcp/blob/main/servers/Azure.Mcp.Server#readme</ReadmeUrl> | ||
| <ReadmePath>$(RepoRoot)/servers/Azure.Mcp.Server/README.md</ReadmePath> | ||
| <ServerJsonPath>servers/Azure.Mcp.Server/server.json</ServerJsonPath> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The paths should be absolute.
maybe
| <ServerJsonPath>servers/Azure.Mcp.Server/server.json</ServerJsonPath> | |
| <ServerJsonPath>$(RepoRoot)servers/Azure.Mcp.Server/server.json</ServerJsonPath> |
or
| <ServerJsonPath>servers/Azure.Mcp.Server/server.json</ServerJsonPath> | |
| <ServerJsonPath>$(MSBuildThisFileDirectory)server.json</ServerJsonPath> |
| "title": "Azure MCP Server", | ||
| "packages": [ | ||
| { | ||
| "registryType": "nuget", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this whole section be inject and not just the version. Otherwise, there's the possibility of conflict between the package name we see here and the one in the server's csproj
What does this PR do?
GitHub issue number?
[Link to the GitHub issue this PR addresses]Pre-merge Checklist
servers/Azure.Mcp.Server/CHANGELOG.mdand/orservers/Fabric.Mcp.Server/CHANGELOG.mdfor product changes (features, bug fixes, UI/UX, updated dependencies)servers/Azure.Mcp.Server/README.mdand/orservers/Fabric.Mcp.Server/README.mddocumentationeng/scripts/Process-PackageReadMe.ps1. See Package README/servers/Azure.Mcp.Server/docs/azmcp-commands.mdand/or/docs/fabric-commands.md.\eng\scripts\Update-AzCommandsMetadata.ps1to update tool metadata in azmcp-commands.md (required for CI)ToolDescriptionEvaluatorand obtained a score of0.4or more and a top 3 ranking for all related test prompts/servers/Azure.Mcp.Server/docs/e2eTestPrompts.mdcrypto mining, spam, data exfiltration, etc.)/azp run mcp - pullrequest - liveto run Live Test Pipeline