Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Scored across 4 tools
The four tools map cleanly to distinct stages: discovery of coverage/canonical names, broad search, full-content fetching, and graph-node expansion. Descriptions explicitly cross-reference each other, such as using tako_available_data before tako_graph_related and tako_search before tako_contents, so boundaries are clear.
All tools share the tako_ namespace prefix and snake_case formatting, making the set predictable. However, the names mix noun, adjective, and verb patterns (tako_contents, tako_available_data, tako_graph_related, tako_search) rather than following a strict verb_noun convention.
Four tools is well-scoped for a read-only data graph and search server. Each tool covers a distinct part of the workflow without redundancy, and none feels trivial or excessive.
The surface covers the core read-only lifecycle: discover coverage, search results, fetch full content, and explore graph relationships. Minor gaps around explicit listing/pagination are mitigated by tako_search, tako_available_data, and tako_graph_related paging, so agents have workarounds.
Find what data Tako holds on an entity or a metric, and the canonical name it holds it under.
Best for: questions about what Tako covers. Put a company, person, or place in q to list the metrics tracked on it; put a metric in q to list the entities it covers. Add metric when you know the measure — you get the resolved pair and a ready-to-run next_call.
Search on the canonical names it returns, not your own phrasing — tako_search matches the graph's names, not yours. A name here means the graph tracks it, not that a card exists. If the follow-up search comes back empty, say Tako has no card for it rather than rephrasing the query. Hand a node id to tako_graph_related to see what else connects to it.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The entity or metric to look up by name — "Carnival", "United States", "Nvidia". Put the measure in `metric`, not here. | |
| label | No | NER label to prefer for `q` — a boost, not a filter. Set it when you can categorize the term: company → ORG, place → GPE, person → PERSON. It never applies to `metric`. | |
| limit | No | How many candidates to resolve for each of `q` and `metric`. Raising it widens what the tool considers, not just what it shows: a deeper metric can become the one `next_call` names. | |
| types | No | Narrow resolution to one kind, an entity or a metric. Omit to resolve both. | |
| metric | No | The measure, when you already know it — "gross margin", "capex". Supplying it resolves the entity+metric pair directly; omit it to browse everything the entity has. |
| Name | Required | Description |
|---|---|---|
| found | Yes | Whether Tako holds matching data; `verified` says on what evidence. |
| entity | No | Lookup path: the resolved entity. |
| metric | No | Lookup path: the resolved metric. |
| matches | Yes | The nodes whose coverage was drilled, best first. |
| guidance | No | The verdict, and the one next action. |
| verified | No | What was checked. `pair`: the metric is on the entity's own list. `coverage`: a list was drilled. `unlinked`: the list was checked, the metric is absent. `resolution`: names resolved only. |
| next_call | Yes | A follow-up search in canonical names. Null when no target is unambiguous. |
| candidates | Yes | The other nodes `q` resolved to, best first. |
| entity_candidates | No | Runners-up. |
| metric_candidates | No | Runners-up. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses important behavior: returned names mean the graph tracks the term, not that a card exists; searches should use canonical names; empty results should be reported rather than rephrased; and a node id can be passed to `tako_graph_related`.
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 front-loaded with purpose and best-use guidance, then adds only actionable caveats about canonical names, empty results, and graph follow-up. Each sentence contributes operational value.
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 rich annotations, full schema descriptions, and existing output schema, the description is complete enough for an agent to call the tool correctly. It covers the workflow, canonical-name behavior, and follow-up paths without needing to explain return values.
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 parameter descriptions are already detailed, including `q`, `metric`, `label`, `limit`, and `types`. The tool description reinforces the entity-versus-metric distinction but adds little parameter-level meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: find what data Tako holds on an entity or metric, including the canonical name. It clearly distinguishes the tool from siblings by naming `tako_search` and `tako_graph_related` and explaining their different roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance for when to use the tool: questions about what Tako covers. It also explains how to use `q` for an entity versus a metric, when to add `metric`, how to use canonical names returned, and what to do if a follow-up search is empty.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full content behind a url: a web page's text, or an exportable Tako card's data rows. Batch up to 10 urls in one call — each fails on its own.
Fetch only cards that tako_search marked exportable: true. Set max_rows when the recent rows are enough. If a page is long, such as a filing or an annual report, set query to a question to get back only the passages that answer it.
Best for: reading one source in full — a page you need to quote, or the rows behind a card you need to compute over.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | The urls to fetch: a Tako card url or a web result url. One call for 8 urls saves 7 round trips. | |
| query | No | Web pages only: a question the passages should answer. The result holds those passages instead of the page. Omit it to get the whole page. | |
| format | No | Tako cards only. `rows` returns the card's data as one table. `card` returns the card's own structure, such as a company card's tabs or a game's box score. A card type without its own structure returns `rows`. Web pages ignore it. | |
| delivery | No | Tako cards only. `inline` returns the data in the result. `link` returns a download link: a CSV file, or a JSON file with `format: "card"`. It expires in 5 minutes. Use `link` when you can run shell commands and want to analyze the data in code. If the download fails, call again inline with `max_rows` at 2,000 or less. | |
| max_rows | No | Tako cards only: how many rows to return. Omit it to get up to 2,000 rows. With `delivery: "link"`, you can raise it to 100,000. Charges scale with rows returned, so lower it when the recent rows are enough. | |
| max_chars | No | Web pages only: character cap on the extracted text. Inline fetches default to 100,000 per url, less across a batch. Raise it for a long document; `truncated` reports a cut. With `query`, it caps the passages instead: 100 to 20,000, and 4,000 by default. |
| Name | Required | Description |
|---|---|---|
| usage | Yes | What this request cost. |
| results | Yes | One per requested url, in order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description discloses batching behavior, per-URL failure isolation, exportability constraints, charge scaling with rows, link expiry, and fallback behavior if a download fails. This is substantial operational context not present in 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 front-loaded with the core action and then organized into practical constraints and use guidance. Every sentence contributes either scope, routing, or operational behavior, with little waste.
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 output schema and annotations, the description covers the remaining gaps an agent needs: what can be fetched, batching limits, failure isolation, exportable cards, long-document querying, row limits, and delivery tradeoffs. It is complete for correct 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?
The schema already documents all six parameters at 100% coverage, so the baseline would be 3. The description adds useful decision guidance for batching, max_rows, and query use on long pages, though it does not add much beyond the schema for format, delivery, or max_chars beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: fetching full content behind URLs, including web page text and Tako card rows. It clearly distinguishes content retrieval from sibling search by emphasizing full-source reading and the exportable-card constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage direction: use this to read one source in full, fetch only cards marked exportable by tako_search, batch URLs, and use query for long documents. It does not directly compare against tako_available_data or tako_graph_related, but the main routing guidance versus search is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Tako's data graph and the live web in one call: many results at once, as structured cards plus web results. The first card's chart renders inline; some hosts also show every other card's chart, in search's order.
It finds results; tako_contents fetches what's behind them. Each card carries a headline value, node ids, and a url — pass the url to tako_contents for rows (exportable: true cards) or a web result's full page text. When exportable is false the rows are locked — read the headline value from the card's description.
Best for: breadth — fan out several narrow queries in parallel. Each query answers one question — one metric for one entity, a comparison set ("Apple revenue", "Nvidia vs AMD gross margin"), or one news or web lookup ("EU AI Act timeline"); several metrics or topics in one query retrieve poorly.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language search query (e.g. "US GDP growth", "Intel vs Nvidia revenue"). Double-quote a multi-word name to keep it one entity ("tesla motors" club revenue); an unpaired quote disables quoting. Website-traffic data is keyed by domain — query "openai.com monthly visits", not "OpenAI website visits". | |
| locale | No | BCP-47 locale tag for language and formatting. Omit it and the server uses en-US. Set it to localize for the user. | |
| sources | No | Which corpora to search; default is both. Narrow to ["web"] only for news or page text — website traffic is in the data graph. | |
| country_code | No | ISO 3166-1 alpha-2 country code for localized results. Omit it and the server uses US. Set it to localize for the user. |
| Name | Required | Description |
|---|---|---|
| cards | Yes | The data cards. Fetch an exportable card's rows with tako_contents on its url. |
| usage | Yes | Cost-plus usage for this request (null when not metered). |
| guidance | No | How a keyless caller unlocks a placeholder card. |
| web_results | Yes | Web results. |
| source_notes | No | What each source is and how it builds its data, keyed by source name. |
| metric_definitions | No | What each metric means (unit, basis, caveats), keyed by metric name, deduped across cards. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world and idempotency, yet the description adds real behavioral facts: only the first card's chart renders inline (host-dependent), `exportable: false` cards have locked rows whose value must be read from `description`, and card urls feed tako_contents for rows or full page text. These are non-obvious runtime behaviors an agent could not infer from 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?
Front-loaded with what the tool does, then the card/contents relationship, then the breadth guidance — a sensible reading order. There is minor redundancy between the sentence introducing tako_contents and the later 'pass the url to tako_contents' instruction, but overall it is dense with useful content rather than padded.
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 an existing output schema and full annotation coverage, the description fills the remaining gaps: result interpretation (locked vs exportable cards), chart rendering limits, and the handoff path to tako_contents. Nothing an agent needs in order to call this correctly and interpret results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes further by specifying query composition semantics — one question per query, one metric per entity, comparison sets, or a single news/web lookup — which the schema does not state. It doesn't restate locale/country_code, but those are fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Tako's data graph and the live web in one call') and immediately distinguishes the output shape (structured cards plus web results) from the sibling that fetches details. An agent can distinguish it from tako_contents without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes between this tool and tako_contents ('It finds results; tako_contents fetches what's behind them'), and names the use case it is best for ('breadth — fan out several narrow queries in parallel'). It also gives the counter-pattern ('several metrics or topics in one query retrieve poorly'), which is the rare when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
tako_contents10 fields changedInput schema / properties / deliveryAdded value: +{
+ "description": "Tako cards only. `inline` returns the data in the result. `link` returns a download link: a CSV file, or a JSON file with `format: \"card\"`. It expires in 5 minutes. Use `link` when you can run shell commands and want to analyze the data in code. If the download fails, call again inline with `max_rows` at 2,000 or less.",
+ "enum": [
+ "inline",
+ "link"
+ ],
+ "type": "string"
+}Input schema / properties / formatAdded value: +{
+ "description": "Tako cards only. `rows` returns the card's data as one table. `card` returns the card's own structure, such as a company card's tabs or a game's box score. A card type without its own structure returns `rows`. Web pages ignore it.",
+ "enum": [
+ "rows",
+ "card"
+ ],
+ "type": "string"
+}Input schema / properties / max_rows / descriptionPrevious value: -"Tako cards only: how many rows to return. Omit it for the whole card, up to 2,000 rows. Every row delivered is billed, so lower it when the recent rows are enough."New value: +"Tako cards only: how many rows to return. Omit it to get up to 2,000 rows. With `delivery: \"link\"`, you can raise it to 100,000. Charges scale with rows returned, so lower it when the recent rows are enough."Input schema / properties / max_rows / maximumPrevious value: -2000New value: +100000Input schema / properties / urls / descriptionPrevious value: -"The urls to fetch: a Tako card url or a web result url. One call for 8 urls costs the same as 8 separate calls and saves 7 round trips."New value: +"The urls to fetch: a Tako card url or a web result url. One call for 8 urls saves 7 round trips."Output schema / properties / results / items / properties / cardAdded value: +{
+ "additionalProperties": {},
+ "description": "The card's structure.",
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+}Output schema / properties / results / items / properties / downloadAdded value: +{
+ "additionalProperties": false,
+ "description": "The file, in link mode.",
+ "properties": {
+ "expires_at": {
+ "type": "string"
+ },
+ "file_format": {
+ "enum": [
+ "csv",
+ "json"
+ ],
+ "type": "string"
+ },
+ "total_rows": {
+ "description": "Rows behind the card, before `max_rows`.",
+ "type": "number"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "expires_at",
+ "file_format"
+ ],
+ "type": "object"
+}Output schema / properties / results / items / properties / error / descriptionPrevious value: -"Why this url alone failed; the others are unaffected."New value: +"Why this url failed."Output schema / properties / results / items / properties / note / descriptionPrevious value: -"Whether `text` holds the passages for `query` or the whole page."New value: +"Whether `text` is passages or the whole page, or a card fell back to rows."Output schema / properties / results / items / properties / text / descriptionPrevious value: -"Web pages only: the page text, or its passages when `query` is set."New value: +"Web pages only: the page text or its passages."tako_search2 fields changedInput schema / properties / sources / descriptionPrevious value: -"Which corpora to search; default is both. Narrow to [\"data\"] once `tako_available_data` confirms coverage; narrow to [\"web\"] only for news or page text — website traffic is in the data graph."New value: +"Which corpora to search; default is both. Narrow to [\"web\"] only for news or page text — website traffic is in the data graph."Output schema / properties / guidance / descriptionPrevious value: -"Zero-card verdict and next action, or how a keyless caller unlocks a placeholder card."New value: +"How a keyless caller unlocks a placeholder card."tako_search1 field changedOutput schema / properties / guidance / descriptionPrevious value: -"Zero-card responses only: what this response is evidence about, and the one next action."New value: +"Zero-card verdict and next action, or how a keyless caller unlocks a placeholder card."tako_contents4 fields changedInput schema / properties / max_chars / descriptionPrevious value: -"Web pages only: character cap on the extracted text. Inline fetches default to 100,000 per url, less across a batch. Raise it for a long document; `truncated` reports a cut."New value: +"Web pages only: character cap on the extracted text. Inline fetches default to 100,000 per url, less across a batch. Raise it for a long document; `truncated` reports a cut. With `query`, it caps the passages instead: 100 to 20,000, and 4,000 by default."Input schema / properties / query / descriptionPrevious value: -"Web pages only: return the passages around matches of this phrase instead of the whole page. The full page is always scanned, so no match means the phrase isn't there."New value: +"Web pages only: a question the passages should answer. The result holds those passages instead of the page. Omit it to get the whole page."Output schema / properties / results / items / properties / note / descriptionPrevious value: -"What the `query` match found."New value: +"Whether `text` holds the passages for `query` or the whole page."Output schema / properties / results / items / properties / text / descriptionPrevious value: -"Web pages only: the page text."New value: +"Web pages only: the page text, or its passages when `query` is set."Live web access for agents: scrape, SERP search, crawl/map, 100+ collectors, datasets, proxies.
SEC filings, Wikipedia, arXiv, US Census and more for AI agents, with every answer source-linked.
Web data for agents: YouTube transcripts, screenshots, Google News, WHOIS, jobs, tech stack, more.
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
Add one secure layer between your agents and this server.
