Fodda Earnings Intelligence
Server Details
Cross-company earnings trends & executive divergence with citable sources.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- piers-fawkes/fodda-mcp
- GitHub Stars
- 1
- Server Listing
- Fodda
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.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
11 toolsgenerate_visualARead-onlyIdempotentInspect
Create a presentation-ready data visualization from research findings. Available chart types: "cultural_shifts" (From→To transitions), "competitive_compass" (brands on 2 axes), "trend_constellation" (network of related trends), "implication_ladder" (Signal→Trend→So What→Do What), "innovation_pathway" (Now→Near-Term→Future), "opportunity_map" (2×2 white space analysis). Returns a branded SVG that renders directly in the chat.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | JSON string containing the chart data. Structure depends on chart_type. cultural_shifts: {shifts:[{from,to}]}. competitive_compass: {brands:[{name,x,y}], axes:{left,right,top,bottom}}. trend_constellation: {trends:[{name,x,y}], connections:[{from,to,strength}]}. implication_ladder: {signal,trend,so_what,do_what}. innovation_pathway: {now,near_term,future}. opportunity_map: {items:[{name,consumer_desire,market_activity}]} | |
| chart_type | Yes | The type of visualization to generate |
Tool Definition Quality
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 that it 'Returns a branded SVG that renders directly in the chat', which is useful output context. However, using 'Create' might imply mutation, though annotations clarify it's read-only. No additional behavioral details (e.g., no side effects) 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?
The description is a single, well-structured paragraph with a clear main verb and a bullet list of chart types. Every sentence adds value, and critical info (purpose, chart types, output format) 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?
The description covers purpose, chart types, data structures, and output format. Missing potential details like error handling or size limits, but for a 2-param tool with no output schema, it is sufficiently complete. Annotations also provide safety context.
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 provides detailed structures for each chart type in the data parameter, significantly expanding on the schema's generic 'JSON string' description. This adds high value for correct parameter usage.
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 presentation-ready data visualization from research findings' and enumerates specific chart types. It distinguishes from sibling tools, which are all data retrieval tools (get_*), by focusing on visualization generation.
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 a visualization is needed, and sibling tool names (all get_*) make it obvious this is for creating visuals while siblings fetch raw data. However, no explicit 'when to use' or 'when not to use' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_company_earningsARead-onlyIdempotentInspect
The canonical per-ticker earnings source. Returns the full truth-layer record for covered tickers (517 consumer-sector companies) — analyst concerns, sentiment labels, strategic activity (marketing/retail/technology/sustainability), CEO intelligence, and validated consumer trends from Fodda's quarterly analysis pipeline. Falls back to web-backfill for uncovered tickers. Uses 0–15 API calls depending on mode/view (coverage is free, snapshot/history = 10, qa = 5, compare = 15). Use this for company-specific data. Use get_earnings_intelligence for cross-company thematic comparisons.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Execution mode (alias for view): snapshot (10 API calls), history (10 API calls), qa (5 API calls), compare (15 API calls), guidance (10 API calls), coverage (free). | |
| view | No | snapshot: full quarterly record with analyst concerns, sentiment, activity, validated trends (10 API calls). history: narrative timeline across quarters (10 API calls). qa: per-analyst Q&A entries with thematic tagging and response directness (5 API calls). compare: side-by-side comparison of 2-5 tickers (15 API calls). coverage: list all covered tickers (free). | snapshot |
| period | No | Quarter filter (e.g. Q1-2026). Defaults to latest quarter. | |
| sector | No | Sector filter for guidance view. | |
| ticker | No | Company ticker symbol (e.g. NKE, LULU, ONON). Required for snapshot, history, and qa views. | |
| userId | No | Optional user identifier for trial usage tracking. | |
| analyst | No | Analyst name filter for qa view. | |
| metrics | No | Comma-separated metric names for history view (e.g. swot_total,ceo_sentiment). Defaults to all. | |
| tickers | No | Comma-separated ticker symbols for compare view (2-5 tickers). Only used when view=compare. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveness=false. Description adds context about fallback to web-backfill, API call consumption per mode, and the nature of returned data, which are useful 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?
Description is concise (approximately 100 words), well-structured with main purpose first, then details, then usage distinction. No redundant sentences.
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 output content and fallback behavior. It also mentions API call counts. Could be improved with output format hints but is largely 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 100%, so baseline is 3. Description adds minimal extra semantic value beyond the schema, mainly reiterating mode/view behavior and API counts.
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 is 'The canonical per-ticker earnings source' and lists specific content returned. It distinguishes itself from sibling tool get_earnings_intelligence, which is for cross-company comparisons.
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 this for company-specific data. Use get_earnings_intelligence for cross-company thematic comparisons.' Also explains fallback behavior for uncovered tickers and provides mode/view guidance with API call counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_earnings_divergenceARead-onlyInspect
Cross-company analyst-management divergence detection from the knowledge graph (legacy-thematic). Surfaces where executives are deflecting, reframing, or avoiding specific topics — the gap between what analysts press on and how management responds. Use for "where are executives deflecting?" or "divergence in [sector] earnings." For per-ticker deflection signals, use get_company_earnings with view=qa and filter by response_directness. Uses 5 tokens ($2.50 via SPT).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 10, max 25) | |
| dateTo | No | ISO date range end | |
| search | No | Free text search (e.g., 'tariffs', 'AI capex', 'margin erosion') | |
| sector | No | Sector filter (e.g., 'retail', 'technology', 'travel') | |
| userId | No | Optional user identifier for trial usage tracking. | |
| dateFrom | No | ISO date range start | |
| industry | No | Industry filter (e.g., 'hotels', 'sportswear', 'luxury') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds value by disclosing cost ('Uses 5 tokens ($2.50 via SPT)') and context (legacy-thematic from knowledge graph). It does not contradict annotations. Minor gap: no detail on output format or ordering, but overall adequate.
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 with no wasted words. It efficiently covers purpose, usage, alternatives, and cost in three sentences. Front-loaded with primary function.
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 7 parameters all documented in schema, no output schema, and good annotations, the description provides use case, alternative, and cost. It lacks detail on returned fields, but the context signals (no output schema) reduce the burden. Minor gap: doesn't explain divergence scoring, but still 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?
All parameters are described in the schema (100% coverage), so baseline is 3. The description does not add additional semantics beyond what the schema provides. It mentions 'search' and 'sector' in examples, but no new detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cross-company analyst-management divergence detection from the knowledge graph (legacy-thematic).' It specifies the verb 'detect' and resource 'divergence', and distinguishes from the sibling 'get_company_earnings' by noting that for per-ticker signals one should use that tool instead.
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 provides usage guidance: 'Use for "where are executives deflecting?" or "divergence in [sector] earnings."' It also tells when not to use this tool: 'For per-ticker deflection signals, use get_company_earnings with view=qa and filter by response_directness.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_earnings_intelligenceARead-onlyInspect
Cross-company thematic earnings intelligence from the knowledge graph and web sources. Use for multi-company comparisons ("what are hotel companies saying about labor costs?"), industry-level queries, or sector filters. For single-brand earnings, brand_tracker includes earnings automatically. For per-ticker structured analysis (analyst concerns, activity breakdown, validated consumer trends), use get_company_earnings instead — it reads the canonical truth layer. Results may include "knowledge_graph" or "web_supplemental" provenance. Uses 5 tokens ($2.50 via SPT).
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Brand name for fuzzy matching (e.g., 'Nike', 'Marriott') | |
| limit | No | Max results to return (default 20, max 50) | |
| dateTo | No | ISO date range end (e.g., '2026-06-01') | |
| search | No | Free text search in earnings summaries (e.g., 'labor costs', 'tariff guidance', 'AI investment') | |
| sector | No | Sector filter (e.g., 'retail', 'technology', 'travel') | |
| ticker | No | Company stock ticker (e.g., 'NKE', 'LVMUY', 'HLT'). At least one filter required. | |
| userId | No | Optional user identifier for trial usage tracking. | |
| dateFrom | No | ISO date range start (e.g., '2025-01-01') | |
| industry | No | Industry filter (e.g., 'hotels', 'sportswear', 'consumer electronics') |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only behavior. The description adds value by noting provenance types ('knowledge_graph' or 'web_supplemental') and cost (5 tokens, $2.50). 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 concise, front-loaded with the primary purpose, and every sentence contributes essential information. No unnecessary words 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 tool with 9 parameters and no output schema, the description covers scope, alternatives, and provenance. A brief note on output format would improve completeness, but current information suffices for most use cases.
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 description doesn't need to redefine parameters. However, it adds context by providing example queries for the 'search' parameter (e.g., 'labor costs'), aiding understanding 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 clearly states the tool provides 'cross-company thematic earnings intelligence' and distinguishes it from sibling tools like get_company_earnings for per-ticker analysis. It uses specific verbs and resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (multi-company comparisons, industry queries) and when not to (single-brand earnings, per-ticker analysis) with direct references to alternatives (brand_tracker, get_company_earnings). Also includes provenance notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_evidenceARead-onlyIdempotentInspect
Get the source articles, case studies, and statistics behind a specific trend — with full citations and publisher attribution. Each item includes source URL, location, brand names, publication date, category, and a formatted citation. Use after search_graph when you need the supporting proof behind a trend. This is a direct lookup by trend ID — not a text search tool.
| Name | Required | Description | Default |
|---|---|---|---|
| top_k | No | Number of evidence items to return (default 5) | |
| userId | No | Optional user identifier for trial usage tracking. | |
| graphId | Yes | The graph ID. Use list_graphs to see all options. Examples: 'retail', 'tech', 'food', 'travel', 'beauty', 'sports', 'sic', 'pew', 'ce-design', 'ezra-eeman-wayfinder', 'dhl-ecommerce-trends-2026', 'automotive-color-trends', 'alyson-stevens-macro', 'generative-realities', 'pwc/sxsw-2026-key-insights', 'green-house/thrive-report', 'michaels-2026-creativity-trend-report', 'delta/the-connection-index' | |
| for_node_id | Yes | The node_id from a prior search_graph result (e.g. '2507.0'). MUST come from the search result's node_id field. Node IDs are NOT sequential integers — do NOT guess or invent IDs like '1', '2', '3'. Do NOT pass the trend name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by detailing return contents (source URL, citation, etc.) and confirming it's a direct lookup. Could mention behavior on empty results or error handling, but overall good.
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 with purpose and return content, followed by usage guidance and key distinction. 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?
The description explains what the tool returns and its place in the workflow (after search_graph). It does not mention the need for a valid graphId from list_graphs (though schema does). For a simple lookup with good annotations, it is largely 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%, baseline 3. The description adds critical guidance for for_node_id (must come from prior search, no guessing) and provides examples for graphId. This exceeds 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 tool retrieves supporting evidence (articles, case studies, statistics) for a specific trend, detailing return fields. It distinguishes itself from search_graph by noting it's a direct lookup by trend ID, not text search.
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 advises to use after search_graph when supporting proof is needed, and clarifies it is a direct lookup, not a text search tool. This provides clear context and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_label_valuesRead-onlyIdempotentInspect
List all brands, locations, technologies, audiences, or trends within a specific knowledge graph. Use to explore what a graph contains — e.g., "what brands are in the retail graph?" or "what locations does the fashion graph cover?". To get a complete list of every trend in a graph, call with label="Trend" — this returns the full deterministic list, useful for industry-report graphs where search may return partial results.
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | The label to fetch values for (e.g., 'Brand', 'Location', 'Technology', 'Audience', 'RetailerType', 'Trend') | |
| userId | No | Optional user identifier for trial usage tracking. | |
| graphId | Yes | The graph ID. Use list_graphs to see all options. Examples: 'retail', 'tech', 'food', 'travel', 'beauty', 'sports', 'sic', 'pew', 'ce-design', 'ezra-eeman-wayfinder', 'dhl-ecommerce-trends-2026', 'automotive-color-trends', 'alyson-stevens-macro', 'generative-realities', 'pwc/sxsw-2026-key-insights', 'green-house/thrive-report', 'michaels-2026-creativity-trend-report', 'delta/the-connection-index' | |
| property | No | Optional property to return values for. Defaults vary by label. |
get_my_accountARead-onlyIdempotentInspect
Check the current user's account status: API call balance, plan, enabled/disabled graphs, and profile info. Use when the user asks "how many API calls do I have?", "what plan am I on?", "what graphs can I access?", or similar account questions. Returns live data — not cached from session start.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds that it 'returns live data — not cached from session start,' which is valuable context beyond 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?
Two concise sentences with no extraneous information. The description is front-loaded with the core purpose and immediately followed by 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?
For a tool with zero parameters and no output schema, the description fully covers purpose, usage triggers, and behavioral characteristics. 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?
No parameters exist, so schema coverage is 100%. The description adds meaning by specifying what the tool returns (balance, plan, graphs, profile), compensating for the lack of an output 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 'Check the current user's account status' and lists specific items like API call balance, plan, enabled/disabled graphs, and profile info. It distinguishes itself from sibling tools (e.g., list_graphs, get_node) by focusing on account-level info.
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 provides example user queries that trigger this tool: 'how many API calls do I have?', 'what plan am I on?', etc. This gives clear when-to-use guidance without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_neighborsARead-onlyIdempotentInspect
Discover what's connected to a specific trend — related brands, technologies, locations, and cross-domain links that search alone wouldn't surface. Returns curated editorial connections between trends that web search cannot provide. Use after search_graph to map the territory around a trend, find which brands are connected, or understand cross-domain relationships. Requires node_id from a prior search_graph result.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Traversal depth (default 1, max 2) | |
| limit | No | Maximum results (default 50) | |
| userId | No | Optional user identifier for trial usage tracking. | |
| graphId | Yes | The graph ID. Use list_graphs to see all options. Examples: 'retail', 'tech', 'food', 'travel', 'beauty', 'sports', 'sic', 'pew', 'ce-design', 'ezra-eeman-wayfinder', 'dhl-ecommerce-trends-2026', 'automotive-color-trends', 'alyson-stevens-macro', 'generative-realities', 'pwc/sxsw-2026-key-insights', 'green-house/thrive-report', 'michaels-2026-creativity-trend-report', 'delta/the-connection-index' | |
| direction | No | Traversal direction: 'out' (default) follows outgoing edges, 'in' follows incoming edges | |
| seed_node_ids | Yes | Array of node IDs to start traversal from. MUST be actual node_id values from a prior search_graph result (e.g. ["2507.0"]). Node IDs are NOT sequential integers — do NOT guess or invent IDs like "1", "2", "3". Always call search_graph first to obtain valid IDs. | |
| relationship_types | No | Filter by relationship types: 'EVIDENCED_BY', 'RELATED_TO', 'SEMANTICALLY_SIMILAR', 'ASSOCIATED_BRAND', 'MENTIONS_BRAND', 'IN_LOCATION' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: it returns curated editorial connections, requires node_id from prior search_graph, and controls depth/direction. 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 is concise (4-5 sentences) and well-structured: first sentence declares purpose, second elaborates on output, third gives usage guidance, fourth states prerequisite. 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?
Given 7 parameters and no output schema, the description covers usage, prerequisites, and key parameter constraints. However, it does not describe the structure of the returned data, which could help an agent understand what to expect.
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 all parameters described. The description goes beyond by explaining that seed_node_ids must be actual node_id values from a prior search_graph result and warns against guessing IDs. It also clarifies depth and limit defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: discover connections to a specific trend, including related brands, technologies, and locations. It distinguishes from siblings by explicitly referring to search_graph as a prior step and noting that the tool provides curated editorial connections that web search alone cannot surface.
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 instructs to use this tool after search_graph to map territory around a trend, requiring a node_id from a prior search_graph result. It lacks explicit when-not-to-use guidance, but the context and prerequisite effectively guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_nodeARead-onlyIdempotentInspect
Get the full profile of a specific trend — detailed description, lifecycle stage (emerging/building/mature), signal strength, geographic scope, and all properties. Use when you need deeper detail on a single trend after search_graph returned a summary. Requires node_id from a prior search_graph result.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The node_id from a prior search_graph result (e.g. '2507.0'). MUST come from the search result's node_id field. Node IDs are NOT sequential integers — do NOT guess or invent IDs like '1', '2', '3'. Do NOT pass the trend name. | |
| userId | No | Optional user identifier for trial usage tracking. | |
| graphId | Yes | The graph ID. Use list_graphs to see all options. Examples: 'retail', 'tech', 'food', 'travel', 'beauty', 'sports', 'sic', 'pew', 'ce-design', 'ezra-eeman-wayfinder', 'dhl-ecommerce-trends-2026', 'automotive-color-trends', 'alyson-stevens-macro', 'generative-realities', 'pwc/sxsw-2026-key-insights', 'green-house/thrive-report', 'michaels-2026-creativity-trend-report', 'delta/the-connection-index' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's behavioral disclosure is supplementary. It adds that the tool returns a full profile with specific fields, and that it depends on a prior search_graph result. No contradictions exist. The description adds useful context beyond annotations, earning a 4.
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: first states what the tool does, second states when to use it. No redundant or extraneous information. Every sentence adds value, making it highly concise and well-structured.
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 (3 parameters, no output schema), the description is complete. It explains the return value (detailed profile with specific fields) and prerequisites. The input schema is fully documented. No gaps are evident for 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.
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 meaning by explicitly linking nodeId to a prior search_graph result and warning against guessing IDs, which is not fully captured in the schema (though schema also warns). This extra guidance elevates the score to 4.
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 'Get the full profile of a specific trend' and lists the returned fields (detailed description, lifecycle stage, signal strength, geographic scope). It distinguishes from sibling tools by noting it's used after search_graph returned a summary. This makes the purpose very clear and unique.
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 clearly specifies when to use: 'Use when you need deeper detail on a single trend after search_graph returned a summary.' It also states the prerequisite: 'Requires node_id from a prior search_graph result.' This provides explicit guidance on context and dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_graphsARead-onlyIdempotentInspect
List all knowledge graphs the user can access — IDs, descriptions, authors, sectors, signal counts. Use FIRST in any session to discover available sources before searching. Returns graph metadata needed for graphId parameters in other tools. Deprecated: waldo, psfk (use retail/tech/food/travel/fashion/beauty/sports instead).
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | Optional user identifier. Authenticated users are identified automatically via API key. For trial users, this helps track usage. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that returned metadata is needed for graphId parameters in other tools and mentions deprecation. No contradictions; behavior is well understood.
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 deprecation note. Front-loaded with the main action and key details. No wasted words; every sentence adds 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 no output schema, the description adequately lists the returned fields (IDs, descriptions, authors, sectors, signal counts). Also explains how the output is used (graphId parameter). Complete for a 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% with one optional parameter. Description explains that authenticated users are identified automatically via API key, adding context beyond the schema. Good explanation of when the parameter is relevant.
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 lists all accessible knowledge graphs with specific metadata (IDs, descriptions, authors, sectors, signal counts). It differentiates from siblings like search_graph by being the initial discovery tool for available sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use first in any session to discover sources before searching, and notes deprecated entries with replacements. Lacks explicit 'when not to use' or comparison to other sibling tools, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_graphARead-onlyInspect
Find trends, signals, and expert insights across 100+ curated knowledge graphs covering retail, beauty, tech, food, travel, sports, and 30+ specialist domains. Returns trend data with cited evidence, source attribution, and lifecycle stage (emerging/building/mature/fading) — not generic web summaries. If graphId is omitted, searches ALL accessible graphs in parallel (recommended default). Use for market trends, competitor analysis, innovation signals, consumer behavior, cultural shifts, or any topic where curated expert intelligence outperforms web search.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Execution mode: "research" for topic research (15 API calls), "compare" for upload & compare intelligence (20 API calls). Defaults to "research". | research |
| limit | No | Maximum number of results (default 10, max 50) | |
| query | Yes | The search query. Location terms are auto-detected and used to filter results geographically. | |
| userId | No | Optional user identifier for trial usage tracking. | |
| graphId | No | Optional graph ID. If omitted, searches ALL accessible graphs. Examples: 'retail', 'tech', 'food', 'travel', 'beauty', 'sports', 'sic', 'pew', 'ce-design', 'ezra-eeman-wayfinder', 'dhl-ecommerce-trends-2026', 'automotive-color-trends', 'alyson-stevens-macro', 'generative-realities', 'pwc/sxsw-2026-key-insights', 'green-house/thrive-report', 'delta/the-connection-index' | |
| skip_skills | No | If true, skip applying any enabled skills (Paralogy, Igloo, etc.) for this query only. Use when the user says "without skills", "skip Paralogy", or "just the raw results". Default: false. | |
| use_semantic | No | Whether to use semantic search (default true) | |
| include_evidence | No | If true, batch-fetch supporting evidence articles inline with results. Default: true. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: parallel search across all accessible graphs, return of lifecycle stage and source attribution, and batch-fetching evidence. 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 single paragraph is concise and front-loaded: purpose first, then output description, then default behavior, then use cases. Every sentence adds value without 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?
Given 8 parameters and no output schema, the description covers essential behavioral aspects and output characteristics (cited evidence, lifecycle stage). Lacks exact return format details but is sufficient for agent understanding.
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%, but the description significantly enriches parameter meaning: explains graphId omission effect, mode API call counts, skip_skills usage, and include_evidence behavior. This goes well beyond the 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?
The description clearly states the tool finds trends, signals, and expert insights across curated knowledge graphs, with specific output attributes. It distinguishes itself from sibling tools like get_evidence or get_node by emphasizing cross-graph search and curated intelligence.
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 clear usage guidance: default behavior when graphId is omitted, typical use cases (market trends, competitor analysis), and mentions when to use skip_skills. It lacks explicit when-not-to-use instructions but covers major scenarios.
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!
Your Connectors
Sign in to create a connector for this server.