AnyEvent/MCP/Intro.pod

=head1 NAME

AnyEvent::MCP::Intro - using MCP servers, clients and permissions

=head1 DESCRIPTION

You can use the servers in this distribution without writing any Perl.
This walkthrough starts with one filesystem server, connects it to an MCP
client, and makes a useful request. Once that works, it explains persistent
configuration, permissions and combining several servers.

If you want to write a small server yourself, continue with
L<AnyEvent::MCP::Server::Simple/TUTORIAL>. Applications needing their own
connection management or dispatch can use the modules described in
L<AnyEvent::MCP/MODULES>.

The examples use C</home/alice/src/project> as an existing project directory.
Replace it with your own absolute path. Commands shown here are commands
for you to run; requests addressed to the LLM are shown separately.

=head1 INSTALLATION

Install the Perl distribution and the external programs used by the
servers. Installing one does not install the other.

For mcp-fs, install Linux bubblewrap and the filesystem utilities. On
Debian or Ubuntu, for example:

   sudo apt install bubblewrap findutils grep patch sed perl yad

C<yad> is optional: it supplies graphical permission dialogs.
Without a usable YAD dialog, the helper tries C</dev/tty>; if neither is
available, it denies the request. Bubblewrap's executable is C<bwrap>.
The machine must allow the unprivileged user namespaces it needs.

mcp-fs detects its utilities at startup and omits tools whose utilities
are unavailable or unsuitable. It requires bubblewrap by default.
See L<mcp-fs/TRUSTED CONFIGURATION> for explicit utility paths and
L<mcp-fs/LIMITATIONS> for the sandbox's limits.

If you have an unpacked distribution or source checkout, run these commands
in its top-level directory:

   perl Makefile.PL
   make
   make test
   make install

C<perl Makefile.PL> reports missing Perl dependencies. Install those with
your usual package manager or CPAN client before continuing. For example,
the main non-core dependencies can be installed with:

   cpan AnyEvent AnyEvent::HTTP common::sense JSON::XS

Use the same Perl installation for dependency installation, building and
running the servers. A module installed for the system Perl might not be
available to a Perl installed under C</opt>. C<make install> needs write
access to the selected Perl's installation directories; use an appropriate
local Perl installation or run that final step with the required privileges.

Installation puts C<mcp-fs>, C<mcp-multibroker>, C<mcp-vim>,
C<mcp-ask-user>, C<anyevent-mcp> and C<anyevent-mcp-askpermission> in the
selected executable directory. Make that directory available in the
environment of your MCP client, or configure absolute executable paths.
A desktop application need not have the same C<PATH> as your shell.

To try an uninstalled source tree after installing its dependencies, you
can run a program with the source library path:

   perl -Ilib bin/mcp-fs --stdio --name code /home/alice/src/project

Do this from the distribution directory. When configuring a client to
start such a command, account for the client's working directory or use
absolute paths to Perl, C<lib> and the script. An installed executable
avoids that extra setup.

=head1 YOUR FIRST FILESYSTEM SERVER

Start with one project and one connection. You do not need a multibroker,
a hand-written configuration file or saved permission rules yet.

=head2 Choose stdio or HTTP

Use B<stdio> when your MCP client runs on the same machine and can launch
a server process. Configure the client to start the following command:

   mcp-fs --stdio --name code /home/alice/src/project

The client starts this process and uses its stdin/stdout for MCP.
You do not start a second copy in a terminal, and there is no listener
URL or HTTP token to configure. Diagnostics go to stderr.

Clients that take a command and an argument array need these values:

   command: mcp-fs
   arguments: --stdio, --name, code, /home/alice/src/project

These describe separate arguments, not one shell command string.
Use an absolute executable path if the client cannot find C<mcp-fs>.
See L</CLIENT EXAMPLES> for examples of particular clients.

Use B<HTTP> when the client connects to an already-running server, or when
it cannot launch a local process. Start this in a terminal on the server
machine and leave it running:

   mcp-fs --name code --bind :31741 /home/alice/src/project

In another terminal, obtain the matching connection URL:

   mcp-fs --name code --bind :31741 --print-url

The second command prints a credential-bearing URL and exits without
opening a listener. Configure that URL in the client. The default address
is IPv4 loopback, so this example is reachable from the same machine only.
A hosted client needs a suitable tunnel or reachable endpoint; its own
C<localhost> is not your computer.

