Verified world changes with sources: topics, companies, countries, SeekEarth and evidence receipts.
Scored across 16 tools
The tools mostly target distinct resources and actions, and descriptions explicitly redirect overlapping cases (e.g. list_changes vs search_changes vs get_topic, get_change vs get_change_history). A few boundaries still require careful reading, especially change retrieval versus history/receipt tools, but the set is generally easy to distinguish.
All tool names follow a consistent snake_case verb_noun convention: get_*, list_*, search_*, and verify_receipt. The verb choice matches the operation type predictably throughout the set.
Sixteen tools is reasonable for a broad read-only intelligence API spanning changes, topics, companies, countries, receipts, briefs, events, and corrections. It is slightly above the typical compact range, but each tool maps to a meaningful resource or operation.
The surface covers the core lifecycle of browsing, searching, retrieving, tracing evidence, and checking corrections across the main domains. Minor gaps remain, such as no tool for retrieving dossier pages despite dossierId being surfaced, and no dedicated scheduled-event detail tool.
Get one published change with its scores, main subject and every outlet that reported it (name, link, date, evidence level, role). Use it after list_changes, search_changes or get_topic to see who reported a change; for its receipts and what AiSeek knew earlier use get_change_history. Parameters: id is the change UUID from those tools, or the last part of an aiseek.dev/{locale}/signals/{id} link; locale translates headline and summary only, while source names and links are the same in every language. Behavior: scores and sources can grow as later reports arrive, so a second call may return more; quoted passages are never returned; a dossierId points to https://aiseek.dev/{locale}/stories/{dossierId}, which no tool returns; a withdrawn or unknown id is an error. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The change id: a UUID such as 3f2b8c1e-5a47-4d0e-9b6a-1c7e2d8f4a90, taken from the id of an item in list_changes, search_changes or get_topic; an unpublished id is an error | |
| 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) |
| Name | Required | Description |
|---|---|---|
| id | Yes | The change id |
| url | Yes | The change's page on aiseek.dev |
| title | Yes | Headline in the requested language |
| scores | No | AiSeek's scores for the change |
| locales | No | Languages the headline exists in (en, zh, ja) |
| sources | Yes | The sources that reported the change: names and links only, never quoted passages |
| summary | No | Summary in the requested language |
| dossierId | No | Id of the in-depth dossier on this change, when one is published |
| detectedAt | Yes | ISO 8601 time AiSeek detected the change |
| reportedAt | No | ISO 8601 time the first source reported it, when known |
| signalType | No | The kind of change |
| effectiveAt | No | ISO 8601 time the change takes effect, when it has one |
| primaryEntity | No | The main company or subject |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real operational context: scores/sources can grow so a later call may return more, quoted passages are never returned, a dossierId maps to a URL no tool exposes, withdrawn/unknown ids error out, and one call consumes quota while rejected arguments are free. That is well beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is front-loaded (purpose, then usage, then 'Parameters:' and 'Behavior:' blocks) and nearly every clause carries actionable information. It is longer than a minimal definition, but the density of constraints justifies it rather than padding it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be described, and the description still covers error cases (withdrawn/unknown id), quota cost, result mutability over time, and the dossierId link convention. Nothing needed to invoke this tool correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning the schema does not: id may be taken from a UUID returned by sibling tools or from the last path segment of an aiseek.dev/{locale}/signals/{id} link, and locale only translates headlines/summaries while source names and links stay identical across languages.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get one published change') and enumerates the returned content (scores, main subject, every reporting outlet with name, link, date, evidence level, role). It also explicitly separates itself from get_change_history, list_changes, search_changes and get_topic, so an agent can route without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the exact upstream tools whose ids feed this call ('Use it after list_changes, search_changes or get_topic') and names the alternative for a different need ('for its receipts and what AiSeek knew earlier use get_change_history'). When-to-use and when-to-use-something-else are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
| 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 |
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.
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.
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.
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.
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.
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.
Get a company's AiSeek profile: name, home country, legal name, website, listings, description, recent published changes, the facts AiSeek states about it and its relations to other entities. Use it after search_companies. Do not use it to search by name (search_companies) or for news about the company (search_changes). Parameters: slug is the exact company slug from search_companies (e.g. toyota); locale changes names, descriptions and headlines. Behavior: a description from Wikipedia carries its link (CC BY-SA 4.0); filings are left out; an unknown slug is an error. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The exact AiSeek company slug (lower case letters, digits and hyphens, e.g. toyota), taken from search_companies | |
| 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) |
| Name | Required | Description |
|---|---|---|
| url | Yes | The company's page on aiseek.dev |
| claims | No | Facts AiSeek states about it |
| entity | Yes | The company |
| profile | No | Legal name, website, reporting currency, headquarters country, description source |
| signals | No | Its recent published changes |
| relations | No | Its stated relations to other entities |
| securities | No | The company's listings |
| description | No | A short description; one taken from Wikipedia carries its link (CC BY-SA 4.0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent/destructive annotations already present, the description still adds real behavioral context beyond them: Wikipedia-sourced descriptions carry a CC BY-SA 4.0 link, filings are excluded, an unknown slug is an error, and the call consumes one unit of the key's quota (with rejected arguments costing nothing). This is exactly the kind of cost/error/attribution detail annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage, parameters and behavior in a compact three-sentence block with no filler. The field enumeration is slightly long and the parameter/behavior clauses are dense, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation, and the description covers the remaining gaps an agent needs: slug provenance, locale effect, attribution, error on unknown slug, and quota cost. Nothing relevant is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 sourcing guidance ('the exact company slug from search_companies') that tells the agent where the value must come from, and clarifies that locale changes names, descriptions and headlines rather than only the schema's narrower 'headlines, summaries and notices'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get a company's AiSeek profile') and enumerates the returned content (name, home country, legal name, website, listings, description, facts, relations). It explicitly distinguishes itself from search_companies and search_changes, so an agent can pick it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing ('Use it after search_companies') plus two negative cases with the sibling that covers each: search_companies for lookup by name, search_changes for news. This is the full when/why-not/alternative triad.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SeekEarth's Change Heat per country: how much verified change each country had against its own recent normal, 0 to 100, where 50 is an ordinary day; it measures change, never danger or instability. Use it to see where things are changing; for all country codes use list_countries, for the changes themselves search_changes, for one place at one moment get_earth_view. Parameters: country (e.g. jp or JP) narrows the answer to one country, otherwise the 60 hottest come back; days sets the window, e.g. 1 for today against normal or 30 for a month; domain (e.g. MARKETS) counts one coverage domain. Behavior: a days value above the plan's cap (Free 7, Pro 30, Intelligence and Developer 90) is cut to the cap without an error, and days/maxDays in the answer show what was used; heat is computed once a day (asOf); changes with no single country are left out. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days, 1 to 90 (default 7); capped by the key's plan: Free 7, Pro 30, Intelligence and Developer 90 | |
| domain | No | Only changes of this coverage domain; omit for the connection's default domain, or all domains when none is set | |
| 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) | |
| country | No | ISO 3166-1 alpha-2 country code, e.g. JP or US, upper or lower case; omit for every country (the 60 hottest) |
| Name | Required | Description |
|---|---|---|
| map | Yes | The SeekEarth page on aiseek.dev for this view |
| asOf | Yes | The last day (UTC, YYYY-MM-DD) the heat was computed for |
| days | Yes | The window used, after the plan's cap |
| method | Yes | Short name of the method version used to compute Change Heat |
| maxDays | Yes | The longest window the plan allows |
| countries | Yes | Countries by heat, highest first (at most 60), or the one country asked for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/non-destructive semantics, and the description still adds substantial non-structured behavior: the plan cap clamp (Free 7 / Pro 30 / Intelligence and Developer 90) that truncates silently rather than erroring, days/maxDays echoed in the answer, once-a-day computation (asOf), exclusion of country-less changes, and quota cost per call. These are exactly the traits an agent needs to predict results and avoid surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph, front-loaded with purpose, then usage alternatives, then parameters, then behavior — a logical order with no filler sentences. It is on the long side for a single block, but every clause carries distinct information and nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and it covers everything else an agent needs: metric interpretation, when to use it vs siblings, all four parameters with examples, plan-based clamping, quota cost, and data-freshness caveats. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 usable semantics beyond the schema: case-insensitive country codes (jp or JP) with the 60-hottest default, and concrete days readings ('1 for today against normal or 30 for a month') that clarify the window's meaning, not just its range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (per-country Change Heat) and instantly defines the metric's scale and meaning (0-100, 50 = ordinary day, measures change not danger). It also explicitly names the siblings it is not (list_countries, search_changes, get_earth_view), so the agent can disambiguate without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('see where things are changing') and routes three adjacent needs to the correct alternative tools by name. This is routing information an agent can act on directly, not implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SeekEarth for one place and moment: the published changes placed there, the Change Heat of its countries, and the Earth's layer items in force (disaster alerts, cyclones, official warnings, conflict, outbreaks, river levels and more), each with its nature and source to credit. Use it for where-and-when questions; for heat across all countries use get_country_heat, for the country list list_countries, for changes by subject search_changes. Parameters: give country, or lat with lon and a radius_km circle; at sets the moment and days the window before it; mode NOW reads today's knowledge of those days, KNOWN what readers could see at the time; layers narrows the Earth layers. Behavior: at most 30 changes, most important first; in KNOWN mode changes withdrawn since are only counted (withdrawnLater); a place is required. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | The moment to read, ISO 8601 date or date-time with a zone (default now); not in the future and within the plan's reach | |
| lat | No | Latitude of the place in degrees (with lon); the place is a circle of radius_km around it | |
| lon | No | Longitude of the place in degrees (with lat) | |
| days | No | Window in days before `at`, 1 to 180 (default 7); capped by the key's plan | |
| mode | No | NOW (default): today's knowledge of the window; KNOWN: what readers could see at `at` | NOW |
| layers | No | Which Earth layers to include (e.g. gdacs, nhc, jma, ucdp, aftershock); omit for every event layer | |
| 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) | |
| country | No | ISO 3166-1 alpha-2 country code, e.g. JP; give either this or lat and lon | |
| radius_km | No | Radius of the circle around lat and lon, 10 to 3000 km (default 500) |
| Name | Required | Description |
|---|---|---|
| at | Yes | The moment read, ISO 8601 UTC |
| url | Yes | The SeekEarth page on aiseek.dev for this place |
| days | Yes | The window in days, after the plan's cap |
| from | Yes | Start of the window, ISO 8601 UTC, after the plan's cap |
| heat | Yes | Change Heat of the place's countries on the UTC day of `at` |
| mode | Yes | KNOWN: what readers could see at `at`; NOW: today's knowledge of the same days |
| place | Yes | The place asked about: {country} or {lat, lon, radiusKm} |
| events | Yes | Items of the Earth's layers in force there (disasters, warnings, forecasts, conflict, displacement, outbreaks, power plants...), each with its layer's nature and source |
| changes | Yes | Published changes placed there in the window, most important first (at most 30); knownAfter and wordingChangedLater mark NOW-only differences |
| maxDays | Yes | The longest window the plan allows |
| sources | Yes | Where each layer comes from and how to credit it |
| withdrawnLater | Yes | KNOWN only: changes readers could see then that have been withdrawn since (counted, never shown) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description still adds real operational context: a cap of 30 changes ordered by importance, KNOWN mode counting withdrawn changes separately (withdrawnLater), a required place, quota consumption per call, and that a rejected argument costs nothing. The only missing behavioral detail is the shape/sectioning of the combined answer, which the output schema presumably covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then routing, then parameters, then behavior — a sensible order with no filler sentences. It is dense and slightly repetitive with the schema (parameters, mode, layers), which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter tool with an output schema, the description covers the things structure cannot: quota cost, required input, result truncation, and mode semantics. An agent has everything needed to call it correctly and interpret the caps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description usefully consolidates the place contract ('give country, or lat with lon and a radius_km circle') and the at/days and NOW-vs-KNOWN relationship, but these restate what the schema properties already say rather than adding new constraints or formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Get SeekEarth for one place and moment' — and immediately enumerates the composite payload (published changes placed there, Change Heat of its countries, Earth layer items in force). It names the sibling tools it is not (get_country_heat, list_countries, search_changes), so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case ('where-and-when questions') and then routes to three named alternatives with the condition that selects each. Nothing about tool selection 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.
Get the latest brief: AiSeek's own summary of a period's changes, grouped by section, each item linking to its page. Use it for a digest; for the raw newest-first list use list_changes, for a subject get_topic or search_changes. Parameters: type DAILY (the default) covers the last UTC day, WEEKLY the last week plus its largest market moves and the coming week's events; locale picks that language's edition of the same brief (zh, en or ja). Behavior: on a Free key a brief opens one day after publication; a younger one returns only title and summary with locked true and unlocksAt; an error if none has been published yet. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | DAILY (the default): one UTC day's changes; WEEKLY: the week's changes with market moves and the week ahead | DAILY |
| 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) |
| Name | Required | Description |
|---|---|---|
| id | Yes | The brief id |
| url | Yes | The brief's page on aiseek.dev |
| date | Yes | The day the brief covers, UTC, YYYY-MM-DD |
| title | Yes | The brief's title |
| locked | No | True on a Free key for a brief younger than one day: only title and summary are given |
| summary | No | The brief's summary |
| nextDate | No | The date of the next brief of this type |
| sections | Yes | The period's changes by section; empty while a Free key's brief is still locked |
| briefType | Yes | DAILY or WEEKLY |
| periodEnd | Yes | End of the period, ISO 8601 |
| unlocksAt | No | When a locked brief opens for Free, ISO 8601 |
| periodStart | Yes | Start of the period, ISO 8601 |
| publishedAt | No | When the brief was published, ISO 8601 |
| previousDate | No | The date of the previous brief of this type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), and the description adds substantial context beyond them: Free-key one-day publication delay, the locked/unlocksAt partial payload for younger briefs, an error when nothing is published, quota cost of one call, and that a rejected argument costs nothing. This is exactly the behavioral detail annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, then routing, then a labelled 'Parameters:' block, then a labelled 'Behavior:' block. Dense but zero filler, and every clause (quota, lock window, error case) earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, and the description still covers the remaining gaps an agent needs: publication delay, partial-payload locking, empty-state error, and quota cost. Nothing material to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond the schema: DAILY is stated as the default covering the last UTC day, WEEKLY adds 'the coming week's events' (the schema only says 'the week ahead'), and locale is framed as selecting the same brief's language edition (zh/en/ja). It does not add syntactic or format detail the schema lacks, so it stays just above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Get the latest brief'), defines what it actually is ('AiSeek's own summary of a period's changes, grouped by section, each item linking to its page'), and explicitly distinguishes it from list_changes, get_topic, and search_changes. An agent can select this tool without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use ('Use it for a digest') and names three alternatives with the conditions that route to each: 'for the raw newest-first list use list_changes, for a subject get_topic or search_changes.' Nothing 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.
Get one SeekTrace evidence receipt: the immutable record of how AiSeek assessed one claim (class FACT, SUPPORTED or HYPOTHESIS, statuses, valid time, evidence links and digests, independence counts, parent receipt, sha256 digest). A receipt records an assessment; it is not a certificate that a claim is true. Use it to read what a receipt says; to check the stored record is unchanged use verify_receipt. Parameters: id is a receipt id from get_change_history (receipts[].id), never a change id; pass the same id to verify_receipt; locale translates only the notice, the record itself is language-neutral. Behavior: a receipt never changes once written (a revision is a new receipt with this one as parent); only public receipts are readable, on every plan; withheld source links are counted in redactedEvidence. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the get_change_history result; only public receipts can be read | |
| 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) |
| Name | Required | Description |
|---|---|---|
| notice | Yes | A reminder that a receipt is not a certificate of truth, in the requested language |
| receipt | Yes | |
| redactedEvidence | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, yet the description adds genuinely new behavior: receipts are immutable and revisions are new receipts with the old one as parent, only public receipts are readable on every plan, withheld links are surfaced via redactedEvidence, and a call consumes quota while a rejected argument costs nothing. That is real operational context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the core definition comes first, then usage routing, then parameter notes, then behavior. Every clause carries information, though the packed parenthetical lists (field enumerations, quota asides) make it heavier than it strictly needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and it covers the remaining gaps: how to obtain the id, immutability semantics, access constraints, redaction behavior, and cost. An agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3, but the description adds disambiguation the schema does not: the id is a receipt id rather than a change id, and the same id is what verify_receipt expects. It also clarifies that locale translates only the notice while the record itself is language-neutral.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Get one SeekTrace evidence receipt' — and then defines what a receipt is (immutable record of how AiSeek assessed one claim) plus the fields it carries. It explicitly contrasts itself with the sibling verify_receipt, so an agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit use rule ('Use it to read what a receipt says; to check the stored record is unchanged use verify_receipt'), names the sibling that covers the other case, and tells the agent where the id comes from (get_change_history receipts[].id, never a change id). When-to-use and the alternative are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one published topic and up to 50 of its published changes from the last 90 days, most relevant first. Use it after list_topics to read what is happening in a subject; for words that are not a topic use search_changes, for the newest changes overall list_changes. Parameters: slug is the topic's slug exactly as list_topics returns it; locale changes names and headlines. Behavior: a topic with no recent change returns its profile and an empty list; an unknown slug is an error. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The topic slug (lower case letters, digits and hyphens), taken from list_topics | |
| 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) |
| Name | Required | Description |
|---|---|---|
| url | Yes | The topic's page on aiseek.dev |
| topic | Yes | The topic |
| changes | Yes | Up to 50 of the topic's published changes from the last 90 days, most relevant first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: quota cost per call, a daily MCP cap for Free keys, that rejected arguments cost nothing, that a topic with no recent change returns its profile plus an empty list, and that an unknown slug is an error. This is exactly the operational context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, followed by routing, parameter notes, and behavior in tight labeled clauses. No filler; every sentence carries decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present the description need not explain return shapes, and annotations cover safety. Combined with the quota, error, and empty-result notes, an agent has everything needed to call this correctly in one shot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning: slug must be 'exactly as list_topics returns it' (cross-tool provenance the schema only hints at), and locale 'changes names and headlines', clarifying the effect rather than just the allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'Get one published topic and up to 50 of its published changes from the last 90 days, most relevant first.' It also implicitly distinguishes itself from list-style siblings by framing this as reading a single subject's activity. An agent can tell what it returns without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit sequencing and routing: 'Use it after list_topics', 'for words that are not a topic use search_changes', 'for the newest changes overall list_changes'. Both the when and the when-not are named with concrete alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the newest published changes on AiSeek (verified changes in economy, markets, policy, technology, companies and science), newest first, 20 per page. Use it to see what is new; to look for a subject, company or country use search_changes, to browse a curated subject use list_topics, and for a digest use get_latest_brief. Parameters: start at page 0 and pass page + 1 while hasMore is true; locale only changes the language of headlines. Behavior: new changes appear as they are published, so page 0 can shift between calls; pages stop at 25 (500 changes). One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, from 0 (the newest 20); each page has 20 changes, up to page 25 | |
| 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) |
| Name | Required | Description |
|---|---|---|
| page | Yes | The page returned, from 0 |
| items | Yes | Up to 20 changes, newest first |
| hasMore | Yes | True when another page exists (pass page + 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial behavior beyond them: page 0 shifts as new changes publish, pages stop at 25 (500 changes), a call consumes the key's quota and rejected arguments are free. This is exactly the operational context an agent needs and cannot get from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every clause carries information: purpose, routing, pagination, behavior, quota. It is delivered as one dense paragraph, so the pagination and quota details are slightly buried rather than front-loaded, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. Given the tool's simplicity (2 optional params), the description covers everything an agent needs: what is returned, ordering, page limits, live-shift caveat, iteration rule, and quota cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description exceeds it by explaining the iteration contract ('start at page 0 and pass page + 1 while hasMore is true') and clarifying that locale affects only the language of headlines, not content selection. It adds genuine meaning about how the two parameters interact with control flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the newest published changes on AiSeek'), plus ordering and page size ('newest first, 20 per page'), and scopes the content domains. It explicitly names the sibling tools it is not (search_changes, list_topics, get_latest_brief), so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use statement ('Use it to see what is new') and routes three distinct alternatives by intent: search_changes for a subject/company/country, list_topics for a curated subject, get_latest_brief for a digest. The selection criteria are stated rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List public corrections about published content, newest first: changes taken down, and changes or dossiers whose evidence was corrected and is under review or was resolved in the last 30 days. Use it to check whether something you read earlier was corrected or to audit AiSeek's error record. Do not use it for one change's evidence history (get_change_history) or new changes (list_changes). Parameters: limit counts corrections from the newest (1 to 50, default 20 or the connection's default); there is no paging, so ask for 50 to see the whole window; locale translates titles. Behavior: nothing is withdrawn automatically: a correction flags what depends on the corrected evidence for review; the window reaches back as far as the plan's (Free 7 days to Developer 180); titles appear only where they may be shown. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many corrections to return, 1 to 50, newest first; omit for the connection's default (20 unless set) | |
| 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) |
| Name | Required | Description |
|---|---|---|
| url | Yes | The corrections page on aiseek.dev |
| items | Yes | |
| hasMore | Yes | |
| nextCursor | Yes | |
| windowDays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world, so the bar is low; the description nonetheless adds substantial non-obvious behavior: nothing is withdrawn automatically, a correction only flags dependents for review, the lookback varies by plan (Free 7 days to Developer 180), titles are shown only where permitted, and quota semantics (one call, rejected argument is free).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single dense paragraph, but front-loads the purpose and routes to alternatives before the parameter and quota details. Every sentence carries operative information (window depth, paging absence, quota cost) rather than filler, though the run-on sentence structure makes it slightly harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be restated, and the description fills the remaining gaps an agent needs: scoping (public, newest-first), depth limits, plan-dependent window, no paging, quota cost, and display restrictions. Nothing required for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description still adds real value by explaining that limit counts from the newest, that there is no paging so limit=50 should be requested to see the whole window, and that locale translates titles. It does not add new syntax beyond that, keeping it at 4 rather than 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) plus resource (public corrections about published content) and ordering (newest first), and immediately bounds the set: taken-down changes plus changes/dossiers with corrected evidence. It names the sibling tools it must not be confused with, so an agent can separate it from get_change_history and list_changes without reading any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two concrete positive use cases ('check whether something you read earlier was corrected', 'audit AiSeek's error record') and two explicit exclusions with the alternative named for each (get_change_history for one change's evidence, list_changes for new changes). When-to-use and when-not-to-use are both fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every country and territory AiSeek places changes in, with its name, its number of published changes in the last 7 days and its Change Heat on the last day. Use it to get all country codes at once or to see which countries have news; for heat details and seven-day series use get_country_heat, for what happened in one place get_earth_view. Parameters: domain counts only changes of one coverage domain (falls back to the connection's default); locale changes the country names. Behavior: about 180 entries in one answer, most changes first, then by code; a country with no change has heat null, not 0; Free keys see at most 7 days. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Count only changes of this coverage domain; omit for the connection's default domain, or all domains when none is set | |
| 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) |
| Name | Required | Description |
|---|---|---|
| asOf | Yes | The last day (UTC, YYYY-MM-DD) the counts were computed for |
| days | Yes | The window the counts cover, in days (7, or the plan's cap when smaller) |
| countries | Yes | Every country and territory AiSeek places changes in, most changes first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/destructive behavior, and the description adds material context beyond them: result size (~180 entries), ordering (most changes first, then by code), null-vs-0 heat semantics, the Free-key 7-day data limit, and quota/cost behavior including that a rejected argument costs nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: purpose first, then usage/exclusions, then parameters, then behavior and cost. Every segment carries information, though the parameters sentence partially duplicates the already-complete schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-optional-parameter list tool with an output schema, the description covers everything an agent needs to call it correctly: scope, alternatives, ordering, null semantics, plan-based data limits, and quota cost. Return values are covered by the output schema and additionally summarized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both enum parameters are already fully documented in the schema, so the baseline is 3. The description's parameter notes largely restate the schema (domain filtering, locale affecting names) and only lightly adds the fallback framing, so it does not clearly exceed the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every country and territory AiSeek places changes in') plus the exact payload (name, count in last 7 days, Change Heat on the last day). It explicitly names the sibling tools it is not (get_country_heat, get_earth_view), so an agent can select it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives two positive use cases ('get all country codes at once', 'see which countries have news') and two explicit exclusions with routing: get_country_heat for heat details and seven-day series, get_earth_view for a single place. When/when-not/alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scheduled decisions and releases in a time range, in time order: central-bank decisions, statistics, earnings, rule effective dates, comment deadlines, trade measures, filings, meetings, votes, launches and speeches. Use it for what is coming or has just passed; for what has already happened and been reported use list_changes or search_changes. Parameters: from and to are UTC times such as 2026-11-01T00:00:00Z; for one week ask from a Sunday 00:00Z to the next Sunday; without them the range is one day ago to 31 days ahead; to must follow from by at most 400 days; domain keeps one coverage domain. Behavior: times are UTC; tracked releases give the previous reading and, once out, the new one (never a forecast); policy-rate figures are left out; how far ahead a plan sees is capped. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the range, ISO 8601 with a zone; default 31 days ahead; at most 400 days after `from` | |
| from | No | Start of the range, ISO 8601 with a zone (e.g. 2026-10-15T00:00:00Z); default one day ago | |
| domain | No | Only events of this coverage domain; omit for the connection's default domain, or all domains when none is set | |
| 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) |
| Name | Required | Description |
|---|---|---|
| to | Yes | End of the range, ISO 8601 UTC |
| from | Yes | Start of the range, ISO 8601 UTC |
| page | Yes | The calendar page on aiseek.dev |
| events | Yes | Events in time order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive safety, and the description adds substantive behavior beyond them: UTC time basis, that tracked releases return previous and then new readings and never a forecast, that policy-rate figures are omitted, that forward visibility is capped, and that each call consumes one quota unit while a rejected argument costs nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose first, then routing, then parameters, then behavior, so an agent can stop reading at any point. The behavioral and parameter sentences are densely clause-stacked, which costs some readability, but almost every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is rightly omitted. With routing, defaults, limits, quota behavior, and UTC semantics all present, an agent has everything needed to call this correctly and interpret the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents defaults and the 400-day limit, so the baseline is 3. The description adds genuine value over the schema: concrete UTC timestamp syntax, the Sunday-to-Sunday week pattern, the effective default window (one day ago to 31 days ahead), and the single-domain filter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List scheduled decisions and releases in a time range, in time order') and enumerates the event categories covered (central-bank decisions, earnings, votes, speeches, etc.). It explicitly distinguishes itself from list_changes and search_changes for past/reported events, so an agent can route without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('what is coming or has just passed') and when-not ('what has already happened and been reported') with the named alternatives list_changes and search_changes. It even supplies the concrete recipe for a common case ('for one week ask from a Sunday 00:00Z to the next Sunday').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List AiSeek's published topics: curated subjects (a technology, an industry, a policy area) that group related changes, with their counts for the last 90 and 7 days and their newest change. Use it to browse by subject or category and to find a slug for get_topic; for free-text search use search_changes. Parameters: domain keeps topics that belong to that coverage domain among others (a topic can sit in several), e.g. TECHNOLOGY or ENERGY; omitted, the connection's default domain or every topic applies; locale translates names and descriptions. Behavior: every matching topic comes back in one list in AiSeek's own order (no paging); counts are computed live on each call. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Only topics of this coverage domain; omit for the connection's default domain, or all domains when none is set | |
| 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) |
| Name | Required | Description |
|---|---|---|
| url | Yes | The topics page on aiseek.dev |
| items | Yes | Published topics in AiSeek's own order |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious context: no paging (one call returns everything), counts are computed live per call, one call consumes a unit of the key's quota, and a rejected argument costs nothing. It stops short of describing result shape or failure modes, but the annotation bar is met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose, then routes to siblings, then groups parameters and behavior into labelled clauses so the reader can stop early. Dense but nearly every sentence carries a distinct fact; only the restatement of default-domain/locale omission overlaps the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description still covers filtering semantics, ordering, lack of paging, live counts and quota cost. Nothing an agent needs in order to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema does not: a topic can belong to several domains so `domain` filters rather than isolates, and `locale` translates names and descriptions. The omission behavior is 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List AiSeek's published topics') and defines what a topic actually is (curated subjects grouping related changes), plus what comes back (90/7-day counts and newest change). It is immediately distinguishable from get_topic and search_changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it 'to browse by subject or category and to find a slug for get_topic', and names the alternative for a different intent ('for free-text search use search_changes'). Both the when and the when-not are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published changes by words, ranked by relevance, best first, not by time. Use it to find changes about a company, country, subject or name; to browse what is newest use list_changes, for a curated subject use get_topic, for a company's profile use search_companies. Parameters: query is matched against headlines and summaries in the language of locale, so search in that language (a Chinese or Japanese query also matches simplified, traditional and Japanese forms of the same characters); limit trims the ranked list (1 to 25). Behavior: no match is an empty list, not an error; each result's id feeds get_change. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many changes to return, 1 to 25, best match first; omit for the connection's default (10 unless set) | |
| query | Yes | Words to look for, 2 to 120 characters: a company, a country, a subject or a name, in any of the three languages | |
| 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) |
| Name | Required | Description |
|---|---|---|
| items | Yes | Matching changes, most relevant first; at most `limit` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world), and the description adds genuinely useful context: empty list instead of an error on no match, result ids feeding get_change, and quota accounting including that a rejected argument costs nothing. It does not, however, describe the result shape or ordering guarantees beyond ranking, which is largely delegated to the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then routing, then parameters, then behavior, with zero filler sentences. It is dense and long-ish, but each clause carries distinct information; only the quota sentence could arguably be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with a full output schema, the description covers everything an agent needs: selection criteria, ranked-vs-time semantics, language matching, limit bounds, no-match behavior, and follow-up linkage via id. No gaps remain that would cause a misinvocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning: query is matched against headlines and summaries in the locale language and cross-matches simplified/traditional/Japanese character forms, and limit trims the ranked list. Those are non-obvious semantics the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (search published changes) plus the ranking rule (by relevance, best first, not by time), which immediately separates it from the chronological siblings. An agent can distinguish it from list_changes without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names four concrete use cases and routes each alternative scenario to the right sibling: newest browsing to list_changes, curated subjects to get_topic, company profiles to search_companies. Everything needed to choose among alternatives is stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AiSeek's public companies by name, alias or ticker and return up to 10 matches, most active first, each with its slug, home country, listings and page url. Use it to find a company's slug for get_company; for news about a company use search_changes with its name. Parameters: query takes a name, alias or ticker in English, Chinese or Japanese (e.g. Toyota, トヨタ, 7203). Behavior: no match is an empty list, not an error; only companies with a public AiSeek page are searched. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A company name, alias or ticker, 2 to 80 characters, in any of the three languages | |
| 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) |
| Name | Required | Description |
|---|---|---|
| items | Yes | Up to 10 matching companies, most active first; empty when nothing matches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds context those annotations cannot: no match returns an empty list rather than an error, only companies with a public page are searched, one call consumes a quota unit (Free keys have a daily MCP cap), and a rejected argument costs nothing. Cost and failure-mode disclosure is genuinely valuable behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and routing, then labeled 'Parameters:' and 'Behavior:' sections. Despite packing purpose, alternatives, examples, and quota semantics, every sentence earns its place with no repetition of the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only search with an output schema, everything an agent needs is present: what it searches, what it returns, what it does not return (non-public companies), empty-result semantics, quota cost, and the sibling to use for adjacent needs. Return-value detail is correctly left to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes beyond the schema for 'query' by giving concrete multilingual examples (Toyota, トヨタ, 7203) that clarify what 'alias or ticker in any of the three languages' actually accepts. The 'locale' parameter is left to the schema, which documents it adequately, so this is not a full 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (AiSeek's public companies) with the matching dimensions (name, alias, ticker) and the exact result shape (up to 10 matches, most active first, with slug, country, listings, page url). It explicitly distinguishes itself from siblings get_company and search_changes, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use routing: 'Use it to find a company's slug for get_company; for news about a company use search_changes with its name.' It names both alternatives and the condition that selects each, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a receipt: recompute its digest from the stored record and report ok, digestMatches, canonicalForm, columnsMatch, evidenceRowsMatch and any problems. ok true means the record is unchanged since it was written. A receipt records an assessment; it is not a certificate that a claim is true. Use it before citing a receipt, after get_receipt has shown what it says; it does not return the content. Parameters: id is the receipt id you read with get_receipt (receipts[].id from get_change_history), never a change id; locale translates only the notice. Behavior: the check runs live on every call; problems name the failing part (DIGEST_MISMATCH, NOT_CANONICAL, COLUMN_MISMATCH:, EVIDENCE_ROWS_MISMATCH, PAYLOAD_UNREADABLE); an unknown or non-public id is an error. One call of the key's quota (Free keys have a daily MCP cap); a rejected argument costs nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the get_change_history result; only public receipts can be read | |
| 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) |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| notice | Yes | A reminder that a receipt is not a certificate of truth, in the requested language |
| problems | Yes | |
| checkedAt | Yes | |
| receiptId | Yes | |
| columnsMatch | Yes | |
| canonicalForm | Yes | |
| digestMatches | Yes | |
| payloadDigest | Yes | |
| evidenceRowsMatch | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read (readOnly/idempotent/non-destructive), but the description goes well beyond: the check 'runs live on every call', the enumerated failure codes (DIGEST_MISMATCH, NOT_CANONICAL, COLUMN_MISMATCH:<field>, EVIDENCE_ROWS_MISMATCH, PAYLOAD_UNREADABLE), the error on unknown/non-public ids, and quota semantics ('one call of the key's quota... a rejected argument costs nothing').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, usage, parameters and behavior are front-loaded in a logical order with no filler sentences. It is dense and somewhat run-on, packing return fields, error codes and quota into one paragraph, which slightly hurts scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a verification tool with an output schema, the description still supplies everything needed to call it correctly: id provenance, locale scope, live-check behavior, failure vocabulary, error conditions and quota cost. Nothing an agent needs is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents both params well, so the baseline would be 3. The description adds real disambiguation beyond the schema by warning that id is 'never a change id' and clarifying that locale 'translates only the notice', which is not stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Verify a receipt: recompute its digest from the stored record') plus the exact outcome fields reported. It also explicitly distinguishes itself from the sibling get_receipt by noting it 'does not return the content', so an agent can route between them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use ('Use it before citing a receipt, after get_receipt has shown what it says') and a semantic boundary ('it is not a certificate that a claim is true'). It also names the upstream tool whose output supplies the id, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_earth_view2 fields changedInput schema / properties / layers / items / enumPrevious value: -[
- "gdacs",
- "eonet",
- "nhc",
- "jtwc",
- "tsunami",
- "pager",
- "volcano-us",
- "drought-us",
- "nws",
- "jma",
- "dwd",
- "space-weather",
- "sea-ice",
- "ucdp",
- "unhcr",
- "ecdc",
- "gem-power",
- "sanctions",
- "chokepoints",
- "ports",
- "eia-energy",
- "lpi",
- "aftershock",
- "flood-uk",
- "rivers-de",
- "rivers-us",
- "tides"
-]New value: +[
+ "gdacs",
+ "eonet",
+ "nhc",
+ "jtwc",
+ "tsunami",
+ "pager",
+ "volcano-us",
+ "drought-us",
+ "nws",
+ "jma",
+ "dwd",
+ "space-weather",
+ "sea-ice",
+ "ucdp",
+ "unhcr",
+ "ecdc",
+ "gem-power",
+ "sanctions",
+ "chokepoints",
+ "ports",
+ "eia-energy",
+ "lpi",
+ "aftershock",
+ "flood-uk",
+ "rivers-de",
+ "rivers-us",
+ "tides",
+ "air-quality"
+]Input schema / properties / layers / maxItemsPrevious value: -27New value: +28get_earth_view2 fields changedInput schema / properties / layers / items / enumPrevious value: -[
- "gdacs",
- "eonet",
- "nhc",
- "jtwc",
- "tsunami",
- "pager",
- "volcano-us",
- "drought-us",
- "nws",
- "jma",
- "dwd",
- "space-weather",
- "sea-ice",
- "ucdp",
- "unhcr",
- "ecdc",
- "gem-power",
- "sanctions",
- "chokepoints",
- "ports",
- "eia-energy",
- "lpi",
- "aftershock"
-]New value: +[
+ "gdacs",
+ "eonet",
+ "nhc",
+ "jtwc",
+ "tsunami",
+ "pager",
+ "volcano-us",
+ "drought-us",
+ "nws",
+ "jma",
+ "dwd",
+ "space-weather",
+ "sea-ice",
+ "ucdp",
+ "unhcr",
+ "ecdc",
+ "gem-power",
+ "sanctions",
+ "chokepoints",
+ "ports",
+ "eia-energy",
+ "lpi",
+ "aftershock",
+ "flood-uk",
+ "rivers-de",
+ "rivers-us",
+ "tides"
+]Input schema / properties / layers / maxItemsPrevious value: -23New value: +27change_historycompanycountry_heatearth_atget_change3 fields changedInput schema / properties / id / descriptionPrevious value: -"The change id: a UUID such as 3f2b8c1e-5a47-4d0e-9b6a-1c7e2d8f4a90, taken from the id of an item in latest_changes or search_changes; an unpublished id is an error"New value: +"The change id: a UUID such as 3f2b8c1e-5a47-4d0e-9b6a-1c7e2d8f4a90, taken from the id of an item in list_changes, search_changes or get_topic; an unpublished id is an error"Input schema / properties / locale / defaultRemoved value: -"en"Input schema / properties / locale / descriptionPrevious value: -"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)"get_change_historyget_companyget_country_heatget_earth_viewget_latest_briefget_receipt3 fields changedInput schema / properties / id / descriptionPrevious value: -"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the change_history result; only public receipts can be read"New value: +"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the get_change_history result; only public receipts can be read"Input schema / properties / locale / defaultRemoved value: -"en"Input schema / properties / locale / descriptionPrevious value: -"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)"get_topiclatest_brieflatest_changeslist_changeslist_correctionslist_countrieslist_scheduled_eventslist_topicsrecent_correctionsrelease_calendarsearch_changes5 fields changedInput schema / properties / limit / defaultRemoved value: -10Input schema / properties / limit / descriptionPrevious value: -"How many changes to return, 1 to 25 (default 10), best match first"New value: +"How many changes to return, 1 to 25, best match first; omit for the connection's default (10 unless set)"Input schema / properties / locale / defaultRemoved value: -"en"Input schema / properties / locale / descriptionPrevious value: -"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)"Output schema / properties / items / items / properties / id / descriptionPrevious value: -"The change id (a UUID): pass it to get_change or change_history"New value: +"The change id (a UUID): pass it to get_change or get_change_history"search_companiesverify_receipt3 fields changedInput schema / properties / id / descriptionPrevious value: -"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the change_history result; only public receipts can be read"New value: +"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the get_change_history result; only public receipts can be read"Input schema / properties / locale / defaultRemoved value: -"en"Input schema / properties / locale / descriptionPrevious value: -"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en, zh or ja; omit for the connection's default language (en unless set)"change_history1 field changedInput schema / properties / id / descriptionPrevious value: -"The change id (a UUID) from latest_changes or search_changes: the same id get_change takes"New value: +"The change id: a UUID such as 3f2b8c1e-5a47-4d0e-9b6a-1c7e2d8f4a90, the same id get_change takes, from latest_changes or search_changes"get_change1 field changedInput schema / properties / id / descriptionPrevious value: -"The change id (a UUID) from latest_changes or search_changes"New value: +"The change id: a UUID such as 3f2b8c1e-5a47-4d0e-9b6a-1c7e2d8f4a90, taken from the id of an item in latest_changes or search_changes; an unpublished id is an error"get_receipt1 field changedInput schema / properties / id / descriptionPrevious value: -"The receipt id (a UUID), from the receipts that change_history lists"New value: +"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the change_history result; only public receipts can be read"verify_receipt1 field changedInput schema / properties / id / descriptionPrevious value: -"The receipt id (a UUID), from the receipts that change_history lists"New value: +"The receipt id: a UUID such as 7d1e4a52-0c3b-4f68-a9d2-5e8b1c6f3a07, taken from receipts[].id in the change_history result; only public receipts can be read"country_heat1 field changedOutput schema / properties / map / descriptionPrevious value: -"The SeekMap page on aiseek.dev for this view"New value: +"The SeekEarth page on aiseek.dev for this view"earth_atchange_historycompany4 fields changedInput schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Input schema / properties / query / descriptionPrevious value: -"A name to look up when the slug is unknown"New value: +"A company name, alias or ticker (2 to 80 characters) to look up when the slug is unknown; used only when `slug` is absent"Input schema / properties / slug / descriptionAdded value: +"The exact AiSeek company slug (lower case letters, digits and hyphens, e.g. toyota); wins over `query` when both are given"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "claims": {
+ "description": "Only for a `slug` lookup: facts AiSeek states about it",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "description": {
+ "description": "Only for a `slug` lookup: a short description; one taken from Wikipedia carries its link (CC BY-SA 4.0)",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "entity": {
+ "additionalProperties": {},
+ "description": "Only for a `slug` lookup: the company",
+ "properties": {
+ "countryCode": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ "items": {
+ "description": "Only for a `query` lookup: up to 10 matching companies, most active first",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "countryCode": {
+ "description": "ISO 3166-1 alpha-2 country code of its home country",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "name": {
+ "description": "The company's name",
+ "type": "string"
+ },
+ "slug": {
+ "description": "The company's AiSeek slug: pass it as `slug`",
+ "type": "string"
+ },
+ "tickers": {
+ "description": "Listings as TICKER:EXCHANGE, comma separated",
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "profile": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Only for a `slug` lookup: legal name, website, reporting currency, headquarters country, description source"
+ },
+ "relations": {
+ "description": "Only for a `slug` lookup: its stated relations to other entities",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "securities": {
+ "description": "Only for a `slug` lookup: the company's listings",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "exchange": {
+ "type": "string"
+ },
+ "ticker": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "ticker",
+ "exchange"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "signals": {
+ "description": "Only for a `slug` lookup: its recent published changes",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "url": {
+ "description": "Only for a `slug` lookup: the company's page on aiseek.dev",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}country_heat5 fields changedInput schema / properties / country / descriptionPrevious value: -"ISO 3166-1 alpha-2 code, e.g. JP; omit for every country"New value: +"ISO 3166-1 alpha-2 country code, e.g. JP or US, upper or lower case; omit for every country (the 60 hottest)"Input schema / properties / days / descriptionAdded value: +"Window in days, 1 to 90 (default 7); capped by the key's plan: Free 7, Pro 30, Intelligence and Developer 90"Input schema / properties / domain / descriptionAdded value: +"Only changes of this coverage domain; omit for all domains"Input schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "asOf": {
+ "description": "The last day (UTC, YYYY-MM-DD) the heat was computed for",
+ "type": "string"
+ },
+ "countries": {
+ "description": "Countries by heat, highest first (at most 60), or the one country asked for",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "changes": {
+ "description": "Published changes placed in the country within the window",
+ "type": "number"
+ },
+ "code": {
+ "description": "ISO 3166-1 alpha-2 country code, e.g. JP",
+ "type": "string"
+ },
+ "convergence": {
+ "description": "True when three or more domains had an important change within 48 hours",
+ "type": "boolean"
+ },
+ "delta": {
+ "description": "Heat minus the day before's heat; null when the day before is unknown",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "domains": {
+ "description": "Coverage domains with changes there",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "heat": {
+ "description": "Change Heat from 0 to 100; 50 is an ordinary day for that country",
+ "type": "number"
+ },
+ "series": {
+ "description": "Heat of the last seven days, oldest first",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "code",
+ "heat",
+ "changes",
+ "domains",
+ "series"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "days": {
+ "description": "The window used, after the plan's cap",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "map": {
+ "description": "The SeekMap page on aiseek.dev for this view",
+ "type": "string"
+ },
+ "maxDays": {
+ "description": "The longest window the plan allows",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "method": {
+ "description": "Short name of the method version used to compute Change Heat",
+ "type": "string"
+ }
+ },
+ "required": [
+ "asOf",
+ "days",
+ "maxDays",
+ "method",
+ "countries",
+ "map"
+ ],
+ "type": "object"
+}get_change3 fields changedInput schema / properties / id / descriptionPrevious value: -"The change id from latest_changes or search_changes"New value: +"The change id (a UUID) from latest_changes or search_changes"Input schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "detectedAt": {
+ "description": "ISO 8601 time AiSeek detected the change",
+ "type": "string"
+ },
+ "dossierId": {
+ "description": "Id of the in-depth dossier on this change, when one is published",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "effectiveAt": {
+ "description": "ISO 8601 time the change takes effect, when it has one",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "description": "The change id",
+ "type": "string"
+ },
+ "locales": {
+ "description": "Languages the headline exists in (en, zh, ja)",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "primaryEntity": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "entityType": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The main company or subject"
+ },
+ "reportedAt": {
+ "description": "ISO 8601 time the first source reported it, when known",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scores": {
+ "additionalProperties": {},
+ "description": "AiSeek's scores for the change",
+ "properties": {
+ "evidenceStrength": {
+ "description": "0 to 1",
+ "type": "number"
+ },
+ "importance": {
+ "description": "0 to 1",
+ "type": "number"
+ },
+ "novelty": {
+ "description": "0 to 1",
+ "type": "number"
+ },
+ "velocity": {
+ "description": "0 to 1",
+ "type": "number"
+ }
+ },
+ "required": [
+ "importance",
+ "novelty",
+ "velocity",
+ "evidenceStrength"
+ ],
+ "type": "object"
+ },
+ "signalType": {
+ "description": "The kind of change",
+ "type": "string"
+ },
+ "sources": {
+ "description": "The sources that reported the change: names and links only, never quoted passages",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "level": {
+ "description": "Evidence level: PRIMARY, REGULATOR, COMPANY, INSTITUTIONAL, MEDIA, COMMUNITY or DERIVED",
+ "type": "string"
+ },
+ "publishedAt": {
+ "description": "When the source published it",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "role": {
+ "description": "How the source is used for the change",
+ "type": "string"
+ },
+ "source": {
+ "description": "Outlet or publisher name",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "url": {
+ "description": "Link to the source article",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "url",
+ "publishedAt",
+ "level",
+ "role"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "description": "Summary in the requested language",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Headline in the requested language",
+ "type": "string"
+ },
+ "url": {
+ "description": "The change's page on aiseek.dev",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "detectedAt",
+ "sources",
+ "url"
+ ],
+ "type": "object"
+}get_receiptlatest_brief3 fields changedInput schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Input schema / properties / type / descriptionAdded value: +"DAILY (the default): one UTC day's changes; WEEKLY: the week's changes with market moves and the week ahead"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "briefType": {
+ "description": "DAILY or WEEKLY",
+ "type": "string"
+ },
+ "date": {
+ "description": "The day the brief covers, UTC, YYYY-MM-DD",
+ "type": "string"
+ },
+ "id": {
+ "description": "The brief id",
+ "type": "string"
+ },
+ "locked": {
+ "description": "True on a Free key for a brief younger than one day: only title and summary are given",
+ "type": "boolean"
+ },
+ "nextDate": {
+ "description": "The date of the next brief of this type",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "periodEnd": {
+ "description": "End of the period, ISO 8601",
+ "type": "string"
+ },
+ "periodStart": {
+ "description": "Start of the period, ISO 8601",
+ "type": "string"
+ },
+ "previousDate": {
+ "description": "The date of the previous brief of this type",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "publishedAt": {
+ "description": "When the brief was published, ISO 8601",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "sections": {
+ "description": "The period's changes by section; empty while a Free key's brief is still locked",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "items": {
+ "description": "The changes in the section",
+ "items": {
+ "additionalProperties": {},
+ "properties": {},
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "section": {
+ "description": "The section, e.g. GLOBAL",
+ "type": "string"
+ }
+ },
+ "required": [
+ "section",
+ "items"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "summary": {
+ "description": "The brief's summary",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "The brief's title",
+ "type": "string"
+ },
+ "unlocksAt": {
+ "description": "When a locked brief opens for Free, ISO 8601",
+ "type": "string"
+ },
+ "url": {
+ "description": "The brief's page on aiseek.dev",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "briefType",
+ "date",
+ "title",
+ "periodStart",
+ "periodEnd",
+ "sections",
+ "url"
+ ],
+ "type": "object"
+}latest_changes3 fields changedInput schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Input schema / properties / page / descriptionPrevious value: -"Page, from 0"New value: +"Page number, from 0 (the newest 20); each page has 20 changes, up to page 25"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "hasMore": {
+ "description": "True when another page exists (pass page + 1)",
+ "type": "boolean"
+ },
+ "items": {
+ "description": "Up to 20 changes, newest first",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "detectedAt": {
+ "description": "ISO 8601 time AiSeek detected the change",
+ "type": "string"
+ },
+ "evidenceStrength": {
+ "description": "How strong the evidence is, from 0 to 1",
+ "type": "number"
+ },
+ "id": {
+ "description": "The change id (a UUID): pass it to get_change or change_history",
+ "type": "string"
+ },
+ "importanceScore": {
+ "description": "Importance from 0 to 1",
+ "type": "number"
+ },
+ "primaryEntity": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The main company or subject of the change"
+ },
+ "reportedAt": {
+ "description": "ISO 8601 time the first source reported it, when known",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signalType": {
+ "description": "The kind of change",
+ "type": "string"
+ },
+ "summary": {
+ "description": "One- or two-sentence summary in the requested language; null when there is none",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Headline in the requested language",
+ "type": "string"
+ },
+ "url": {
+ "description": "The change's page on aiseek.dev in the requested language",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "detectedAt",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "page": {
+ "description": "The page returned, from 0",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "items",
+ "hasMore",
+ "page"
+ ],
+ "type": "object"
+}recent_correctionsrelease_calendar5 fields changedInput schema / properties / coverage / descriptionAdded value: +"Only events of this coverage domain; omit for all"Input schema / properties / from / descriptionPrevious value: -"ISO time; default one day ago"New value: +"Start of the range, ISO 8601 with a zone (e.g. 2026-10-15T00:00:00Z); default one day ago"Input schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Input schema / properties / to / descriptionPrevious value: -"ISO time; default 31 days ahead"New value: +"End of the range, ISO 8601 with a zone; default 31 days ahead; at most 400 days after `from`"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "events": {
+ "description": "Events in time order",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "figure": {
+ "description": "For a tracked release: the previous reading and, once out, the new one (never a forecast); null for policy rates"
+ },
+ "id": {
+ "description": "The event id",
+ "type": "string"
+ },
+ "importance": {
+ "description": "How much such an event usually moves markets",
+ "type": "string"
+ },
+ "kind": {
+ "description": "POLICY_DECISION, DATA_RELEASE, RULE_EFFECTIVE, COMMENT_DEADLINE, TRADE_MEASURE, FILING_DUE, EARNINGS, MEETING, VOTE, PRODUCT_LAUNCH or SPEECH",
+ "type": "string"
+ },
+ "precision": {
+ "description": "EXACT (a time), DAY (a date only) or WINDOW (a span ending at windowEnd)",
+ "type": "string"
+ },
+ "region": {
+ "description": "US, EA, GB, JP, CN, CA, AU or CH when the source says",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scheduledAt": {
+ "description": "ISO 8601 time, UTC",
+ "type": "string"
+ },
+ "sourceName": {
+ "description": "Who announced it",
+ "type": "string"
+ },
+ "sourceUrl": {
+ "description": "Link to the announcement",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "description": "SCHEDULED, RESCHEDULED, CANCELLED or OCCURRED",
+ "type": "string"
+ },
+ "title": {
+ "description": "What is scheduled",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "from": {
+ "description": "Start of the range, ISO 8601 UTC",
+ "type": "string"
+ },
+ "page": {
+ "description": "The calendar page on aiseek.dev",
+ "type": "string"
+ },
+ "to": {
+ "description": "End of the range, ISO 8601 UTC",
+ "type": "string"
+ }
+ },
+ "required": [
+ "from",
+ "to",
+ "events",
+ "page"
+ ],
+ "type": "object"
+}search_changes4 fields changedInput schema / properties / limit / descriptionAdded value: +"How many changes to return, 1 to 25 (default 10), best match first"Input schema / properties / locale / descriptionPrevious value: -"Language of titles and summaries: en, zh or ja"New value: +"Language of headlines, summaries and notices in the answer: en (the default), zh or ja"Input schema / properties / query / descriptionAdded value: +"Words to look for, 2 to 120 characters: a company, a country, a subject or a name, in any of the three languages"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": {},
+ "properties": {
+ "items": {
+ "description": "Matching changes, most relevant first; at most `limit`",
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "detectedAt": {
+ "description": "ISO 8601 time AiSeek detected the change",
+ "type": "string"
+ },
+ "evidenceStrength": {
+ "description": "How strong the evidence is, from 0 to 1",
+ "type": "number"
+ },
+ "id": {
+ "description": "The change id (a UUID): pass it to get_change or change_history",
+ "type": "string"
+ },
+ "importanceScore": {
+ "description": "Importance from 0 to 1",
+ "type": "number"
+ },
+ "primaryEntity": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "name"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The main company or subject of the change"
+ },
+ "reportedAt": {
+ "description": "ISO 8601 time the first source reported it, when known",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "signalType": {
+ "description": "The kind of change",
+ "type": "string"
+ },
+ "summary": {
+ "description": "One- or two-sentence summary in the requested language; null when there is none",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "description": "Headline in the requested language",
+ "type": "string"
+ },
+ "url": {
+ "description": "The change's page on aiseek.dev in the requested language",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "detectedAt",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "items"
+ ],
+ "type": "object"
+}verify_receiptcompanycountry_heatget_changelatest_brieflatest_changesrelease_calendarsearch_changesVerified changes to watched EU acts, read-only, with each fact's source.
Verify claims with verdict, confidence & cited sources; batch verify, source checks, daily brief.
Food verification for people and AI agents: evidence-backed verdicts, with sources and dates.
Source-backed public tables with citations, claim checks, and reviewable corrections.
Add one secure layer between your agents and this server.