Add an MCP server for askgod at <askgod_server_address>/mcp.

[Res260]

Add an MCP server for askgod at <askgod_server_address>/mcp.

It has two methods: one to submit flags and one to list the scoreboard.
The list scoreboard method contains a small prompt injection to troll the players.

A new column is added to the scores table: source. Its purpose is to track if the flag was submitted using the REST API or using MCP.

The askgod admin list-scores aud askgod history commands were changed to display the source of each flag.

Note: This PR was mainly vibecoded using Claude Code, but I reviewed all of it. However, I'm not a golang expert so a thorough review would be appreciated.

[Res260]

@stgraber Le lint semble chialer sur des fichiers que j'ai pas touchés, sais-tu pourquoi?

[stgraber]

@Res260 try rebasing now. I've just pushed a whole bunch of fixes to modernize things and sort out all the newer lint.

[Res260]

@stgraber everything should be good now

[stgraber]

Other than the API change mentioned above, this is going to need quite a few updates:

• This should be split into quite a few separate commits, off the top of my head, I'd say:
  • Docker compose change
  • Moving of the IP logic into utils
  • Updating of existing code following the move of the function to the utils package
  • Introduction of the new API fields in the API package
  • DB schema update
  • DB functions update
  • CLI update for the new field
  • Introduction of the MCP logic

On the styling front, our normal pattern for commands is to have them start with a capital letter and end with a period. It looks like all the newly introduced comments fail to follow the existing pattern.

We've also recently been putting http.MaxBytesReader in place everywhere we read user provided data, the MCP endpoints should use that too.

I also am quite concerned about having validation logic duplicated in both the REST and MCP endpoints, especially things like scoreboard filtering or the validity of a team who's attempting to submit a flag.

As someone with zero interest in the MCP stuff, I'm not likely to remember to update that code so we may well end up with submissions allowed under MCP which aren't on REST, that would be bad. My preference would be for the MCP stuff to put together a regular http.Request and call the REST endpoint internally so it would be guaranteed to go through the exact same logic as a normal REST query.

If that's impractical, then the logic should be extracted from the REST endpoint and be put somewhere that can be called from both REST and MCP with neither of the handlers performing any additional validation on the submitted data.

I also think that the trolling/nagging logic probably ought to be configurable.
I'm not aware of any use of Askgod outside of NorthSec but if it is used externally, the nagging/trolling may not be desired in that environment.

Oh and speaking of configuration, the entire MCP stuff should be an optional feature that needs to be enabled in the server configuration.

[Res260]

Update: J'ai refactor le tout. Le au lieu de Source dans le score table, ça sera un bool ai_agent qui peut aussi être activé via le askgod client via --agent ou autodétecté via des variables d'environnement communes d'AI Agents (comme CLAUDECODE=1). L'autodétection est désactivable via variable d'environnement ou --no-ai-autodetect.

This should be split into quite a few separate commits

Still todo, je ferai à la fin quand le review sera fini, idem pour les signoff

On the styling front, our normal pattern for commands is to have them start with a capital letter and end with a period. It looks like all the newly introduced comments fail to follow the existing pattern.

De quelle commande on parle? Je sais pas si c'est encore pertinent suite au refactor.

We've also recently been putting http.MaxBytesReader in place everywhere we read user provided data, the MCP endpoints should use that too.

Fixed

I also am quite concerned about having validation logic duplicated in both the REST and MCP endpoints, especially things like scoreboard filtering or the validity of a team who's attempting to submit a flag.
As someone with zero interest in the MCP stuff, I'm not likely to remember to update that code so we may well end up with submissions allowed under MCP which aren't on REST, that would be bad. My preference would be for the MCP stuff to put together a regular http.Request and call the REST endpoint internally so it would be guaranteed to go through the exact same logic as a normal REST query.

Done, c'est en effet plus clean

I also think that the trolling/nagging logic probably ought to be configurable. I'm not aware of any use of Askgod outside of NorthSec but if it is used externally, the nagging/trolling may not be desired in that environment.

Retiré altogether

Oh and speaking of configuration, the entire MCP stuff should be an optional feature that needs to be enabled in the server configuration.

Done

Donc j'attend le review final et je retravaille les commits

[stgraber]

Ça me prend le re-shuffle des commits pour pouvoir faire le review.

Je review toujours commit par commit dans l'ordre et m'attend généralement à ce que le codebase soit compilable à chacun de ces points pour pouvoir être capable de bisect dans le future sans avoir une batch de commits brisés qui font skipper le bisect.

[Res260]

@stgraber C’est fait! J’ai également retiré le refactor de la méthode qui retournait le Team selon le IP, les diffs sont pas mal plus clean sans ce refactor.