Add MCP module notes and comments for hosts

[adfoster-r7]

Updates the Metasploit MCP tool to expose note information on Metasploit modules, as well as host comments.

Verification

Running the inspector tool:

npx @modelcontextprotocol/inspector -- bundle exec ./msfmcpd

Veriftying module notes:

Verifying host comments:

[adfoster-r7]

Binding to localhost would resolve to ipv6 then have issues:

$ ./msfmcpd
[DEPRECATION NOTICE] json-schema support for MultiJSON is deprecated and will be removed in a future version. To stop using MultiJSON, add `JSON::Validator.use_multi_json = false` to your application's initialization code.
No configuration file specified, using defaults
Validating configuration...
Configuration valid
Fatal error: Address family not supported by protocol family - connect(2) for [::1]:55553
/Users/user/.rvm/gems/ruby-3.2.5/gems/rex-socket-0.1.65/lib/rex/socket/comm/local.rb:267:in `connect'
/Users/user/.rvm/gems/ruby-3.2.5/gems/rex-socket-0.1.65/lib/rex/socket/comm/local.rb:267:in `block in create_by_type'
/Users/user/.rvm/gems/ruby-3.2.5/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
/Users/user/.rvm/gems/ruby-3.2.5/gems/timeout-0.4.3/lib/timeout.rb:38:in `handle_timeout'
/Users/user/.rvm/gems/ruby-3.2.5/gems/timeout-0.4.3/lib/timeout.rb:194:in `timeout'

[cdelafuente-r7]

Just checking, did you get the same error with the MCP server, which also default to localhost?

Also, can you also update the example config files:

• metasploit-framework/config/mcp_config.yaml.example

  Line 4 in cd0eed7

  host: localhost

• metasploit-framework/config/mcp_config_jsonrpc.yaml.example

  Line 4 in cd0eed7

  host: localhost

[dwelch-r7]

I also ran into this error with the mcp server FWIW

[adfoster-r7]

ctrl+c didn't work:

Server ready - waiting for MCP requests
Press Ctrl+C to shutdown
^CFatal error: can't be called from trap context
/Users/user/Documents/code/metasploit-framework/lib/rex/logging/log_dispatcher.rb:90:in `synchronize'
/Users/user/Documents/code/metasploit-framework/lib/rex/logging/log_dispatcher.rb:90:in `log'
/Users/user/Documents/code/metasploit-framework/lib/rex/logging/log_dispatcher.rb:182:in `ilog'
/Users/user/Documents/code/metasploit-framework/lib/msf/core/mcp/application.rb:72:in `shutdown'
/Users/user/Documents/code/metasploit-framework/lib/msf/core/mcp/application.rb:167:in `block in install_signal_handlers'

[cdelafuente-r7]

I traced back this issue and it is related to the call to ilog in shutdown, which call Mutex#synchronize at some point. This comes from the last change that has been made to make it compatible with Framework logging system. Mutex#synchronize can't be called from a signal trap context.
That said, during my testing, I found out @main_thread.raise doesn't work neither. The rescue Interrupt is never triggered in #run. However using a fresh new Thread seems to work:

Thread.new { shutdown('INT'); exit 0 }.join

Another option would be to use at_exit, which is what @dwelch-r7 suggests in this PR

This solution is simpler but we lose the ability to distinguish signals from normal exits. That said, since The Interrupt exception handler call shutdown('INT') even if a SIGTERM is received, so it will always logged as SIGINT. Maybe passing the signal in the Interrupt exception and then passing it to shutdown would solve this, but it is not a big deal.

Whatever solution we choose, we should add specs that check if #shutdown is correctly called when a INT or TERM signal is received.

Thought?

[cdelafuente-r7]

So, the issue with the Signal trap is that it gets overwritten by Puma when the http transport is used (see my comment here). So it looks like we haven't a lot of options.

[adfoster-r7]

Adding where it's connecting to:

  RPC server started via msfrpcd (PID: 37410)
- Waiting for RPC server to become available...
+ Waiting for RPC server to become available at 127.0.0.1:55553...