Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.8/5 across 3 of 3 tools scored.
Each tool has a clear, distinct purpose: tako_answer for specific data questions with synthesized answers, tako_available_data for checking data existence, and tako_search for broad reconnaissance and chart retrieval. No overlap or ambiguity.
All tools share the 'tako_' prefix and use descriptive names. 'tako_answer' and 'tako_search' follow a verb pattern, while 'tako_available_data' uses a noun phrase, creating a minor inconsistency, but the pattern is still recognizable.
With only 3 tools, the set is lean but covers the core workflow of checking availability, searching broadly, and asking specific questions. It feels slightly thin but is reasonable for a specialized data query server.
The tools cover checking data existence, searching, and answering specific questions. However, the descriptions reference a missing tool 'tako_contents' for reading full page contents, indicating a notable gap in the surface for performing all expected operations.
tako_answerTako: AnswerASTART HERE for any question that wants a value, figure, or finding: ask one specific data question, get one synthesized answer grounded in the data or web tako cites.
It is the only tool whose single response can finish the job: it reads the cited pages internally, inlines the cited cards' rows, and returns a coverage verdict. Retrieval hands back captions and links you must then chase, and every extra round trip re-sends the whole conversation.
Best for: a single, self-contained data question with one answer. The answer is synthesized from the cited sources; the cards are its citations. Also the values channel for non-exportable cards: when a card is exportable: false (usually license-gated), ask here with its METRIC node id pinned and strict:true to get the figures.
Reach past it only for a different job: tako_search for breadth recon (it locates data, it does not carry values), tako_available_data when the question is what Tako covers, the Answer Agent for open-ended research.
Grounds over BOTH data and web by default. Run tako_available_data first when unsure the data exists — pass metric to get the entity+metric pair — then pin the METRIC node id it returns, with strict:true (an entity-only pin, or a pin without strict, does not steer retrieval). Cited cards inline their recent rows (see include_contents/preview_rows), so the series arrives with the answer; for full history or a cited page's text, call tako_contents on its url.
Results arrive as markdown: the synthesized answer first, then its cited data cards (headline, exportable flag, node ids, a rows-count pointer) and web citations, then source notes. The cited cards' actual rows ride in structuredContent (cards[].content), not the markdown, alongside machine essentials (request_id, usage, guidance, chart-widget fields). The top cited card also renders inline as a chart on hosts that support it — do NOT re-post image_url or embed_url as a markdown image or link, or it renders twice.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural-language question to answer (e.g. "What was US GDP in 2024?"). Website-traffic data is keyed by domain — ask about "openai.com monthly visits", not "OpenAI website visits". | |
| locale | No | Locale for results. | en-US |
| strict | No | Hard filter. When true, return ONLY cards matching at least one node in node_ids (which must then be non-empty — empty node_ids + strict is a 400). When false (default), pinned nodes are preferred/boosted but organic results still return. | |
| sources | No | Source(s) to ground in. Default ["data","web"] (both) — keep BOTH enabled unless you have a confirmed reason to narrow. Narrow to ["data"] only once `tako_available_data` has confirmed the proprietary data exists (web is the fallback when it does not). Narrow to ["web"] only for content a data graph cannot hold (news articles, page text, qualitative claims) — never because a metric merely feels web-native: website traffic, app usage, and similar digital metrics ARE in the proprietary data graph. ("tako" is a legacy synonym for "data".) | |
| node_ids | No | Graph node ids (from tako_available_data) to PIN into the proprietary data source. Pinned nodes get a strong retrieval boost. Max 20. Applies only to the 'data' source. | |
| country_code | No | ISO country code for localized results. | US |
| preview_rows | No | Cap on the rows of each cited card's data inlined when include_contents is true — always the N MOST-RECENT rows (default 20, the free inline allowance the server ships; values above your account's allowance have no effect). For more rows, call tako_contents on the card's url (priced beyond the first 20). Ignored when include_contents is false. | |
| include_contents | No | Inline each cited data card's recent rows alongside the answer (default true; preview_rows sets how many) — the values arrive with the prose, no follow-up fetch. Set false — prose + citations only — for broad fan-outs or when coverage is unconfirmed (no prior tako_available_data check). DATA cards only; cited web pages are never auto-inlined (billed per page — use tako_contents). |
| Name | Required | Description |
|---|---|---|
| cards | No | Cards cited by the answer. |
| usage | Yes | Cost-plus usage for this request (null when not metered). |
| width | No | |
| answer | No | The synthesized, citation-backed answer. |
| height | No | |
| pub_id | No | |
| guidance | No | Present only when the data source grounded zero cards: the deterministic coverage verdict. |
| dark_mode | No | |
| embed_url | No | |
| image_url | No | |
| request_id | Yes | |
| web_results | No | Web results cited by the answer, each with a `snippet` of the passages selected against the question rather than the page's opening text. A ' … ' inside one marks a discontinuity — joined passages or the page's own ellipsis — so never quote across it as one continuous sentence. `null` means no relevant passage was found on that page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds substantial behavioral context: it reads cited pages internally, inlines cited card rows, returns a coverage verdict, and places rows in structuredContent rather than markdown. It also warns against re-posting image_url/embed_url to avoid double rendering and exposes pricing nuances for preview_rows and tako_contents. 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?
The description is front-loaded with 'START HERE' and organized into clear paragraphs covering purpose, workflow, and output format. It is lengthy but every sentence provides operational value, so it earns its length. A slightly leaner version could still preserve all 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?
For a tool with 8 parameters and an output schema, the description is comprehensive: it explains the markdown layout vs structuredContent, the coverage verdict, chart rendering, source narrowing rules, and how to interact with sibling tools and tako_contents. It even mentions a specific error case (strict+empty node_ids is a 400), making it complete for safe 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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the special workflow for non-exportable cards: ask with a METRIC node id pinned and strict:true to get figures. It also clarifies that an entity-only pin or a pin without strict does not steer retrieval, which is not in the node_ids or strict 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?
The description opens with 'START HERE for any question that wants a value, figure, or finding' and explicitly states it produces 'one synthesized answer grounded in the data or web tako cites.' It clearly distinguishes itself from siblings by naming 'tako_search for breadth recon' and 'tako_available_data when the question is what Tako covers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use ('Best for: a single, self-contained data question with one answer') and when-not-to-use with named alternatives ('Reach past it only for a different job: tako_search... tako_available_data... the Answer Agent'). It also provides a concrete prerequisite workflow: run tako_available_data first, pin the METRIC node id, and set strict:true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tako_available_dataTako: Available DataAFind what proprietary, continuously-updated structured data exists on something — summarized in one call. Free and fast.
Ask it when the question IS coverage: what does Tako have on X, is this measure tracked at all, what is it called. Then build the real question around what comes back. NOT a required first step — for a straightforward data question, tako_search or tako_answer directly is usually right.
Worth one call first when you need a measure's EXACT name: resolving a loose phrase to the canonical metric name measurably improves what the priced call retrieves (measured, 9 of 15 pairs).
Works on an entity (a company, person, or place → the metrics tracked on it, e.g. Tesla) or a metric (→ the entities it is tracked across, e.g. Inflation Rate).
Tips:
Know the measure? Split it: q="Carnival", metric="passenger cruise days" — you get the entity+metric pair and a runnable next_call in ~0.6s. Only omit metric to browse everything an entity has.
One metric across many entities → one metric-first call; one entity across many metrics → one entity-first call. The returned coverage list answers all of them at once — never loop one call per name.
Pass label when you can categorize the term (company → ORG, country → GPE, person → PERSON).
Each match lists the exact metric/entity names, and structuredContent.matches[].coverage.items[] pairs each name with its node id. To land on exactly one metric, pin THAT node id alone with strict:true and name the entity in the query text; the call then returns that metric's card or nothing. When the measure is known — you passed metric, or q named a metric — next_call is that follow-up prewritten (query + the metric node + strict) — run it verbatim.
A broad entity's coverage list is capped, so it can be truncated: treat a name you don't see as UNCONFIRMED rather than absent, and fall back to the web instead of re-calling this tool to double-check.
This tool confirms a name EXISTS in the graph; it cannot confirm a chart exists behind it. If next_call returns 0 cards, retry the same query WITHOUT node_ids before concluding Tako has no data — the pin is a hard filter and the data is often held under a sibling node.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The NAME of the entity (or metric) to look up, min 2 chars — e.g. "Carnival", "United States", "Nvidia". Put the measure in `metric`, not here. | |
| label | No | NER label to prefer for `q` (boost, not a filter). Supply when you can categorize the term (company→ORG, place→GPE, person→PERSON, ...). Describes the ENTITY only — it is not applied to `metric`. | |
| types | No | Narrow resolution to a "thing" ("entity") or a "measure" ("metric"). Omit to search both. | |
| metric | No | The measure you want, when you already know it — e.g. "gross margin", "passenger cruise days", "capex". Supplying it is the FAST path: the tool resolves the entity+metric pair directly and hands back a runnable next_call, instead of listing every metric the entity has. Omit it only to browse what exists. |
| Name | Required | Description |
|---|---|---|
| found | Yes | True when at least one match has live data coverage — not mere node resolution. |
| query | Yes | |
| entity | No | |
| metric | No | The metric whose node_id belongs in the follow-up's node_ids. |
| matches | Yes | The resolved matches and their coverage, each entry carrying the node id to pin. To fetch a specific metric precisely: call tako_search or tako_answer with node_ids=[<the metric's node_id>] AND strict:true — an entity-only pin without strict does not steer retrieval. |
| next_call | Yes | Ready-to-run follow-up: call this tool with exactly this query, node_ids and strict. node_ids holds the METRIC node only — strict is an OR over pinned nodes, so adding the entity id widens the filter back out. Null when no metric resolved. |
| metric_query | No | |
| entity_alternates | No | |
| metric_alternates | No | Runners-up. The top metric is right ~80% of the time and the top three ~93-95%, so check these before accepting the primary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint/destructiveHint, which the description does not contradict. The description adds substantial behavioral context beyond those flags: it is free/fast, summarized, the coverage list is capped/truncated, absence from the list should be treated as UNCONFIRMED, it cannot confirm chart existence, next_call is prewritten and should be run verbatim, and a 0-card result should trigger a retry without node_ids. 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 long but front-loaded with the core purpose, then usage guidance, then operational tips. The length is mostly justified by the tool's dual entity/metric behavior and its failure modes (truncation, hard node-id filter, 0-card results). Some redundancy could be tightened, but every major section 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?
For a complex discovery tool, the description is contextually complete: it covers the return shape (matches[].coverage.items[] pairing names with node id, next_call), edge cases (truncated lists, 0 cards from a hard filter), and fallback strategies (treat unseen as UNCONFIRMED, retry without node_ids, fall back to web). The existence of an output schema does not reduce the value of this thorough contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning beyond the schema: it explains the relationship between q and metric ('Put the measure in metric, not here'), when to omit metric to browse, that label applies only to q, and how types narrows resolution. This is more than the schema's standalone parameter 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?
The description opens with a specific verb+resource: 'Find what proprietary, continuously-updated structured data exists on something' and immediately distinguishes itself from siblings by framing the tool as the coverage/discovery call and naming tako_search/tako_answer as the alternatives for straightforward data questions. This clearly positions the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use ('Ask it when the question IS coverage') and when-not-to-use ('NOT a required first step'), names the alternative tools, and provides a concrete trigger condition ('Worth one call first when you need a measure's EXACT name'). It also includes practical guidance for entity-first vs metric-first calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tako_searchTako: SearchAReconnaissance and chart retrieval across the live web and proprietary data: many results at once, returned as structured cards and web links, and the top card auto-renders inline as a chart.
It locates data — and for exportable: true cards it also includes a free 20-row preview by default (include_contents) — but a license-gated card carries no rows at all (headline value only, via description), and a web result is only a snippet, not a value. For a plain "what is X", tako_answer is the better-suited tool: one written figure beats parsing a preview table yourself, and reaching here first for that costs an extra round trip that re-sends the whole conversation. To ask it about a card you already have, pin that card's METRIC node id ALONE (the mt:: entry in its nodes) with strict:true — pinning every node id on the card, or omitting strict, does not steer retrieval.
Best for: breadth — fanning out many narrow queries in parallel to see what exists across several entities or metrics; retrieving a chart card when the chart or embed is itself the deliverable; and harvesting node ids and urls to feed tako_answer or tako_contents. It is cheap and fast, and built for exactly this fan-out.
Coverage spans economics, finance, company KPIs, demographics, sports, markets, weather, elections, prediction markets, website/app traffic, real estate, energy, health, and more — metrics that sound web-only (e.g. SimilarWeb-style website traffic) are in the data graph.
Each query resolves one entity + one metric ("Apple revenue", "Nvidia vs AMD gross margin"); broad or compound queries ("today's sports + odds") retrieve poorly. When the question is what Tako covers, or you need a metric's exact name, run tako_available_data (free) instead of guessing here.
Data and web come back together — treat them as one result, not an either/or. Returns: cards (up to count) with preview rows and chart URLs, plus web_results. To read a web result in full, call tako_contents on its url (web urls are always fetchable; a card's full csv needs exportable: true).
Non-exportable cards (exportable: false, usually license-gated) return no rows: read the headline value from the card's description when it carries one, or get specific figures via tako_answer — pin that card's METRIC node id ALONE (the mt:: entry in its nodes) with strict:true — pinning every node id on the card, or omitting strict, does not steer retrieval (each such card carries a values_hint saying exactly this).
Results arrive as a markdown document: a Tako Data section (per card: headline, exportable flag, node ids, chart link, a rows-count pointer), then Web Results, then source notes. The cards' actual rows and the web results' snippets ride in structuredContent (cards[].content, web_results[].snippet), not the markdown, alongside machine essentials (request_id, usage, chart-widget fields).
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Maximum number of results to return per source (1-20). | |
| query | Yes | Natural-language search query (e.g. "US GDP growth", "Intel vs Nvidia revenue"). Website-traffic data is keyed by domain — query "openai.com monthly visits", not "OpenAI website visits". | |
| effort | No | Search effort: "fast" (default) or "instant" (fastest, serves cached embeds as-is). Omit for fast. | |
| locale | No | Locale for results. | en-US |
| strict | No | Hard filter. When true, return ONLY cards matching at least one node in node_ids (which must then be non-empty — empty node_ids + strict is a 400). When false (default), pinned nodes are preferred/boosted but organic results still return. | |
| sources | No | Source(s) to search. Default ["data","web"] (both) — keep BOTH enabled unless you have a confirmed reason to narrow. Narrow to ["data"] only once `tako_available_data` has confirmed the proprietary data exists (web is the fallback when it does not). Narrow to ["web"] only for content a data graph cannot hold (news articles, page text, qualitative claims) — never because a metric merely feels web-native: website traffic, app usage, and similar digital metrics ARE in the proprietary data graph. ("tako" is a legacy synonym for "data".) | |
| node_ids | No | Graph node ids (from tako_available_data, or a card's nodes) to PIN into the proprietary data source. Pinned nodes get a strong retrieval boost. Max 20. Applies only to the 'data' source. | |
| country_code | No | ISO country code for localized results. | US |
| preview_rows | No | Cap on the rows of each card's data inlined when include_contents is true — always the N MOST-RECENT rows (default 20, the free inline allowance the server ships; values above your account's allowance have no effect). Lower it to trim context on broad fan-outs. For MORE than 20 rows, call tako_contents on the card's url (max_rows up to 2,000 — first 20 free, priced beyond). Ignored when include_contents is false. | |
| include_contents | No | Inline each Tako card's data preview (default true; preview_rows sets how many rows). Set false — pointers-only, no rows — for large parallel fan-outs or when coverage is unconfirmed (no prior tako_available_data check). DATA source only; web page text is never auto-inlined (billed per page — use tako_contents). Full export is a separate tako_contents call, only for cards marked `exportable: true`. |
| Name | Required | Description |
|---|---|---|
| cards | No | The data cards — the payload. Each carries its title, description (headline value), facts, and inline rows under `content`. |
| usage | Yes | Cost-plus usage for this request (null when not metered). |
| width | No | |
| height | No | |
| pub_id | No | |
| guidance | No | Present only on a zero-card response: the recovery protocol. |
| dark_mode | No | |
| embed_url | No | |
| image_url | No | |
| request_id | Yes | |
| web_results | No | Web results, each with a `snippet`. A snippet is the passages selected against your query, not the page's opening text, so it usually carries the answer-bearing sentence. A ' … ' inside one marks a discontinuity — either passages joined from different parts of the page, or the page's own ellipsis — so read it as a whole and never quote across it as one continuous sentence. `null` means that page had no relevant passage — its url is still fetchable via tako_contents. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, but the description goes far beyond them: it discloses that non-exportable cards carry no rows, web results are snippets, data and web results come back together, pinning requires the METRIC node id alone with strict:true, and returns come as markdown plus structuredContent. 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 dense and front-loaded with purpose, but it is also verbose and repeats key instructions: the 'pin METRIC node id ALONE' guidance appears twice, and non-exportable cards' lack of rows is stated twice. While the length is somewhat justified by complexity, the redundancy prevents a higher score.
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 10 parameters, an output schema, and rich annotations, the description is fully complete: it covers purpose, usage boundaries, behavioral quirks, parameter guidance, return format, and sibling-tool coordination. An agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds practical meaning: query examples ('Apple revenue'), website-traffic queries keyed by domain, the 'one entity + one metric' heuristic, and the strict node-pinning nuance — all beyond the schema's own text. This earns a 4, though the schema alone already does much of the work.
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 explicitly states it performs 'Reconnaissance and chart retrieval across the live web and proprietary data' and explains the output format (structured cards, web links, auto-rendered chart). It distinguishes itself from siblings by naming tako_answer and tako_available_data as alternatives, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Best for: breadth — fanning out many narrow queries in parallel' and 'retrieving a chart card when the chart or embed is itself the deliverable.' It names alternatives with specific conditions: 'For a plain "what is X", tako_answer is the better-suited tool' and 'run tako_available_data (free) instead of guessing here.' It also advises on narrowing sources, covering both when and when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.
