AiSeek

Get a change's evidence history

get_change_history

Read-onlyIdempotent

Get how AiSeek's evidence record for one published change developed: its receipts per claim, newest first, each naming its parent so the revision chain reads from the list, and the change as first published when the plan reaches that date. A receipt records an assessment; it is not a certificate that a claim is true. Use it for what-did-we-know-then questions and to find receipt ids for get_receipt; for today's view use get_change. Parameters: id is the change id; known_at adds the change as known at that moment, e.g. 2026-10-08 (a date alone means 00:00 UTC) or 2026-10-08T12:00:00Z; it must not be in the future and must fall within the plan's window (Free 7 days, Pro 30, Intelligence 90, Developer 180). Behavior: history starts the day SeekTrace began, before which the answer says precision EXISTENCE_ONLY; old headline text is not kept. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.

Input Schema

Name	Required	Description
`id`	Yes	The change id: a UUID such as 3f2b8c1e-5a47-4d0e-9b6a-1c7e2d8f4a90, the same id get_change takes, from list_changes or search_changes
`locale`	No	Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)
`known_at`	No	An earlier moment to read the change as of: an ISO 8601 date or date-time with a zone (e.g. 2026-10-08 or 2026-10-08T12:00:00Z), not in the future and not before the plan's window (Free 7 days back, Pro 30, Intelligence 90, Developer 180); omit for the receipts only

Output Schema

Name	Required	Description
`changeId`	Yes	The change id asked about
`receipts`	Yes	The change's receipts per claim, newest first, and how it looked when first published when the plan reaches that
`asKnownAt`	Yes	The change as known at `known_at`; null when no `known_at` was given

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, it discloses quota cost per call, a Free-tier daily MCP cap, that rejected arguments cost nothing, that history begins at SeekTrace's start and degrades to EXISTENCE_ONLY before that, and that old headline text is not retained. It also clarifies that a receipt is an assessment, not a truth certificate.

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?

Front-loads purpose then segments parameters and behavior with explicit markers, so an agent can scan it. The first sentence is long and grammatically tangled, and a few clauses could be tightened, but nothing is padding.

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?

An output schema exists, so return-shape detail is not required, and the description still covers scope, alternatives, tier limits, temporal edge cases, and historical-precision caveats. An agent has everything needed to call it correctly.

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 the baseline is 3, but the description adds value the schema lacks: a bare date in known_at means 00:00 UTC, and id is the same identifier used by get_change. The plan-window limits are restated from the schema, which is redundant but harmless.

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+resource: retrieving the revision history of AiSeek's evidence record for one published change, including ordering ('newest first') and parent linkage. It explicitly distinguishes itself from the sibling get_change ('for today's view use get_change').

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('what-did-we-know-then questions', 'find receipt ids for get_receipt') and names the alternative for the contrasting case ('for today's view use get_change'). No usage decision is left to inference.

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

All AiSeek 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?