Skip to main content
Glama

Create tracker

create_tracker
Destructive

Set up a standing search the user wants watched — 'track LinkedIn posts that mention hubspot', 'track tweets mentioning @dharmesh', 'watch acme.com/pricing for changes'. query is what to watch for; tracker_type says where to watch (LinkedIn posts unless they ask for tweets/X or a specific page URL — a URL to watch means web_page, with the URL in url and query as a short label for it). linkedin_post and twitter_search requests become a daily cloud agent that emails a digest of new posts; web_page creates a tracker in their brain that runs daily and emails changes, filtered by the prompt. Always give the user the returned page_url as a link — that page is where they review and manage it.

Input Schema

NameRequiredDescriptionDefault
urlNoweb_page trackers only: the page URL to watch for changes.
queryYesThe search keywords to watch for (e.g. 'hubspot').
promptYesThe user's tracking request in their own words, verbatim, filters included (e.g. 'Track linkedin posts that mention hubspot and have more than 10 likes'). Stored on the tracker and later applied as a filter to what the search returns.
tracker_typeNoWhere to watch. Defaults to linkedin_post.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tracker_type / enum
      Previous value: -[
      -  "linkedin_post",
      -  "twitter_search",
      -  "google_search",
      -  "web_page"
      -]New value: +[
      +  "linkedin_post",
      +  "twitter_search",
      +  "web_page"
      +]
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

The description adds meaningful behavior beyond the annotations: LinkedIn and Twitter trackers become a daily cloud agent that emails digests, while web_page trackers run daily in the user's brain and email changes filtered by the prompt. It also instructs the agent to return page_url to the user for review and management. It does not cover permissions or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then adds only useful routing, behavioral, and return-value details. Despite being longer than average, every sentence contributes necessary context for a multi-mode creation tool.

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 no output schema, the description explicitly tells the agent what to return and how to use page_url. It also explains the different tracker behaviors and type-selection logic, leaving no major gap for correct invocation.

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 parameter documentation is already strong. The description still adds value by explaining the relationship between url, query, and tracker_type for web_page trackers, including that query becomes a short label for the watched URL.

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 specific verb and resource: 'Set up a standing search.' It immediately clarifies the function with concrete examples and explains how the tracker type changes what is created.

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

Usage Guidelines4/5

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

It gives clear routing guidance among tracker_type values: LinkedIn posts by default, tweets when requested, and web_page when a URL should be watched. It does not explicitly compare against sibling tools such as watch_web or manage_web_watch.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.