Repeat the same name and listener overrides when printing the URL.
Both commands must use the same user and configuration directory.
Port zero chooses an ephemeral port, which C<--print-url> cannot predict;
use an explicit port for this walkthrough.

The HTTP server generates and saves its private master secret when needed.
You can initialize it explicitly with C<anyevent-mcp init>, but that
command is unnecessary when configuration already exists and will refuse
to replace it. Keep the printed URL private: possession of its token
authenticates a client.

=head2 Make a useful request

Once your client reports that the server is connected, ask the LLM:

   Show me the configured workdirs. List the top-level files in the
   project, then read its README. Do not modify files or run commands.

C<workdirs> returns the configured paths, sandbox grants, trusted mounts
and runtime paths. Listing names requests C<inspect> permission; reading
contents requests C<read> permission. Expect a permission prompt when
there is no saved rule allowing the operation.

Choose C<Allow once> for the first operation. The worker then runs with
the requested sandbox grants. A denial is a tool failure that the LLM
should report, rather than an empty file or a disconnected server.

For a slightly larger task, ask:

   Find TODO comments in this project and explain the three that look
   most useful to address next. Do not modify files or run commands.

This can use C<find>, C<grep> and C<read-lines>. You need not write MCP
requests yourself. If a client offers its own tool-approval prompt, that
is an additional client policy; it does not replace mcp-fs's permissions.

=head2 Understand the workdir

The directory passed at startup tells mcp-fs which workdir to expose.
It does not grant permission for every operation in that directory.
Each operation still requests its action and sandbox grants.

With one workdir, tools can omit the C<workdir> argument. With several:

   mcp-fs --stdio --name code /home/alice/src/project /home/alice/notes

tools select one using a zero-based index, a numeric string or an exact
configured/resolved path returned by C<workdirs>. Relative tool paths
are relative to that selection. The tool index C<0> is not a name you
put in permission rules.

C<workdir-read> exposes the selected workdir read-only.
C<workdir-write> makes it writable and implies read access.
A path in another configured workdir requires all-workdirs authority;
a path elsewhere requires suitable home/world or shared-tmp authority.
A symlink cannot make an unmounted target appear inside the sandbox.

Prefer separate, non-overlapping workdirs. Overlapping mounts have
unspecified access effects. See L<mcp-fs/SANDBOX GRANTS> before granting
access beyond the selected workdir.

=head2 Inspect version-control changes

For a Git, SVN, CVS or Mercurial working copy, ask the LLM to use
C<vcs-diff> and C<vcs-status>, with C<backend> set to C<git>, C<svn>, C<cvs>
or C<hg>. C<workdirs> reports the available clients. These tools accept
filenames and construct the command themselves; no shell pipeline or arbitrary
VCS options need to be approved.

For example:

   Show the CVS diff for this project, limited to 200 lines.
   Then show its status, keeping stdout lines matching "File:|Status:".

These operations have their own permission actions. They request read access
to the selected workdir and home configuration; CVS also requests network
access automatically. Read permission for ordinary file tools does not
automatically authorize a VCS operation.

For arbitrary C<exec> commands, the same output options are available:
C<grep> filters stdout using PCRE, C<max_lines> limits matching stdout lines,
and C<max_bytes> bounds returned bytes per stream. Prefer these options to a
shell wrapper that mixes execution and output processing. Stderr is unfiltered,
and exit status still describes the original command.

Defaults return at most 2000 stdout lines and 64 KiB per stream. Raw capture
has a separate 1 MiB limit per stream. A true C<capture_truncated> means
output was omitted before filtering or collection ended on timeout, so absent
matches do not prove the omitted output had none. See L<mcp-fs/Command output>
for all result flags and limits.

=head1 CONFIGURING YOUR SETUP

There are three different things to configure: how the client connects,
how the server runs, and which operations the user allows. Changing one
does not necessarily change the other two.

=head2 Where each setting belongs

=over

=item Directories to expose

Pass workdirs on the mcp-fs startup command. For a stdio server, that
command belongs in the client's server configuration. For an HTTP server,
it belongs in the command used to run the service.

=item Connection transport

The client launches a command for stdio or connects to a URL for HTTP.
C<--stdio> selects the former for mcp-fs and the multibroker.

=item Listener address, port and tokens

Use C<[instance NAME]> in the global configuration or command-line
C<--bind> and C<--token> overrides.

