A
licenseA
qualityB
maintenanceQuery 2,500+ verified public datasets (World Bank, IMF, Eurostat, OECD, WHO) from your AI agent. Search, analyze, and visualize data, and publish charts — with verified SEC + official source data.
28
662
1
MIT
Tako
Server Details
Give your agent web search and authoritative datasets: S&P Global, FRED, OECD, SimilarWeb & more.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- TakoData/tako-mcp
- GitHub Stars
- 5
- Server Listing
- Tako MCP
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.5/5.0
Tool DescriptionsA
Average 4.8/5 across 3 of 3 tools scored.
Server CoherenceA
Disambiguation4/5
Each tool has a distinct primary role: tako_available_data for coverage discovery, tako_search for broad reconnaissance, and tako_answer for specific single-answer questions. However, tako_search and tako_answer can both retrieve data values, requiring agents to carefully read the instructions to pick the right one.
Naming Consistency3/5
All tools share the tako_ prefix, but the second part mixes verbs (answer, search) with a noun phrase (available_data), so the pattern is not fully consistent. The names are still readable and predictable, but they deviate from a strict verb_noun convention.
Tool Count5/5
With three tools, the server is well-scoped for its data Q&A purpose. Each tool earns its place: one for discovering coverage, one for browsing/searching, and one for synthesizing answers. The count is within the ideal 3-15 range.
Completeness3/5
The set covers discover, search, and answer, but the descriptions explicitly reference a fourth tool, tako_contents, for fetching full cited pages and history. Without it, the workflow has a notable gap for detailed content retrieval, though the other tools can work around this for many cases.
Available Tools
3 toolstako_answerTako: AnswerARead-onlyInspect
START 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 (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.
ParametersJSON Schema
| 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). |
Output Schema
ParametersJSON Schema
| 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 | |
| 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. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and destructive annotations, the description discloses that the tool 'reads the cited pages internally, inlines the cited cards' rows, and returns a coverage verdict'. It warns about structuredContent placement and the chart rendering pitfall ('do NOT re-post image_url or embed_url... or it renders twice'), adding significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense; every sentence contributes. It is front-loaded with a clear imperative and organized by best-for, alternatives, behavior, and output format. A slightly more compact structure would improve scannability, but the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description still adds vital context: output arrives as markdown, rows are in structuredContent, coverage verdict is returned, chart-widget fields exist, and pitfalls are noted. Combined with rich annotations and schema, the description fully equips an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaningful parameter nuance: strict true with empty node_ids is a 400, pinning a METRIC node id is needed to steer retrieval, sources narrowing rules, preview_rows account allowance, and include_contents false for broad fan-outs. This goes beyond schema descriptions but some duplication remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: ask one specific data question, get one synthesized answer', clearly identifying the tool's verb and resource. It explicitly distinguishes itself from tako_search and tako_available_data by stating 'Reach past it only for a different job', so sibling differentiation is strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Best for: a single, self-contained data question with one answer' and 'Reach past it only for a different job' naming tako_search and tako_available_data. It also prescribes a workflow (run tako_available_data first, pin the METRIC node id with strict:true) and explains when to narrow sources.
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 DataARead-onlyInspect
Find 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.
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | The OUTCOME. Discovery path (no `metric`): at least one match has live data coverage, not mere node resolution. Lookup path (`metric` supplied): both halves resolved and the pinned metric passed the name test — read `verified` for what was actually CHECKED. Never means a chart exists; only running `next_call` establishes that. |
| 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. |
| verified | No | WHAT WAS CHECKED, as distinct from `found`, which is the outcome. `coverage`: a coverage list was drilled. `pair`: the metric is on the entity's own metric list — the strongest free evidence there is. `unlinked`: the entity's list was checked and holds nothing matching, so a pinned call will probably return 0 cards; the emitted next_call therefore drops the pin. `resolution`: no pair evidence (check skipped or failed) — treat exactly as before. |
| 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. |
Tool Definition Quality
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond the annotations: the coverage list is capped/truncated, the tool confirms existence in the graph but not chart availability, and a node_id pin can be a hard filter that may return 0 cards so a retry without node_ids is advised. This is exactly the kind of non-obvious behavior an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized into summary, when-to-use, tips, and caveats. Every section carries unique information, though a few phrases echo the schema descriptions ('boost, not a filter', 'omit only to browse'). The structure makes it scannable despite its size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool, the description covers all critical edge cases: truncated coverage lists, retries without node_ids, the difference between graph existence and chart existence, and how to use next_call prewritten. An output schema exists, so return values are not the description's job, but operational completeness is fully addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 goes beyond schema by showing the fast-path pattern of splitting q and metric, explaining label as a NER boost, and noting that omitting metric browses everything. Some of this repeats schema text, but the worked examples and task-level guidance add meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of purpose: 'Find what proprietary, continuously-updated structured data exists on something — summarized in one call.' It identifies a specific verb (find), resource (structured data), and scope (coverage), and clarifies how it differs from sibling tools by framing it as a coverage-discovery step before the real query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Ask it when the question IS coverage' and 'Worth one call first when you need a measure's EXACT name.' It also provides important exclusions and fallback behavior: treat unseen names as UNCONFIRMED rather than absent, fall back to the web, and never loop calls per name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tako_searchTako: SearchARead-onlyInspect
Reconnaissance 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 (usage, chart-widget fields).
ParametersJSON Schema
| 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`. |
Output Schema
ParametersJSON Schema
| 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 | |
| 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. |
Tool Definition Quality
A4.9/5.0
Behavior5/5
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: top card auto-renders as a chart, exportable vs license-gated card handling, and that data/web results come back together. It also discloses output placement in structuredContent vs markdown, enhancing the agent's understanding beyond the basic read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough and front-loaded with the core purpose, but it is quite long and includes some redundancy (e.g., the METRIC node id ALONE pinning advice appears twice). While every sentence is informative, the repetition and density prevent a perfect score, though the length is largely justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope, query format, parameter usage, alternatives, edge cases (non-exportable cards, legacy source synonym), and return structure comprehensively. Even with a rich output schema, it goes beyond by explaining how to interpret results and use them with sibling tools, making it fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds significant parater semantics beyond simple field descriptions. For example, it explains to keep `sources` on both unless a reason exists, the exact behavior of `strict` with `node_ids` (pin METRIC node id alone), and that `preview_rows` always returns the most-recent rows. These usage nuances are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reconnaissance and chart retrieval across the live web and proprietary data', stating exactly what the tool does. It distinguishes from siblings by noting 'For a plain "what is X", tako_answer is the better-suited tool' and 'run tako_available_data ... instead of guessing here', clearly positioning tako_search for breadth-oriented searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Best for: breadth...') and when not to ('broad or compound queries retrieve poorly'). It names alternatives (tako_answer for plain questions, tako_available_data for coverage) and even describes the cost tradeoff of using this tool first for simple lookups.
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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables AI agents to access SEC EDGAR filings, US Treasury rates, BLS labor statistics, and economic indicators without API keys.610MIT
hasdata-mcpofficial
AlicenseAqualityAmaintenanceDirect access to 40+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.2424MIT- AlicenseAqualityBmaintenanceProvides AI agents live web access through scraping, multi-engine search, site mapping, crawling, SEO audits, and 31 data collectors via natural language tool calls.9MIT
Try in Browser
Your Connectors
Sign in to create a connector for this server.