project get prints a raw origin URL, so callers guess the owner instead of reading it #16

New issue

Open

opened 2026-08-20 05:31:15 +00:00 by gravityfargo · 0 comments

gravityfargo commented

2026-08-20 05:31:15 +00:00

Owner

local-tools project get <name> reports the origin as a bare URL:

name=athena-file
origin=ssh://git@git.modernleft.org/ModernLeft/athena-file.git
tool=forgejo (MCP)

Every forge call that follows needs that URL split into the host / owner/repo pair the Forgejo MCP tools take as repo. local-tools repo platform already does exactly that split, but only for a directory:

host=git.modernleft.org
repo=gravityfargo/templates

So the parsed form is reachable for the repo you are standing in and not for a project you merely name.

What it cost

Filing an issue on athena-file from inside templates, working from a bare repo name in ADOPTERS.md. The owner was assumed to be gravityfargo, matching the repo the work was happening in. It is ModernLeft. The forge answered 301 redirecting to the real path and the MCP server refused to follow it, so nothing was created and the guess surfaced as an error rather than as a misfiled issue. The registry had the correct owner the whole time.

Suggested fix

Have project get emit the parsed pair beside the URL, reusing the repo platform parser:

origin=ssh://git@git.modernleft.org/ModernLeft/athena-file.git
host=git.modernleft.org
repo=ModernLeft/athena-file

A --project <name> option on repo platform would answer the same question. project get is the better home: it is already the "tell me about this project" verb, it does not require the project to be checked out at path, and it keeps the answer to one call rather than project path followed by repo platform <path>.

The tool=forgejo (MCP) line shows the entry is already meant to route forge calls. It routes to the right server but not to the right repo.

`local-tools project get <name>` reports the origin as a bare URL: ``` name=athena-file origin=ssh://git@git.modernleft.org/ModernLeft/athena-file.git tool=forgejo (MCP) ``` Every forge call that follows needs that URL split into the `host` / `owner/repo` pair the Forgejo MCP tools take as `repo`. `local-tools repo platform` already does exactly that split, but only for a directory: ``` host=git.modernleft.org repo=gravityfargo/templates ``` So the parsed form is reachable for the repo you are standing in and not for a project you merely name. ## What it cost Filing an issue on `athena-file` from inside `templates`, working from a bare repo name in `ADOPTERS.md`. The owner was assumed to be `gravityfargo`, matching the repo the work was happening in. It is `ModernLeft`. The forge answered `301` redirecting to the real path and the MCP server refused to follow it, so nothing was created and the guess surfaced as an error rather than as a misfiled issue. The registry had the correct owner the whole time. ## Suggested fix Have `project get` emit the parsed pair beside the URL, reusing the `repo platform` parser: ``` origin=ssh://git@git.modernleft.org/ModernLeft/athena-file.git host=git.modernleft.org repo=ModernLeft/athena-file ``` A `--project <name>` option on `repo platform` would answer the same question. `project get` is the better home: it is already the "tell me about this project" verb, it does not require the project to be checked out at `path`, and it keeps the answer to one call rather than `project path` followed by `repo platform <path>`. The `tool=forgejo (MCP)` line shows the entry is already meant to route forge calls. It routes to the right server but not to the right repo.

No labels

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gravityfargo/local-tools#16

No description provided.

Rows
Columns