=item Trusted mounts and utility paths

For mcp-fs, use C<[program NAME]> defaults and C<[instance NAME]>
overrides in the global configuration.

=item Allowed operations and sandbox grants

Use the permission rules file, normally created through approval dialogs.
This file is separate from the global configuration.

=item Location of permission prompts

Use C<--ask helper>, C<--ask tty>, C<--ask yad>, C<--ask auto> or C<--ask mcp>, or set
C<PERL_ANYEVENT_MCP_PERMISSION_ASK> in the server's environment.

=item Combined server connections

Put prefix/server pairs on the multibroker startup command. HTTP child
credentials can also use C<[client PREFIX]> in the global configuration.

=back

=head2 One complete named configuration

The global file is C<$XDG_CONFIG_HOME/anyevent-mcp/global.ini>, falling
back to C<$HOME/.config/anyevent-mcp/global.ini>. Settings are UTF-8
C<key = value> lines; values are unquoted. Whole-line C<#> and C<;>
comments are allowed. See L<AnyEvent::MCP/GLOBAL CONFIGURATION> for the
complete format.

Start with the existing file, preserving its C<[global]> secret.
If you have no file yet, C<anyevent-mcp init> creates it privately.
Add the following sections:

   [program mcp-fs]
   mount.opt = ro:/opt

   [instance code]
   bind = 127.0.0.1:31741

The optional C<mount.opt> line assumes C</opt> exists and contains tools
or libraries your workers need. Omit it if you do not need that access.
The ordinary sandbox runtime includes C</usr>, C</bin> and system
libraries, but not C</opt>. If your worker Perl is C</opt/bin/perl>, you
can additionally put C<executable.perl = /opt/bin/perl> in that program
section. Supply the actual executable path; selecting it does not itself
mount its files or libraries.

Now start:

   mcp-fs --name code /home/alice/src/project

and retrieve its URL with:

   mcp-fs --name code --print-url

Both use C<[instance code]>. No explicit token is needed: the server
derives one from its name and the existing master secret.

For this setup:

   program defaults: [program mcp-fs]
   instance settings: [instance code]
   selected workdir: /home/alice/src/project
   permission file: ~/.config/anyevent-mcp/rules/fs-code.ini
   rule-manager profile: fs-code

The permission pathname above assumes the default configuration directory.
C<anyevent-mcp manage-rules fs-code> opens the graphical rule manager;
C<anyevent-mcp edit-rules fs-code> opens the file in your editor.

Keep global configuration and rule files owned by the server user and
private, normally mode 0600. C<--config FILE> on C<anyevent-mcp init>
selects that command's output file; it does not make the servers use an
arbitrary alternate file. Use the same C<HOME>/C<XDG_CONFIG_HOME>
environment when running the server and its management commands.

=head2 Names, prefixes and profiles

C<--name code> selects instance settings, derived HTTP credentials and
mcp-fs's C<rules/fs-code.ini>. Without C<--name>, mcp-fs uses C<default>,
giving profile C<fs-default>. Two processes with the same program, name and
configuration share credentials and rules, even if their workdirs differ.

A multibroker prefix, such as C<files>, only routes tools: C<grep> becomes
C<files.grep>. It does not rename the child server or select its rules.
For example:

   mcp-multibroker files \
      'stdio:mcp-fs --name code /home/alice/src/project'

The tools are C<files.*>, but the child still uses instance C<code>
and rule-manager profile C<fs-code>. The multibroker's own C<--name>
selects its upstream listener settings.

=head2 Configuration changes and restarts

Command-line listener options override the named global settings.
For mcp-fs trusted settings, an instance entry overrides the corresponding
program entry; an empty instance mount value suppresses the inherited mount.

Workdirs, mounts, utility paths, listener settings and tokens are read at
startup. Change the file or startup command, then restart the affected
server. The multibroker also needs restarting to change its prefix/server
pairs; refreshing discovery does not change those pairs.

Permission rules are reread on permission checks, so editing them does
not require a restart. A client's displayed tool list can still be cached.
After restarting a child, refresh tool discovery or reconnect the client
as described in L</COMBINING SERVERS>.

=head1 PERMISSIONS IN PRACTICE

HTTP authentication establishes that the client may connect.
Permission checks decide whether a tool may perform an operation.
A correct token therefore does not prevent permission prompts.

=head2 What the prompt means

