Skip to main content

ToolMisconfiguration

@forge/monorepo

@forge/monorepo / backend/src / ToolMisconfiguration

Type Alias: ToolMisconfiguration

ToolMisconfiguration = { approvalPolicy: string; configField: string; kind: "approval-check-missing"; layer: "registry" | "delegating-envelope"; toolName: string; } | { configField: string; kind: "duplicate-tool-name"; layer: "registry"; providerIds: readonly string[]; toolName: string; }

Defined in: backend/src/tools/registry.ts:233

A tool that can never run, and why — #162.

One type for both fail-closed layers, because wiring one and not the other is precisely the case that misled in #155: the report has to say which layer is unwired, or it sends the reader to the wrong file.

kind is a union with one arm today rather than a bare string, so a second class of unrunnable tool has an obvious place to go and an exhaustive switch over it keeps compiling.

Union Members​

Type Literal​

{ approvalPolicy: string; configField: string; kind: "approval-check-missing"; layer: "registry" | "delegating-envelope"; toolName: string; }

approvalPolicy​

readonly approvalPolicy: string

configField​

readonly configField: string

The exact field the reader has to set, named so the report is actionable without a grep.

kind​

readonly kind: "approval-check-missing"

layer​

readonly layer: "registry" | "delegating-envelope"

toolName​

readonly toolName: string

Type Literal​

{ configField: string; kind: "duplicate-tool-name"; layer: "registry"; providerIds: readonly string[]; toolName: string; }

configField​

readonly configField: string

kind​

readonly kind: "duplicate-tool-name"

Two providers offering the same tool name — #188.

Found when the first-party tool library became a second first-party provider. findAuthorized takes the first match, so a provider listed earlier silently shadows a later one: the catalogue shows the name twice, possibly with different descriptions and different effects, and execution picks one of them with nothing recording which. A read tool shadowing an external-write tool of the same name is an unapproved write; the reverse is a read that suddenly needs a human.

MCP-imported tools are namespaced mcp__<server>__<tool> precisely so a remote server cannot do this. Nothing was stopping two local providers.

layer​

readonly layer: "registry"

providerIds​

readonly providerIds: readonly string[]

toolName​

readonly toolName: string