Altinity / Altinity/altinity-mcp
Split Altinity Cloud MCP gateway from local altinity-mcp
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 38
- Forks
- 8
- Avg merge
- 6d 14h
- Merged PRs (30d)
- 8
Description
The existing altinity-mcp binary serves local/single-cluster use cases: stdio, single ClickHouse target, and legacy HTTP/JWE/OpenAPI behavior.
Altinity Cloud needs a narrower gateway binary:
- HTTP streamable transport only
- OAuth required
- no stdio/SSE
- no JWE token routing
- no OpenAPI
- multicluster routing via
/mcp/{cluster} - per-token/per-cluster dynamic tool catalog cache
This avoids adding many mutually exclusive runtime modes to the current binary and keeps local usage stable.
Possibly, we need to strip the OAuth functionality from "non-cloud" binary, too.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the existing altinity-mcp binary's stdio, single-ClickHouse, legacy HTTP/JWE/OpenAPI, and SSE paths, then identify the entry points for HTTP streamable transport and OAuth. Define the separate cloud gateway around /mcp/{cluster}, with per-token/per-cluster dynamic tool catalog caching; done when the cloud and local binaries preserve their stated mode boundaries and multicluster routing works.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- clickhouse, go
- Domain
- api, authentication, cloud, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100