The prompt describes an action, paths or command, a reason and sandbox
grants. For filesystem tools, the actions are:

   inspect     stat, list, find
   read        file-read, read-lines, grep
   write       file-write, file-patch
   manage      path-op
   exec        arbitrary command execution
   vcs-diff    working-copy differences
   vcs-status  working-copy status

The action and grants are independent. Allowing C<read> does not allow
C<write>, even if a worker grant permits both kinds of filesystem access.
C<exec> runs arbitrary commands; it is not a classification of supposedly
safe command prefixes.

Choose allow/deny once, or always. Closing the dialog denies once.
An optional denial reason is returned with the error; it is not added to
successful tool results. An always choice opens a rule editor.
Filesystem allow rules can select grants and the selected workdir when
the authority depends on it. Deny rules can also select an exact affected
path. Exec offers persistent command/argv subjects.

For exec, C<View stdin...> lets you inspect supplied input without closing
the approval dialog. Filesystem and Vim patch tools similarly offer
C<View patch...>, including the target file or editor and buffer. Longer
text is shown as an explicitly incomplete preview. These are YAD button
labels; other interfaces can show the details inline.
That input is display-only: an exec allow rule does
not constrain future stdin. Allowing an interpreter command can therefore
allow a different script on its next invocation.

A worker accessing several paths requests their combined sandbox authority
once. If the chosen grants are insufficient, it fails before starting.

=head2 Save a useful read-only policy

After trying individual operations, you might want the LLM to inspect and
read the project without asking each time, while keeping changes subject
to approval. Put these rules in C<rules/fs-code.ini>, or create equivalent
allow rules through the prompt:

   [rule]
   decision=allow
   action=inspect
   workdir=/home/alice/src/project
   sandbox-grants=workdir-read

   [rule]
   decision=allow
   action=read
   workdir=/home/alice/src/project
   sandbox-grants=workdir-read

   [rule]
   decision=deny
   action=exec

Use the exact workdir spelling passed at server startup. Absolute startup
paths make this easier. If creating the rules file manually, ensure it
belongs to the server user and is private before making another request.
For the default configuration directory:

   chmod 600 ~/.config/anyevent-mcp/rules/fs-code.ini

Use the corresponding XDG path when configured. Without matching rules, write and manage operations
still ask. The final rule denies command execution outright; omit it if you
want execution to ask instead.

Rules run in order, stopping at the first match. An allow rule matches only
when its grants cover the request, including implications.
C<workdir-write> implies C<workdir-read>; C<network> remains independent.
Action and subject match exactly unless beginning with C<^>, which selects
a Perl regular expression. Workdir matching is always exact.
An explicit C<ask> rule can override later allow rules.

These allow rules authorize sandbox access to the selected workdir.
They cannot confine authority to one file or a subtree inside it.
Filesystem operations do not offer persistent path subjects.
An exact C<path> matcher is available for deny rules only.
Trusted runtime and configured mounts remain baseline access independently
of these grants. See L<mcp-fs/TRUSTED CONFIGURATION>.

=head2 Change or remove saved rules

Use:

   anyevent-mcp manage-rules fs-code
   anyevent-mcp edit-rules fs-code

The first command lets you delete and reorder rules in YAD.
The second uses C<$VISUAL>, C<$EDITOR>, C<sensible-editor> or C<vi>.
An earlier deny or ask rule can explain why adding a later allow rule
does not change the result.

For a custom application with another rule pathname, use:

   anyevent-mcp manage-rules-file /path/to/rules.ini
   anyevent-mcp edit-rules-file /path/to/rules.ini

A failed attempt to save a permanent rule is an error, not a successful
permanent approval. The file must remain private and owned by the server
user. For full syntax and programming interfaces, see
L<AnyEvent::MCP::Server::Permissions>.

=head2 Choose where to ask

The default C<helper> mode runs C<anyevent-mcp-askpermission> on the server
machine. It tries YAD, then C</dev/tty>, then denies if neither can be used.
The helper inherits the server's display environment.
C<--ask tty> and C<--ask yad> instead force the built-in terminal or YAD
interface. They ignore custom helper settings and never try another
interface. These modes work for permission prompts and ordinary forms,
including forms handled by a multibroker.
C<PERL_ANYEVENT_MCP_PERMISSION_HELPER> selects a different executable.

