Leaving readOnlyHint unset is what makes a missing destructiveHint default to true

Line 1929 of the same file decides how an omission gets read. It says destructiveHint "is meaningful only when readOnlyHint == false" ^[11]. On a tool that declares readOnlyHint: true and stops there, leaving destructiveHint out is exactly right, and a client that reads true into it has made an error ^[12]. On a tool that declares nothing at all, readOnlyHint falls to its own default of false, that makes destructiveHint meaningful, and its default of true applies ^[13]. The same omission is correct in the first server and destructive in the second, because of a second field the tool also left unset.

Directly above the interface, at lines 1903 to 1908, the schema says all properties in ToolAnnotations "are hints" and "are not guaranteed to provide a faithful description of tool behavior". Clients, it adds, "should never make tool use decisions based on ToolAnnotations received from untrusted servers" ^[9]. Take a memory server whose save_memory tool ships no annotations. A client implementing the defaults gates that call as destructive, and a client reading the absent object as "no annotation gate applies" routes it straight through. Both of those clients are behaving correctly ^[25]. The dev.to walkthrough describes this as a schema that supplies defaults for a field it also instructs clients not to decide on, and says both halves are in force ^[26].

Himanshu Kumar audited a deployed server on 2026-08-30 and found six tools, all six of them annotation-free ^[5]. "The server did not lie. It said nothing," he wrote ^[6].

The scanner in Ivanova's review was stricter than the schema on exactly this point. Four of the tools it flagged were read-only, so line 1929 makes destructiveHint meaningless on them, and the value she added to clear the review is one the spec leaves optional ^[3][12]. Her account covers one review, published on dev.to on 2026-09-07 ^[1].

How common the silent tool is depends on a count whose method needs checking. The dev.to author downloaded each project's branch archive at a named commit, walked every regular file, and counted case-insensitive byte occurrences of the four field names. The walk was not restricted to paths containing "mcp", because that filter would have missed the assertions in mem0's tests/test_memory_core.py ^[14]. Case matters too: the Go SDK capitalizes the same fields, so a case-sensitive grep returns a false zero on any Go server ^[15]. In the four trees that returned zero, the same pass counted the word "annotations" 115 times in zep, 30 in graphiti, 210 in cognee and 36 in Memori ^[17].

Three of those four ship an MCP server in the same repository. zep registers 13 tools through mcp.AddTool under mcp/zep-mcp-server ^[18], graphiti registers 13 through @mcp.tool() decorators in mcp_server/src/graphiti_mcp_server.py ^[19], and cognee's sits under cognee-mcp/src ^[20]. Between them, zep and graphiti register 26 tools in trees where the count returned zero for all four field names ^[24]. Memori is a different case: the 6 registerTool calls under integrations/openclaw/src/tools belong to an OpenClaw plugin, and its MCP server is in a separate repository, MemoriLabs/memori-mcp ^[21].

All a zero in that count says is that those four strings are absent from the published source of that tree. For it to mean the deployed tools are unannotated, the registration code has to sit in the tree that was walked, and Memori shows that condition failing. If your own server registers tools through a wrapper that never touches these four fields, a client implementing the defaults applies all four defaults to every tool you expose ^[10]. A client following the NOTE applies none of them ^[9]. The dev.to author left his own published package out of the count. His reason was that measuring his own tree by a method he chose is not a comparison a reader should have to trust ^[23].