feat(create_repository): support namespace_id for group/user targeting - #434
feat(create_repository): support namespace_id for group/user targeting#434awkto wants to merge 1 commit into
Conversation
The create_repository tool previously always created projects in the authenticated user's personal namespace, with no way to target a group or other namespace. Adds an optional namespace_id field (numeric ID or full path) that passes straight through to the GitLab REST call. When omitted, behavior is unchanged.
6aeda79 to
4e63650
Compare
zereight
left a comment
zereight
left a comment
There was a problem hiding this comment.
Left one comment about the namespace_id input contract.
| .describe("Repository visibility level"), | ||
| initialize_with_readme: z.coerce.boolean().optional().describe("Initialize with README.md"), | ||
| namespace_id: z | ||
| .union([z.coerce.number(), z.string()]) |
There was a problem hiding this comment.
I think we should narrow this to numeric namespace IDs unless we also add a lookup step. GitLab's POST /projects API documents namespace_id as an integer group/subgroup ID, but this schema and the tool description accept a full path string and pass it straight through to the create-project request. That means inputs like "my-group/sub-group" are advertised as valid by the MCP schema, but they are not actually supported by this endpoint contract.
Could we either make this z.coerce.number().optional() and update the descriptions/test plan to say numeric namespace ID only, or resolve a full namespace path to its numeric ID before calling POST /projects?
zereight
left a comment
zereight
left a comment
There was a problem hiding this comment.
Requesting changes because the schema currently advertises full namespace path strings for namespace_id, but the GitLab POST /projects contract expects a numeric namespace ID. Please either narrow the schema/descriptions/test plan to numeric IDs, or add a namespace path lookup before creating the project.
|
Closing this because the requested changes have been stale for an extended period and there is no actionable re-review signal at the moment.\n\nIf you want to continue this work, please reopen the PR or open a fresh one with the requested fixes addressed, and we can review it again. |
2 participants
Summary
create_repositorycurrently always creates projects in the authenticated user's personal namespace — there is no way to create a project under a group, or under another user (for admins). This PR adds an optionalnamespace_idfield that passes straight through toPOST /projects, so agents can target groups likegitlab.example.com/my-team/<repo>in one call.When
namespace_idis omitted, behavior is unchanged (defaults to the authed user's personal namespace).Accepts either a numeric namespace ID or a full path string, matching the GitLab REST API's own flexibility for this field.
Changes
schemas.tsnamespace_id(optional,number | string) toCreateRepositorySchema(the MCP tool input schema exposed viatools/registry.ts).CreateRepositoryOptionsSchema(the internal function param type).index.ts— includenamespace_idin thePOST /projectsbody only when it is provided (conditional spread, so the payload shape is untouched for the default case).Test plan
npm install(which runsprepare→tsc) succeeds with no type errors.create_repositorywithoutnamespace_id→ project is created in the authed user's personal namespace (existing behavior).create_repositorywithnamespace_id: <group_id>→ project is created under that group.create_repositorywithnamespace_id: "my-group/sub-group"→ project is created under that path.Motivation
Came up while using the MCP against a self-hosted GitLab: the agent needed to create projects under a dedicated group (e.g.
github/<repo>for GitHub-mirrored projects), and the only workaround was to shell out toglab apiwith-f namespace_id=<id>. One-line addition on the server side removes the need for that workaround entirely.