chore: add MCP registry server.json

[bdshadow]

Publishes the Tolgee MCP server to the official MCP Registry (https://registry.modelcontextprotocol.io) as a remote server entry pointing at https://app.tolgee.io/mcp/developer, authenticated via an X-API-Key header (PAT or PAK).

Summary by CodeRabbit

• Chores

  • Added a server configuration to enable Tolgee MCP integration, providing authenticated streamable HTTP connectivity (requires an API key header) for remote access.

• Documentation

  • Added a new guide explaining the MCP registry entry, required configuration fields, publish workflow, and prerequisites for publishing new server versions.

[coderabbitai]

📝 Walkthrough

Walkthrough

Added an MCP server manifest (server.json), documentation, and .gitignore entries to publish Tolgee as a remote MCP server with a streamable-http remote requiring an X-API-Key header.

Changes

Cohort / File(s)	Summary
MCP Server Configuration server.json	New MCP server manifest for io.github.tolgee/tolgee: schema, name/title/description, websiteUrl, repository info, version: 1.0.0, and a remotes entry using streamable-http at https://app.tolgee.io/mcp/developer requiring X-API-Key.
Documentation docs/mcp-server/README.md	New README describing the MCP server entry, publication workflow (mcp-publisher validate/login/publish), schema reference, and GitHub org membership prerequisite.
Repository ignores /.gitignore	Added entries to ignore publisher auth tokens: /.mcpregistry_github_token, /.mcpregistry_registry_token.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested reviewers

• JanCizmar
• dkrizan

Poem

🐰 I hop with a manifest, neat and spry,

A server declared beneath the sky.
Remotes and keys in tidy array,
Tolgee's ready to publish today. 🥕✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title says 'chore: add MCP registry server.json' but the PR is actually adding MCP server registry support and publishing infrastructure, which is a feature addition, not routine maintenance.	Consider whether this should be 'feat:' instead of 'chore:' since it adds new MCP registry publishing capability. If 'chore:' is intentional, the change type classification should align with the actual scope and impact.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch bdshadow/publish-mcp-to-registry

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

server.json (1)

12-12: Keep manifest version synchronized with runtime MCP version.

Line 12 hardcodes "version": "1.0.0", but runtime MCP server info is sourced from VersionProvider (backend/app/src/main/kotlin/io/tolgee/mcp/McpConfig.kt:26-31). If these drift, registry metadata becomes stale. Consider tying this field to the release pipeline or documenting a required manual bump step.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server.json` at line 12, The manifest currently hardcodes "version": "1.0.0"
which can drift from the runtime MCP version provided by
VersionProvider/McpConfig; update the build so server.json's version is produced
at release-time from the same source as VersionProvider (e.g., inject the MCP
version into server.json as a build artifact or generate server.json from a
template during CI/CD), or alternatively add a clear release-note step that
documents manually bumping server.json whenever McpConfig's MCP version
changes—ensure the symbol VersionProvider (or the MCP_VERSION constant in
McpConfig) is the canonical source and wire the pipeline/template to read it and
replace the manifest entry.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@server.json`:
- Line 12: The manifest currently hardcodes "version": "1.0.0" which can drift
from the runtime MCP version provided by VersionProvider/McpConfig; update the
build so server.json's version is produced at release-time from the same source
as VersionProvider (e.g., inject the MCP version into server.json as a build
artifact or generate server.json from a template during CI/CD), or alternatively
add a clear release-note step that documents manually bumping server.json
whenever McpConfig's MCP version changes—ensure the symbol VersionProvider (or
the MCP_VERSION constant in McpConfig) is the canonical source and wire the
pipeline/template to read it and replace the manifest entry.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 394291e9-b07b-45e1-88f6-b4a0bbff87d8

📥 Commits

Reviewing files that changed from the base of the PR and between 050fd3d and ce23250.

📒 Files selected for processing (1)

• server.json