Bulk keyword search volume, CPC, competition and difficulty, plus an optional Google Trends summary.
Scored across 5 tools
The four platform tools have clearly distinct targets: aborting a run, inspecting a run, reading dataset rows, and reading a single key-value record. The only mild overlap is that get-actor-run's 'nextStep' output can point toward the dataset/KV tools, but boundaries remain understandable. The domain tool is unambiguous on its own.
The four platform tools follow a clean verb_noun kebab-case pattern (abort-actor-run, get-actor-run, get-dataset-items, get-key-value-store-record). The domain tool 'meridianlabs--keyword-search-volume' breaks that convention entirely, using a vendor-namespaced double-hyphen resource name with no verb. Mixed conventions, though still readable.
Five tools is thin for the stated purpose: four are generic Apify plumbing and only one actually performs keyword search volume/CPC/trends work. The count is not wrong, but the surface feels like a fragment of a larger actor platform rather than a well-scoped keyword-research server.
The lifecycle is broken: there is abort-actor-run and get-actor-run but no generic start/run-actor tool, and no list-actors or list-datasets/list-key-value-stores discovery, so an agent cannot enumerate or kick off anything except the single hardcoded keyword actor. Core keyword-research workflows (e.g. related ideas per seed, trends lookups) are only reachable through one tool with no fallback or discovery path.
Abort an Actor run that is currently starting or running. For runs with status SUCCEEDED, FAILED, ABORTING, ABORTED, or TIMED-OUT, this call has no effect. The results will include the updated run details after the abort request.
USAGE:
Use when you need to stop a run that is taking too long or misconfigured.
USAGE EXAMPLES:
user_input: Abort run y2h7sK3Wc
user_input: Gracefully abort run y2h7sK3Wc
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the Actor run to abort. | |
| gracefully | No | If true, the Actor run will abort gracefully with a 30-second timeout. |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the no-effect-on-terminal-states rule, which is exactly what makes the idempotent hint meaningful, plus the fact that updated run details come back. It omits auth/permission requirements and any rate-limit behavior.
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 action and the state constraint, and every prose sentence earns its place. The 'USAGE EXAMPLES' block of raw user_input lines is mostly decorative and pads the definition slightly.
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 an output schema present, return values need not be spelled out, and the description still notes that updated run details are returned. For a two-parameter mutation with full annotation coverage, only auth requirements are unaddressed, which is a minor gap.
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 both parameters and the 30-second graceful-abort timeout are already documented in the schema. The description only gestures at 'gracefully' via an example, adding no syntax or semantic meaning beyond the schema. Baseline 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?
Specific verb (Abort) plus resource (Actor run) and a state qualifier ('currently starting or running'), which immediately distinguishes it from siblings like call-actor and get-actor-run. An agent can select it 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?
Explicit when-to-use ('stop a run that is taking too long or misconfigured') and an explicit no-op condition (terminal statuses such as SUCCEEDED, FAILED, ABORTED, TIMED-OUT). It does not name an alternative tool or describe prerequisites, so it falls 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.
Get detailed information about a specific Actor run.
Returns run result: status, storages (datasets/keyValueStores alias map), stats, summary, nextStep.
summary describes the past (e.g. "SUCCEEDED in 22s. 47 items; 3 fields available.").
nextStep prescribes one primary follow-up action with identifiers interpolated (e.g. "Use get-dataset-items with datasetId=...").
waitSecs (0–45, default 30) waits up to that many seconds for terminal status before returning.
USAGE:
Use to check the status of a run started by any Actor-running tool.
Pass waitSecs > 0 to block until terminal (or until the cap elapses).
USAGE EXAMPLES:
user_input: Show details of run y2h7sK3Wc
user_input: Wait for run y2h7sK3Wc to finish
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The ID of the Actor run. | |
| waitSecs | No | Maximum seconds to wait for the run to reach a terminal state (SUCCEEDED, FAILED, ABORTED, TIMED-OUT). 0 returns immediately with the current status. Cap: 45. Default: 30. |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, but the description adds real behavioral context beyond them: the summary vs. nextStep semantics, and that waitSecs blocks for up to 45s (default 30) before returning the current state. This is substantive added value, though it doesn't cover error/failure modes.
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 purpose, then segmented into Returns/USAGE/EXAMPLES blocks. Every line carries information, though the two usage examples are somewhat redundant with the USAGE prose, adding minor length.
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 an output schema present and 100% parameter coverage, the description need only orient the agent, which it does fully: purpose, when to use, wait semantics, and concrete invocation examples. Nothing needed to call it correctly is missing.
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 the baseline is 3, but the description goes further by framing waitSecs as a blocking/wait mechanism with its cap and default, and by describing what runId's run produces. Slight above-baseline value over the schema text.
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?
States a specific verb and resource ('Get detailed information about a specific Actor run') and enumerates the returned result fields (status, storages, stats, summary, nextStep). It does not explicitly distinguish itself from siblings like call-actor or abort-actor-run, so it falls just short of the 5 benchmark.
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 USAGE block names the condition ('check the status of a run started by any Actor-running tool') and explains when to pass waitSecs > 0 to block until terminal. It gives clear context but stops short of explicit exclusions or naming the sibling to use for other run operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get items (rows) from a dataset — the output/results produced by an Actor run. Returns the rows themselves, not dataset metadata, counts, or a schema. When the user provides a datasetId and asks to retrieve results, output, data, or rows, call this tool directly. Default limit is 20. Use clean=true to skip empty items and hidden fields.
USAGE:
Use when you need to read data from a dataset (all items or only selected fields).
USAGE EXAMPLES:
user_input: Retrieve results from dataset abc123
user_input: Get only metadata.url and title from dataset username~my-dataset
| Name | Required | Description | Default |
|---|---|---|---|
| desc | No | If true, results are returned in reverse order (newest to oldest). | |
| omit | No | Comma-separated list of fields to exclude from results. | |
| clean | No | If true, returns only non-empty items and skips hidden fields (starting with #). Shortcut for skipHidden=true and skipEmpty=true. | |
| limit | No | Maximum number of items to return. Default is 20. | |
| fields | No | Comma-separated list of fields to include in results. Fields in output are sorted as specified. Use dot notation for nested objects (e.g. "metadata.url"); the server auto-flattens parent prefixes. | |
| offset | No | Number of items to skip at the start. Default is 0. | |
| flatten | No | Comma-separated list of fields to flatten (e.g. flatten="metadata" turns {"metadata":{"url":"x"}} into {"metadata.url":"x"}). Normally derived automatically from dot-notation in `fields`; specify only as a diagnostic override. | |
| datasetId | Yes | Dataset ID, name (resolved against your own datasets), or full name as username~name. |
| Name | Required | Description |
|---|---|---|
| items | Yes | Dataset items |
| limit | Yes | Limit used for pagination |
| offset | Yes | Offset used for pagination |
| summary | Yes | Summary of the result |
| nextStep | Yes | One follow-up action with tool name |
| datasetId | Yes | Dataset ID |
| itemCount | Yes | Number of items returned |
| totalItemCount | Yes | Total items in dataset |
| apifyConsoleUrl | No | Personalized Apify Console link to the dataset; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the description adds value by disclosing the default limit of 20, what clean=true does, and that results are the raw rows. Return-shape details are largely deferred to the existing output schema, which is appropriate.
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 purpose and the anti-scope sentence, followed by short usage notes and examples. Slightly redundant in repeating the limit default and the clean flag across sections, but nothing wasteful enough to hurt.
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 read tool with full schema coverage and an output schema, the description supplies the purpose, trigger, and key defaults an agent needs. Pagination interaction (offset/limit) and flatten behavior are left to the schema, which is reasonable given the output schema exists.
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 schema already documents all eight parameters in depth. The description only restates the default limit and clean=true semantics, adding little beyond the structured fields; baseline 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?
States a specific verb and resource ('Get items (rows) from a dataset') and immediately delimits scope by saying it returns rows themselves, not metadata, counts, or schema. An agent can distinguish the intent 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?
Gives a clear trigger ('When the user provides a datasetId and asks to retrieve results, output, data, or rows, call this tool directly') plus a usage section and two concrete examples. It lacks explicit when-not guidance relative to any alternative, but the sibling list contains no competing dataset-read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the value stored under a specific key in a key-value store — a single record, not a listing of all keys. Requires the exact key name. The response preserves the original Content-Encoding; most clients handle decompression automatically.
USAGE:
Use when you need to retrieve a specific record (JSON, text, or binary) from a store.
USAGE EXAMPLES:
user_input: Get record INPUT from store abc123
user_input: Get record data.json from store username~my-store
| Name | Required | Description | Default |
|---|---|---|---|
| recordKey | Yes | Key of the record to retrieve. | |
| keyValueStoreId | Yes | Key-value store ID, name (resolved against your own key-value stores), or full name as username~name. |
| Name | Required | Description |
|---|---|---|
| key | Yes | Record key |
| value | Yes | The stored value (JSON, text, or binary) |
| summary | Yes | Summary of the result |
| contentType | No | MIME type of the stored value |
| keyValueStoreId | Yes | Key-value store ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered elsewhere. The description earns credit for adding behavioral context beyond that: the 'requires the exact key name' precondition and the note that the response preserves the original Content-Encoding, which most clients decompress automatically — a real return-value trait callers would otherwise trip over.
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 key facts — scope, exact-key requirement, encoding caveat — are front-loaded in three tight sentences. The subsequent USAGE and USAGE EXAMPLES blocks are somewhat redundant with the first paragraph, costing a little efficiency.
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?
A two-parameter read tool whose annotations, 100% schema coverage, and output schema already cover safety, inputs, and return shape. The description closes the remaining gap with the Content-Encoding behavior, which is exactly the non-obvious detail an agent needs.
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%, including the keyValueStoreId resolution rules (name vs. username~name) and minLength constraints in the schema itself. The description only reinforces that the key must be exact, adding little semantics beyond what the schema already documents, so the baseline 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?
States a specific verb and resource ('Get the value stored under a specific key in a key-value store') and preemptively scopes it against a listing tool: 'a single record, not a listing of all keys.' An agent can immediately tell this is a point lookup, not an enumeration.
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 says when to use it ('when you need to retrieve a specific record (JSON, text, or binary)') and includes two concrete usage examples showing the store identifier formats. However, it never states when NOT to use it or names an alternative/sibling for enumeration, so the guidance is implied rather than comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This tool calls the Actor "meridianlabs/keyword-search-volume" and retrieves its output results. Actor description: Keyword search volume API from $5 per 1,000: monthly volume, CPC, competition (Keyword Planner figures, no Ads account), difficulty, intent and 12-month history. Up to 1,000 keyword ideas per seed. Optional Google Trends summary per keyword. Failed lookups are free.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Search volume: one row per keyword you enter. Keyword ideas: each keyword you enter is a seed, and you get related keywords people search for. Each row has searchVolume (12-month average, rounded the way Google Ads rounds it, so it won't match the average of monthlySearches), monthlySearches (oldest first), cpc in USD, competition, keywordDifficulty (0-100) and searchIntent. Every idea costs the same as one keyword lookup ($0.003). Example values: "volume" | volume |
| country | No | Where the searches happen, as a two-letter code: US, GB (United Kingdom; "UK" is not accepted), DE, AU, IN and so on. Search volume and Google Trends both use this country. Example values: "US" | US |
| keywords | Yes | **REQUIRED** Search terms, one per line. Volume mode: each keyword is one lookup (paste hundreds at once). Ideas mode: up to 20 seed keywords per run. Duplicates are removed. Google Ads limits: up to 80 characters and 10 words per keyword. Example values: ["air fryer","standing desk","halloween costumes","pickleball paddle","crm software"] | |
| language | No | Language code or name, e.g. en, fr or French. Leave empty for the country's main language. Only matters in multi-language countries (e.g. Canada: en/fr; Switzerland: de/fr/it; United States: en/es). | |
| waitSecs | No | Max seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget. | |
| ideasSource | No | Ideas mode only. Suggestions are best for long-tail phrases around one product or topic; related keywords widen the topic. Example values: "suggestions" | suggestions |
| includeBing | No | Adds Bing (Microsoft Advertising) monthly searches, CPC, competition and 12 months of history next to the Google figures. Costs $0.25 per run for up to 1,000 keywords (one charge per 1,000), on top of the per-keyword price. United States, United Kingdom, Canada, Australia, Germany and France only, in English, French or German. Needs a paid Apify plan. Volume mode only. | |
| failOnErrors | No | Useful for schedules and monitoring: the run is marked failed if any keyword's volume or Trends lookup errors. Failed lookups are still not charged. | |
| includeTrends | No | Adds momentum (rising / falling / stable), change year on year, peak and seasonality with a plain-English summary. Costs an extra $0.003 per keyword; only charged when the Trends lookup answers. Volume mode only. Example values: true | |
| maxConcurrency | No | How many Google Trends lookups run at once. Search volumes are fetched in bulk regardless. Example values: 5 | |
| maxIdeasPerSeed | No | Ideas mode only. Each idea row costs $0.005, so 100 ideas cost $0.50 per seed. An idea that two seeds share is delivered and charged once. Example values: 100 | |
| minSearchVolume | No | Ideas mode only. Leave out ideas with fewer monthly searches than this (filtered before you are charged). | |
| trendsTimeRange | No | Seasonality and year-on-year change need weekly data over more than a year: keep Past 5 years unless you need recent momentum only. Example values: "past_5_years" | past_5_years |
| Name | Required | Description |
|---|---|---|
| tip | No | Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key |
| runId | Yes | Actor run ID |
| stats | No | Run statistics |
| status | Yes | Run status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED |
| actorId | Yes | Stable Apify Actor ID from the run record |
| summary | Yes | Past-tense summary of the run state |
| exitCode | No | Actor process exit code; populated for terminal states (especially FAILED) |
| nextStep | Yes | One primary follow-up action with identifiers interpolated |
| storages | Yes | Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry. |
| actorName | No | "username/actor-name" |
| startedAt | No | ISO timestamp when the run started |
| finishedAt | No | ISO timestamp when the run finished (terminal states only) |
| statusMessage | No | Pass-through from Apify run.statusMessage |
| apifyConsoleUrl | No | Personalized Apify Console link to the run; present only for Console sessions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety bar is nominally covered, but the description never explains what is actually being mutated (an Actor run is created and money is spent). It does add genuinely useful behavioral context that annotations cannot: pricing ($5 per 1,000, $0.003 per keyword), that failed lookups are free, and that Trends is only charged when it answers. Missing is any statement about run lifecycle or polling behavior.
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 compact sentences, front-loaded with what the tool does and then the Actor's capability/cost summary; no padding. The 'Actor description:' framing is slightly meta but efficient for conveying pricing and feature scope.
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 a full input schema, an output schema, and annotations present, the description covers purpose and cost adequately. It leaves gaps on run semantics (blocking vs. returning at the waitSecs cap and polling per nextStep), mode-specific constraints not in the top-level text, and routing relative to its four siblings, which matters for a 13-parameter paid 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 schema already documents all 13 parameters in detail, including enums, defaults and cost per idea. The description only weakly echoes a few of them ('Up to 1,000 keyword ideas per seed', 'Optional Google Trends summary'), which adds little beyond the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the specific resource (keyword search volume via the meridianlabs Actor) and enumerates concrete outputs: monthly volume, CPC, competition, difficulty, intent, 12-month history. The scope (volume vs. ideas mode, 1,000 ideas per seed, optional Trends) is clear enough to distinguish it from generic siblings, though it never explicitly contrasts itself with get-dataset-items or get-actor-run.
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?
No when-to-use or when-not guidance beyond an implicit 'use this to get keyword volume data'. It never tells the agent when to pick this over the sibling tools (e.g. use get-actor-run to poll a run started with waitSecs=0, or get-dataset-items to re-fetch results), nor does it state prerequisites such as needing an Apify plan for the Bing add-on.
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.
meridianlabs--keyword-search-volume4 fields changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / chargedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / errorAdded value: +{
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / keywordDifficulty / typePrevious value: -[
- "number",
- "null"
-]New value: +"number"Output schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / trends / properties / errorAdded value: +{
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "message": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}meridianlabs--keyword-search-volume1 field changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / keywordDifficulty / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]meridianlabs--keyword-search-volume1 field changedOutput schema / properties / storages / properties / datasets / properties / default / properties / itemsSchema / properties / trendsAdded value: +{
+ "properties": {
+ "averageValue": {
+ "type": "number"
+ },
+ "charged": {
+ "type": "boolean"
+ },
+ "currentValue": {
+ "type": "number"
+ },
+ "currentVsAveragePct": {
+ "type": "number"
+ },
+ "dataSource": {
+ "type": "string"
+ },
+ "momentum": {
+ "type": "string"
+ },
+ "peakDate": {
+ "type": "string"
+ },
+ "recentChangePct": {
+ "type": "number"
+ },
+ "recentWindow": {
+ "type": "string"
+ },
+ "seasonal": {
+ "type": "boolean"
+ },
+ "seasonalPeakMonth": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "seasonalWindow": {
+ "type": [
+ "null",
+ "string"
+ ]
+ },
+ "status": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "timeRange": {
+ "type": "string"
+ },
+ "yearOnYearChangePct": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+}Bulk Google keyword search volume, CPC, difficulty, intent and monthly history; 94 countries.
Bulk Google Trends: interest over time, regions, rising queries and plain-English trend summaries.
Google Trends in bulk: interest over time, by region, related and rising queries, trending now.
Google keyword search volume, CPC, difficulty, intent and keyword ideas. Runs on Apify.
Add one secure layer between your agents and this server.