Skip to content

Add Magic Hour MCP server - #21

Open
runshouse wants to merge 2 commits into
openmodelsrun:mainfrom
runshouse:codex/add-magic-hour-mcp
Open

Add Magic Hour MCP server#21
runshouse wants to merge 2 commits into
openmodelsrun:mainfrom
runshouse:codex/add-magic-hour-mcp

Conversation

@runshouse

Copy link
Copy Markdown

Summary

  • add the official Magic Hour hosted MCP server
  • document its verified 44-tool video, image, and audio capability set
  • include the public repository, Streamable HTTP endpoint, authentication requirement, and discovery tags

Verification

  • completed a public MCP handshake against https://mcp.magichour.ai/
  • verified tools/list returns 44 tools
  • ran python validate.py: 209 files passed

@madeburo

madeburo commented Sep 1, 2026

Copy link
Copy Markdown
Member

hi @runshouse

Thanks for the submission. I verified that the registry validation passes, the hosted endpoint completes the MCP handshake, and tools/list currently returns 44 tools.

Before merging, please address the following:

  1. Add a tested install or machine-readable connection configuration. The endpoint currently appears only in the description, and MAGIC_HOUR_API_KEY is declared without any configuration that passes it as an Authorization: Bearer ... header. An OAuth-based mcp-remote configuration would also be acceptable if tested against the hosted endpoint.

  2. Clarify the authentication boundary. An unauthenticated call to ping also returns Authentication required, so authentication is required for every tool call, not only generation and editing operations. Tool discovery alone is public.

  3. Include the actual tool definitions and input schemas from the live tools/list response. The submission claims 44 verified tools but does not expose any of them through the registry metadata.

  4. Please disclose that some tools create or delete projects and that generation operations may immediately consume Magic Hour credits.

The service itself appears legitimate and reachable, but the current entry does not yet provide a complete or reproducible integration.

@runshouse

Copy link
Copy Markdown
Author

Addressed all four points in a4b3234:

  1. Added a machine-readable mcp-remote install config that sends MAGIC_HOUR_API_KEY as the Authorization Bearer token. I tested the exact command against https://mcp.magichour.ai/; MCP initialize and tools/list succeeded.
  2. Clarified that discovery is public but every tool call requires authentication, including ping and project/status helpers.
  3. Added all 44 live tool definitions in live order, with input schemas matched against the current tools/list response. Descriptions are included within this registry's 1,000-character schema limit.
  4. Added explicit disclosure that tools can create/delete projects and generation requests may consume credits immediately.

python validate.py passes all 209 registry files.

@madeburo

madeburo commented Sep 1, 2026

Copy link
Copy Markdown
Member

@runshouse

rechecked commit a4b3234. One security blocker surfaced after reviewing the complete tool inventory. The hosted upload_file_to_presigned_url helper accepts both a server-local file path and a caller-provided destination URL. For a public hosted endpoint, this needs documented and tested restrictions on readable paths, allowed destination hosts, and redirects—or the helper should be available only in local deployments.

Please address this in the hosted Magic Hour MCP implementation, not only by removing the tool from the registry metadata. I recommend coordinating any implementation details privately with the Magic Hour maintainers. Once the live tool surface is secured and the registry entry is refreshed, I’ll be happy to re-review

@runshouse

runshouse commented Sep 1, 2026

Copy link
Copy Markdown
Author

Thanks for catching this. I addressed it in the hosted Magic Hour MCP implementation, not just the registry metadata: magichourhq/magic-hour-mcp#57

The fix removes upload_file_to_presigned_url from the MCP tool registry and deletes the server-filesystem reader/uploader implementation entirely. The supported flow is now only: mint a presigned URL, then have the caller or a dedicated upload bridge send the bytes. A regression test asserts that the local-filesystem helper is not exposed.

Verified against the deployed Vercel preview: MCP initialize succeeds and tools/list returns 43 tools with upload_file_to_presigned_url absent. Production still reports the previous 44-tool inventory until this fix is merged and deployed.

I am intentionally leaving this registry PR unchanged until the production implementation is secured; after the live hosted tools/list reports the 43-tool surface, I will refresh the registry entry and post the production verification here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants