Populars: Dades actualitzades el 27 d’octubre del 2026

Categories

Internet1.356
Comunicació321
Àudio i vídeo898
Gràfics i disseny539
Ofimàtica i productivitat1.124
Eines per a desenvolupadors3.134
Eines d’IA529
Seguretat i privadesa385
Eines del sistema3.114
Jocs523
Educació i ciència239
Xarxa i TI284

Baixar GitLab MCP Server 2.7.4 per a Windows

GitLab MCP server exposing the REST v4 and GraphQL APIs as tools for AI assistants.

Aquesta és una versió anterior. La versió actual és la 3.3.0. GitLab MCP Server 3.3.0 · Data de publicació:

Fitxers d’instal·lació 2.7.4

ArquitecturaTipusÀmbitMida del fitxerBaixaSHA256
64 bits Portable — — github.com VirusTotal
ARM64 Portable — — github.com VirusTotal

L’enllaç i l’SHA256 provenen del manifest comunitari del Gestor de paquets del Windows. Convé comparar el hash del fitxer baixat abans d’executar-lo.

Notes de la versió

Yes, another release. Sorry. That is four in two days, and I promise there is no grand strategy behind the cadence — just someone finally trying the OAuth mode in anger and discovering it had never authenticated a single human being in its entire life.
In my defence: it looked fine. It had a verifier, a metadata endpoint, a token cache, tests, and documentation. What it did not have was a working request.
OAuth mode never worked. At all. (#309)
--auth-mode=oauth verified your Bearer token correctly, extracted your identity correctly, cached it correctly — and then built the GitLab client that does the actual work with the token in a PRIVATE-TOKEN header. GitLab accepts glpat- there. It does not accept gloas- OAuth access tokens there, in any header but Authorization: Bearer. So every single call after a perfectly successful login came back 401.
Fixed by giving the pool an OAuth-aware constructor (NewAuthSourceClient + a static token source) that it selects when --auth-mode=oauth, and by making the two raw HTTP probes — the version check and the credential-rejection check — pick their scheme from the same decision instead of hardcoding PRIVATE-TOKEN. Verified end-to-end against gitlab.com with a real authorization-code + PKCE flow, which is how it should have been verified the first time.
The same PR stopped assuming scopes. The verifier used to stamp every identity as api-scoped; it now introspects the token's real scopes (/personal_access_tokens/self for PATs, /oauth/token/info for OAuth tokens) and falls back to the old assumption only where introspection is unavailable.
Browser clients were being refused before anyone looked at them (#312)
The cross-origin protection wrapped the handler with no way to configure it, so every cross-origin POST got a 403 from Go's stdlib before MCP dispatched anything. That is correct default behaviour and it stays the default — but "validate the Origin header" is not the same instruction as "reject every origin", and there was no allowlist.
- --trusted-origins — comma-separated absolute origins (scheme://host[:port], an IP is fine for local deployments) allowed to make cross-origin browser requests. Empty by default, so nothing changes for anyone who does not set it. * accepts any origin and logs a warning that the protection is off. A malformed entry fails startup rather than being quietly dropped.
- --public-url's origin is trusted automatically. The flag already declared "the externally reachable origin of this deployment"; now it also behaves like one. It is validated in legacy mode too, since it finally has an effect there.
- A dual-header hole is closed. In OAuth mode the SDK verified the Bearer token, but credential extraction still preferred PRIVATE-TOKEN when both headers were present — so a request could be authorized as one identity and executed as another. OAuth mode is now Bearer-only.
- The RFC 9728 metadata endpoint answers its own CORS preflight. It was mounted GET-only, which sent OPTIONS to the catch-all gate and 401-ed it, locking out exactly the browser-based clients that discover the server that way. It also gained the two RECOMMENDED fields it was missing, resource_name and resource_documentation.
- Two flags that -h had never listed, -public-url and -trusted-origins, are in the full help output. The first is required for OAuth mode, so following the help text could not get you a running server.
Documentation that matches the software (#311)
Twenty-one files, including the bilingual site. The parts worth calling out are the ones that were actively false: the site claimed PRIVATE-TOKEN still works in OAuth mode through header normalization (it does not — that is a 401), and every OAuth startup example omitted the --public-url flag without which the server refuses to start.
Beyond the corrections: which MCP clients can actually complete an OAuth flow against gitlab.com and which cannot (and why mcp is the one scope you must never grant a Dynamic Client Registration client), token lifetimes and refresh behaviour, the device authorization grant and why you do not want it, reverse-proxy and path-inserted metadata URLs, and the cross-origin model written down where the rest of the security model lives.
Two more things that would have shipped broken (#314)
PUBLIC_URL was documented and never read. In HTTP mode the environment layer carried AUTH_MODE but not PUBLIC_URL, so a container that set both started, read the mode, and then refused to run: "oauth mode requires --public-url". Which means a compose deployment — the shape this server is usually run in over HTTP — could not enable OAuth at all, while the reference happily listed PUBLIC_URL as the flag's environment equivalent. It and TRUSTED_ORIGINS now overlay like everything else, with a passed flag still winning.
Honest scopes turned into a lockout. Introspecting a token's real scopes only helps if you then ask for the right one. The server asked for api unconditionally, and the SDK requires every listed scope to be present, so a read_api token got 403 from a server running --read-only that could not have written anything anyway. The required scope is now derived from what the deployment can actually do — read_api under --read-only or --safe-mode, api otherwise — and advertised in scopes_supported, so a client following discovery asks for exactly that much and no more. An api token still works everywhere, because it is a superset.
Also
CodeRabbit now reviews pull requests targeting any branch, not only the default one — stacked pull requests above the bottom layer were being merged unreviewed. And the LobeHub badge in the README stopped showing red: the listing had been green for a while, but GitHub's image proxy had cached the old picture and only a changed URL evicts it.
A full README audit corrected the rest: the one OAuth example that could not start, a /health endpoint that returns JSON rather than the word ok, completions listed as five argument types when there are seventeen, a FAQ answer that forgot the update check exists, and meta-tool counts that five documents had drifted away from — the real figures are 32/49/50 meta-tools over 847/1065/1071 individual ones, and the tests have been asserting them all along.
Full detail in #309, #312, #311 and #314.

https://github.com/jmrplens/gitlab-mcp-server/releases/tag/v2.7.4

El més popular a Assistents d’IA i LLM

Mostra-ho tot
  1. Claude CodeAssistents d’IA i LLM · Anthropic PBC
  2. Codex CLIAssistents d’IA i LLM · OpenAI, Inc.
  3. ChatGPTAssistents d’IA i LLM · lencx
  4. GPT4AllAssistents d’IA i LLM · Nomic
  5. JanAssistents d’IA i LLM · Jan
  6. WSL ManagerAssistents d’IA i LLM · Bostrot
  7. oh-my-piAssistents d’IA i LLM · Can Bölük
  8. T3 CodeAssistents d’IA i LLM · T3 Tools
  9. CC SwitchAssistents d’IA i LLM · farion1231
  10. LobeHubAssistents d’IA i LLM · LobeHub

Etiquetes

Comparteix