For a modern client supporting MCP form elicitation, you can instead use:

   mcp-fs --stdio --name code --ask auto /home/alice/src/project

C<auto> uses the client's form support when advertised for that request,
otherwise the local helper. C<mcp> requires that support and fails when
unavailable. It does not silently fall back. Use client-side permission
approval only when that client is a trusted authority to grant access.

To set the default for servers using the shared permission engine:

   PERL_ANYEVENT_MCP_PERMISSION_ASK=auto \
      mcp-fs --stdio --name code /home/alice/src/project

An explicit application C<ask> setting or C<--ask> overrides the environment.
For spawned stdio children, C<mcp-multibroker --ask auto> passes this
default to them. It cannot change the environment of an independently
running HTTP server.

The multibroker can handle form elicitation locally for both stdio and HTTP
children. C<--ask helper> selects local dialogs even if the upstream client
advertises native forms; C<--ask mcp> forwards forms upstream, and C<auto>
uses native forms when advertised. If a client claims support but silently
declines questions, use C<helper>. A decline never causes a fallback prompt.

Standalone C<mcp-ask-user> also supports these modes and defaults to the
local helper. A question is different from an approval: answering it does
not grant a filesystem worker any authority.

=head1 COMBINING SERVERS

Once the first connection works, use the multibroker to give a client
one connection for several servers:

   mcp-multibroker --name tools --bind :31740 \
      code 'stdio:mcp-fs --name code /home/alice/src/project' \
      notes 'stdio:mcp-fs --name notes /home/alice/notes'

Quote each C<stdio:> shell command as one argument.
The broker supplies the child's stdio environment and starts ordinary
children lazily, on first use. The explicit child names give them separate
permission profiles C<fs-code> and C<fs-notes>.

Obtain the upstream HTTP URL with:

   mcp-multibroker --name tools --bind :31740 --print-url

Configure this URL in place of the client's old direct connection.
The client can now see C<code.grep>, C<code.read-lines>, C<notes.find>
and other prefixed tools. It does not need a separate connection to each
child.

For a client launching the multibroker locally, configure:

   mcp-multibroker --stdio --name tools \
      code 'stdio:mcp-fs --name code /home/alice/src/project' \
      notes 'stdio:mcp-fs --name notes /home/alice/notes'

C<--stdio> selects the upstream connection. The child commands still use
C<stdio:>; that selects each downstream connection independently.
No upstream HTTP URL is needed in this case.

=head2 Discover and refresh tools

Ask the LLM:

   Call discover-brokers and list-tools, then show me which servers
   are available and what each is for.

C<discover-brokers> returns instructions, no instructions, or an error for
each configured server. C<list-tools> requests current tool definitions;
unreachable servers are omitted. A reachable server can still fail later.

If the client still has an old direct tool list, C<call-tool> can invoke
an exact prefixed name found by C<list-tools>. Refresh the client's MCP
connection if it continues to hide newly available tools.

Discovery queries the configured servers. It cannot add a server absent
from the broker's startup command. Changing that command requires a restart.

=head2 Add an HTTP child

A broker can mix spawned stdio servers and existing HTTP endpoints:

   mcp-multibroker --stdio \
      code 'stdio:mcp-fs --name code /home/alice/src/project' \
      remote https://example.org/mcp/ --bearer TOKEN

C<--bearer> immediately after the HTTP pair belongs to that child.
C<--token> before all pairs configures the multibroker's own HTTP listener.
They authenticate different connections.

To avoid putting a child's bearer token in the startup command, add:

   [client remote]
   bearer = TOKEN
   timeout = 300

to the private global configuration, and omit C<--bearer> from the command.
The prefix C<remote> selects these client defaults. The command-line URL
still chooses the endpoint. Use the actual credential accepted by that
server, not the literal placeholder C<TOKEN>.

A token already present in a child's URL needs no separate bearer option.
The bundled servers use static URL-safe tokens; they do not validate
OAuth access tokens or implement HTTP Basic authentication.
Use TLS or an appropriate tunnel when credentials cross untrusted networks.

The multibroker does not put every child inside the mcp-fs sandbox.
Each process or remote service has its own authority and enforcement.

=head2 Add a live Vim editor

Install the Vim plugin using L<mcp-vim/VIM PLUGIN INSTALLATION>. It is
included in the source distribution but is not installed by Perl's
C<make install>.

