Skip to main content
Glama

Digital Maker AI

by io.github.digitalmakerai
OverviewDiscussionsAdmin

search_trends

Read-onlyIdempotent

Search interest over time, related searches and video ideas for a keyword or niche, from Digital Maker AI's Trend Finder cache. Use it when the user asks whether a niche is growing or dying, what people are searching around a topic, which of several niches looks strongest, or what is trending right now. Good to call before create_video when the user is still deciding what to make.

CACHED, NOT LIVE. This reads only what the Trend Finder has already fetched, so it costs nothing and is instant, but coverage is partial: a keyword nobody has looked up yet will miss. Every result states how old it is, and you MUST pass that age on to the user rather than presenting the numbers as today's. On a miss, say so and point them at the Trend Finder page at https://digitalmaker.ai rather than guessing at numbers from your own knowledge, which for search interest you do not have.

Interest values are Google Trends relative scores from 0 to 100, where 100 is that term's own peak in the window. They compare a term against itself over time, NOT against other terms, and they are not search volumes. Never describe them as searches per month.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
geoNoTwo-letter country code such as US, GB, AU, or WW for worldwide. Defaults to WW, which has by far the best coverage. Only set this if the user specifically asked about one country.
includeNoall is the default and returns whatever is cached. interest is the trend line only. related is what else people search around it. ideas is cached video title suggestions for that keyword.
keywordNoThe niche or search term to look up, in plain words: 'stoicism', 'personal finance', 'true crime'. Leave out entirely to see what is trending right now instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark it read-only and idempotent, yet the description adds genuinely new behavioral context: reads are cached not live, coverage is partial, every result carries an age that must be relayed to the user, and on a miss the agent should route to the website rather than fabricate numbers. It also warns against misinterpreting the 0-100 values as search volumes. This is well beyond what annotations provide.

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?

It is long, but front-loaded with purpose before caveats, and each block (usage, cache warning, metric semantics) carries distinct, non-redundant information. Slightly over-extended for a three-param read tool, but nothing is padding.

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 no output schema, the description correctly compensates by explaining what the returned interest values mean (Google Trends relative scores 0-100, self-relative, not volumes) and the cached-age caveat. An agent has everything needed to call it and interpret results honestly.

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 100% and all three parameters are already documented in-schema (including the WW default and the include enum values), so the description adds no per-parameter syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb and resource ('Search interest over time, related searches and video ideas for a keyword or niche') and scopes it to a named data source (Digital Maker AI's Trend Finder cache). An agent can distinguish it from siblings like create_video or find_faceless_channels without opening the schema.

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?

It explicitly enumerates the triggering questions ('is a niche growing or dying', 'what people are searching around a topic', 'which of several niches looks strongest', 'what is trending right now') and recommends calling it before create_video. Both when-to-use and the pre-condition for a sibling are stated.

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

All Digital Maker AI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources