AdvertiserLeads MCP server

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

Annotations only cover readOnly and openWorld; the description adds genuinely non-obvious behavior: results under a day old are cached/reused and fresh checks are capped at 10/day anonymous and 50/day signed in. That rate-limit detail is exactly the kind of operational constraint annotations cannot express, though it does not say what happens when the cap is hit.

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?

Outputs are front-loaded in the first clause, and the parenthetical tool list, while long, adds real coverage information. Two sentences with little waste; the enumeration of third-party vendors could be trimmed without loss.

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?

With no output schema, the description carries the burden of describing return contents and does so concretely, and it covers the negative-result case plus caching and quota limits. The only meaningful gap is the absence of any cross-reference to the sibling tools that could equally serve a domain-lookup intent.

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?

There is a single `domain` parameter with 100% schema coverage that already documents that a URL works. The description restates 'for a domain' without adding format, normalization, or subdomain handling details, so it sits at the baseline set by the fully-documented 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?

Names a specific verb+resource (check a store by domain) and then enumerates exactly what is returned: platform, catalog size, price range, store age, and homepage tracking pixels. It even handles the negative case ('or not a store'), so an agent knows the tool is a classifier as well as an inspector, distinguishing it from lookup_brand/search_signals.

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?

Usage is only implied — the agent can infer it applies when it has a domain and wants store/ecommerce intel, but the description never explicitly contrasts with siblings like lookup_brand or search_signals, nor states when it is the wrong choice. The rate-limit sentence hints at a cost consideration but not a selection rule.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context by disclosing that the response includes the caller's plan entitlements — an authorization/entitlement dimension the annotations say nothing about.

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?

A single sentence with no padding, front-loaded with the primary resource (niches) before the secondary payloads. Slightly list-heavy but every clause identifies distinct returned content.

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?

With no input parameters and no output schema, the description carries the burden of explaining the return shape, and it does enumerate the three payload categories (niches, signal types/filters, plan). Nothing critical is missing, though it could note whether results are paginated or static.

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?

Zero parameters, so the baseline is 4; there is nothing for the description to compensate for. It does usefully clarify that the payload includes consumable filter values rather than just labels.

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 names the specific content the tool returns: tracked niches, signal types and filter values, and the caller's plan entitlements. It implicitly distinguishes itself from search_signals by positioning itself as the reference/enumeration tool for that sibling's inputs, though it never states a verb like 'list' explicitly beyond the title.

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?

Mentioning that it exposes 'filter values search_signals accepts' hints that this should be consulted before calling search_signals, but the when-to-use relationship to check_store and lookup_brand is left unstated. Usage is implied rather than prescribed.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses plan gating (free tier limited to 5 new domains a day), that Pro+ unlocks recent ads, that unknown domains trigger a live Meta Ad Library check subject to a daily limit. That is exactly the quota and side-effect context an agent needs before calling an open-world read.

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?

Front-loaded with the core question and the identity resolution it performs, then the return payload. The sentence is long and the returned-field enumeration ('advertising since, live ads, trend (new, scaling, stable, stopped), channels and store platform') is dense, but each element carries real information.

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?

With no output schema, the description must carry the return contract, and it does: it enumerates the ad signals, the signed-in enrichment fields, and the tier differences. Combined with the quota disclosure, an agent has enough to call it and interpret the result.

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 single 'domain' parameter is already documented with its example and the 'URL works too' allowance. The description adds no additional semantics about the parameter, so the baseline of 3 applies.

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 opening question 'Is this store running Meta ads?' plus 'Finds the Facebook page behind a store domain and returns advertising since, live ads, trend...' gives a specific verb and resource with a clear scope of returns. It is understandable without opening the schema, though it never names the siblings (check_store, list_niches, search_signals) to explicitly separate itself from them.

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?

Usage is implied by the ad-intelligence framing and by the note that unknown domains are checked live against the Meta Ad Library, so an agent can infer when to reach for it. There is no explicit when-not or alternative named, and nothing distinguishes it from check_store, which sounds adjacent.

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

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

Annotations only supply readOnlyHint and openWorldHint; the description carries substantial extra load and does it well — masked output on free/anonymous access, per-row billing against a monthly export quota, and the fact that re-seeing the same brand in a month is free. These are non-obvious cost and data-visibility behaviors an agent could not infer from the schema or 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?

Purpose and defaults are front-loaded in the first sentence, and the billing/masking caveats follow in a logical order with no filler. The opening sentence is long and stacks several returned fields mid-clause, which slightly hurts scanability, but every sentence earns its place.

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 eight optional parameters, no output schema, and only two annotations, the description covers defaults, access tiers, masking, and quota economics — the things an agent most needs to call it correctly. It leaves partial gaps around data freshness ('latest day' is not defined) and the exact shape of returned rows beyond the fields named.

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 all eight parameters are already documented, but the description still adds meaning: it explains that omitting `signal` yields new+scaling and omitting `niche` spans all plan-covered niches, and it ties masking to the result cap. It stops short of explaining `offset`/`limit` interplay for paging or what `min_ads` measures against, so it exceeds the baseline without being exhaustive.

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 names a specific verb and resource — searching US ecommerce brands flagged on the latest day for a change in their Meta ads — and enumerates the exact signal classes returned (newly advertising, scaling, struggling, stopped) plus attached fields (store platform, live ad count, ad channels). This is concrete enough to distinguish it from lookup_brand (single-brand lookup) and list_niches (niche enumeration) without opening any schema.

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?

It states the operating context clearly: default behavior is new+scaling brands across all niches the caller's plan covers, and free/unauthenticated callers get masked names with only the niche filter. That tells an agent when the tool is applicable and what limits apply. It never explicitly names a sibling as the alternative for a different need, which keeps it out of 5 territory.

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