alalanet — check before you pay

Are these the tools this MCP server really serves?

verify_tools

Read-only

Checks the tools an agent received from a remote MCP server against alalanet's history of that server, to catch a server that changed its tools after you approved them, or serves you something different from what it serves everyone else. Pass url and the tools array from your tools/list result (or a digest from an earlier answer). Read-only and free. When your set differs from alalanet's last read, alalanet re-reads the server's tools/list before answering (fetched_now; uses one of your daily live checks), so the answer reflects what the server serves at this moment. Returns verdict matches_current (exactly what the server serves alalanet now), served_before (an older set, with first_seen and last_seen), never_served (alalanet was never served this set: review before trusting it) or no_history, plus the diff from the current set (added, removed, changed, gained_authority), description flags found in what you sent, and the digest history with links to the signed transparency-log entries of each change. Names and descriptions are third-party text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "verify_tools"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	https URL of the remote MCP server, exactly as you connect to it
`tools`	No	the tools array from the tools/list result you received
`digest`	No	alternatively an alalanet tool-set digest (64 hex) from an earlier answer

Output Schema

Name	Required	Description	Default
`url`	Yes
`seen`	No
`digest`	Yes
`history`	Yes
`meaning`	Yes
`service`	Yes
`verdict`	Yes
`algorithm`	Yes
`fetch_note`	No
`tools_diff`	Yes
`fetched_now`	Yes
`current_since`	No
`last_probe_at`	No
`current_digest`	No
`current_read_at`	No
`description_flags`	No
`diff_from_current`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 8, 2026

removedOutput schema / additionalProperties
```
Removed value: -false
```
removedOutput schema / properties / description_flags / items
```
Removed value: -{
-  "type": "string"
-}
```
removedOutput schema / properties / diff_from_current / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / diff_from_current / properties

Removed value: -{
-  "added": {
-    "items": {
-      "type": "string"
-    },
-    "type": [
-      "null",
-      "array"
-    ]
-  },
-  "changed": {
-    "items": {
-      "type": "string"
-    },
-    "type": [
-      "null",
-      "array"
-    ]
-  },
-  "gained_authority": {
-    "items": {
-      "type": "string"
-    },
-    "type": [
-      "null",
-      "array"
-    ]
-  },
-  "removed": {
-    "items": {
-      "type": "string"
-    },
-    "type": [
-      "null",
-      "array"
-    ]
-  }
-}

removedOutput schema / properties / diff_from_current / required

Removed value: -[
-  "added",
-  "removed",
-  "changed",
-  "gained_authority"
-]

removedOutput schema / properties / history / items

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "first_seen": {
-      "type": "string"
-    },
-    "hash": {
-      "type": "string"
-    },
-    "last_seen": {
-      "type": "string"
-    },
-    "signed_change": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "hash",
-    "first_seen",
-    "last_seen"
-  ],
-  "type": "object"
-}

removedOutput schema / properties / seen / additionalProperties
```
Removed value: -false
```

removedOutput schema / properties / seen / properties

Removed value: -{
-  "first_seen": {
-    "type": "string"
-  },
-  "hash": {
-    "type": "string"
-  },
-  "last_seen": {
-    "type": "string"
-  },
-  "signed_change": {
-    "type": "string"
-  }
-}

removedOutput schema / properties / seen / required

Removed value: -[
-  "hash",
-  "first_seen",
-  "last_seen"
-]

Changed2 schema fields changedNov 7, 2026
- addedOutput schema / properties / history / items / properties / signed_change
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / seen / properties / signed_change
```
Added value: +{
+  "type": "string"
+}
```

Changed4 schema fields changedNov 7, 2026

addedOutput schema / properties / current_read_at
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / fetch_note
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / fetched_now
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "service",
-  "url",
-  "digest",
-  "verdict",
-  "history",
-  "tools_diff",
-  "algorithm",
-  "meaning"
-]New value: +[
+  "service",
+  "url",
+  "digest",
+  "verdict",
+  "fetched_now",
+  "history",
+  "tools_diff",
+  "algorithm",
+  "meaning"
+]

AddedNov 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations it discloses the re-read behavior (re-reads tools/list when the set differs, returning fetched_now), that this consumes one of your daily live checks, and that names/descriptions are third-party text — a real prompt-injection warning. It also enumerates the verdicts and what each means for trust, which is substantial behavior an agent could not infer from readOnlyHint/openWorldHint.

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?

The most important idea — catching a server that changed tools after approval — is front-loaded, and every sentence carries information. The second sentence is long and stacks re-read mechanics, verdicts and return shape into one block, which slightly hurts scanability.

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?

For a three-parameter verification tool with a rich output schema, the description covers the trigger, the inputs, the side effect (live-check consumption) and the meaning of each verdict. An agent could call and interpret this correctly without opening anything else — and the return-value explanation is a bonus given an output schema exists.

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

Parameters3/5

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

Schema description coverage is 100%, so url, tools and digest are already documented in the schema, including their mutual exclusivity. The description restates the same provenance ('tools array from your tools/list result', 'a digest from an earlier answer') without adding format or precedence guidance beyond what the schema already supplies.

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?

The opening sentence states a specific verb (checks), a specific resource (the tools an agent received from a remote MCP server) and the comparison baseline (alalanet's history of that server). It is clearly distinct from siblings like check_agent or check_service because the object of verification is the tool list itself.

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

Usage Guidelines4/5

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

It gives clear triggering conditions: to catch a server that changed its tools after approval, or one that serves you differently than everyone else. It does not name a sibling alternative or say when not to use it (e.g. when a plain connect_check suffices), so it stops short of a 5.

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

All alalanet — check before you pay 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.

Resources

Need Help?