Vitruveo Chain Tools MCP

historical availability

historical_availability

Read-only

Probe historical block and state data for a specific address and block to check availability; results indicate point-in-time access, not complete archive coverage.

Instructions

Point probes of historical block and state; never proof of complete archive coverage.

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

Input Schema

Name	Required	Description	Default
`address`	No
`blockNumber`	No		0

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0-rc.1Nov 9, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuine behavioral caveat beyond that: results are point samples and must not be interpreted as proof of complete archive coverage. It still omits what happens for unavailable blocks/addresses (error vs. false vs. empty), which matters for a probe tool.

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?

A single short sentence with the scope statement front-loaded and the caveat second; no filler. It is terse to the point of under-specification, but the structure itself is sound.

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

Completeness2/5

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

With no output schema, 0% schema description coverage, and two undocumented parameters, the description carries the full explanatory burden and delivers only a one-line caveat. It does not say what a positive or negative result looks like, nor how the two parameters shape the probe, leaving real gaps for a tool whose entire purpose is interpreting availability.

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

Parameters2/5

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

Schema description coverage is 0% and the description supplies no parameter meaning at all. Only a loose mapping exists: "historical block" hints at blockNumber and "state" at address, but nothing explains the address format, that blockNumber defaults to "0", or that "latest" is accepted. For a 2-param tool with zero documented fields, the description fails to compensate.

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

Purpose3/5

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

"Point probes of historical block and state" names the resource (historical block/state data) but uses jargon ("point probes") instead of a concrete verb like "check" or "query". An agent can infer this is an availability spot-check rather than a data-fetch, but the description never states what is actually returned (a boolean? a block? an error?), and it does not distinguish itself from siblings like block_details or address_history_page.

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: the phrase "never proof of complete archive coverage" signals this is for spot-checking archival availability, not for exhaustive verification. There is no explicit when-to-use or when-not-to-use statement, and no named alternative for the full-coverage case, so the agent must infer the routing decision.

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

Deploy Server