Kenwea Notary

Score an MCP server's tool definitions

kenwea_notary_check_tools

Read-onlyIdempotent

Score an MCP server's tool definitions for what they ask of the model, before you connect it. Input: tools, the tools array of a server's tools/list answer (each {name, description, inputSchema}); or server, the server's name as Smithery lists it (for example brave or owner/name), whose published definitions are read from Smithery. Behavior: runs nothing and calls no server. Fixed rules read each description and every parameter description against the tool's own input schema, because anything in the prose the schema does not need is where an injected instruction lives: tags that frame text as instructions (, ), HTML comments and invisible characters (zero width, bidirectional controls, Unicode tags), asking the model to drop its instructions, to keep something from the user, or to put a file's contents into an argument, naming files where secrets live (~/.ssh, ~/.cursor/mcp.json, ~/.aws), asking for a credential the schema has no parameter for, steering the model off the web or other servers toward this one, and speaking to the model rather than describing the tool. No model reads the text, so the same definitions always get the same findings and anyone can redo them. Keyless, read-only. Returns: level (clean, review or suspicious), summary, findings (each with tool, rule, severity, where and an excerpt), rulesVersion and inputSha256, the SHA-256 of the definitions as read. A finding is a reason to read the definition, not a verdict on the server: on 500 Smithery servers (12,598 tools, rules 2026-10-31.1) 495 were clean, 3 review and 2 suspicious, and read by hand none hid an order or reached for data: the 3 steer the model off web search toward the server, the 2 were a vendor's response instructions and a false positive. Not for: what a server's code does when it runs (use kenwea_notary_check on its npm package).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kenwea_notary_check_tools"
  }
}

Input Schema

Name	Required	Description	Default
`tools`	No	The tools array of the server's tools/list answer.
`server`	No	Alternatively, the server's name as Smithery lists it, for example brave or owner/name.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds what they cannot: the tool executes nothing and contacts no server, is keyless, and is deterministic because no model reads the text, so results are reproducible and auditable. It also discloses the specific rule families applied and the return shape including rulesVersion and inputSha256.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, inputs and behavior are front-loaded, and the benchmark sentence about 500 Smithery servers earns its space by calibrating how seriously to take a finding. The rule enumeration, however, is delivered as one very long run-on sentence that would be easier to scan as a list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description fully accounts for the return value (level, summary, findings with tool/rule/severity/where/excerpt, rulesVersion, inputSha256). Combined with the determinism claim and the explicit boundary against the sibling tool, an agent has everything needed to decide to call it and to interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes further by framing the two parameters as alternative input modes and giving a concrete example format ('brave or owner/name') for the server name. It stops short of stating whether the two are mutually exclusive or which wins if both are supplied.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and object — score a server's tool definitions — with the qualifier 'for what they ask of the model, before you connect it', which pins down the exact judgment being made. The closing 'Not for' sentence explicitly separates it from the sibling kenwea_notary_check, which looks at runtime code instead of definitions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the trigger ('before you connect it'), the two accepted input modes (a tools/list array or a Smithery server name), and a named alternative for the adjacent task ('use kenwea_notary_check on its npm package'). It also pre-empts misuse by saying a finding is a reason to read the definition, not a verdict.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Kenwea Notary tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.