Provides tools for searching public Meta ads by query and market, and analyzing competitor ads, including creative mix, messaging, landing pages, and social metadata.
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., "@GenuDo Market Intelligence MCP What's the market evidence for AI receptionists in Saudi Arabia?"
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.
A shared, evidence-first market-intelligence server for deciding which AI employees GenuDo should build and package across Egypt, Saudi Arabia, and the UAE.
The repository runs as both:
a remote Streamable HTTP MCP at /mcp, designed for Apify Actor Standby;
a local stdio MCP for development and offline client testing.
flowchart LR
A["GitHub repository"] --> B["Apify Actor Standby"]
B --> C["Source adapters"]
C --> D["Meta Ads Actor"]
C -. future .-> E["Search, jobs, web, social, pricing, reviews"]
B --> F["Central research store"]
G["ChatGPT / Codex"] --> B
H["Claude"] --> B
I["Other MCP clients"] --> BThe MCP owns taxonomy, normalization, scoring, caching, research history, and evidence retrieval. Source Actors only collect data. This keeps the seven public tools stable as new sources are added.
Related MCP server: muze-mcp
Tool | Purpose | Starts a paid source run? |
| Search public Meta ads by query and market | Yes |
| Research one AI employee category across selected markets | Yes |
| Deep-dive one competitor's ads, messages, creative mix, landing pages, and social metadata | Yes |
| Compare stored category evidence and GenuDo process fit | No |
| Retrieve the ads and advertisers supporting a finding | No |
| Retrieve a saved research run and its methodology | No |
| Show connectivity, roadmap, taxonomy, storage, and recent runs | No |
Every live tool limits result counts. Deep competitor research is opt-in because advertiser and per-ad enrichment costs more.
The V1 opportunity-screening score is:
45% GenuDo process fit
30% commercial validation from visible Meta ad activity
25% competitive whitespaceMeta ads show commercial supply, advertiser breadth, localization, creative testing, and campaign persistence. They do not directly prove buyer demand, conversions, advertising spend, or ROAS. The output repeats that caveat. Search demand, jobs, reviews, customer research, and willingness-to-pay evidence belong in later source adapters before an investment decision.
The initial taxonomy covers GenuDo's current positions and adjacent expansion candidates:
Sales Agent
Customer Support
Customer Success
Appointment Setter
Receptionist
Lead Qualifier
Follow-up / Reactivation
SDR / BDR
Accounts Receivable / Collections
Order / Fulfillment
HR Onboarding / Employee Operations
Recruiting / Candidate Screening
Procurement / Supplier Operations
IT Service Desk
Claims / Case Processing
Each category includes English and Arabic market-discovery queries. Call list_sources for the canonical IDs and process-fit metadata.
Requirements: Node.js 20 or newer.
npm install
cp .env.example .env
npm testPut APIFY_TOKEN in your local .env file or secret manager. Never commit it or paste it into chat.
Start the HTTP server:
npm run devThe endpoints are:
GET http://localhost:3000/health
POST http://localhost:3000/mcpFor local stdio:
npm run build
npm run start:stdioVariable | Required | Default | Purpose |
| For local live research | injected by Apify when hosted | Calls source Actors and enables centralized Apify storage |
| No |
| Meta Ads source Actor |
| No |
| Named shared key-value store |
| Recommended outside Apify-managed auth | none | Optional application-level bearer authentication |
| Recommended when binding publicly | none | Comma-separated accepted HTTP hostnames |
| No |
| HTTP port |
| No |
| Bind address; Docker sets |
| Injected by Apify | typically | Apify container/Standby port; takes precedence over |
With APIFY_TOKEN, completed and failed runs are appended to a named Apify dataset while full run records and normalized evidence are saved in the named key-value store. This avoids a shared mutable index when Standby scales to multiple instances. Without the token, development uses .data/research-store.json and live source calls remain unavailable.
The repo includes .actor/actor.json and a multi-stage Docker image. It is configured for Actor Standby and exposes /mcp.
Recommended GitHub deployment:
Create a private Actor in Apify.
Set the source type to Git repository.
Enter this repository URL and use the main branch.
For a private GitHub repository, add the read-only deployment key supplied by Apify.
Build the Actor. Apify injects the authenticated run user's APIFY_TOKEN; do not duplicate an owner token in actor.json.
Open Standby, select the successful build, and copy the Standby hostname.
Set MCP_ALLOWED_HOSTS to localhost,127.0.0.1,YOUR-STANDBY-HOST (without https:// or a path), then restart the Standby run.
Confirm https://YOUR-STANDBY-HOST/health, then use https://YOUR-STANDBY-HOST/mcp as the MCP URL.
For development, the Apify CLI can push the same Actor definition:
apify login
apify pushActor Standby keeps the HTTP server warm, scales incoming requests, and bills while a warm run is active. Tune memory, concurrency, and idle timeout in the Standby settings after observing real usage.
Choose one deliberate access model:
Apify-managed private access: keep the Actor private and initially connect with an authenticated Apify token. For team use, create a dedicated GenuDo service user/account instead of distributing an owner-level token.
Application bearer access: make the endpoint reachable and set a strong MCP_BEARER_TOKEN in Apify secrets.
OAuth gateway: place a team identity gateway in front of the Actor later when per-user revocation and audit are required.
Do not distribute GenuDo's owner-level APIFY_TOKEN to team devices. That token belongs only in the hosted server environment.
Store the team bearer value in each device's environment, not in shell history:
export GENUDO_INTELLIGENCE_TOKEN="..."
codex mcp add genudo-intelligence \
--url https://YOUR-STANDBY-HOST/mcp \
--bearer-token-env-var GENUDO_INTELLIGENCE_TOKENOr use Settings → MCP servers → Add server → Streamable HTTP, then restart the client after saving.
For an unauthenticated development endpoint, omit --bearer-token-env-var.
claude mcp add --transport http --scope user \
genudo-intelligence https://YOUR-STANDBY-HOST/mcp \
--header "Authorization: Bearer ${GENUDO_INTELLIGENCE_TOKEN}"For team-shared Claude project configuration, prefer environment-variable expansion in .mcp.json so the secret itself is never committed:
{
"mcpServers": {
"genudo-intelligence": {
"type": "http",
"url": "https://YOUR-STANDBY-HOST/mcp",
"headers": {
"Authorization": "Bearer ${GENUDO_INTELLIGENCE_TOKEN}"
}
}
}
}Implement a new adapter under src/sources, return normalized evidence, and keep source-specific fields out of the stable tools. Planned adapters include:
search_google
search_jobs
research_linkedin
research_instagram
scrape_competitor_website
research_pricing
research_reviewsThe scoring layer should only label a metric “demand” after direct demand evidence is connected.
npm run check
npm test
docker build -t genudo-market-intelligence-mcp .Tests validate Meta URL generation, Arabic normalization, supply metrics, and the full seven-tool MCP manifest.
Secrets are read only from the runtime environment.
Health and source-status outputs never include token values.
Raw public-source records are stored for auditability but omitted from normal MCP responses.
Evidence retrieval is capped and filterable to avoid flooding model context.
Only public Meta Ad Library material should be collected, subject to applicable laws and platform terms.
Use a private repository and least-privilege deployment credentials until the service is ready for broader use.
Run a deep Meta Ads research pass for one competitor, including creative mix, CTAs, landing domains, localization, social metadata, and longest-running ads.
| Name | Required | Description | Default |
|---|---|---|---|
| markets | No | ||
| competitor | Yes | ||
| results_per_market | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate the safety profile (non-readonly, non-destructive, open-world, non-idempotent). The description adds research scope but does not disclose further behaviors like latency, data freshness, or side effects, so it provides only modest added 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 sentence, front-loaded with the action verb, and generally concise. The list of content areas is somewhat long but not wasteful, making it effectively sized.
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 tool appears complex with multiple parameters and no output schema. The description lists what the research includes, but omits parameter details and return structure, leaving partial gaps for an agent deciding whether to invoke it.
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 0%, and the description does not explain the meanings of 'markets' or 'results_per_market'. Only 'one competitor' indirectly refers to the competitor parameter, so the description fails to compensate for the lack of parameter documentation.
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 action ('Run') and resource ('deep Meta Ads research pass for one competitor'), and lists specific content areas (creative mix, CTAs, landing domains, localization, social metadata, longest-running ads), which distinguishes it from sibling tools like search_meta_ads.
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 use when deep, single-competitor research is needed, which provides clear context. However, it does not explicitly name alternative tools or include exclusion criteria, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two or more AI employee categories using stored evidence. Does not start paid source runs; missing research is reported explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| markets | No | ||
| category_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond this: it guarantees no paid source runs and explains that missing research will be reported explicitly. This enriches the agent's understanding without contradicting the 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?
The description consists of two crisp, front-loaded sentences. The first sentence states the core function, and the second provides a crucial behavioral boundary. Every word adds value with zero redundancy.
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 the tool's moderate complexity (2 parameters, one required), the description covers the main purpose, the no-cost guarantee, and the missing-data behavior. It lacks any description of the return value format, but the explicit statement about missing research reporting partially compensates. The rich annotations also reduce the overall burden.
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 0%, so the description must compensate for parameter explanation. It only hints at category_ids via 'two or more AI employee categories' but completely ignores the 'markets' parameter and does not explain its purpose, allowed values, or default behavior. The schema provides no description either, leaving the agent guessing.
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: 'Compare two or more AI employee categories using stored evidence.' It uses a specific verb (compare) and specific resource (AI employee categories). The second sentence differentiates it from tools that start paid research, distinguishing it from siblings like research_ai_employee_market.
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 provides clear usage context: it compares categories using stored evidence and explicitly states that it 'Does not start paid source runs,' indicating when not to use it. However, it does not explicitly name sibling alternative tools or provide a full when-to-use vs. when-not-to-use matrix.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized ads and advertisers from stored research, with optional run, market, category, and competitor filters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| run_id | No | ||
| markets | No | ||
| advertiser | No | ||
| active_only | No | ||
| category_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that data is 'normalized' and from 'stored research', but does not disclose return format, pagination behavior, or the effect of active_only. This is adequate but not rich.
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-structured sentence. It front-loads the main action and resource, then lists filters without unnecessary detail. No wasted words.
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 6 parameters, no output schema, and no required parameters, the description is too brief for fully correct invocation. It does not explain limit behavior, active_only semantics, the advertiser/competitor distinction, or the structure of the returned evidence. More context is needed.
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 0%, so the description must compensate. It mentions run, market, category, and 'competitor' filters, but omits limit and active_only. The term 'competitor' does not directly match the schema parameter 'advertiser', creating potential ambiguity for the agent.
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 the specific verb 'Retrieve' and clearly identifies the resource: 'normalized ads and advertisers from stored research'. It also mentions optional filters (run, market, category, competitor), which helps distinguish it from siblings like search_meta_ads (likely live search) and get_research_run (run metadata).
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 for retrieving stored research data with filters, but it does not explicitly state when to use this tool instead of alternatives or any exclusions. It provides no direct guidance on choosing between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the durable metadata, inputs, metrics, and summary for a previous research run.
| Name | Required | Description | Default |
|---|---|---|---|
| run_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds meaningful context by specifying 'durable' and listing the returned contents (metadata, inputs, metrics, summary), which gives the agent a clear idea of what to expect from the response. However, it does not mention error behavior (e.g., missing run_id) or response formatting, which would be additional value.
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 of 13 words, front-loaded with the verb 'Retrieve' and the resource. Every word adds specificity (durable, metadata, inputs, metrics, summary). There is no redundancy or filler, making it highly efficient.
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 retrieval tool with one parameter, no output schema, and rich annotations, the description is largely complete. It tells the agent exactly what data will be returned and that it pertains to a past run. The main missing piece is parameter semantics, which is covered separately, but overall the description combined with annotations gives a solid understanding of the tool's behavior.
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 schema description coverage at 0%, the description bears full responsibility for explaining the parameter. It does not explicitly mention 'run_id' or explain that it identifies the research run to retrieve. The phrase 'previous research run' implies it, but the tool name and description do not directly connect the single parameter to an identifier format or how to obtain it. This is a significant gap given only one parameter exists.
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 the specific verb 'Retrieve' and clearly identifies the resource as 'a previous research run', listing the exact contents (durable metadata, inputs, metrics, summary). This distinguishes it from siblings like get_market_evidence or list_sources, which serve different retrieval purposes.
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 provides no explicit guidance on when to use this tool vs alternatives. It does not mention get_market_evidence or other related tools, nor does it state prerequisites or situations where another tool would be more appropriate. The phrase 'previous research run' implies use after a run exists, but no comparative direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show connected and planned intelligence sources, centralized storage status, the AI employee taxonomy, and recent research runs. Never exposes secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds a valuable behavioral guarantee: 'Never exposes secrets.' This provides context beyond the structured annotations and reassures the agent about data sensitivity, though it doesn't mention return-format or size limits.
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 that lists all output categories and ends with a critical safety note. Every word earns its place; no redundancy or fluff.
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?
Despite lacking an output schema, the description enumerates the major content areas (sources, storage status, taxonomy, research runs), which sufficiently conveys what the agent can expect. It doesn't specify exact formats, but for a no-parameter listing tool, this coverage is strong enough. Missing a little detail on how 'recent' is defined, but acceptable.
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?
The tool has zero parameters, so the schema provides complete coverage at 100%. With no parameters, the baseline is 4 per the rubric; the description doesn't need to add parameter details, and it correctly focuses on what the tool returns.
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 ('Show') and enumerates exactly what the tool lists: connected and planned sources, storage status, AI employee taxonomy, and recent research runs. This clearly distinguishes it from the more focused sibling tools (search_meta_ads, analyze_competitor_ads, etc.) which target single operations.
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 this is the overview tool for seeing all sources and related metadata, but it does not explicitly state when to use it instead of a sibling or provide alternative suggestions. It lacks explicit when/when-not guidance, so it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Research one taxonomy category across EG/SA/UAE using its Arabic and English queries. Produces market metrics, evidence, and a clearly caveated opportunity-screening score.
| Name | Required | Description | Default |
|---|---|---|---|
| markets | No | ||
| languages | No | ||
| category_id | Yes | Category ID from list_sources, for example collections or hr_onboarding. | |
| results_per_query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, openWorldHint=true) already communicate the non-read-only, open-world nature. The description adds behavioral detail about using both Arabic and English queries and producing a 'clearly caveated' score, but does not disclose runtime, dependencies beyond schema, or potential side effects beyond what annotations imply.
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?
Two sentences, front-loaded with scope and outputs, no redundant wording. Every sentence earns its place, making it highly efficient and easy to scan.
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 description covers core inputs and outputs at a high level, which is adequate for a research tool with annotations present. However, it omits results_per_query semantics and does not detail what 'market metrics' or 'evidence' include, leaving some ambiguity without an output schema.
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 only 25% (only category_id has a description), so the description compensates by explaining taxonomy category, markets (EG/SA/UAE), and languages (Arabic/English). However, results_per_query is not addressed in the description. This provides meaningful added meaning for three of four parameters.
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 researches one taxonomy category across EG/SA/UAE using Arabic and English queries, and specifies outputs (market metrics, evidence, opportunity-screening score). This verb+resource+scope structure distinguishes it from sibling tools like compare_ai_employee_opportunities and get_market_evidence.
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 a single-category, multi-market research use case but does not explicitly state when to prefer it over alternatives (e.g., compare_ai_employee_opportunities) or when not to use it. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search public Meta Ad Library data by keywords and market. This runs a paid Apify source Actor and stores normalized evidence for reuse.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Also fetch advertiser/social details. Slower and more expensive. | |
| markets | No | ||
| queries | Yes | English and/or Arabic keyword queries. | |
| active_only | No | ||
| results_per_query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint false, but the description adds meaningful context: it discloses the paid nature of the underlying Actor and the side effect of storing normalized evidence. This goes beyond annotations, though it does not cover rate limits or authentication, which are less critical given the external API context.
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 only two sentences, front-loaded with the core purpose and followed by a key operational detail. Every word contributes, with no redundancy or filler.
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 does not clarify what the tool returns, which is a notable gap. It does provide context about paid execution and evidence storage, which helps, but it lacks guidance on output shape and relationship to sibling tools, making it only moderately 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 coverage is only 40%, and the description does little to compensate. It mentions 'by keywords and market,' which aligns with the queries and markets parameters, but it does not explain active_only, results_per_query, or the significance of deep beyond the schema's own description. The description adds marginal value over the 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: 'Search public Meta Ad Library data by keywords and market.' This is a specific verb+resource+scope and distinguishes it from siblings like analyze_competitor_ads and get_market_evidence, which focus on analysis or retrieval of stored evidence.
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 by mentioning 'runs a paid Apify source Actor and stores normalized evidence for reuse,' hinting that this fetches fresh data for later retrieval. However, it does not explicitly state when to use this tool versus alternatives like get_market_evidence or analyze_competitor_ads, leaving the usage context implicit.
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.0analyze_competitor_adscompare_ai_employee_opportunitiesget_market_evidenceget_research_runlist_sourcesresearch_ai_employee_marketsearch_meta_adsScored across 7 tools
Each tool targets a distinct part of the research workflow: keyword search, category research, competitor deep-dive, comparison, evidence retrieval, run metadata, and source listing. Clear descriptions and different action verbs prevent selection ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., search_meta_ads, compare_ai_employee_opportunities, list_sources). No mixed conventions or vague verbs; the naming is predictable and readable.
With 7 tools, the server is well-scoped for market intelligence research. Each tool serves a clear purpose in the workflow—from raw search to analysis and retrieval—without redundancy or missing essentials.
The toolset covers the full research lifecycle: searching, researching, analyzing, comparing, and retrieving evidence/run metadata. Minor gaps like missing update/delete operations for runs or sources are not critical for a research-focused server.
Competitive ad intelligence for AI agents: portfolios, ad/content search, analytics, discovery.
Create, launch & analyze ad campaigns, spy on competitors - Google, Meta, TikTok, LinkedIn & more.
Search Meta, Google Ads, LinkedIn, and TikTok ad libraries plus creative analysis via MCP.
MCP for 8,700+ current AI jobs. 13 tools: search, match, salaries, companies, commerce quotes.
