Allows AI agents to query verified public data from 2,700+ datasets (World Bank, FRED, Eurostat, etc.) using MCP tools for discovery, cross-dataset joins, statistical analysis, and chart publishing.
Verified data for AI agents. 2,700+ public datasets (World Bank, FRED, Eurostat, OECD, WHO, ECB, US Census, IMF) joined under one ontology, with built-in statistical analysis and chart publishing. Plug it into Claude Desktop, ChatGPT, Cursor, or any MCP-compatible client | your model gets numbers it cannot hallucinate.
autario.com | Documentation | Get an API Key
No hallucinated numbers. Every value is sourced from a known publisher and cited back to a primary URL. Use verify_value to double-check any claim.
Cross-dataset joins, no setup. Indicators across different datasets share autario_time + autario_entity shadow columns, so get_entity_data(USA, [gdp, unemployment, life_expectancy]) returns one wide table, joined automatically.
Statistical primitives built-in. correlate, regression, find_drivers, lag_analysis, seasonality_decomposition and more, with effect sizes, p-values, and plain-language interpretations.
Charts that persist. publish_chart writes a Plotly spec to autario.com. The result is a permanent, embeddable URL like autario.com/chart/{slug} | the LLM builds the spec, autario pulls real rows for it, no hallucinated data path.
LLM-agnostic. Works with Claude, GPT, Gemini, local models | anything that speaks MCP.
Related MCP server: NexusForge EU Finance
Install the server, then ask your assistant questions like these. The model picks the right tools and answers with cited data.
Ask: "What drives US inflation? Look at money supply, oil prices, and unemployment."
Tools: list_indicators -> find_drivers
Output: Ranked drivers with r, p-value, R squared per candidate.Ask: "Compare life expectancy in Germany, USA and Japan from 2000 to 2023, then publish a chart."
Tools: compare_entities -> publish_chart
Output: Wide-format table joined on year, plus a permanent autario.com/chart/{slug} URL.Ask: "Is consumer confidence a leading indicator of US retail sales?"
Tools: lag_analysis
Output: Cross-correlation peak at lag k, with interpretation in months.~/.config/claude/claude_desktop_config.json on Mac/Linux, %APPDATA%\Claude\claude_desktop_config.json on Windows.
{
"mcpServers": {
"autario": {
"command": "npx",
"args": ["autario-mcp"]
}
}
}Restart your client. The server reports tool count to stderr on launch.
Point your client at the hosted endpoint. No install needed.
URL: https://autario.com/mcp
Transport: Streamable HTTP (POST /mcp)The hosted endpoint also supports MCP prompts: analyze-dataset, create-chart, compare-countries.
Add API credentials to the stdio config or send them as x-api-key / x-api-secret headers to the HTTP endpoint.
{
"mcpServers": {
"autario": {
"command": "npx",
"args": ["autario-mcp"],
"env": {
"AUTARIO_API_KEY": "your_key",
"AUTARIO_API_SECRET": "your_secret"
}
}
}
}Get keys at autario.com/account.
28 MCP tools, organized by function.
Search the catalog, inspect schemas, pull rows.
Tool | What it does | Parameters |
| Search the Autario public data catalog. Returns dataset IDs, titles, descriptions, categories, publishers, row counts, last_refreshed_at, AND trusted ontology fields (topic, subtopic, unit, frequen... | query (string), category (string), limit (number), page (number) |
| Browse the Autario indicator registry — semantic layer over all 2600+ datasets. Each indicator has a topic (economy, health, energy, …), unit (USD, %, years, …), frequency (year/month/day), and ent... | topic (string), unit (string), frequency (string), entity_type (string), publisher (string), search (string), limit (number) |
| Get all indicators available for one entity (country, aggregate, etc.). Returns indicator IDs with metadata + time coverage. Use this to discover what you can query about Germany, USA, G7, or any k... | entity_id (string), topic (string) |
| Get full metadata for a specific dataset including title, description, publisher, category, keywords, row count, and creation date. | dataset_id (string) |
| Get the column names, data types, and total row count for a dataset. Always call this before query_dataset to understand the available columns for filtering and sorting. | dataset_id (string) |
| Query data from a dataset with optional filtering, sorting, and field selection. Supports server-side aggregations (avg/sum/count/min/max/stddev/median) with optional GROUP BY for token-efficient q... | dataset_id (string), limit (number), offset (number), fields (string), sort (string), filter (array), aggregate (string), groupby (string) |
| List published chart visualizations on Autario. Returns chart IDs, titles, insights, linked datasets, and creation dates. Use to discover existing analyses. | q (string), limit (number), offset (number) |
| Get a specific chart by ID or slug. Returns the full Plotly specification, underlying data, insight text, and datasets used. The chart URL is shareable at autario.com/chart/{id}. | chart_id (string) |
The differentiator. Join indicators across datasets via shared time + entity shadow columns. No manual relationship setup.
Tool | What it does | Parameters |
| Fetch wide-format data for ONE entity across MULTIPLE indicators — joined automatically on time via shadow columns. This is the "cross-dataset join" capability: no manual relationship setup needed.... | entity_id (string), indicators (array), time (string) |
| Compare ONE indicator across MULTIPLE entities (e.g. GDP of DEU vs USA vs CHN). Returns wide-format rows like [{time:"2020", DEU:3846, USA:20937, CHN:14688}, …]. Use this for country comparisons, c... | entities (array), indicator (string), time (string) |
| Verify that a claimed value is correct. Use this when a user asks "did you hallucinate that?" or when you want to double-check your cited numbers before presenting. Pass the indicator, entity, time... | indicator (string), entity (string), time (string), expected (number) |
Run analyses against verified data. Outputs include effect sizes, p-values, and plain-language interpretations.
Tool | What it does | Parameters |
| Summary statistics for a single indicator+entity: n, mean, median, std, min/max, quartiles, skew, histogram. Use FIRST before running any test so you know what the data looks like (sample size, com... | indicator (string), entity (string), time (string) |
| Compute Pearson + Spearman correlation between two indicators for one entity. Returns r, p-value, n, and human-readable interpretation. Use for "does X move with Y?" questions. Includes causation d... | entity (string), a (string), b (string), time (string) |
| Linear regression of y ~ x for one entity. Returns slope, intercept, R² and interpretation. Use for "how does X predict Y?" questions. | entity (string), y (string), x (string), time (string) |
| Period-over-period percentage change for an indicator. Use for growth rates (YoY, QoQ, MoM). | entity (string), indicator (string), time (string), period (string) |
| Rolling window statistics (mean/std/min/max/sum) for an indicator. Smooths noise, reveals trends. | entity (string), indicator (string), window (number), op (string), time (string) |
| Create a derived series from two indicators using an Excel-style op: ratio (A/B), ratio_pct (A/B100), diff (A-B), sum (A+B), product (AB). Returns the per-timepoint result + summary. Use for thin... | a (string), b (string), entity (string), op (string), time (string) |
| Cross-correlation at multiple lags. Answers "does A lead or lag B?". Peak |r| at positive lag means A precedes B by that many periods. Common use: "is consumer confidence a leading indicator of ret... | a (string), b (string), entity (string), max_lag (number), time (string) |
| Additive decomposition Y = trend + seasonal + residual. Use this to strip the seasonal cycle from a series and reveal the underlying trend | great for monthly or quarterly data (retail sales, unemp... | indicator (string), entity (string), period (number), time (string) |
| KILLER ANALYSIS: given a target KPI + multiple candidate indicators, rank which candidates best predict the target by correlation strength. Perfect for "what moves my KPI?" questions. Returns ranke... | entity (string), target_indicator (string), candidates (array), time (string) |
| HEADLINE OP: given an outcome metric + entity, rank which other metrics best explain the outcome. Auto-selects candidates from the ontology if | entity (string), outcome (string), candidates (string), time (string) |
Current quotes for public companies. Beats stale training-data answers.
Tool | What it does | Parameters |
| Get current stock metrics for a public company. Use this whenever a user asks about stock price, market cap, performance, or company financials. Returns the latest verified data from autario.com in... | ticker (string), metrics (array) |
Publish charts, create + populate datasets. Get keys at autario.com/account.
Tool | What it does | Parameters |
| Publish a new chart visualization to Autario. Requires a Plotly spec with column references (x_col, y_col, group_by, group_value). Autario pulls real data from the specified datasets to ensure data... | title (string), plotly_spec (object), insight (string), narration (string), dataset_ids (array) |
| Update an existing chart you own. Only the API key that created the chart can update it. Use this to modify the Plotly spec, title, or insight of a previously published chart. | chart_id (string), plotly_spec (object), title (string), insight (string), narration (string) |
| Create a new empty dataset on Autario. Returns a dataset_id you can populate with write_rows. Only create new datasets if the data does not already exist on Autario. Requires AUTARIO_API_KEY. | title (string), description (string), category (string), is_public (boolean) |
| Append rows of data to an existing dataset. The schema is automatically inferred from the first batch. All values are stored as text. Maximum 10,000 rows per call; use multiple calls for larger dat... | dataset_id (string), rows (array) |
| Delete all rows from a dataset while keeping the schema and columns intact. Useful for refreshing data before re-importing. Requires AUTARIO_API_KEY. | dataset_id (string) |
| Permanently delete a dataset and all its data. This action cannot be undone. Only the dataset owner can delete it. Requires AUTARIO_API_KEY. | dataset_id (string) |
Variable | Default | Purpose |
|
| API base. Override only for self-hosting. |
| unset | Required for write tools. Read tools work anonymously. |
| unset | Companion secret for the API key. |
World Bank, FRED, Eurostat, OECD, IMF, ECB, WHO, US Census Bureau, plus user-contributed datasets. Every dataset record includes a source_url pointing back to the primary publisher. Live catalog: autario.com/data.
This package is part of the autario monorepo. Tool definitions live in tools.js (single source of truth, shared with the HTTP transport in remote.js). The Tool Reference section above is auto-generated.
# regenerate the README Tool Reference from tools.js
npm run build-readme
# verify README is in sync (used in CI)
npm run check-readmeautario.com | datasets, charts, ontology
Documentation | API + MCP reference
Agent Guide | machine-readable description of every tool and endpoint
Issues | bug reports + feature requests
MIT.
Create a derived series from two indicators using an Excel-style op: ratio (A/B), ratio_pct (A/B100), diff (A-B), sum (A+B), product (AB). Returns the per-timepoint result + summary. Use for things like debt-to-GDP ratio, revenue-per-employee, spread between two yields.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| entity | Yes | ||
| op | No | ratio | ratio_pct | diff | sum | product | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds that it returns per-timepoint results plus a summary, but does not elaborate on error handling, performance, or data source requirements. No contradiction with annotations.
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?
Description is two sentences: first defines the core functionality, second provides practical use cases. Every word is informative, no fluff or repetition. Front-loaded and 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?
While the description mentions the return value (per-timepoint result + summary), it omits details about return format, error states, missing data handling, or prerequisites (e.g., do indicators need to be from the same entity?). For a tool with 5 parameters and no output schema, the description is adequate but not fully comprehensive.
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 low (20%), with only the 'op' parameter having a description. The description compensates by explaining the operations and their meanings, but fails to detail the 'a', 'b', 'entity', and 'time' parameters (e.g., what format or constraints apply).
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 states the tool creates derived series from two indicators using specific Excel-style operations (ratio, ratio_pct, diff, sum, product). It provides concrete examples like debt-to-GDP ratio, distinguishing it from sibling tools that focus on comparison, correlation, or data management.
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 gives explicit use cases ('Use for things like...'), providing clear context for when to apply the tool. However, it does not mention when not to use it or highlight alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete all rows from a dataset while keeping the schema and columns intact. Useful for refreshing data before re-importing. Requires AUTARIO_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | The UUID of the dataset to clear all rows from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the destructive nature (delete all rows) and adds context beyond annotations: keeping schema intact and requiring AUTARIO_API_KEY. It aligns with annotations (destructiveHint=true) and provides extra value.
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 two sentences with no wasted words. It starts with the action, states the effect, gives a use case, and mentions a requirement. Perfectly concise.
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 one parameter, no output schema, and simple behavior, the description is complete. It explains what happens (delete rows, keep schema), why use it (refresh data), and a requirement (API key). No gaps.
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 single parameter 'dataset_id' has a clear description in the schema ('The UUID of the dataset to clear all rows from'), and schema coverage is 100%. The description does not add additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
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 'Delete all rows from a dataset while keeping the schema and columns intact,' using a specific verb and resource. It distinguishes from siblings like 'delete_dataset' and 'write_rows' by emphasizing that only rows are removed, not the structure.
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 provides a clear use case: 'Useful for refreshing data before re-importing.' It implies when to use but does not explicitly state when not to use or mention alternatives, though the sibling context makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare ONE indicator across MULTIPLE entities (e.g. GDP of DEU vs USA vs CHN). Returns wide-format rows like [{time:"2020", DEU:3846, USA:20937, CHN:14688}, …]. Use this for country comparisons, cross-region analyses, or any chart that compares the same metric across entities.
| Name | Required | Description | Default |
|---|---|---|---|
| entities | Yes | Entity codes to compare (max 50). E.g. ["DEU","USA","CHN"] | |
| indicator | Yes | Indicator ID to compare. Get from list_indicators. | |
| time | No | Optional time range: "2010-2023" or "2020" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds behavioral traits like output format (wide-format rows) and an example. No contradiction with annotations.
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: purpose with example, output format, and use cases. Front-loaded with core purpose, no extraneous words. Highly 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?
Tool is relatively simple with 3 parameters and rich annotations. Description explains purpose, output format, and use cases adequately. Could mention that entities must exist in the system, but references list_indicators for indicator retrieval.
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%; all parameters have descriptions. The description reinforces that indicator is singular and entities are multiple but adds minimal new semantics beyond the schema. Baseline 3 is appropriate.
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 states the tool compares one indicator across multiple entities, provides an example (GDP of DEU vs USA vs CHN), and distinguishes from sibling tools like get_entity_data by specifying cross-entity comparison.
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?
Description explicitly mentions use cases (country comparisons, cross-region analyses, charts comparing same metric across entities). It does not mention when not to use or alternatives like get_entity_data, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute Pearson + Spearman correlation between two indicators for one entity. Returns r, p-value, n, and human-readable interpretation. Use for "does X move with Y?" questions. Includes causation disclaimer automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Entity code (e.g. DEU) | |
| a | Yes | First indicator ID | |
| b | Yes | Second indicator ID | |
| time | No | Optional time range: "2010-2023" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by detailing return values (r, p-value, n, interpretation) and the automatic causation disclaimer, which are behavioral traits beyond what 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?
Three sentences with no waste: states purpose, return values, usage, and a disclosure. Every sentence is essential and front-loaded.
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, the description compensates by listing return fields. The tool is straightforward, and annotations cover idempotency. Could detail the time parameter format, but schema already describes it as optional.
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 schema already documents all parameters. The description does not add additional parameter details beyond the schema, so a baseline score of 3 is appropriate.
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 specifies 'Compute Pearson + Spearman correlation between two indicators for one entity', which is a specific verb+resource combination. This clearly differentiates from sibling tools like regression (which models relationships differently).
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 'Use for "does X move with Y?" questions', providing clear guidance on when to use. It could be improved by explicitly mentioning when not to use, but the context is sufficient given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new empty dataset on Autario. Returns a dataset_id you can populate with write_rows. Only create new datasets if the data does not already exist on Autario. Requires AUTARIO_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Dataset title (e.g. "Global CO2 Emissions by Country") | |
| description | No | Description of the dataset contents, source, and methodology | |
| category | No | Category for the dataset (e.g. "Finance & Economics", "Health & Society", "Environment") | |
| is_public | No | Whether the dataset is publicly visible (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutation (readOnlyHint=false) and not destructive. The description adds that it returns a dataset_id and requires an API key. It does not specify error behavior on duplicate entries or other side effects, so additional context is limited.
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 sentences, front-loaded with the primary action, followed by return value and usage condition. Every sentence is informative and no unnecessary words.
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 creation tool with no output schema, the description covers purpose, return value, and a key usage condition. Missing details on duplicate handling and deeper behavioral traits, but overall adequate given schema completeness.
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 input schema has 100% coverage with clear descriptions for each parameter. The tool description adds no extra meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 'Create a new empty dataset on Autario.' with a specific verb and resource. It distinguishes from siblings by mentioning the returned dataset_id and the subsequent write_rows step.
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 advises 'Only create new datasets if the data does not already exist,' implying a check beforehand. It also mentions the required AUTARIO_API_KEY. However, it does not explicitly suggest an alternative tool like search_datasets to verify existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a dataset and all its data. This action cannot be undone. Only the dataset owner can delete it. Requires AUTARIO_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | The UUID of the dataset to permanently delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), the description adds that the action cannot be undone and requires owner and API key, giving useful behavioral context.
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 concise sentences with no wasted words, front-loading the key point of permanent deletion.
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 simple destructive action with one parameter, the description covers permanence, ownership, and auth requirements. No output schema needed.
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% with a clear description for dataset_id. The tool description does not add additional parameter info, but the schema already handles it well, so baseline 3 is appropriate.
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 it permanently deletes a dataset and all its data, distinguishing it from sibling tools like create_dataset or query_dataset.
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?
Specifies that deletion is irreversible, requires owner permission, and needs AUTARIO_API_KEY. Provides clear context for when to use, but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summary statistics for a single indicator+entity: n, mean, median, std, min/max, quartiles, skew, histogram. Use FIRST before running any test so you know what the data looks like (sample size, completeness, distribution shape).
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | ||
| entity | Yes | ||
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable detail on what statistics are computed (n, mean, median, etc.), providing behavioral context beyond annotations.
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?
Two sentences: first defines output, second gives usage guidance. No redundant information, front-loaded, and 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?
Despite no output schema, the description lists all key statistics returned (including histogram). It provides usage context. Missing details on optional 'time' parameter, but overall sufficient for the tool's simplicity.
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 mentions 'single indicator+entity', clarifying that indicator and entity are the main identifiers. However, with 0% schema coverage, it does not explain the 'time' parameter or its optionality. The parameter names are self-explanatory, so minimal added value.
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 verb ('Summary statistics') and resource ('single indicator+entity'), listing specific statistics. It distinguishes from siblings like 'correlate' or 'regression' by focusing on basic exploratory stats for a single combination.
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 states 'Use FIRST before running any test so you know what the data looks like', guiding the agent to use it for initial data exploration. While it doesn't mention when not to use, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KILLER ANALYSIS: given a target KPI + multiple candidate indicators, rank which candidates best predict the target by correlation strength. Perfect for "what moves my KPI?" questions. Returns ranked list with r, p-value, R² for each candidate. Maximum 30 candidates per call.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Entity code (e.g. DEU) | |
| target_indicator | Yes | The KPI you want to explain | |
| candidates | Yes | Candidate indicator IDs to test (max 30) | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds behavioral details: it performs correlation analysis, returns r, p-value, R², and a ranked list, and limits candidates to 30. This supplements the annotations without contradiction, though no information about potential side effects or permissions is needed given the annotations.
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 front-loaded with the core purpose. The term 'KILLER ANALYSIS' adds a slight attention-grabbing tone but does not detract from clarity. Each sentence adds value: defining the task, use case, output, and constraint. It could be slightly tightened but remains effective.
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 covers the main functionality, output format, and constraint. However, it does not explain the optional time parameter or provide details on how results are ordered (e.g., by r or p-value). Given no output schema, more detail on the return structure would improve completeness. The presence of annotations partially compensates, but the missing time parameter guidance 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?
The description clarifies the roles of target_indicator and candidates, and adds the constraint of maximum 30 candidates, which goes beyond the schema descriptions. However, the 'time' parameter lacks description in both schema and description, leaving its purpose unclear. With 75% schema coverage, the description provides meaningful additional context for the core 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 clearly states that the tool ranks candidate indicators by correlation strength to predict a target KPI. It uses specific verbs (rank, predict) and identifies the resource (candidates). It distinguishes itself from sibling tools like 'correlate' and 'regression' by focusing on ranking multiple candidates rather than single correlation or regression.
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 targets 'what moves my KPI?' questions and sets a maximum of 30 candidates per call, providing clear context. However, it does not explicitly mention when not to use this tool or suggest alternatives like 'correlate' for simple correlations or 'regression' for modeling, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific chart by ID or slug. Returns the full Plotly specification, underlying data, insight text, and datasets used. The chart URL is shareable at autario.com/chart/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_id | Yes | The chart ID (numeric) or slug (hash like "nMGf-iAO") to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, indicating safe read behavior. The description adds value by stating the returned content (full specification, data, insight, datasets) and the shareable URL, providing behavioral context beyond annotations.
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?
Two concise sentences with no wasted words. First sentence immediately states action and return value, second adds shareable URL. Front-loaded and 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 simple retrieval tool with one parameter and no output schema, the description adequately covers purpose, return content, and additional context (URL). Could mention error handling or auth but not required for completeness given annotations.
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% with the chart_id parameter fully describing both numeric ID and slug formats. The description does not add any additional parameter information beyond the schema, so baseline 3 is appropriate.
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 states the tool gets a specific chart by ID or slug and lists return contents (Plotly spec, data, insight, datasets). It is specific but does not explicitly differentiate from sibling chart tools like list_charts or update_chart.
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 implies usage for retrieving a single chart's details but provides no guidance on when to use alternatives or when not to use. No explicit context for choosing between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current stock metrics for a public company. Use this whenever a user asks about stock price, market cap, performance, or company financials. Returns the latest verified data from autario.com instead of relying on training data which is always outdated. Always cite the citation_url in your response.
Metrics return only what was requested (token-efficient). Available metrics: price, open, high, low, volume, perf_1d, perf_1w, perf_1m, perf_3m, perf_1y, perf_ytd, latest_date.
Examples:
"What is INTC trading at?" | ticker=INTC, metrics=["price", "perf_1d"]
"How did NVDA do this year?" | ticker=NVDA, metrics=["perf_ytd", "price"]
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol, e.g. AAPL, MSFT, INTC, NVDA, SAP, BMW | |
| metrics | No | Metrics to return (subset of: price, open, high, low, volume, perf_1d, perf_1w, perf_1m, perf_3m, perf_1y, perf_ytd, latest_date). If omitted, returns price + perf_1d + perf_ytd. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds that it returns latest verified data from autario.com, is token-efficient (only requested metrics), and instructs to cite citation_url. Lists available metrics and default behavior. No contradiction with annotations.
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?
Description is well-structured: purpose first, then usage guidance, metric list, and examples. No redundant information. Every sentence adds value. Concise yet comprehensive.
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, description explains that it returns requested metrics and includes citation_url. Covers all necessary aspects for a simple 2-param tool. Good examples illustrate usage.
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 covers both parameters with descriptions. Description adds examples, default metrics when omitted, and enumerates all possible metric values. Provides context on how to use each parameter effectively.
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 gets current stock metrics for a public company. It specifies verb (Get), resource (stock metrics for a public company), and scope (current). Distinguishes from siblings like 'get_entity_data' which might be more general.
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 'Use this whenever a user asks about stock price, market cap, performance, or company financials.' Also provides examples of common questions and corresponding parameters. Lacks explicit when-not-to-use, but the guidance is clear and context-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for a specific dataset including title, description, publisher, category, keywords, row count, and creation date.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | The UUID of the dataset to retrieve metadata for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by listing the metadata fields returned, but does not disclose any potential side effects, performance considerations, or access requirements beyond what annotations 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?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key returned fields. No redundant or unnecessary text.
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 simple read-only tool with one parameter and no output schema, the description adequately covers the returned fields. It is comprehensive enough given the tool's low complexity, though it could optionally note the return format or that it requires a valid dataset_id.
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 describes the dataset_id parameter with 'The UUID of the dataset to retrieve metadata for', achieving 100% coverage. The description does not add any extra meaning to the parameter beyond what the schema provides.
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 it retrieves full metadata for a specific dataset, listing the fields included (title, description, publisher, etc.). This distinguishes it from siblings like get_dataset_schema (which gets schema) and search_datasets (which searches).
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 implies usage when you need a dataset's general metadata, but it does not explicitly state when to use this tool versus alternatives like get_dataset_schema or search_datasets. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the column names, data types, and total row count for a dataset. Always call this before query_dataset to understand the available columns for filtering and sorting.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | The UUID of the dataset to get the schema for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the return content (column names, data types, row count). No behavioral contradictions.
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?
Two sentences with no wasted words. First sentence states function, second provides usage hint. Perfectly front-loaded.
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 one parameter, full schema coverage, no output schema, the description is complete: it explains what is returned and when to use it. No gaps.
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% with dataset_id described as 'The UUID of the dataset to get the schema for'. The description adds no extra semantics beyond the schema, meeting the 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 clearly states it retrieves column names, data types, and row count—specific verb and resource. It distinguishes from siblings by explicitly directing to call before query_dataset.
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 states 'Always call this before query_dataset' to understand columns for filtering/sorting, providing clear when-to-use guidance. However, it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch wide-format data for ONE entity across MULTIPLE indicators — joined automatically on time via shadow columns. This is the "cross-dataset join" capability: no manual relationship setup needed. Returns JSON rows like [{time:"2020", gdp:3846, unemployment:3.8, life_expectancy:81.3}, …]. Perfect for multi-indicator dashboards or correlation analyses.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity code (e.g. "DEU", "USA", "EUU") | |
| indicators | Yes | Indicator IDs (max 10). Get these from list_indicators or get_entity_profile. | |
| time | No | Optional time range, e.g. "2010-2023" or "2020". Format: YYYY or YYYY-YYYY |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent, and closed world. The description adds behavioral details: returns JSON rows with a concrete example, explains automatic join via shadow columns, and specifies a max of 10 indicators. No contradictions.
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, front-loaded: first sentence states action and scope, second explains unique join capability, third shows return format and use cases. No wasted words, every sentence 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?
Given no output schema, the description provides a return format example and covers entity, indicators, time, join mechanism, and use case. It does not address error cases or limits on time ranges, but for a read-only data fetch tool with good annotations, it is sufficiently complete.
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% with basic descriptions. The description adds valuable context: indicators come from list_indicators/get_entity_profile, max 10 allowed, time parameter is optional and can be a range. This goes beyond the schema alone.
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 states it fetches wide-format data for one entity across multiple indicators with automatic time join. It highlights the cross-dataset join capability, distinguishing it from sibling tools like compare_entities (multiple entities) and get_entity_profile (single indicator).
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 'Perfect for multi-indicator dashboards or correlation analyses', giving clear use cases. Does not mention when to avoid it or list alternatives, but the description implicitly excludes multi-entity use and automatic join sets it apart from manual query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all indicators available for one entity (country, aggregate, etc.). Returns indicator IDs with metadata + time coverage. Use this to discover what you can query about Germany, USA, G7, or any known entity. Entity IDs are ISO 3166 codes (DEU, USA, CHN) or World Bank aggregates (WLD, EUU, EMU, SSF).
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | Entity code (e.g. "DEU" for Germany, "USA" for United States, "EUU" for European Union, "WLD" for World) | |
| topic | No | Optional: filter indicators by topic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by stating return content (indicator IDs with metadata and time coverage) and clarifying entity ID standards (ISO 3166 codes or World Bank aggregates), which aids agent understanding without contradicting annotations.
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 concise sentences: purpose, usage guidance, and ID format detail. No filler. The most critical information is front-loaded ('Get all indicators...'), making it easy for an agent to parse quickly.
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 an output schema, the description adequately summarizes return values (indicator IDs, metadata, time coverage). It doesn't detail the exact structure, but for a discovery tool with simple return types, this is sufficient. Strong enough for an agent to form correct expectations.
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 has 100% description coverage for both parameters. The description adds context for entity_id by specifying ISO 3166 codes and World Bank aggregates, going beyond the schema's examples. The topic parameter is not elaborated further, but the schema already explains its optional filtering role.
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 specifies a concrete action: 'Get all indicators available for one entity.' It mentions return values (indicator IDs, metadata, time coverage) and distinguishes from siblings like 'get_entity_data' by focusing on discovery rather than data retrieval.
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 clearly tells when to use the tool: to discover what indicators exist for an entity. Provides examples (Germany, USA, G7) and entity ID formats. While it doesn't explicitly mention when not to use, the sibling set implies alternatives like 'get_entity_data' for actual values, making the guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-correlation at multiple lags. Answers "does A lead or lag B?". Peak |r| at positive lag means A precedes B by that many periods. Common use: "is consumer confidence a leading indicator of retail sales?".
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First indicator id (candidate leading series) | |
| b | Yes | Second indicator id (candidate lagging series) | |
| entity | Yes | Entity code (e.g. USA) | |
| max_lag | No | Max lag in periods (1-20, default 5) | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true. Description adds that it computes cross-correlation at multiple lags and interprets peaks, but does not discuss computational limits or data requirements.
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?
Two concise sentences plus a common use example. Every sentence adds value, no fluff. Front-loaded with core purpose.
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 annotations covering safety and no output schema, the description explains output interpretation (peak |r|). Could specify output format or handling of no correlation, but still fairly complete.
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 covers 80% of parameters with descriptions (a, b, entity, max_lag). Description does not add new parameter-specific details beyond what schema provides. Baseline of 3 is appropriate.
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 states the tool computes cross-correlation at multiple lags to answer 'does A lead or lag B?', with example interpretation. Distinguishes from sibling tools like 'correlate' by focusing on lag analysis.
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 a common use case ('is consumer confidence a leading indicator of retail sales?') and explains how to interpret results. While it doesn't explicitly list when not to use or alternatives, the guidance is sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List published chart visualizations on Autario. Returns chart IDs, titles, insights, linked datasets, and creation dates. Use to discover existing analyses.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search term to filter charts by title or question | |
| limit | No | Maximum number of charts to return (default 20, max 100) | |
| offset | No | Number of charts to skip for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that it only returns published charts and lists specific fields, which enhances transparency beyond the annotations. No contradictions.
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 consists of two concise sentences that efficiently convey purpose, return data, and use case without any fluff 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?
Without an output schema, the description adequately lists return fields. It mentions published charts but could explicitly state that only published charts are listed. It does not describe pagination, but parameters cover that. Overall sufficient for a simple list 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 100%, so each parameter already has descriptions. The tool description does not add further detail on parameters, meeting the baseline. No additional value from tool description for 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 specifies it lists published chart visualizations on Autario, details the return fields (IDs, titles, insights, etc.), and states the use case of discovering existing analyses. This clearly distinguishes it from siblings like 'get_chart' and 'publish_chart'.
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 advises using the tool 'to discover existing analyses,' providing clear context. However, it does not explicitly state when not to use it or compare with alternatives, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the Autario indicator registry — semantic layer over all 2600+ datasets. Each indicator has a topic (economy, health, energy, …), unit (USD, %, years, …), frequency (year/month/day), and entity_type (country/subnational/aggregate). Use this to discover what data is available before querying it. Much more precise than search_datasets when you know what topic or unit you need.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Filter by topic: economy | finance | trade | marketing | health | demographics | education | energy | environment | food | technology | media | housing | transport | tourism | space | government | military | minerals | |
| unit | No | Filter by unit: USD | EUR | % | per capita | per 1000 | years | tonnes | tonnes CO2 | GWh | TWh | index | count | … | |
| frequency | No | Filter by frequency: year | quarter | month | week | day | |
| entity_type | No | Filter by entity_type: country | subnational | aggregate | company | security | |
| publisher | No | Filter by publisher (World Bank, Eurostat, FRED, WHO, …) | |
| search | No | Full-text search across indicator titles + descriptions | |
| limit | No | Max results (default 50, max 500) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context that this is a browsing/discovery tool with no side effects, and explains the scope (2600+ datasets) and filtering capabilities. No contradiction.
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 (3 sentences), front-loaded with purpose, and every sentence adds value. No fluff 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?
For a browsing tool with no output schema, the description adequately explains what the tool returns (list of indicators with metadata, filterable by topic, unit, frequency, etc.) and how it fits into the workflow (discovery before querying). Fully covers the tool's role.
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 schema already documents all 7 parameters. The description adds examples of filter values (e.g., 'economy, health, energy') and emphasizes the filtering purpose, but doesn't provide substantial new semantics beyond what the schema offers. Baseline 3 is appropriate.
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 it browses the Autario indicator registry, a semantic layer over 2600+ datasets, and lists the metadata fields (topic, unit, frequency, entity_type). It directly distinguishes from search_datasets.
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 'Use this to discover what data is available before querying it' and contrasts with search_datasets: 'Much more precise than search_datasets when you know what topic or unit you need.' Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Period-over-period percentage change for an indicator. Use for growth rates (YoY, QoQ, MoM).
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| indicator | Yes | ||
| time | No | ||
| period | No | yoy | qoq | mom (default: yoy) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, so the description's behavioral disclosure is minimal. It adds that the output is a percentage change, but doesn't elaborate on calculation details or edge cases. No contradiction with annotations.
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 extremely concise—two short sentences—with no redundant information. It front-loads the core purpose and immediately gives usage examples.
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 simple nature of a percentage change tool and the presence of safety annotations, the description covers the basics. However, it lacks details on return values, edge cases, or parameter formats, which could be problematic for agents unfamiliar with the domain.
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 only 25% (only 'period' has a description). The description mentions 'YoY, QoQ, MoM' which helps with the 'period' parameter, but does not explain 'entity', 'indicator', or 'time'. With low schema coverage, the description should compensate but fails to do so.
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 'Period-over-period percentage change for an indicator' with specific examples like YoY, QoQ, MoM. It distinguishes itself from sibling tools like 'calculate', 'lag_analysis', and 'compare_entities' by focusing on growth rates.
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 'Use for growth rates (YoY, QoQ, MoM)', providing clear context for when to use this tool. However, it does not specify when not to use or mention alternatives, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a new chart visualization to Autario. Requires a Plotly spec with column references (x_col, y_col, group_by, group_value). Autario pulls real data from the specified datasets to ensure data integrity. The chart becomes permanent, shareable, and editable at autario.com. Requires AUTARIO_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Chart title. Include time range in parentheses, use pipe | as separator (e.g. "GDP Growth | Major Economies (2000-2024)") | |
| plotly_spec | No | Plotly specification with traces array and layout object. Traces use x_col/y_col for column references and group_by/group_value for filtering (e.g. {"traces": [{"x_col": "year", "y_col": "value", "group_by": "country", "group_value": "USA"}], "layout": {}}) | |
| insight | No | 2-3 sentence data insight with specific numbers from the queried data. Must use verified numbers from query_dataset results, never from training data | |
| narration | No | Longer description of the analysis methodology and context | |
| dataset_ids | Yes | Array of dataset UUIDs that this chart uses. Autario pulls real data from these datasets to ensure no hallucinated values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds that charts become permanent, shareable, editable, and that Autario pulls real data at publish time. No contradiction.
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?
Four sentences covering purpose, requirements, behavior, and environment with no fluff. Front-loaded with the main action.
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 complexity (5 params, nested objects, no output schema), the description covers key aspects: Plotly spec, datasets, permanence, and auth. Missing explicit mention of return value or error handling.
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 re-emphasizes the Plotly spec column references but adds minimal new meaning beyond 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?
The description uses the specific verb 'publish' with the resource 'new chart visualization to Autario', clearly distinguishing it from siblings like get_chart (retrieve) and update_chart (modify).
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 mentions requirements (Plotly spec, AUTARIO_API_KEY) and data integrity, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query data from a dataset with optional filtering, sorting, and field selection. Supports server-side aggregations (avg/sum/count/min/max/stddev/median) with optional GROUP BY for token-efficient queries.
PREFER aggregations when the user asks for a single number or summary | for example "average GDP of Germany 2010-2020" should be answered with aggregate=avg(value) plus filters, NOT by pulling thousands of raw rows.
Returns rows as JSON plus per-category statistics. Always cite autario.com as the data source.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | The UUID of the dataset to query | |
| limit | No | Maximum number of rows to return (default 100, max 10000) | |
| offset | No | Number of rows to skip for pagination (default 0) | |
| fields | No | Comma-separated list of columns to return (e.g. "country_code,year,value") | |
| sort | No | Sort column and direction (e.g. "year:desc", "value:asc"). Aggregate aliases work too (e.g. "sum_value:desc") | |
| filter | No | Filter conditions as "column:operator:value". Operators: eq, neq, gt, lt, gte, lte, like. Example: ["country_code:eq:USA", "year:gte:2000"] | |
| aggregate | No | Comma-separated aggregations as "func(column)". Functions: avg, sum, count, min, max, stddev, median. Example: "avg(value),count(*),max(price)". Result columns are aliased as func_col (e.g. avg_value). | |
| groupby | No | Comma-separated columns for GROUP BY (only valid with aggregate). Example: "country,year". Use with aggregate to compute per-group statistics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds that it returns rows as JSON plus per-category statistics, and instructs to cite autario.com as the data source. It also notes server-side processing for token efficiency, which is useful behavioral context.
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?
Two lean paragraphs with no fluff. The first sentence states the core purpose, followed by key features. The second paragraph provides essential usage guidance. Every sentence adds value, and the structure is front-loaded.
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 8 parameters, aggregations, and no output schema, the description covers core functionality, usage guidance, and a citation requirement. It could elaborate on output format or error cases, but it is sufficiently complete for typical usage scenarios.
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 each parameter already has a detailed description. The main description adds little new parameter-level meaning, though it does highlight aggregate alias usage in sorting and the preference for aggregations. This is adequate but not exceptional beyond 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?
The description uses a specific verb 'Query' and resource 'dataset', with optional filtering, sorting, field selection, and server-side aggregations. It distinguishes this tool from siblings like 'calculate' and 'correlate' by focusing on direct querying from a dataset.
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 recommends using aggregations for single-number or summary queries, giving an example of 'average GDP of Germany 2010-2020'. It does not name sibling tools for alternatives, but the guidance is clear and contextually relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Linear regression of y ~ x for one entity. Returns slope, intercept, R² and interpretation. Use for "how does X predict Y?" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| y | Yes | Dependent variable (target) indicator ID | |
| x | Yes | Independent variable (predictor) indicator ID | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, destructiveHint, and idempotentHint. Description adds that it returns interpretation, but does not detail behavior for edge cases (e.g., insufficient data). No contradiction with annotations.
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?
Two concise sentences, front-loaded with key information. No unnecessary words.
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?
No output schema, but description lists return values. Missing error conditions, but for a straightforward tool, it is sufficiently complete.
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 50%, with 'y' and 'x' described. Description mentions 'for one entity', adding some clarity for the 'entity' parameter, but 'time' remains unexplained. Slight added value beyond 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?
Description clearly states linear regression, specifies outputs (slope, intercept, R², interpretation), and gives a usage example ('how does X predict Y?'). Distinguishes from sibling tools like 'correlate' and 'what_matters'.
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 states when to use ('Use for how does X predict Y? questions'), providing clear context. Does not explicitly mention when not to use, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rolling window statistics (mean/std/min/max/sum) for an indicator. Smooths noise, reveals trends.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | ||
| indicator | Yes | ||
| window | No | Window size in periods (2-100) | |
| op | No | mean | std | min | max | sum | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds minimal behavioral context beyond that, only mentioning 'smooths noise, reveals trends'. It does not disclose any additional behavioral traits or limitations such as handling of missing data or window boundary effects.
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 extremely concise, consisting of two sentences that front-load the key action and purpose. Every word contributes to understanding, with no fluff or repetition.
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 5 parameters, no output schema, and simple functionality, the description covers the core purpose but lacks details about the time parameter, return format, and prerequisites (e.g., data alignment). Annotations fill some gaps, but overall completeness is moderate.
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 mentions 'indicator' (mapping to the indicator parameter) and lists the supported operations (mean, std, min, max, sum) which aligns with the op parameter. However, with 40% schema coverage, the description does not explain the entity or time parameters, leaving them underspecified. The window parameter is partially covered by the schema's description and the tool's name.
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 computes rolling window statistics (mean/std/min/max/sum) for an indicator, and mentions noise smoothing and trend revelation. This effectively distinguishes it from siblings like lag_analysis or pct_change by specifying the rolling window operation.
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 implies usage for smoothing noise and revealing trends, which suggests time series analysis, but it does not explicitly state when to use this tool versus alternatives like lag_analysis or pct_change. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Autario public data catalog. Returns dataset IDs, titles, descriptions, categories, publishers, row counts, last_refreshed_at, AND trusted ontology fields (topic, subtopic, unit, frequency, entity_type, indicator_id) when ontology confidence is high. Use this first to discover available datasets before querying. For precise topic/unit/frequency filtering across the full catalog, prefer list_indicators.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term to match against dataset titles, descriptions, and keywords (e.g. "GDP growth", "CO2 emissions", "unemployment rate") | |
| category | No | Filter by category. Options: "Finance & Economics", "Trade", "Technology", "Health & Society", "Energy", "Environment", "Demographics", "Education", "Infrastructure" | |
| limit | No | Maximum number of results to return (default 20, max 100) | |
| page | No | Page number for pagination (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds valuable context about ontology fields being returned only when confidence is high, and the scope of search (titles, descriptions, keywords). No contradictions.
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?
Two sentences: first explains purpose and output, second gives usage guidance. Front-loaded, no filler, every phrase 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?
Given no output schema, description adequately lists returned fields and conditions. Could mention pagination more, but schema already covers limit/page. Sibling context helps complete the picture.
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% with descriptions for each parameter. Description adds meaning by stating the search matches against 'dataset titles, descriptions, and keywords', which is not in schema. Exceeds baseline 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?
Description clearly states the tool searches the Autario public data catalog, returns specific fields (including ontology fields when confidence high), and distinguishes from sibling list_indicators by recommending this for initial discovery.
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 'Use this first to discover available datasets before querying' and directs to list_indicators for precise filtering. Provides good when-to-use but doesn't exhaustively cover all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Additive decomposition Y = trend + seasonal + residual. Use this to strip the seasonal cycle from a series and reveal the underlying trend | great for monthly or quarterly data (retail sales, unemployment). Returns per-timepoint components + summary amplitude.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | ||
| entity | Yes | ||
| period | No | Seasonal period in time steps (12=monthly, 4=quarterly, 7=weekly). Auto-inferred from indicator frequency if omitted. | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context: it uses additive decomposition and returns specific outputs. No contradiction. It provides more behavioral detail than annotations alone, but does not address potential limitations or assumptions.
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 one sentence with a pipe separator, front-loading the core action and equation. It is concise and efficient, though the structure could be slightly improved with clearer breaks between purpose, usage, and output.
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 complexity and lack of output schema, the description covers the method, usage context, and output format. However, it omits parameter details, edge cases, and assumptions (e.g., no missing data). More completeness would improve usability.
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 only 25% (only 'period' has a description). The description hints at period options ('monthly or quarterly') but does not explain 'indicator', 'entity', or 'time'. Parameters are largely left unexplained, and the description fails to compensate for the low schema 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?
The description clearly states the tool performs additive decomposition (Y = trend + seasonal + residual) with the purpose of stripping the seasonal cycle to reveal underlying trends. It also specifies output: per-timepoint components and summary amplitude. This distinguishes it from sibling tools like 'correlate' or 'regression'.
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 advises when to use the tool ('strip the seasonal cycle', 'reveal the underlying trend') and gives example data types ('monthly or quarterly data, retail sales, unemployment'). However, it does not mention when not to use it or alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing chart you own. Only the API key that created the chart can update it. Use this to modify the Plotly spec, title, or insight of a previously published chart.
| Name | Required | Description | Default |
|---|---|---|---|
| chart_id | Yes | The chart ID or slug returned by publish_chart | |
| plotly_spec | Yes | Updated Plotly specification with traces and layout | |
| title | No | Updated chart title | |
| insight | No | Updated insight text with verified numbers | |
| narration | No | Updated analysis description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds the ownership restriction and specifies what can be modified, providing context beyond annotations.
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?
Two short sentences, no redundant words. First sentence gives purpose and ownership rule, second lists what can be updated. Efficient and front-loaded.
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?
Covers ownership condition and typical use cases. No output schema, but update tools often return a success indicator; not critical. Could mention return value or errors, but sufficient for an update 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 100%, so the schema already describes all parameters. The description only lists three of the five parameters (omitting 'narration'), adding no deeper semantics than 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?
The description clearly states the tool updates an existing chart owned by the user, listing specific modifiable aspects (Plotly spec, title, insight). It distinguishes from create (publish_chart) and read (get_chart) tools.
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 'Only the API key that created the chart can update it', which is a strong usage condition. Does not explicitly state when not to use, but the condition implies alternatives if ownership is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that a claimed value is correct. Use this when a user asks "did you hallucinate that?" or when you want to double-check your cited numbers before presenting. Pass the indicator, entity, time, and your expected value. Returns whether autario's live value matches, with relative difference and provenance.
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | Indicator ID | |
| entity | Yes | Entity code (e.g. DEU, USA, EUU) | |
| time | Yes | Time period (e.g. "2023" or "2023-06") | |
| expected | No | The value you want to verify. Omit for existence-only check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent. Description adds return details (match, relative difference, provenance) and parameter guidance (optional expected for existence check). No contradictions with annotations.
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 concise sentences: purpose, usage scenario, then parameter and return summary. No redundancy or unnecessary detail. Front-loaded with key 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?
Given 4 parameters with full schema descriptions and no output schema, description adequately covers inputs and return behavior (match, relative difference, provenance). Could include more detail on response format if needed, but sufficient for selection.
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 already provides 100% parameter coverage. Description merely restates parameter names and optionality of 'expected', adding no new semantics beyond schema descriptions.
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 states the tool's purpose: 'Verify that a claimed value is correct.' It provides specific use cases ('did you hallucinate that?' or double-check cited numbers), distinguishing it from sibling tools like calculate or compare_entities.
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: when a user questions accuracy or to double-check numbers. However, it doesn't discuss when not to use or suggest alternatives, which would improve differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HEADLINE OP: given an outcome metric + entity, rank which other metrics best explain the outcome. Auto-selects candidates from the ontology if candidates is omitted (same topic + entity_type). Returns a ranking with confidence labels (strong/suggestive/weak/inconclusive) + reason strings + sharpen-suggestions pointing at related domains not yet included. Frequencies are auto-aligned to the coarser common grain — no inflated n-counts. Use this instead of find_drivers when you want a narrative-grade answer.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | Yes | Entity code (e.g. USA, DEU) | |
| outcome | Yes | Indicator id of the outcome metric | |
| candidates | No | Optional comma-separated candidate indicator ids. If omitted, auto-selects from ontology. | |
| time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint: true, destructiveHint: false, idempotentHint: true, so the safety profile is clear. The description adds behavioral details: auto-alignment of frequencies to avoid inflated n-counts, confidence labels, reason strings, and sharpen-suggestions. No contradiction.
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?
Two sentences with a headline structure. Every sentence provides essential information: purpose, auto-selection behavior, return format, and usage guidance. No wasted words.
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 complexity (ranking, auto-selection, frequency alignment), annotations cover safety, and description covers purpose, usage, and return format. No output schema but description sufficiently details output (ranking with confidence labels, reasons, sharpen-suggestions). Complete for agent invocation.
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 75%. Description adds meaning: clarifies that if 'candidates' is omitted, auto-selection occurs based on same topic and entity_type. For 'outcome' and 'entity', it implies their roles but doesn't detail syntax. Adds value beyond 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?
The description states the tool ranks which metrics best explain an outcome metric for an entity, using specific verbs ('rank') and resources ('other metrics'). It explicitly distinguishes itself from the sibling tool 'find_drivers' with a clear use-case differentiation.
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 guidance: 'Use this instead of find_drivers when you want a narrative-grade answer.' Also explains when candidates can be omitted (auto-selection from ontology) and mentions frequency alignment, giving clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append rows of data to an existing dataset. The schema is automatically inferred from the first batch. All values are stored as text. Maximum 10,000 rows per call; use multiple calls for larger datasets. Requires AUTARIO_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | The UUID of the dataset to append rows to | |
| rows | Yes | Array of row objects where keys are column names (e.g. [{"country": "USA", "year": "2024", "value": "25000"}]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds important behavioral context beyond annotations: schema inference from first batch, all values stored as text, and max row limit. No contradiction with annotations.
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 are front-loaded with purpose and constraints, efficient but could condense 'automatically inferred from the first batch' slightly.
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?
Covers essential aspects (purpose, limit, auth) but omits success indication or error handling, which is acceptable given no 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%, and the description adds minimal new information beyond the schema (e.g., example format not needed). Meets 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 clearly states the action ('append rows') and the resource ('existing dataset'), distinguishing it from sibling tools like clear_rows and create_dataset.
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?
Specifies a maximum row limit and hints at batching for larger datasets, but lacks explicit when-not-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Several tools have overlapping analytical purposes (e.g., 'find_drivers' and 'what_matters' both rank explanatory metrics; 'correlate' and 'regression' both assess relationships). While descriptions attempt to differentiate, an agent could easily select the wrong tool for a given task, especially for causal or explanatory queries.
All tool names use snake_case, but the structure varies: most follow a verb_noun pattern (e.g., 'create_dataset', 'search_datasets'), while others are single verbs or phrases (e.g., 'calculate', 'describe', 'what_matters'). This inconsistency may make it harder for an agent to predict tool names.
With 28 tools, the server covers a broad range of data operations from discovery to analysis to charting. While each tool may have a distinct purpose, the high number could overwhelm an agent, and some tools seem redundant (e.g., multiple correlation/regression variants).
The tool set covers the lifecycle of data: discovery, retrieval, analysis, visualization, and management. Minor gaps exist, such as the inability to update or delete individual rows, but core analytical workflows (e.g., correlation, regression, forecasting) are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Macro data for AI agents: GDP, inflation, unemployment and more (World Bank, US BLS). No keys.
SEC EDGAR financials, insider trading, and economic data for AI agents. US GAAP + IFRS.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Autario/autario-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