A spawned mcp-vim child also listens for editor connections. Start it
eagerly so Vim can connect before the first MCP tool call:

   mcp-multibroker --stdio \
      code 'stdio:mcp-fs --name code /home/alice/src/project' \
      vim 'stdio:mcp-vim --name editor' --eager

In another terminal, obtain the editor child's URL prefix:

   mcp-vim --name editor --print-url

Append the desired target name in Vim:

   :Mcp http://HOST:PORT/TOKEN/my-editor

Use the actual printed prefix in place of C<http://HOST:PORT/TOKEN/>.
Ask the LLM to call C<vim.targets>, then C<vim.state> before reading or
editing buffers. These tools see live, possibly unsaved buffers.
Edits require a current changedtick and do not save files to disk.

C<--eager> belongs immediately after its stdio pair.
An eager connection failure is logged; the broker does not continuously
restart the child. Later tool use can try connecting again.

=head2 Ask the client's human a question

To let the assistant ask you questions, add a question server:

   mcp-multibroker --stdio \
      code 'stdio:mcp-fs --name code /home/alice/src/project' \
      questions 'stdio:mcp-ask-user'

The LLM can call C<questions.ask-user> with a question, up to three
suggested answers and room for free text. For example, tell it to use
that tool if choosing among several possible tasks needs your input.
For several fields or other value types, C<questions.ask-form> accepts
C<message> and C<requestedSchema> directly and returns the standard
elicitation response. Both tools use the same configured presentation mode.
Decline and cancel are distinct results; neither supplies an answer.

By default the multibroker displays questions locally, using YAD or a terminal.
Add C<--ask mcp> before the broker entries to use the client's native forms,
or C<--ask auto> to select by advertised capability. This also works with
C<mcp-ask-user> started separately: give that server C<--ask mcp> so it
delegates presentation to its connecting multibroker.

C<anyevent-mcp-form-elicitation> is the standalone form renderer. It reads standard MCP
form parameters as UTF-8 JSON on stdin and writes an accept/decline/cancel
response as JSON on stdout. C<PERL_ANYEVENT_MCP_ELICITATION_HELPER> selects
a replacement executable. See L<anyevent-mcp-form-elicitation> for supported fields
and L<mcp-ask-user> for question arguments and result fields.

=head1 HTTP TOKENS AND SERVER IDENTITY

For the ordinary bundled HTTP endpoints, a client can present an accepted
token in either of these ways:

   POST /TOKEN/
   POST /                 Authorization: Bearer TOKEN

URL tokens are path components, not browser cookies.
For another configured endpoint, C</TOKEN> prefixes that endpoint path.
All accepted tokens authenticate the same operations; they are not separate
users or permission levels. Permissions still govern the tool operation.

By default, the master secret and server name determine one stable token
and a port in 16384..32767. Changing a server's name changes its derived
credentials and default port. Changing or losing the master secret changes
all derived credentials. Keep an existing C<[global]> secret when editing
other configuration.

To configure explicit tokens:

   [instance code]
   tokens = first-secret,second-secret

Replace those placeholders with actual unguessable URL-safe tokens.
Repeated C<--token> options replace the whole configured list and the
derived default. The first token appears in C<--print-url>; all are accepted.
mcp-vim also accepts its token set for Vim and browser WebSocket connections.

If C<--print-url> disagrees with the client's URL, compare the name,
command-line overrides, user and configuration environment with the running
process. The command resolves configuration; it does not ask the running
server which URL it uses. A changed file needs a server restart.

An Origin allowlist restricts browser origins; it does not authenticate
clients. A CORS preflight can succeed without a token, while the MCP POST
still requires one. See L<AnyEvent::MCP::Server::HTTP/AUTHENTICATION> for
the low-level server interface.

=head1 CLIENT EXAMPLES

Client settings and command syntax evolve independently of this distribution.
These examples show the connection choices; consult the linked client
documentation if its interface differs. Replace illustrative paths and
credentials with your own.

=head2 OpenAI Codex CLI

For the first direct filesystem connection:

   codex mcp add code -- \
      mcp-fs --stdio --name code /home/alice/src/project
   codex mcp list

For a multibroker connection:

   codex mcp add mytools -- \
      mcp-multibroker --stdio \
      code 'stdio:mcp-fs --name code /home/alice/src/project'

Use C</mcp> within Codex to inspect connections.
See L<Codex MCP documentation|https://learn.chatgpt.com/docs/extend/mcp>.

