#general
👋 Hey team, I'm Alexander. I'll be working on https://github.com/archestra-ai/archestra/issues/3790 . Just wanted to drop a comment to another person that the issue is reserved for the interviews, but then Matvey dropped a comment. Thank you!
👋1
9 replies
Hey, team 👋 my name is Vadim, I'd like to work on an Asana knowledge connector. Opened https://github.com/archestra-ai/archestra/issues/3885 with a design question I'd like to align on before finalizing
Hi @user,
I am an external contributor. I saw issue #3851 and built the unified endpoint. Wanted to share what I did and ask if I can submit a PR.
What I built:
New files:
src/routes/proxy/routes/unified.ts — the main route handlersrc/routes/proxy/adapters/unified-translation.ts — the translation layerHow it works:
• The
/v1/unified/chat/completions endpoint receives a standard OpenAI format request. It reads the model field, looks it up in the existing model registry to find which provider owns it (anthropic, openai, gemini, groq, cohere etc.), then delegates to that provider's existing adapter. The response is translated back to OpenAI format before sending to the client.• For providers that are already OpenAI-compatible (OpenAI, Groq, Mistral) , no translation needed, just pass through.
• For providers with different formats (Anthropic, Gemini, Cohere) — I wrote translation functions (
oaiToAnthropic, oaiToGemini, oaiToCohere) and a NativeWrapperStreamAdapter that handles streaming for translated providers.•
GET /v1/unified/models — queries the existing model registry and returns all models from all providers in standard OpenAI list format. This is needed so n8n can discover available models.What is preserved:
• All existing features go through the same
handleLLMProxy pipeline — virtual • keys, auth middleware, security policies engine, TOON compression, MCP tools, nothing is bypassed.
Routes registered in server.ts:
•
GET /v1/unified/models•
POST /v1/unified/chat/completions•
POST /v1/unified/:agentId/chat/completionsStatus:
• Code is done and tested locally
• Demo video with n8n is pending (will record once I confirm I can submit)
Can external contributors work on this? The label says "only for core team"
so just want to check before I spend time on the video and PR.
Thank you!
Read-only live mirror of Archestra.AI Slack
👋Join the discussion withAI enthusiasts!👋 Hey team, I'm Alexander. I'll be working on https://github.com/archestra-ai/archestra/issues/3790 . Just wanted to drop a comment to another person that the issue is reserved for the interviews, but then Matvey dropped a comment. Thank you!
👋1
9 replies
@user hey, this how I plan to design it visually
1. Card, example of
Organizarion scope connection badge2. Initial connect dialog with updated Scope selector including
Organizarion3. Team selection still works as before
4. Connections list: "Shared" renamed to "Team",
Organization block added5. Empty state for the
Organization block
Hi, thanks for reaching! UI makes sense to me, small questions:
1. How "Organization" chip should it look like when MCP has both org-wide and personal installation? Also Organization icon on the scope card is not matching the icon on the MCP Server card. Do we really need it? Maybe use org-logo instead 🤔
2. Should we really split "Shared connections" here on teams and "organization"
Current UI is not ideal though, feel free to propose any changes to make it simpler and better.
How "Organization" chip should it look like when MCP has both org-wide and personal installation?
all of them (see screenshot). Org, personal, teams
Also Organization icon on the scope card is not matching the icon on the MCP Server card. Do we really need it?
by mistake, will make it consistent
Should we really split "Shared connections" here on teams and "organization"
Agreed, I can add "Add to organization" button along with "Add to team" and keep the "Shared connections" block mostly as is (show TeamName or "Oragnization" in the Owner column)
👍1
PR is ready for review https://github.com/archestra-ai/archestra/pull/3933
👀1
BTW while working on the issue I noticed the group labels on the MCP Registry index page are misleading — and so are the variable names in the code.
In
InternalMCPCatalog.tsx, items are split into two sections based on scope: (item) => item.scope === "personal",
);
const publishedItems = allFilteredItems.filter(
(item) => item.scope !== "personal",
);```
These render under headings `Unpublished` and `Published`. The problem is that this implies a lifecycle — a personal connection looks like a draft waiting to be promoted. In reality `scope === "personal"` is a permanent access boundary, not a transient state. A user could reasonably ask "how do I publish this?" and there's no answer.
Would it be ok to rename these to reflect what the distinction actually is (access scope)?
`draftItems` → `personalItems`,
`publishedItems` → `sharedItems`,
headings:
`Unpublished` → `Personal`
`Published` → `Shared`
Pure rename, no behavior change. Also, that would be similar to *Connections* tab wordings.
The code was added here <https://github.com/archestra-ai/archestra/pull/3180/changes#diff-dda8f6bec4ed047f79cc8f7b815b10028c5a3e3f3c09e6d1bc63e436ae2e6e8eR968> by <@U0975SLALTT>Created a PR to fix that https://github.com/archestra-ai/archestra/pull/4057
❤️1:pr-merged:1:archestra-love:1