Skip to main content
Glama
phalkmin

trendzeist-mcp

by phalkmin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

aeo_opportunities

Find answer-engine optimization opportunities by clustering question-shaped searches for 1-5 seeds, scoring trends, news, Wikipedia, and site coverage to surface citable gaps.

Instructions

AEO opportunity finder. For 1-5 seeds: question-shaped searches (Trends + a capped Autocomplete pass) clustered by seed and title angle, each scored with the seed's recent trend (direction_now over 12 months, growth_3m), Google News coverage (who to quote / pitch), Wikipedia presence, the site's own coverage and the evidence type that makes the answer citable (score_breakdown explains every point). site_queries = queries the site already ranks for (fill from a Search Console MCP or page titles); clusters then carry coverage covered / partial / gap and exclude_covered drops covered ones. Spam-like rising queries are ignored. Up to ~1+10 requests per seed; partial failures per source in errors. limit: clusters (1-25).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
geoNo
limitNo
seedsYes
timeframeNotoday 3-m
site_queriesNo
exclude_coveredNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.0
    • addedInput schema / properties / exclude_covered
      Added value: +{
+  "default": false,
+  "title": "Exclude Covered",
+  "type": "boolean"
+}
    • addedInput schema / properties / site_queries
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Site Queries"
+}
  2. Addedv0.4.0

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses the request budget (~1+10 per seed), per-source partial failures surfaced in `errors`, that autocomplete is capped, that spam-like rising queries are ignored, and that clusters carry covered/partial/gap with exclude_covered dropping covered ones. These are exactly the operational traits an agent needs before calling a multi-source network tool.

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?

Front-loaded with the core purpose, then dense but mostly information-bearing sentences; nothing reads as filler. It is a run-on block though, and the bare 'limit: clusters (1-25)' trailing sentence is awkwardly detached from the rest of the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still adds useful semantics (score_breakdown, coverage categories, errors). For a complex composite tool it is nearly complete, with the only real gap being the unexplained geo and timeframe inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it explains four of six parameters meaningfully: seeds (1-5), site_queries (definition plus suggested source), exclude_covered (drops covered clusters) and limit (clusters 1-25). It leaves geo and timeframe entirely undocumented, so two parameters remain opaque to the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete composite purpose: it finds AEO opportunities by clustering question-shaped searches and scoring them against trend, news, wiki, site-coverage and citability signals. This implicitly distinguishes it from single-source siblings like mine_questions, news_coverage and wiki_attention, which it composes. It never names an alternative or defines the 'AEO' acronym, so a reader must infer the domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the seed/site_queries framing and by the note to fill site_queries from a Search Console MCP or page titles, which tells the agent how to prepare input. However there is no explicit when-to-use-this vs. the many sibling tools (e.g. when to call this composite instead of mine_questions + news_coverage). The one actionable routing hint is about sourcing site_queries, not about tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools