Wrong username in Github API calls, those fails

[MiguelElGallo]

Describe the bug

• Using get_me it identifies my correct Github user name lets call it correctuser.
• Any call to something that used the username, for example:
  Calling to: create_branch fails with:
  MPC -32603: failed to get repository: GET [https://api.github.com/repos/**wronguser**/iparq](vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-sandbox/workbench/workbench.html): 404 Not Found []

Is worth noting that the call is using wronguser in the URL that is why it is failing, the user that puts there is just my login to my Mac OS, NOT my Github username

Affected version

server version v0.1.0 (b893367) 2025-04-04T15:38:21Z

Steps to reproduce the behavior

1. Use MacOS
2. Try to call to create_branch
3. See error

Expected vs actual behavior

It should call the api with:
GET [https://api.github.com/repos/correctuser/iparq]

Logs

MPC -32603: failed to get repository: GET https://api.github.com/repos/wronguser/iparq: 404 Not Found []

As you can see instead of correctuser, is setting a username that is not my github username but the login to my operating systems

[AlexanderYastrebov]

#110 seems related as there MCP also used wrong owner name.

[barshopen]

I'm getting the same error when attempting to search or create issues.
I confirmed that the token I'm using has access to do these operations by creating and searching for issues with curl with the same token.

[SamMorrowDrums]

We can't entirely be responsible for the choices made by the LLM here, especially as this can be called by any of them. My experience is that some models do better than others for this, and that you can try to use the translations feature to change the description of get_me to validate if a change to that improves behaviour.

Please let me know. Also note the software and ideally model version you are using. Some are better than others at this, and more can be with great tool descriptions and field descriptions.

I'm not sure what it would take to get this issue closed? I'm assuming you can correct the behaviour with more prompting by yourself until it does the correct thing.

Let me know but I'd be tempted to close the issue out as it's not a bug. The MCP server works just fine. The LLM controlling it on the other hand is not working just fine. The only part in our control is guiding it with better descriptions.

[SamMorrowDrums]

I am going to close this out, as it's largely out of our control. Get Me fixes many of these scenarios, but depending on the model you might need to be more explicit sometimes to get it to do the right thing.

[subnix]

@SamMorrowDrums Can we enhance the error handling and make it more user-friendly?

The MCP server currently returns an internal error that shouldn't be accessible to clients (LLMs). Consequently, clients are unable to resolve the issue because the error is not visible to them.

According to the MCP documentation, tool errors should be reported within the result object, not as MCP protocol-level errors. This allows LLMs to identify and potentially handle the error.

Therefore, I propose the following solution: we should return a tool error (instead of an internal error) that clearly indicates that a provided repository doesn't exist.

Example:

{"jsonrpc":"2.0","id":"someid","result":{"content":[{"type":"text","text":"repository user/foo does not exist"}],"isError":true}}

[SamMorrowDrums]

@subnix I agree entirely. @mattdholloway was hopefully going to find and fix these.