Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@servicehawk-ad-intel Record this plumber ad swipe: free drain inspection offer, headline 'Drains slow?'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for building a competitive ad swipe file from public Meta Ads Library research, for ServiceHawk, an agency that sells automation to home service businesses (plumbers, HVAC, pest control, roofers, electricians).
It is not a bot for logging into Meta, scraping past a paywall, or bypassing rate limits. It does none of that, on purpose:
No credentials, ever. It has no login flow and cannot be given one.
No fetching outside a small host allowlist (facebook.com, www.facebook.com, m.facebook.com, transparency.meta.com by default).
No destructive tools. Every write goes to a local append-only file.
No cloning. The scoring tools grade a pattern's reusable structure (hook, offer, proof, format); the copy generator writes new lines from that structure, never a competitor's actual sentence.
What it is: a small, honest tool for turning public ad research into a scored, searchable swipe file, plus a generator that drafts new ServiceHawk ad copy from the angles that keep showing up as winners.
Meta's official Ad Library API only really covers social issue, election, and politics ads worldwide, plus all ad types for the UK and EU over the past year. For ordinary US commercial competitor research, that leaves the public Ad Library web UI and manually saved pages, not a clean API you can query in bulk. This server is built around that constraint instead of pretending it does not exist: it helps you build the right search URLs, captures a public page when one is reachable without login, and gives you a structured way to record what you saw by hand when it is not.
Related MCP server: AdWhispr MCP Server
cd servicehawk-ad-intel-mcp
npm install
npm run smoke
npm run smoke:mcpnpm run smoke exercises the scoring and storage logic directly.
npm run smoke:mcp spins up the server over stdio and calls it as a real
MCP client would, so both checks run against the actual code path, not a
mock.
node /path/to/servicehawk-ad-intel-mcp/src/server.jsIt speaks MCP over stdio, so in practice you point an MCP client at it instead of running it by hand. Example client config:
{
"mcpServers": {
"servicehawk-ad-intel": {
"command": "node",
"args": ["/path/to/servicehawk-ad-intel-mcp/src/server.js"]
}
}
}Any MCP-capable client (Claude Code, Claude Desktop, or your own MCP client built on the SDK) can load it this way. The server has one job: expose the tools below over stdio. It does not manage its own client connection or UI.
Tool | Takes | Returns |
| Optional |
|
|
|
|
|
|
|
| Same ad fields as above, without saving |
|
| Optional |
|
| Optional |
|
|
|
|
score_ad_pattern rewards signals that predict a reusable pattern: how long
an ad has run, how many similar variants exist, whether the copy lands on a
home-service pain point, whether the offer is a low-friction diagnostic
(free audit, free report), and whether the headline is short enough to read
in a feed scroll. It penalizes risky claims (guarantees, "#1", platform
trademarks in the copy) and bloated primary text. The score is a signal for
prioritizing research, not a prediction of CPA or ROAS, and the tool says so
in its own output.
Everything is stored locally as flat files, not a database:
data/swipes.jsonl one recorded ad observation per line
data/captures/*.json saved public-page capturesOverride the location with AD_INTEL_DATA_DIR. See .env.example.
No credentials anywhere in this server or its config.
No logged-in scraping and no bypassing of Meta's own blocks. If a page comes back blocked, the tool says so and tells you to capture it by hand.
No arbitrary URL fetching. capture_public_ad_page checks the hostname
against an allowlist before it makes a request, full stop.
Every write is append-only to a local file. Nothing here deletes or overwrites past research.
This server ships with a written contract for every tool: what it takes, what it returns, and what it explicitly refuses to do (see Safety, above). Getting that contract right did not come from one pass at the code.
The work was split across roles that each owned one narrow piece of it
(the tool contracts, the scoring rules, the safety constraints) instead of
one generalist trying to hold the whole thing in its head at once. A
separate, independent pass then checked the result against the actual
source code rather than trusting the first answer, and a set of
deterministic checks, not a model's own say-so, decided what was safe to
publish. That is the same standard applied to every claim in this README:
the tool list, the input contracts, and the safety behavior above were
verified against src/lib.js and src/server.js, not written from memory.
Path | What |
| MCP server: registers the tools above and wires each one to |
| The actual logic: URL building, allowlisted fetch, scoring, and swipe file storage |
| Exercises the scoring and storage logic directly, no MCP layer |
| Spawns the server and calls it as a real MCP client, over stdio |
The scoring model is a fixed set of hand-written rules, not a trained model. It rewards home-service and diagnostic-offer signals specifically, not general ad quality, so a strong score in a different vertical means less.
Meta can and does block automated fetches of Ad Library pages. When that
happens the right move is manual capture into record_ad_swipe, not a
workaround, and this server does not try to build one.
capture_public_ad_page only extracts text; it does not download images
or video, and it does not render JavaScript.
Built by Roderick Finch, ServiceHawk AI (servicehawkai.com), Pembroke Pines, FL.
MIT licensed.
Create a public Meta Ads Library search URL for manual competitive ad research.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword or advertiser phrase, such as 'review automation' or 'plumber reviews'. | |
| ad_type | No | Meta ad type filter. Defaults to all. | |
| country | No | Two-letter country code. Defaults to US. | |
| page_id | No | Optional Meta page ID to view all active ads for a page. | |
| media_type | No | Creative media type filter. | |
| active_status | No | Active status filter. Defaults to active. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the tool only creates a URL for manual use, implying no side effects like fetching, capturing, or storing ad data. It does not detail the output format or error behavior, but for a pure URL generator the behavior is adequately disclosed.
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 sentence with no filler. The key action and purpose are front-loaded, and every word contributes to the agent's understanding.
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 six optional parameters and no output schema, the description is nearly complete. It clearly states the result is a public Meta Ads Library search URL for manual research, making the return value obvious. A slightly more explicit note about the URL format or pure string return would make it fully 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 all six parameters are fully documented in the input schema. The description adds no per-parameter semantics, but it does not need to; the baseline of 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('public Meta Ads Library search URL'), and the phrase 'for manual competitive ad research' distinguishes it from sibling tools like capture_public_ad_page or record_ad_swipe. An agent can immediately tell this builds a URL rather than performing research or recording results.
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 phrase 'manual competitive ad research' gives clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but the sibling tool names make the distinction obvious, and no strong when-not guidance is needed for a simple URL builder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch and store metadata/text from an allowlisted public ad-library page without login or bypass behavior.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL from Meta Ad Library, ad snapshot, or allowlisted transparency page. | |
| timeout_ms | No | Request timeout in milliseconds. Defaults to 10000. | |
| max_text_chars | No | Maximum extracted visible text characters to store. Defaults to 6000. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose that it operates only on 'allowlisted public' pages and does not attempt login or bypass, which is useful safety context. However, it doesn't state whether the operation is idempotent, what happens if the URL is not allowlisted, whether it overwrites existing stored data, or any error behavior. It also doesn't mention that it stores data (a write operation) with potential implications. These gaps reduce transparency.
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, compact sentence that front-loads the core action and constraints. It is free of filler and every clause carries meaning: it specifies what is fetched/stored, the source domain, and the negative constraint. This is exemplary conciseness.
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 three parameters, no output schema, and no annotations, the description provides the core function but lacks important contextual details. It does not explain what the tool returns (the stored result or a confirmation), how it handles failures (e.g., if the URL is not public or allowlisted), or when an agent should prefer this over a sibling like record_ad_swipe. Given the lack of annotations and output schema, the description is not fully sufficient for an agent to decide when and how to use it 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 description coverage is 100%, so all three parameters (url, timeout_ms, max_text_chars) already have descriptions in the schema. The tool description adds little beyond the schema: it mentions 'fetch and store' and 'allowlisted public' but these are already implied by the schema's url description. There is no additional clarification about how parameters interact or edge cases, so the description adds minimal value beyond the structured 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's function: 'Fetch and store metadata/text from an allowlisted public ad-library page'. It names the specific verb ('Fetch and store'), the resource ('allowlisted public ad-library page'), and explicitly notes what it does NOT do ('without login or bypass behavior'). This distinguishes it from siblings like build_meta_ad_library_url (which builds URLs) and record_ad_swipe (which records swipes), making it easy for an agent to understand its core role.
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 gives context about the intended use: it is for 'allowlisted public ad-library pages' and avoids 'login or bypass behavior'. However, it does not explicitly name alternative tools or state when to use this tool versus siblings. For example, it doesn't mention that record_ad_swipe is for user swipes, or when to use build_meta_ad_library_url to construct a URL first. The usage guidance is implied but not explicit, leaving the agent to infer appropriate conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ServiceHawk-safe Meta still-image ad copy variants from known winning angle families.
| Name | Required | Description | Default |
|---|---|---|---|
| cta | No | CTA label. Defaults to Get Free Audit. | |
| angle | No | Angle family to generate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'ServiceHawk-safe' but does not define what that entails (e.g., compliance rules, formatting constraints). It does not state whether the tool is read-only, what it returns (e.g., a list of strings, count of variants), or if it depends on prior data from other tools. The behavior is vague and under-specified.
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-formed sentence that leads with the main action and object. It is concise with no redundant phrases or filler. It efficiently conveys the core purpose without over-explaining.
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 that there is no output schema and no annotations, the description must be self-sufficient. It does not describe the output format (e.g., a JSON array of strings), the number of variants generated, or what 'ServiceHawk-safe' means in practice. It also does not mention any prerequisites like needing to run summarize_winning_patterns first. An agent would be uncertain about the tool's exact behavior and return value.
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% – both 'cta' and 'angle' have descriptions, and 'angle' has an enum. The description's mention of 'known winning angle families' aligns with the angle enum but adds no new meaning. The description does not clarify default behaviors beyond the schema (e.g., default CTA is already given in the schema). Thus, the description adds no value beyond the schema, fitting the baseline of 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 uses a specific verb 'generate' with a clear resource 'Meta still-image ad copy variants' and source 'known winning angle families'. It clearly distinguishes from sibling tools like build_meta_ad_library_url or record_ad_swipe, which handle different concerns. An agent can identify this tool's unique function 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool versus alternatives, nor does it reference sibling tools or exclusion conditions. The phrase 'from known winning angle families' implies a dependency but does not explicitly state when this tool is appropriate. There is no guidance on when not to use it or how it relates to other ad-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stored ad swipe observations filtered by vertical, offer, and minimum score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of records to return. | |
| offer | No | Optional offer substring filter. | |
| vertical | No | Optional vertical substring filter. | |
| min_score | No | Minimum score from 0 to 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read operation, it doesn't explicitly state that it's read-only, doesn't mention pagination behavior, ordering, or how the filters interact. It doesn't contradict anything, but offers no insight into side effects or performance.
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, concise sentence that front-loads the main action and lists all filter dimensions. No filler or repetition.
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 simple list tool with no output schema and all parameters optional, the description is mostly adequate. However, given no annotations and no output schema, it could add info about default sorting or result count, but that's a minor gap given the tool's simplicity.
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?
With 100% schema description coverage, the schema already documents each parameter's purpose. The description adds a high-level summary of filtering but doesn't clarify filter semantics (e.g., substring matching, whether min_score is inclusive) beyond what the schema provides. Baseline 3 is appropriate.
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 a specific verb ('List'), resource ('ad swipe observations'), and the filtering dimensions (vertical, offer, minimum score). It distinguishes from siblings like record_ad_swipe and score_ad_pattern by focusing on retrieval, but doesn't explicitly name a sibling it is not.
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 through its filter parameters, but provides no explicit guidance on when to use this tool versus alternatives like summarize_winning_patterns or generate_servicehawk_variants. It doesn't state when not to use it or offer alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record one observed ad pattern into the local swipe file and score its reusable winning signals.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Analyst notes. | |
| offer | Yes | Offer or CTA, such as free audit, demo, report, or consultation. | |
| format | No | Creative format, such as image, static image, carousel, or video. | |
| headline | Yes | Ad headline or largest visible hook. | |
| vertical | No | Vertical, such as plumbing, HVAC, reputation management, or local SEO. | |
| page_name | Yes | Advertiser/page name. | |
| source_url | No | Public ad or library URL used as evidence. | |
| active_days | No | Observed active duration if known. | |
| description | No | Ad description or link preview text. | |
| active_since | No | Observed start date in YYYY-MM-DD if known. | |
| primary_text | No | Primary ad body text copied from the public ad. | |
| visual_notes | Yes | Observed visual pattern, layout, scene, or creative notes. | |
| seen_repeated | No | Whether this hook/visual pattern appears repeatedly. | |
| variant_count | No | Number of similar variants observed. | |
| landing_page_url | No | Landing page URL if visible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates a write side effect ('local swipe file') and a scoring behavior, but it does not disclose whether recordings append, overwrite, or require an existing file, nor does it mention permissions or response details.
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 sentence with no filler. It front-loads the core action and resource, and every word contributes to the agent's understanding.
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 core action and target resource are clear, and the schema covers parameter details, making the tool callable. However, with no output schema and no annotations, the description does not mention what the tool returns, such as a confirmation, the saved record, or the winning-signal score.
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 the input schema already fully documents all 15 parameters. The tool description adds no parameter-specific meaning, which is acceptable given the rich schema, yielding the baseline score.
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 states a specific verb ('Record'), resource ('local swipe file'), and adds a secondary behavior ('score its reusable winning signals'), so the agent understands what the tool does. It does not explicitly contrast itself with the sibling score_ad_pattern, which also involves scoring, so it slightly misses full sibling differentiation.
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 phrase 'one observed ad pattern' implies this tool is for capturing a single observation, which provides some usage context. However, there is no guidance on when to prefer this over score_ad_pattern, or whether repeated recordings of the same pattern should be deduplicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a copied ad pattern for reusable winning signals without saving it.
| Name | Required | Description | Default |
|---|---|---|---|
| offer | Yes | Offer or CTA. | |
| format | No | Creative format. | |
| headline | Yes | Ad headline or visible hook. | |
| vertical | No | Ad vertical. | |
| active_days | No | Observed active duration if known. | |
| description | No | Description or link preview text. | |
| active_since | No | Observed start date in YYYY-MM-DD if known. | |
| primary_text | No | Primary ad body text. | |
| visual_notes | Yes | Visual pattern or scene notes. | |
| seen_repeated | No | Whether this hook/visual pattern appears repeatedly. | |
| variant_count | No | Number of similar variants observed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the key non-persistent behavior ('without saving it'), but it does not disclose what the scoring call returns, whether it makes external calls, or any other operation-level side effects.
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, front-loaded sentence with no wasted words. The critical 'without saving it' qualifier is placed prominently at the end of the main clause.
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 purpose and non-saving behavior are covered, and the schema handles parameter documentation. However, there is no output schema, and the description does not explain what the score result looks like or how to interpret it, leaving a meaningful gap for a scoring 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 description coverage is 100%, so the input schema already fully documents all 11 parameters. The description adds no parameter-specific meaning beyond framing them as aspects of a 'copied ad pattern', so the baseline of 3 is appropriate.
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 states a specific action ('Score'), a specific resource ('a copied ad pattern'), and the intent ('for reusable winning signals'). It also distinguishes itself from save-oriented tools with 'without saving it'.
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 makes clear this is for scoring an ad pattern rather than persisting it, which differentiates it from record_ad_swipe and list_ad_swipes. However, it does not explicitly name alternatives or state when-not-to-use it beyond the no-saving qualifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize top stored swipe patterns and recommend ServiceHawk remix angles.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Number of top swipes to include. | |
| min_score | No | Minimum score to include. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It implies a read-only analytical operation, but it never explicitly says whether it mutates data, what side effects occur, or how it accesses stored patterns. This is a significant gap for an unannotated tool.
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, front-loaded sentence with no filler or redundancy. Every word earns its place, and the size is appropriate for a simple two-parameter tool.
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?
Without annotations or an output schema, and with overlapping sibling tools, the description is too thin. It does not clarify the expected return format, default behavior when parameters are omitted, or which sibling handles variant generation versus summarization. The agent can infer the domain but lacks important invocation 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 description coverage is 100%, and both top and min_score already have clear descriptions in the input schema. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Summarize') with a clear resource ('top stored swipe patterns') and names the expected outcome ('recommend ServiceHawk remix angles'). It is distinguishable from list_ad_swipes and score_ad_pattern, though it does not explicitly contrast with generate_servicehawk_variants.
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?
There is no guidance on when to use this tool versus its siblings, such as generate_servicehawk_variants or list_ad_swipes. It also does not state prerequisites like having stored patterns first, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0build_meta_ad_library_urlcapture_public_ad_pagegenerate_servicehawk_variantslist_ad_swipesrecord_ad_swipescore_ad_patternsummarize_winning_patternsScored across 7 tools
Each tool targets a distinct step in the ad research workflow: generating variants, building search URLs, capturing pages, scoring/recording patterns, listing, and summarizing. The only mild overlap is between generate_servicehawk_variants and summarize_winning_patterns, but their inputs and outputs are clearly different enough.
All tool names follow a predictable snake_case verb_noun pattern: generate_, build_, capture_, record_, score_, list_, summarize_. This makes the tool set easy to navigate and mentally model.
Seven tools is well-scoped for an ad intelligence server, covering generation, capture, evaluation, storage, retrieval, and synthesis without unnecessary duplication. Each tool earns its place in the workflow.
The core ad-research lifecycle is covered: capture, score, record, list, and summarize. The main gap is the lack of update/delete operations for stored swipes, but agents can still complete the primary workflow without them.
Search Meta, Google Ads, LinkedIn, and TikTok ad libraries plus creative analysis via MCP.
Run Meta ads from your AI assistant: briefings, drop diagnosis, winners, budgets, receipts.
Research any brand's ads, clone their proven winners, launch on Google and TikTok — from chat.
GrowthHackers copywriting prompts (Meta/Google Ads, email, VSL) as MCP tools — search & generate.
