Documentation
¶
Overview ¶
Package chatmcptools publishes a chat.Tool set on a loopback MCP server, so a provider that drives a CLI in another process can offer that CLI the caller's in-process Go handlers.
The server's life is one subprocess call. Every local-CLI provider spawns a process and waits for it, so the useful span is exactly that, and a listener costs microseconds to create. That is what keeps a Close method off chat.ChatClient. See https://gitlab.com/phpboyscout/go/chat/-/wikis/specs/0009-claude-local-mcp-tools
A program links it with a blank import, which registers Serve with the core; local-CLI providers look the server up rather than importing this package:
import _ "gitlab.com/phpboyscout/go/chat-mcptools"
It knows nothing about any particular CLI. Serve returns where to reach the server and the token to present; turning that into command-line arguments is the provider's job, because that is the part that genuinely differs. See https://gitlab.com/phpboyscout/go/chat/-/wikis/specs/0022-codex-and-agy-local
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Session ¶
type Session = chat.ToolSession
Session is a running tool server: the core's chat.ToolSession, so a provider can take it from the registry without importing this package. Stop is idempotent and must be called. Keep Token out of argv: a command line is world-readable through ps.
func Serve ¶
Serve publishes tools and returns where to reach them.
An empty set is not an error and starts nothing: the returned Session has an empty Endpoint and a Stop that does nothing, so a provider can call this unconditionally and check Endpoint to decide whether it has anything to tell its CLI about.