Make package publishing job runs contingent upon changes existing

[cliffhall]

Description

In release.yml

• In the publish-pypi job,

  • only run if there are Python packages to publish

• In the publish-npm job,

  • only run if there are Typescript packages to publish

Motivation and Context

Multiple attempts to approve a release have failed.

The process includes gathering the metadata about the release, simultaneously publishing both Python (pypi) and Typescript (npm) packages that may be in the release, and then finishing up with a final step that creates the actual release description and downloadable artifacts on the repo itself.

The Typescript packages appear to have been published:

However, it appears we had no Python packages to publish this time around, and an assumption in the release.yml that there would always be changes in both has brought that fork of the publish process to a halt. And therefore, the next step of finalizing the release has not been run.

How Has This Been Tested?

This is a speculative fix since I cannot actually publish the packages myself.

Breaking Changes

Nope.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options