Time-series nobody else archives: LLM price history, prediction markets, gas, perp funding.
Scored across 12 tools
Each tool has a clearly distinct purpose: search, price current, price changes, price advisor, data search, data latest, data history, data changes, movers, anomalies, and verdict. Even related tools like price_changes and data_changes differ by domain, and movers vs anomalies vs verdict each target different analytical views. No two tools overlap in functionality.
All tools follow the anansi_ prefix with lowercase underscore-separated names. Patterns like anansi_search, anansi_price_current, anansi_data_changes are consistent, with free/paid variants distinguished by suffixes like _recent. The naming is uniformly descriptive and predictable.
With 12 tools, the set is well-scoped for a data/pricing service that covers both free and paid tiers, multiple data views (current, history, changes), and analytical extras (movers, anomalies, verdict). It is neither overly minimal nor bloated, and each tool earns its place.
The surface covers the full lifecycle of data access and analysis: name resolution (anansi_search), current values (price_current, data_latest), historical series (data_history), change tracking (price_changes, data_changes), rankings (movers), anomaly detection (anomalies), and composite verdicts (verdict). No essential capability is missing for the stated domain.
PAID ($0.05 via x402). Statistical outliers: keys whose latest move breaks their OWN historical baseline, returned with a z-score. Use it to separate a genuinely abnormal move from ordinary volatility. Do NOT use it to rank raw speed (anansi_movers) and treat results cautiously on a young dataset, where a short baseline inflates z-scores. Input: z_threshold defaults to 3.0.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| dataset | Yes | ||
| z_threshold | No | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the $0.05 x402 payment requirement, the z-score methodology, and the baseline caveat. It does not detail return shape or error/payment failure behavior, but it clearly communicates the core behavior.
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 compact, front-loaded with cost, and every sentence contributes: purpose, use case, exclusions, cautions, and parameter default. No filler or redundancy.
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?
The description is strong on use-case and behavioral context but incomplete for a 4-parameter tool with no output schema and no annotations: dataset and field are not specified, payment_header semantics are absent, and the return structure is only implied. It would be fully complete with a sentence on parameter semantics.
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 0%, so the description must compensate. It only explains z_threshold's default and role; dataset, field, and payment_header are required or relevant but not defined. The phrase 'keys whose latest move' hints that field is a numeric measurement, but this is not sufficient for correct invocation.
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?
Description opens by stating the tool returns statistical outliers, specifically keys whose latest move breaks their own historical baseline, with z-scores. It also distinguishes this from anansi_movers by warning not to use it to rank raw speed.
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 separate genuine abnormal moves from ordinary volatility and gives a concrete alternative/exclusion: do not use it for raw speed ranking, which belongs to anansi_movers. It also cautions about young datasets inflating z-scores.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.02 via x402). Field-level diffs across a whole dataset: for each key that changed, which field moved, its from and to values, and when. Use it to detect movement across many keys without pulling every series. Do NOT use it for LLM prices specifically — anansi_price_changes_recent is free and anansi_price_changes is the full version. Input: since is a unix timestamp; omit for the whole archive.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| dataset | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses cost ($0.02 via x402) and describes output content (from/to values, when), but it does not explain payment mechanics, pagination, errors, or auth behavior. Partial but not fully transparent.
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 and efficient, front-loading the paid warning and then providing purpose, use guidance, exclusions, and input meaning in a few sentences. No filler or redundant restatement.
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?
The tool has three parameters, no output schema, and no annotations, so the description needs to carry a lot. It covers purpose, usage, cost, and `since`, but omits crucial invocation details like how to provide the payment header and what `dataset` values are valid. Adequate but incomplete for a paid tool.
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 0%, so the description must compensate. It meaningfully explains `since` as a unix timestamp and says omitting it returns the whole archive. However, `dataset` and `payment_header` are not directly documented beyond their names and the paid hint, leaving a gap.
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 clearly states a specific action and scope: field-level diffs across a whole dataset, showing which field moved, from/to values, and when. It distinguishes itself from the price-related siblings and frames its purpose as detecting movement across many keys without pulling every series.
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 explicitly says when to use it ('Use it to detect movement across many keys without pulling every series') and when not to ('Do NOT use it for LLM prices specifically'), naming the alternatives anansi_price_changes_recent and anansi_price_changes. This is clear, actionable guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.02 via x402). The full recorded time-series for ONE key in one dataset, oldest to newest, each row carrying its observation timestamp. Use it to chart or backtest a single series. Do NOT use it to compare many keys at once (anansi_data_latest returns them all for one moment) and do NOT expect history predating our first observation — the archive is days old and depth varies by dataset. Inputs: dataset and key exactly as returned by anansi_search; since is a unix timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| since | No | ||
| dataset | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. It discloses the paid nature ($0.02 via x402) and the data depth limitation ('archive is days old and depth varies by dataset'). However, it does not explicitly state that the tool is read-only or non-destructive, though 'history' implies read. It could mention that there are no side effects, but the payment note and data depth are significant. Score 4, not 5, because it omits the safety profile.
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 a single paragraph, but it is front-loaded with the key purpose and payment info. It is concise and each sentence adds value, though it could be broken into bullet points for readability. It is not overly long and is efficient, so 4.
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?
Given the absence of output schema, the completeness of the dataset and that the 'key' and the description, it is not providing a full picture. The description covers the purpose, usage, and limitations, but it does not specify the return format or pagination. However, the archive is of the return format, but for a single series, it may be acceptable. 4 is possible. The description is reasonably complete, but it does not describe the exact shape of the output, which is a gap.
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 0 movement захранения, with 0% coverage, so the description must compensate. The description explains that 'dataset and key exactly as returned by anansi_search' and that 'since' is a unix timestamp, adding meaning beyond the raw schema. The description also clarifies the 'since' parameter's semantics but does not explain all parameters, but on the 'payment_header' but not full semantics for 'since' and 'dataset' beyond the pointer to search, which is helpful. is 4 is appropriate given the 0% coverage, the description covers many of the basic coverage is that the 'key', so the description provides essential. This is well for the extra. The descriptions of the parameters, including the form of the parameter. The parameters are not provided to have a role, but the description's contribution is significant.
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 clearly states the tool returns a time-series for one key in one dataset, oldest to newest, with timestamps. It distinguishes from siblings like anansi_data_latest, which returns all keys for one moment, and anansi_data_search. The verb is specific: 'chart or backtest a single series'.
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 when to use (charting/backtesting a single series) and when not to use (comparing many keys at once, pointing to anansi_data_latest). It also warns against expecting history predating the archive. This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.005 via x402). Current state of every tracked key in one dataset, as recorded at our last poll, with provenance naming the source and licence. Use it for the newest snapshot of a whole dataset — prediction-market probabilities, gas by chain, perp funding, stablecoin pegs. Do NOT use it for LLM prices (anansi_price_current is free) and do NOT use it for change-over-time (anansi_data_changes). Input: dataset must be an exact name from anansi_search; key optionally narrows to one row.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| dataset | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden and does so well. It reveals the tool is paid, states the exact cost, clarifies the data is from the last poll rather than real-time, and describes the provenance included in the result.
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 three tightly packed sentences, with cost, purpose, exclusions, and input semantics all included. Every sentence earns its place, and the warning-oriented structure makes it easy for an agent to decide when to call this tool.
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?
Given no output schema, no annotations, and only one required parameter, the description fully covers the necessary context: current snapshot state, provenance, payment, valid input sourcing, optional key narrowing, and intended use cases. The agent can select and invoke the tool correctly from this description alone.
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?
The description significantly compensates for 0% schema coverage by explaining dataset ('exact name from anansi_search') and key ('optionally narrows to one row'). However, the payment_header parameter is neither named nor explained in connection with the x402 payment, leaving a small but real gap.
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 clearly states what the tool does: returns the current state of every tracked key in a dataset as of the last poll, with provenance and licence. This specific snapshot description distinguishes it from siblings like anansi_data_changes and anansi_price_current.
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?
Usage guidance is explicit: use it for the newest whole-dataset snapshot, with concrete examples like prediction-market probabilities and gas by chain. It also gives explicit exclusions, naming anansi_price_current for LLM prices and anansi_data_changes for change-over-time, and requires dataset names from anansi_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.01 via x402). Full-text search across the CURRENT state of every sellable dataset at once, returning matching rows with their dataset name. Use it when you do not know which dataset holds a value. Do NOT use it to resolve a name to an identifier — anansi_search does that free — and note it searches current state only, not history. Input: q is a phrase match.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it is a paid operation ($0.01 via x402), searches only current state (not history), and returns rows with dataset names. While it implies read-only behavior via 'search', it does not explicitly state side effects, but given the context this is sufficient.
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 moderately concise and well-structured, covering cost, action, scope, usage guidance, and parameter note in separate sentences. It is not overly verbose, though it could be slightly tightened without losing critical 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?
The description provides enough context for an agent to decide when to use it, including cost and scope. It lacks details on limit and payment_header, but these are likely standard parameters. The absence of an output schema is noted, but the description explains the return type (rows with dataset names).
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?
The description explains that 'q is a phrase match', adding value beyond the schema. However, it does not elaborate on 'limit' or 'payment_header', which remain unexplained in both schema and description. With three parameters, only one is described, so coverage is partial.
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 clearly states the tool performs a full-text search across all sellable datasets, returning matching rows with dataset names. It also distinguishes itself from the sibling anansi_search by explicitly noting it is not for name-to-identifier resolution.
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 provides explicit usage guidance: 'Use it when you do not know which dataset holds a value' and 'Do NOT use it to resolve a name to an identifier — anansi_search does that free'. This clearly defines when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.03 via x402). Velocity ranking: which keys in a dataset moved fastest on one numeric field over a window, returned as rate of change with the underlying from/to values. Use it to find what is moving without reading every series. Do NOT use it to judge whether a move is unusual for that key — that is anansi_anomalies. Inputs: field must be a numeric field present in the dataset; window_s is seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| limit | No | ||
| dataset | Yes | ||
| window_s | No | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the payment cost ($0.03 via x402), the return structure (rate of change with from/to values), and the requirement that field be numeric. It does not mention side effects or limits, but this appears to be a read-only analysis tool, and the disclosed information is significant.
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 concise and well-structured. It front-loads the cost, then defines the purpose, usage guidance, and input hints in a logical flow. Every sentence adds value with no fluff.
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?
Despite lacking an output schema, the description explains the return shape (rate of change with from/to values) and gives key constraints. It does not cover all parameters but covers the critical ones. For a moderately complex ranking tool, this is nearly complete, though it could clarify the ranking direction (descending) and default limit behavior.
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 0%, so the description must compensate. It adds semantics for 'field' (must be numeric) and 'window_s' (in seconds), but does not explain 'limit', 'dataset', or 'payment_header'. 'limit' and 'payment_header' are less ambiguous given defaults and context, but the coverage is partial, warranting a mid score.
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 precisely states the tool's function: ranking keys by velocity (rate of change) on a numeric field over a window, returning rate of change with from/to values. It clearly distinguishes from siblings by naming anansi_anomalies as the alternative for a different purpose.
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 usage guidance is given: 'Use it to find what is moving without reading every series' and 'Do NOT use it to judge whether a move is unusual for that key — that is anansi_anomalies.' This clearly states when and when not to use, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.05 via x402). Answers 'which model should I route to' in one call: returns the cheapest models satisfying hard constraints on price, context window and modality, ranked by prompt price ascending, PLUS every price change and deprecation affecting those candidates in the window. Use it when choosing or re-validating a routing target. Do NOT use it merely to look up one model's price (anansi_price_current, free). Inputs: max_prompt_price in USD per token (e.g. 0.000001); min_context in tokens; modality is a substring of the modality string such as 'text' or 'image'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| modality | No | ||
| window_s | No | ||
| min_context | No | ||
| payment_header | No | ||
| max_prompt_price | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is paid ($0.05 via x402) — critical for cost-aware agents — and that it returns both ranked candidates and price change/deprecation data. It explains the ranking order and the window parameter. It lacks details like pagination or limits, but the paid nature and output composition are clearly disclosed, exceeding baseline.
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 each sentence adds value: purpose, usage, exclusions, and parameter examples. It is slightly long but front-loaded with the most important cost warning. No wasted words, but slightly involved with multiple clauses; still efficient.
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 tool with 6 params, no annotations, and no output schema, the description covers the core purpose, constraints, ranking, and additional output (price changes). It does not detail all parameters (limit, window_s default, payment_header) but those have schema defaults. It gives enough context for correct invocation, though a bit more on output structure would be ideal, but not critical.
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 0%, so the description must compensate. The description clearly explains the semantics of key parameters: max_prompt_price in USD per token, min_context in tokens, modality as substring. It also mentions window_s implicitly via 'in the window' and provides examples. This is strong compensational value for all critical parameters.
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 uses a specific verb ('answers') with a clear resource ('which model should I route to') and explicitly distinguishes itself from siblings by naming an alternative (anansi_price_current). It states the core function: returns cheapest models satisfying hard constraints ranked by prompt price, plus price changes/deprecations. This is highly specific and differentiated.
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?
The description explicitly states when to use: 'when choosing or re-validating a routing target' and provides a clear exclusion: 'Do NOT use it merely to look up one model's price' with a named alternative (anansi_price_current, free). It also explains the inputs' semantics, giving concrete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.03 via x402). The COMPLETE observed price-change history for every tracked LLM, with no time window and no row cap: model, field, from/to in USD per token, percent move, and detection timestamp. Use it to audit a provider's pricing behaviour over the whole archive or to feed a cost model. Do NOT use it for a quick 'did anything change lately' check — anansi_price_changes_recent answers that free. Input: since is a unix timestamp; omit it for everything we hold.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the paid nature ($0.03 via x402), the lack of a row cap or time window, and the exact fields returned. It does not describe auth/failure behavior, but for a read-only historical query it gives enough context for an agent to gauge cost and scope.
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?
Approximately 55 words, every sentence earns its place: cost, scope, output fields, use cases, negative guidance, and input semantics are all included without repetition. It is slightly dense as one block, but nothing is extraneous.
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, no-output-schema, no-annotation tool, this description reasonably covers the output projection, cost, coverage, and the key `since` parameter. It misses explaining `payment_header` and does not describe response format details, but for the complexity level, it is sufficient.
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 0%, so the description must compensate. It explains the `since` parameter as a unix timestamp with 'omit it for everything we have', which is useful, but it never mentions the `payment_header` parameter, which is especially relevant for a paid tool. Half of the inputs are undocumented.
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 the resource (COMPLETE observed price-change history for every tracked LLM) and the action (audit, feed cost model). It differentiates from the sibling tool anansi_price_changes_recent by explicitly stating this is the full-archive version, not the recent snapshot.
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?
Provides explicit when-to-use guidance: auditing pricing behavior over the entire archive or feeding a cost model. Also provides a clear do-not-use directive for 'quick did anything change lately' checks and names the correct alternative tool. This is textbook disambiguation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. LLM price changes we observed in the last 7 days: per model, which field moved (prompt, completion, cache_read), the from/to values in USD per token, the percentage move, and the unix timestamp we detected it. Providers publish only their current catalogue and overwrite it silently, so this record exists nowhere upstream. Use it to detect that a model you depend on got cheaper, dearer, or vanished. Do NOT use it for windows longer than 7 days or more than 25 rows — it is capped; use anansi_price_changes (paid) for the full unwindowed history. Input: days is clamped to 7.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description takes on the full burden. It discloses that the tool captures changes that 'exists nowhere upstream' because providers overwrite their catalogue, and it reveals input clamping ('days is clamped to 7') and row capping ('more than 25 rows — it is capped'). However, it does not explicitly state whether the operation is read-only or if there are any side effects, though it is implied as a data query tool.
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 a single paragraph that is somewhat conversational but logically structured: it starts with the tool's output, explains its unique value, gives usage guidance, and ends with constraints. It is not overly verbose and each sentence adds information, though it could be slightly more compact.
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?
Given the tool's simplicity and lack of an output schema, the description covers all essential aspects: what it does, why it exists (to capture data not available upstream), when to use it, and its limitations. It does not discuss error handling or output format, but these are not critical for a simple query tool and the information provided is sufficient for an agent to use 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?
The schema provides no parameter descriptions, so the description is the only source. It mentions 'Input: days is clamped to 7' and refers to 'windows longer than 7 days' and 'more than 25 rows', giving some meaning to `days` and `limit`. However, it does not directly define each parameter's purpose or expected values in a structured way, leaving some ambiguity.
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 clearly states that the tool provides LLM price changes observed in the last 7 days, detailing what fields are returned (per model, field moved, from/to values, percentage, timestamp). It also explicitly states the use case: 'Use it to detect that a model you depend on got cheaper, dearer, or vanished.' This distinguishes it from siblings by noting its limitation and pointing to the paid alternative for full history.
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?
The description explicitly says when to use the tool ('Use it to detect...') and when not to use it ('Do NOT use it for windows longer than 7 days or more than 25 rows'). It also gives a clear alternative ('use anansi_price_changes (paid) for the full unwindowed history') and notes that the input 'days is clamped to 7', setting expectations for usage constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Current per-token prices for LLMs as recorded at our last poll: usd_per_prompt_token and usd_per_completion_token (USD per single token, not per million), context window in tokens, and the observation timestamp (unix seconds). Use this to check what a model costs right now, or to compare a handful of models before routing. Do NOT use it to see how a price MOVED — it returns only the latest observation; use anansi_price_changes_recent (free) or anansi_price_history (paid). Input: model_id is a substring match, so 'gpt-5' matches every gpt-5 variant; resolve exact IDs with anansi_search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| model_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral details: it is free, returns only the latest observation, and uses substring matching. It also discloses the return fields and timestamp, making behavior transparent.
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 packed but not bloated; every sentence adds value. It is front-loaded with 'FREE' and key output fields, but a bit long and could be tightened without losing clarity.
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?
The description explains the output fields (per-token prices, timestamp), usage context, and provides cross-references and hints. It fully covers what an agent needs to know to decide when to use this tool and what results to expect, despite lacking an 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?
The description explains model_id's substring behavior but entirely omits the 'limit' parameter. Since schema coverage is 0%, it should explain both parameters; the limit's purpose (likely result cap) is not mentioned.
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 clearly states the tool's function: retrieving current per-token prices for LLMs, with specific fields listed. It distinguishes itself from siblings by explicitly noting it returns current prices and not price movements, with alternatives named.
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?
Provides explicit use cases ('check what a model costs right now, or compare a handful of models') and anti-use cases ('Do NOT use it to see how a price MOVED'), pointing to specific alternative tools. Also explains substring matching and how to resolve exact IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FREE. Resolves a partial name into exact model IDs and dataset names you can pass to the other tools; returns two string arrays (models, datasets), capped at 25 each. Use this FIRST whenever you have a fuzzy name like 'deepseek' or 'gas' and need the canonical identifier. Do NOT use it to retrieve values or search inside records — it matches names only; use anansi_price_current for prices or anansi_data_search (paid) to search every field of every dataset. Input: q is a case-insensitive substring.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: discloses it is FREE, results are capped at 25 each, and matching is case-insensitive substring. It also clarifies it does not search inside records. However, it omits details about the limit parameter's effect and error/edge cases, so a 4 is appropriate.
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 concise but information-dense, front-loaded with the core action, followed by usage guidance, exclusions, and input details. Each sentence earns its place; no fluff or redundancy. It balances thoroughness with brevity.
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 name-resolution tool with two parameters and no output schema, the description is largely complete: it explains the return structure (two arrays capped at 25), usage context, and exclusions. The missing limit parameter explanation is the main gap, but overall it is sufficiently comprehensive for agent use.
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 0%, so the description must explain parameters. It clearly defines q as 'a case-insensitive substring,' which is helpful. But the limit parameter is never mentioned; its behavior and relationship to the 25-cap remain ambiguous. This partial compensation yields a score of 3.
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 clearly states the tool's purpose: 'Resolves a partial name into exact model IDs and dataset names' and explicitly differentiates from siblings by emphasizing it only matches names, not retrieves values. It uses specific verbs and resources, making it unmistakable.
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 instructs to 'Use this FIRST whenever you have a fuzzy name' and warns 'Do NOT use it to retrieve values' with direct alternatives: 'use anansi_price_current for prices or anansi_data_search (paid) to search every field.' This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID ($0.04 via x402). One-call composite for a single key: its latest value, its velocity, its rank against peers in the same dataset, and its anomaly z-score — the answer four separate calls would give. Use it when you have one specific key and want a verdict rather than raw series. Do NOT use it to survey many keys (anansi_movers) or to fetch a full series (anansi_data_history). Inputs: dataset, key and a numeric field, all exactly as named in the dataset.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| field | Yes | ||
| dataset | Yes | ||
| payment_header | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It discloses paid cost ($0.04 via x402), composite nature (combining four calls), and single-key scope. It does not cover error behavior or missing-key handling, but the core behavioral traits are transparent.
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?
Three sentences plus an input hint, all front-loaded with the most important information (cost, composite, use cases). No filler or redundant repetition of schema titles.
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?
Given no output schema and no annotations, the description explains the tool's return substance (latest value, velocity, rank, z-score), usage context, and input expectations. It is slightly incomplete around payment_header behavior and failure modes, but adequate for a single-key composite lookup.
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 0%, so the description must compensate. It clarifies dataset, key, and numeric field must match dataset naming exactly, which adds meaning. However, it omits the payment_header parameter entirely and does not explain how field is used in ranking or z-score calculation, leaving partial coverage.
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?
Description clearly identifies the tool as 'one-call composite for a single key' returning latest value, velocity, rank, and anomaly z-score. It distinguishes itself from sibling tools like anansi_movers and anansi_data_history with explicit scope.
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?
Provides explicit when-to-use ('when you have one specific key and want a verdict rather than raw series') and when-not-to-use instructions, naming specific alternatives for surveying many keys (anansi_movers) and fetching full series (anansi_data_history).
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.
anansi_anomaliesanansi_data_changesanansi_data_historyanansi_data_latestanansi_data_searchanansi_moversanansi_price_advisoranansi_price_changesanansi_price_changes_recentanansi_price_currentanansi_searchanansi_verdictdata_changesdata_historydata_latestdata_searchhow_to_payintel_anomaliesintel_moversintel_verdictlist_datasetslist_offeringsmodel_advisormodel_changesdata_changesdata_historydata_latestdata_searchhow_to_payintel_anomaliesintel_moversintel_verdictlist_datasetslist_offeringsmodel_advisormodel_changesCrypto perps data for AI agents: funding rates, open interest, liquidations, order book, CVD.
Financial data for AI agents: crypto data, Polymarket odds, weather/oil calibration, trust scoring.
Prediction markets, on-chain flows, ETF flows, equities and macro intelligence for AI agents.
Live crypto market signals for AI agents: perp liquidations, funding, OI positioning, yield, FX.
