BUILT_IN_TOOL_SUMMARIES

const BUILT_IN_TOOL_SUMMARIES: Readonly<Record<string, string>>

Defined in: core/dist/config/tool-descriptions.d.ts:99

§4.3/§4.4 — the one-line descriptions handed to the rater with the granted tools’ names.

Authored here on purpose. §4.3 admits this list as “trusted, locally-generated text, not part of the fenced block”, so it may not be assembled from tool description fields at large: an MCP server’s tool description is attacker-influenceable text, and placing it outside the fenced block would open an injection channel straight past the rater’s untrusted-input preamble. Only tools named in THIS table are ever offered, so an MCP, custom or A2A tool can never contribute text to the rater prompt.

Restricted to tools that could plausibly stand in for a shell command — the file tools, content search, and the fixed dev-command tools (whose command is human-authored config, so suggesting run_tests over npm test is exactly the trade this section exists to make). gth_checklist, gth_status_update and show_a2ui_surface are omitted: they substitute for nothing a model would otherwise shell out for, and a suggestion list is only useful while it is short.

gth_web_fetch is deliberately NOT here, though it is ungated at every rung. §4.5’s justification for disclosing the posture at all is that the granted tools are “by construction, the constrained ones confined to the working folder” — a network fetch is not. Offering it would let a refused curl/wget come back as a suggestion whose §7 clause tells the model, verbatim, that the alternative “will not interrupt the user”: a refused egress turned into a free one, through the rater rather than through the gate. An attack halts before any message reaches the model, but a merely destructive fetch would not. Same reasoning excludes MCP and custom tools, which additionally supply text we did not author.