fsryanorg commented

(Migrated from codeberg.org)

Perhaps I'm asking for something that is not part of the design--so please forgive me if I'm asking for something that is out of scope. It seems like the means of authenticating with forgejo should be from the one making the tool call rather than the MCP server. This seems to be how it works with stdio. Is it not possible to do that with HTTP/SSE?

The reason I'm asking is that my use case is to use forgejo-mcp as a central MCP server for several agents and/or the coding assistants of my devs--not just a singular coding assistant. I need these agents to have different levels of access to entities of different organizations. While I understand that I will have to make tokens for each persona, I don't want to have to run an MCP-sidecar process for each of them in order to ensure proper access.

What do you recommend that I do?

Perhaps I'm asking for something that is not part of the design--so please forgive me if I'm asking for something that is out of scope. It seems like the means of authenticating with forgejo should be from the one making the tool call rather than the MCP server. This seems to be how it works with stdio. Is it not possible to do that with HTTP/SSE? The reason I'm asking is that my use case is to use forgejo-mcp as a central MCP server for several agents and/or the coding assistants of my devs--not just a singular coding assistant. I need these agents to have different levels of access to entities of different organizations. While I understand that I will have to make tokens for each persona, I don't want to have to run an MCP-sidecar process for each of them in order to ensure proper access. What do you recommend that I do?

byteflavour commented

2026-05-24 01:26:01 +00:00

(Migrated from codeberg.org)

Mhm ... did u try it? I am not sure if it works but did u try to to run the server like described ...

forgejo-mcp --transport http --url https://your-forgejo-instance.org --token <your-token>

but without the token?

forgejo-mcp --transport http --url https://your-forgejo-instance.org

I was asuming the whole time this works and the credentials can be part of the request?! Currently i don't use it that but i thought thats the way it would work ...

Mhm ... did u try it? I am not sure if it works but did u try to to run the server like described ... ```bash forgejo-mcp --transport http --url https://your-forgejo-instance.org --token <your-token> ``` but without the token? ``` forgejo-mcp --transport http --url https://your-forgejo-instance.org ``` I was asuming the whole time this works and the credentials can be part of the request?! Currently i don't use it that but i thought thats the way it would work ...

byteflavour commented

2026-05-24 03:24:59 +00:00

(Migrated from codeberg.org)

I checked it ... u r right. it's not the way forgejo-mcp currently works. I have addressed the problem in pr #138.

fsryanorg commented

2026-05-24 03:30:46 +00:00

(Migrated from codeberg.org)

I think I may not have explained my usecase--or maybe I don't understand. So I'll try to be more specific about what I'm asking for and what my present understanding is.

My present understanding

The token allows the client to access the entities it needs to have access to and none that it does not. Thus, I have two options:

Use an instance of forgejo-mcp as a client sidedar so that the clients my use their individual token, or
Configure a centralized server Use an extremely permissive token that provides access to basically everything and then impose access control external to the MCP server.

My use case

Both of the above approaches are not ideal for my use case. The MCP server needs to be a centralized MCP server that many clients can access, but each client needs to have a limited subset of access, as in the topology below (using HTTP transport)

-----------
| client 1 | ------
-----------        |
                   |
-----------        |      -------------            ---------
| client 2  | -------->  | forgejo-mcp | -------> | forgejo |
-----------        |      -------------            ---------
                   |
-----------        |
| client 3  | -----
-----------

.... And probably several more clients that spin up and down dynamically ....

Is it more clear what I'm asking for now? Am I just wrong in my understanding of how forgejo-mcp works? In any case, it was pretty clear to me, via the existing documentation, that my usecase was not supported.

I think I may not have explained my usecase--or maybe I don't understand. So I'll try to be more specific about what I'm asking for and what my present understanding is. # My present understanding The token allows the client to access the entities it needs to have access to and none that it does not. Thus, I have two options: 1. Use an instance of forgejo-mcp as a client sidedar so that the clients my use their individual token, or 2. Configure a centralized server Use an extremely permissive token that provides access to basically everything and then impose access control external to the MCP server. # My use case Both of the above approaches are not ideal for my use case. The MCP server needs to be a centralized MCP server that many clients can access, but each client needs to have a limited subset of access, as in the topology below (using HTTP transport) ``` ----------- | client 1 | ------ ----------- | | ----------- | ------------- --------- | client 2 | --------> | forgejo-mcp | -------> | forgejo | ----------- | ------------- --------- | ----------- | | client 3 | ----- ----------- ``` .... And probably several more clients that spin up and down dynamically .... Is it more clear what I'm asking for now? Am I just wrong in my understanding of how forgejo-mcp works? In any case, it was pretty clear to me, via the existing documentation, that my usecase was not supported.

byteflavour commented

2026-05-24 03:37:06 +00:00

(Migrated from codeberg.org)

