Skip to main content
Glama
Sign In
sdc-mapper-mcp

sdc-mapper-mcp

Official
by SemanticDataCharter
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_log

Walks the audit log's hash chain from the first entry to report whether any entry was altered or removed, confirming log integrity.

Instructions

Walk the log's hash chain from the first entry and report whether any entry was altered or removed.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.1.1

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It usefully discloses that the walk starts at the first entry and covers both alteration and removal, which implies a read-only, whole-log operation, but it says nothing about cost/latency on long chains, whether it short-circuits at the first bad entry, or whether auth is required.

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

Conciseness5/5

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

A single sentence with the operation and its result front-loaded; every clause earns its place and nothing is redundant.

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?

No output schema exists, but the description conveys the key return semantics (tampered-or-removed vs. clean). Minor gaps remain — result granularity (per-entry vs. boolean) and behavior on failure — which keep it just short of complete.

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?

The tool takes zero parameters, so the baseline is 4; there are no parameter semantics to explain and the description correctly implies it is invoked without arguments, scoped only to 'the log'.

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 specific verb and resource (walk the log's hash chain from the first entry) plus the exact outcome it produces (whether any entry was altered or removed). This is clearly distinguishable from siblings like log_summary or fidelity, which do not claim integrity verification.

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 only implied by the verb 'verify' — an agent can infer this is for integrity/tamper checking. There is no explicit when-to-use vs. log_summary or when-not guidance (e.g., cost on very large logs, or that it only covers this log's chain).

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

Deploy Server

Other Tools