Documentation
¶
Overview ¶
Package toolvisibility decides which registered tool a narrowed deployment serves, for every caller that registers a tool surface the way the server does.
Read-only mode, safe mode and --exclude-tools act in two places. The catalog-backed tools receive them per action from the catalog filter, inside the catalog every assembler shares. The tools registered outside the catalog, the gitlab_interactive_* flows the meta and individual surfaces register, receive them from Apply, a pass over the tools a server holds once registration is done: it removes the tools --exclude-tools names, by their registered name or, for a standalone utility, by any spelling the catalog's exclusion rule accepts; in read-only mode it removes every tool without a read-only hint; and in safe mode it wraps what is left with previews, exempting the catalog-backed dispatchers because they already preview per action.
It is a package of its own for the reason internal/tools/dynamiccatalog is: the pass needs the two filters internal/tools holds and the two tool names internal/tools/dynamic declares, and neither package can hold it without an import cycle in its tests.
It was moved out of cmd/server when a second caller needed it: the surface evaluator that used to live under cmd registered its own server, so the pass ran nowhere but the binary and a read-only or safe-mode meta evaluation scored a surface on which gitlab_interactive_issue_create still created the issue, while the product would have withdrawn or previewed it. That caller is gone and the defect with it, because the evaluation under test/e2e drives the real binary: the pass runs in cmd/server, where it always ran, and an evaluation now sees exactly the surface a client sees because it is the same process.
What keeps it here rather than folded back is the other half, which the second caller only made visible: cmd/server is the one package exempt from the coverage rule, so while the pass lived there it had no unit test of its own on its policy. Here it has one.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Apply ¶
func Apply(ctx context.Context, server *mcp.Server, cfg *config.ServerConfig, toolSurface string, surfaceCatalog *actioncatalog.Catalog)
Apply narrows the tools registered on server to what cfg says the deployment serves, in three steps: the tools cfg.ExcludeTools names are removed, then read-only mode removes every tool without a read-only hint, or safe mode wraps every mutating tool that the catalog does not already preview per action. Read-only mode wins over safe mode, since nothing is left for safe mode to wrap.
It runs after registration, over every tool the server holds, which is what reaches the tools registered outside the catalog: the catalog filter has already applied the same configuration to the catalog-backed ones, per action, and this pass is the second mechanism the standalone flows need. The exclusions reach those flows by the catalog's own rule, so an entry naming one by its group name or its canonical action ID removes it here as its tool name does (see removeExcluded). toolSurface and surfaceCatalog decide the safe-mode exemptions (see catalogBackedToolNames); a surface whose exclusions were applied to the catalog legitimately has nothing left for the first step to remove.
The token-scope filter is deliberately absent. It is applied to the catalog, before registration, by the three catalog assemblers, which is the only place it can reach the individual surface: its keys are meta-tool group names and that surface registers one tool per action, so a pass over registered names here matched nothing and left every admin tool listed for a token with no admin_mode. See gitlabtools.MetaToolScopes.
Types ¶
This section is empty.
Source Files