=head2 Anthropic Claude Code

For the direct connection:

   claude mcp add --transport stdio --scope user code -- \
      mcp-fs --stdio --name code /home/alice/src/project
   claude mcp list

Replace the launched command with the multibroker command above when you
want several servers. Use C</mcp> for connection status. See
L<Claude Code MCP documentation|https://code.claude.com/docs/en/mcp>.

=head2 Google Gemini CLI

Merge a direct server entry into C<~/.gemini/settings.json>:

   {
     "mcpServers": {
       "code": {
         "command": "mcp-fs",
         "args": [
           "--stdio", "--name", "code", "/home/alice/src/project"
         ]
       }
     }
   }

For a combined connection, use C<mcp-multibroker> as the command and its
C<--stdio> and prefix/server pairs as the argument array.
Use C</mcp> to inspect the connection. See
L<Gemini CLI MCP documentation|https://geminicli.com/docs/tools/mcp-server/>.

=head2 Hosted clients, including ChatGPT web

A hosted client cannot spawn your local stdio command or reach your
machine's loopback address directly. Run the server or multibroker in HTTP
mode and configure a supported tunnel or reachable endpoint.

For ChatGPT, use its custom MCP setup and, for a private server, an
appropriately configured Secure MCP Tunnel. Availability depends on the
client's plan, workspace and feature permissions. See
L<ChatGPT custom MCP servers|https://developers.openai.com/api/docs/guides/custom-mcp-server>
and L<Secure MCP Tunnel|https://developers.openai.com/blog/connect-private-mcp-servers-to-openai-products>.

=head1 TROUBLESHOOTING

=head2 The server does not start

Read stderr or the client's server log. Missing Perl modules, a missing
workdir, unsuitable utilities or an unavailable bubblewrap executable can
fail startup. Confirm that the client launches the same executable and
arguments you intended, with the expected C<PATH> and Perl installation.

For a local sandbox check, run from the project directory:

   mcp-fs --exec-cmd workdir-read -- ls

This runs C<ls> with the named grants and trusted baseline mounts, without
MCP or saved permission rules. A failure here can identify a bubblewrap
or runtime problem. It does not test the client connection or approval UI.
C<--sandbox none> disables isolation and changes worker authority; it is
not a fix that preserves the same permission boundary.

=head2 The client cannot connect

For stdio, configure a command the client launches, rather than a URL.
A separately running stdio process is not the client's connection.
Do not put banners or diagnostics on stdout.

For HTTP, leave the server running and check its address and port.
C<--print-url> exits without starting it. Loopback binds accept local
connections only; hosted or remote clients need the appropriate route or
tunnel. An occupied port causes a listener error, so check the server log.

=head2 Authentication fails

Obtain the URL with the same name, bind/token overrides and configuration
environment as the running process. Use the complete path, including any
required trailing slash. A clean URL needs an accepted bearer token.

A multibroker child credential is not necessarily the upstream listener's
credential. C<--bearer> after a child pair and C<--token> before the pairs
configure different sides of the connection.

If the server warns that it cannot save the master secret, another process
may derive a different token. Fix ownership and write access to the private
configuration. Do not replace an existing secret simply to add a setting.

=head2 Connected, but there are no tools

Inspect the server's stderr for omitted utilities. mcp-fs's C<workdirs>
tool reports configuration even when a utility-dependent tool is absent.
For a multibroker, call C<discover-brokers> to see individual connection
errors, then C<list-tools> to refresh definitions.

A third-party child might require initialization or features this client
implementation does not support. See L<AnyEvent::MCP::Client> and its
transport documentation for limitations.

=head2 There is no approval dialog

First check whether the tool was denied by a saved rule or is waiting for
the client's own approval. An allowed operation needs no server prompt.

The default helper runs on the server machine. A background service may
have neither a usable display nor C</dev/tty>, even though your interactive
shell has both. Supply the appropriate display environment, a usable helper,
or C<--ask auto> with a modern client supporting form elicitation.
C<--ask mcp> reports an error if that support is absent.

Setting an asking mode cannot make an unsupported client display a form.
Check stderr and the tool error instead of assuming a missing dialog is
an approval.

=head2 It asks again after I chose allow

Allow-once covers one tool invocation, including its permission retries.
The next invocation asks again. Use allow-always to save a rule.