yep, i think i got that. check pr #138. Addresses this the common need for a mcp working actually as a distributed service @fsryanorg?

byteflavour commented

2026-05-24 03:41:17 +00:00

(Migrated from codeberg.org)

This is exactly what PR #138 enables. With that change, you can run a single centralized forgejo-mcp instance and each client provides its own token via the standard HTTP Authorization header.

How it works with PR #138

1. Start the server (optionally without any global token):

# No token at startup required
forgejo-mcp --transport http --url https://codeberg.org

2. Client 1 makes a request with their specific token:

# Client 1 identifies as 'User A'
curl -X POST http://mcp-server:8080/mcp \
  -H "Authorization: token <TOKEN_USER_A>" \
  -H "Mcp-Session-Id: <SESSION_ID>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": { "name": "get_my_user_info", "arguments": {} }
  }'

3. Client 2 makes a request in the same session (or a different one) with their token:

# Client 2 identifies as 'User B'
curl -X POST http://mcp-server:8080/mcp \
  -H "Authorization: token <TOKEN_USER_B>" \
  -H "Mcp-Session-Id: <SESSION_ID>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": { "name": "get_my_user_info", "arguments": {} }
  }'

The server extracts the token from the header for every individual request, creating a short-lived Forgejo client scoped specifically to that request/identity. This keeps the server completely stateless regarding authentication, perfectly supporting your distributed service topology.

This is exactly what PR #138 enables. With that change, you can run a single centralized `forgejo-mcp` instance and each client provides its own token via the standard HTTP `Authorization` header. ### How it works with PR #138 **1. Start the server (optionally without any global token):** ```bash # No token at startup required forgejo-mcp --transport http --url https://codeberg.org ``` **2. Client 1 makes a request with their specific token:** ```bash # Client 1 identifies as 'User A' curl -X POST http://mcp-server:8080/mcp \ -H "Authorization: token <TOKEN_USER_A>" \ -H "Mcp-Session-Id: <SESSION_ID>" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_my_user_info", "arguments": {} } }' ``` **3. Client 2 makes a request in the same session (or a different one) with their token:** ```bash # Client 2 identifies as 'User B' curl -X POST http://mcp-server:8080/mcp \ -H "Authorization: token <TOKEN_USER_B>" \ -H "Mcp-Session-Id: <SESSION_ID>" \ -d '{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_my_user_info", "arguments": {} } }' ``` The server extracts the token from the header for **every individual request**, creating a short-lived Forgejo client scoped specifically to that request/identity. This keeps the server completely stateless regarding authentication, perfectly supporting your distributed service topology.

fsryanorg commented

2026-05-24 03:43:24 +00:00

(Migrated from codeberg.org)

@byteflavour wrote in https://codeberg.org/goern/forgejo-mcp/issues/137#issuecomment-15749870:

I checked it ... u r right. it's not the way forgejo-mcp currently works. I have addressed the problem in pr #138.

Ah. I didn't see this as I was messing around with the formatting of my beautiful diagram. Thanks. I'll read through that issue.

@byteflavour wrote in https://codeberg.org/goern/forgejo-mcp/issues/137#issuecomment-15749870: > I checked it ... u r right. it's not the way forgejo-mcp currently works. I have addressed the problem in pr #138. Ah. I didn't see this as I was messing around with the formatting of my beautiful diagram. Thanks. I'll read through that issue.

byteflavour commented

2026-05-24 03:47:56 +00:00

(Migrated from codeberg.org)

yeah, your post is great ... my agent also praised the diagram ;)

ah and btw ... #138 isn't a new issue. it's a pull request ... u can check it out and play around with it. i tested it and it works in my lab.

yeah, your post is great ... my agent also praised the diagram ;) ah and btw ... #138 isn't a new issue. it's a pull request ... u can check it out and play around with it. i tested it and it works in my lab.

goern commented

2026-05-24 06:08:42 +00:00

(Migrated from codeberg.org)

woke up to this thread — love it ❤️

@fsryanorg thanks for the crisp use case and that diagram — it carried the point. exactly the topology i want forgejo-mcp to support.

@byteflavour respect. diagnosing the gap and shipping PR #138 in the same morning is what open source should feel like. reviewing it now.

community over centralization 🔥

woke up to this thread — love it ❤️ @fsryanorg thanks for the crisp use case and that diagram — it carried the point. exactly the topology i want forgejo-mcp to support. @byteflavour respect. diagnosing the gap and shipping PR #138 in the same morning is what open source should feel like. reviewing it now. community over centralization 🔥

goern commented

2026-05-25 13:55:18 +00:00

(Migrated from codeberg.org)

please give https://codeberg.org/goern/forgejo-mcp/releases/tag/v2.24.2 a try

Rows
Columns

Client-side token specification support? #137

My present understanding

My use case

How it works with PR #138