AstraNL local proof NL

get_evidence

Read-onlyIdempotent

Machine-checkable evidence for an AstraNL task, action or receipt: the signed log events that mention it, each verified live, with a proof block stating what is verified, what is not, validity, status, limitations and next actions.

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": {
      "task_id": "<task_id>"
    },
    "name": "get_evidence"
  }
}

Input Schema

Name	Required	Description	Default
`task_id`	Yes	task id, action id or receipt id

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 10, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), but the description adds valuable behavioral context: it states that events are verified live and that the response includes a proof block detailing what is verified, what is not, validity, status, limitations, and next actions. It stops short of describing performance, error conditions, or the exact proof block format.

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?

The description is a single, front-loaded sentence that packs the purpose, the returned data, and the proof block contents without redundant phrasing. Every clause contributes to understanding what the tool does and returns.

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?

With no output schema, the description carries the burden of explaining return values, and it does so by naming the signed log events and enumerating the proof block fields. Combined with annotations that cover the read-only safety profile and a fully documented parameter, an agent has enough information to invoke and interpret the tool correctly.

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% and the single parameter's schema already explains that it accepts a task, action, or receipt id. The description reinforces that the evidence pertains to those entities but adds no syntax, format, or constraint details beyond the schema.

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 description specifies the resource (machine-checkable evidence for an AstraNL task, action or receipt) and the returned artifact (signed log events plus a proof block), so the tool's purpose is clear. It does not compare itself to siblings like check_task or verify_astranl, leaving differentiation to the agent.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus the sibling tools, nor any prerequisites or exclusions. The description only defines what the tool returns, not the situations that call for it.

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

All AstraNL local proof NL tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?