Skip to main content
Glama
Sign In

Semanto by Trooth

by co.trooth
OverviewDiscussionsAdmin

Check a signed URL

semanto_verify
Read-onlyIdempotent

Checks a page against the current signed version. With no hash, Trooth fetches the page as an agent does (Accept: text/markdown) and hashes what it is served, which is what semanto_install_check checks too; compared says which. When the live HTML changed after the last signature, the site serves the last signed bytes under a behind notice; the notice is stripped before hashing and served_state says behind. status: matches, differs (hash is what was found, signed_hash what was signed), not_served (the page did not answer with markdown), unknown_url or not_signed. No key needed.

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": "semanto_verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesThe address to check.
hashNoOptional: the sha256: digest of the markdown you were served, to compare instead of fetching.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / hash
      Added value: +{
+  "description": "Optional: the sha256: digest of the markdown you were served, to compare instead of fetching.",
+  "type": "string"
+}
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered; the description adds genuinely new behavior. It discloses the Accept: text/markdown fetch, the fact that a behind notice can be served and is stripped before hashing, that served_state reports this, and that no key is required. What it does not cover is cost/latency of the network call or caching behavior.

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

Conciseness3/5

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

The purpose is front-loaded in the first sentence, which is good, but the remainder is a dense run-on chain of clauses that mixes fetch semantics, notice stripping and the status enum in one paragraph. Fragments like 'compared says which' cost a re-read. The status vocabulary could be a compact list instead of a comma run.

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

Completeness4/5

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

There is no output schema, so the description carries the burden of describing return values and it largely does: status values (matches, differs, not_served, unknown_url, not_signed), plus the served_state, compared and signed_hash fields. A few of those fields are named without definition ('compared'), which is the main residual gap for a no-output-schema tool.

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 baseline would be 3, but the description earns more by explaining what the hash argument means in context: it is the digest of the markdown you were served, and supplying it switches the tool from fetching to comparing. It also clarifies the 'hash is what was found, signed_hash what was signed' distinction, which the schema does not.

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

Purpose4/5

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

The opening sentence gives a specific verb and resource: checking a page against its current signed version, and the status enumeration makes the outcome space concrete. It even names the sibling semanto_install_check as functionally equivalent, which helps an agent place it. It falls short of 5 because that sibling reference is framed as an equivalence rather than a reason to pick one over the other.

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

Usage Guidelines3/5

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

Usage is implied through the two modes: with no hash the tool fetches and hashes what it is served, with a hash it compares the digest the caller already holds. 'No key needed' removes a possible prerequisite. However, it never says when to reach for this instead of semanto_page, semanto_status or semanto_install_check, and no exclusions are stated.

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

All Semanto by Trooth toolsInspect
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