Inspect the saved rule's action, workdir and grants. Listing names and
reading contents are different actions. A rule for one exact workdir
spelling will not match a differently spelled startup argument.
A request for extra authority, such as networking, does not match a
workdir-read-only allow rule. Earlier ask or deny rules take precedence.

Confirm that the prompt's permanent rule was successfully saved and that
you are editing the rules for the actual child name, not merely its
multibroker prefix.

=head2 The worker cannot see a directory or executable

The worker sees granted mounts and trusted baseline mounts, not everything
the server process can see. Check C<workdirs> for the selected path, mounts
and runtime paths. A symlink target outside those mounts is unavailable.

For tools or libraries under C</opt>, add an appropriate trusted mount
as shown earlier and restart mcp-fs. A configured executable path alone
does not mount the executable or its dependencies inside the worker.
A trusted mount supplies baseline access to every worker using it; a
writable mount likewise supplies baseline write authority.

An arbitrary command might also need its user's configuration or repository
credentials under HOME, or network access. Request the corresponding grants
when needed; do not assume C<workdir-read> includes them.
For example, CVS over SSH can use C<workdir-read> and C<ssh-agent>.
The latter includes network access, the agent socket and C<~/.ssh/known_hosts>,
without exposing private key files or the rest of HOME. The broker must
inherit C<SSH_AUTH_SOCK> from your environment. User-configured helpers
outside the runtime mounts need an explicit trusted mount.
An explicit exec grant array replaces the default rather than adding to it.

=head2 My configuration change seems to be ignored

Check which file and section the process actually selects. Global settings
use the server user's C<HOME>/C<XDG_CONFIG_HOME>. Instance names, program
basenames and multibroker prefixes serve different purposes.

Restart after changing startup settings, mounts or utilities. Permission
rules need no restart, but their order still matters. Refresh discovery
after a child restart; reconnect a client that retains an old tool list.
C<--print-url> reads the current configuration, which can differ from an
older running process.

=head2 The command failed, but the MCP request succeeded

C<exec> reports exit status, signal or timeout as a normal tool result.
A successful MCP exchange is not a successful Unix command.
Conversely, a transport failure does not prove a command did nothing:
it may have completed before the connection was lost. Calls are not
automatically replayed after a transport failure.

=head1 TESTING

The default test level is 0. It checks protocol behaviour, permissions,
validation and ordinary process operation, including worker cancellation
and reaping. Watchdogs allow slow machines time to finish; they do not
make successful tests wait for the whole timeout.

   prove -Ilib t

Set C<PERL_ANYEVENT_MCP_TESTS> to 1 to include the extended tests:

   PERL_ANYEVENT_MCP_TESTS=1 prove -Ilib t

Level 1 adds GNU find/grep/sed/patch operations, real Vim scripting, browser
transfer integration, short idle-lifetime tests, a helper descendant holding
a pipe open, and tests which deliberately wait for a command timeout or
cancel a form helper across several processes. Run this level before releases.
Values greater than 1 currently select the same tests as level 1.

Missing GNU utilities or required Vim functions cause explicit skips even
at level 1. The permission and form UI tests use a YAD stand-in: neither
level requires YAD, X11 or an interactive display. The filesystem tests
use a bubblewrap stand-in and check arguments and worker behaviour; they
do not test kernel isolation. The browser tests use simulated peers.

=head1 WHERE TO GO NEXT

For available tools and server-specific options:

   perldoc mcp-fs
   perldoc mcp-multibroker
   perldoc mcp-vim
   perldoc mcp-ask-user
   perldoc anyevent-mcp

For a complete first Perl server, options, replies, permission checks and
asynchronous work, see L<AnyEvent::MCP::Server::Simple/TUTORIAL>.
For the module map and shared configuration reference, see L<AnyEvent::MCP>.
For permission rule details, see L<AnyEvent::MCP::Server::Permissions>.

=head1 SEE ALSO

L<AnyEvent::MCP>, L<AnyEvent::MCP::Server::Simple>,
L<mcp-fs>, L<mcp-multibroker>, L<mcp-vim>, L<mcp-ask-user>,
L<AnyEvent::MCP::Server::Permissions>

=cut
Revision:	1.12
Committed:	Thu Oct 15 02:09:52 2026 UTC (2 weeks, 3 days ago) by root
Branch:	MAIN
Changes since 1.11:	+5 -1 lines
Log Message:	* empty log message *