BUILT_IN_TOOL_ANNOTATIONS
constBUILT_IN_TOOL_ANNOTATIONS:Readonly<Record<string,AuthoredToolAnnotations>>
Defined in: _worktrees/docs-release/gaunt-sloth/packages/core/src/core/approvals/toolAnnotationSources.ts:141
§4.7 — what each of our own tools does, in the MCP ToolAnnotations vocabulary. Read verbatim
through the trusted provenance (§4.7.1: we author these), so every value here has to be true
rather than convenient.
Keyed by the registered tool NAME, not by owner — gsloth’s own GthFileSystemToolkit and
gth_* tools, plus the conventional ls/glob/grep a graph builder or MCP server may
register — because the conventions overlap on read_file/write_file/edit_file and one flat
table by name serves them all, exactly as BUILT_IN_TOOL_ACCESS does.
The judgments that carry security weight:
- A local read is
readOnlyHint: true,openWorldHint: false. It mutates nothing and reaches nothing off this machine. gth_web_fetchisreadOnlyHint: trueANDopenWorldHint: true— §4.7.3. It mutates nothing locally and reaches the network, and the two facts are independent. Reading it as a local read is precisely what §4.7.3 forbids: §4.6 floors a shell fetch before any model call, and “the same fetch reached through a tool instead of throughcurlmust not be ungated”, or the preflight is a rule about spelling rather than about fetching.- Anything that writes, moves or deletes is not
readOnlyHint: true, and isdestructiveHint: truewherever the call can destroy something that was already there — whichcreate_directorycannot andwrite_file,edit_file,move_fileand the two deletes can. idempotentHintsays whether repeating the identical call changes anything further. It has no built-in consumer (§4.7.2) and is recorded so the vocabulary round-trips and a user’s ownhintentry can reference it. MCP defines it, likedestructiveHint, as meaningful only whenreadOnlyHintis false, so on a read row it is moot and statedtrue: a tool that changes nothing cannot change anything further on a second call, and a read row claiming otherwise would contradict itself.