I run the Content Pipeline for your Nova products, scan trends, expand seeds into opportunities, ge…
Scored across 11 tools
Each tool maps to a distinct pipeline stage or resource: seeds, opportunities, drafts, jobs, publishing, and indexing are clearly separated. The only close pair, get_job_status vs list_jobs, is still distinguishable as specific-job lookup versus recent-job listing.
All tool names use snake_case with a verb-first pattern such as list_seeds, expand_seeds, generate_content, publish_content, and index_content. The convention is consistent throughout, including get_job_status and trigger_scan.
The 11 tools are well-scoped for a content pipeline covering scan, expand, generate, publish, index, and status monitoring. Each tool appears to earn its place without excessive granularity.
The core pipeline lifecycle is covered from seed scanning through publishing and indexing, with listing and job status support. Minor gaps exist around editing or inspecting individual draft content and cleaning up drafts, but agents can likely work around them via list_drafts and regeneration.
Delete staged opportunities that shouldn't be generated.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The content product id (from list_products on Product Admin). | |
| opportunity_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Delete' implies a destructive mutation, but the description does not state whether deletion is irreversible, what permissions are required, or what happens to related generated content. These are significant omissions for a destructive 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 wasted words. It is concise but perhaps too terse given the destructive nature of the operation.
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 destructive mutation with no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not explain prerequisites, reversibility, side effects, or what 'staged' means in this 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 only 50%: product_id is documented in the schema, but opportunity_ids has no description. The tool description adds no parameter details at all, so it fails to compensate for the undocumented array parameter.
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 ('Delete') and resource ('staged opportunities') with a qualifying purpose ('that shouldn't be generated'). It is clear enough to distinguish from most siblings, though it does not explicitly contrast with list_opportunities or other opportunity-related tools.
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 'staged opportunities that shouldn't be generated' implies a condition for use, but there is no explicit when-to-use, when-not-to-use, or alternative guidance. An agent can infer this is for cleanup of unwanted staged items, but the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Expand selected seeds into content opportunities (level 2 of the pipeline).
| Name | Required | Description | Default |
|---|---|---|---|
| seed_ids | No | ||
| product_id | Yes | The content product id (from list_products on Product Admin). | |
| country_code | No | ||
| limit_per_seed | No | ||
| lookback_hours | No |
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 never says whether this creates opportunities (write), whether it is asynchronous (the existence of get_job_status suggests it may be), what permissions are required, or whether the expansion is limited/de-duplicated against existing opportunities.
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 tight sentence with the core action front-loaded and zero waste. However, its brevity is under-specification rather than efficiency, given five parameters with thin documentation.
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?
Five parameters, 20% schema coverage, no annotations, and no output schema; the description would need to explain the optional-seed behavior, what the four tuning parameters do, and whether the call is sync or job-based. None of that is present.
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 20% — only product_id is documented. The description says 'selected seeds' but seed_ids is optional, so the critical behavior when it is omitted is undefined, and limit_per_seed, lookback_hours, and country_code are entirely undocumented in both schema and description.
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+resource pair: expand seeds into content opportunities, and places it as 'level 2 of the pipeline', which separates it from list_seeds and generate_content. It stops short of naming the sibling it should be used after, but an agent can tell what it does.
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 'level 2 of the pipeline' hint implies this runs after seed selection and before content generation, giving implied ordering. There is no explicit when-to-use/when-not guidance, no mention of how to obtain seed_ids, and no alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate draft articles for selected opportunities (seo_intent or reward_intent, per the product's pipeline_type).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The content product id (from list_products on Product Admin). | |
| opportunity_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but doesn't disclose critical traits: whether generation is synchronous or returns a job id (siblings like get_job_status and trigger_scan suggest async workflows), what permissions are required, whether existing drafts are overwritten, or whether it incurs cost/rate limits. It only clarifies that outputs are draft articles, leaving the mutation/async profile undisclosed.
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, front-loaded sentence that identifies the action and resource without waste. The parenthetical about pipeline_type is slightly cryptic but adds relevant domain context rather than padding.
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 two-required-parameter generation tool with no annotations and no output schema, the description should explain what gets returned (job id vs. draft ids) and the async semantics implied by sibling job-status tools. It also leaves opportunity_ids undocumented, so an agent lacks enough context to call it correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: product_id is documented in the schema, but opportunity_ids has no schema description. The description partially compensates by framing these as 'selected opportunities,' implying an array of opportunity ids from a prior listing. It also introduces pipeline_type context (seo_intent or reward_intent) that explains how the product determines draft type, but doesn't map this clearly to any parameter.
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: 'Generate draft articles for selected opportunities.' This clearly distinguishes it from siblings like list_drafts and publish_content. However, it doesn't explicitly name which sibling to use for follow-up steps (e.g., get_job_status), leaving some differentiation implicit.
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 context—generating drafts for opportunities selected from a prior listing step—but offers no explicit when-to-use/when-not guidance or alternatives. An agent must infer that this is a write operation to be used after list_opportunities and before publish_content, without being told so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status/result of a background pipeline job (scan, expand, generate, publish, index all run as jobs).
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
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 does disclose the meaningful behavioral fact that several operations run asynchronously as jobs and that this returns both status and result, but it omits whether the result is only present on completion, whether the record is retained after completion, and how unknown/expired job_ids behave.
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 front-loaded sentence with a parenthetical that earns its place by mapping job types to the sibling tools. No filler or repetition of the tool name.
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 one-parameter read tool with no annotations and no output schema, the description should explain the shape of the status/result (e.g. state values, when a result is available). It conveys the concept of async job polling but leaves the return contract, which has no schema to fall back on, undefined.
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 single parameter job_id has 0% schema description coverage, so the description must compensate. It only implies where job_id comes from (a job) and gives no format, source, or error semantics, leaving the agent to guess that it should be taken from a trigger_scan/expand_seeds/generate_content response.
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+resource ("Check the status/result of a background pipeline job") with a parenthetical that enumerates the job-producing operations (scan, expand, generate, publish, index), which separates it from the siblings that trigger those jobs. It stops short of explicitly contrasting with list_jobs, which is the nearest ambiguous neighbor.
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 mention of background jobs implies this is a polling call made after a job is triggered, but the description never states when to use it versus list_jobs, nor that a job_id must first be obtained from a trigger_* call. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit published URLs to Google Search Console for indexing.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| product_id | Yes | The content product id (from list_products on Product Admin). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It is an external side-effecting action against Google's API with known quotas and (typically) asynchronous processing, yet the description says nothing about rate limits, partial failure, idempotency, or whether a job/status handle is returned.
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 front-loaded sentence with no redundancy — the core action is stated immediately. It is terse to the point of under-specification, but that is a completeness issue rather than wasted text.
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 mutation tool with no annotations, no output schema, and an undocumented required array parameter, the description is not complete enough. It omits return behavior (sync success vs job id), quota/rate constraints, and the failure mode for unpublished or invalid URLs.
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 50%: product_id is documented ('from list_products on Product Admin') but the urls array has no description of format (absolute vs relative, whether they must belong to the product's property) or cardinality limits. The description's 'published URLs' is the only hint and does not compensate for the gap on the required urls parameter.
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 ('Submit') and resource ('published URLs to Google Search Console for indexing'), which is far more informative than the bare name index_content. It does not need to differentiate from siblings since none of the listed tools (publish_content, trigger_scan, etc.) overlap directly, but it stops short of noting scope limits such as the GSC property or URL count.
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 'published URLs' implies a precondition (content must already be published) and gestures at the publish_content sibling, but no explicit when-to-use or when-not-to-use guidance is given. Nothing tells the agent whether to call this after publish_content, whether repeated submissions are safe, or what alternative exists for unpublished content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List staged article drafts for a product (unpublished by default).
| Name | Required | Description | Default |
|---|---|---|---|
| published | No | ||
| product_id | Yes | The content product id (from list_products on Product Admin). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; 'List' plus '(unpublished by default)' does establish that this is read-only and that the default scope excludes published items, which is real behavioral context. However, it says nothing about pagination, result limits, or permissions, which matters for a listing tool with no 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?
A single sentence with zero filler, and the scoping plus default behavior are front-loaded. Nothing is redundant with the name or title.
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 two-parameter read tool with no output schema and no annotations, the description covers purpose and the default filter but omits return shape and whether results are paginated or bounded. Adequate but leaves gaps an agent may care about when drafting a call plan.
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 50%: product_id is documented in the schema, while the published boolean has no schema description at all. The description fills exactly that gap by declaring the default filtering behavior, so an agent knows that omitted published means drafts-only.
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 (List) and resource (staged article drafts) scoped to a product, which is far more informative than the bare tool name. It doesn't explicitly name a sibling or carve out a boundary against publish_content or list_products, so it stops short of a 5.
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 'unpublished by default' implies the tool's role in a draft-review workflow, but there is no explicit statement of when to use this versus related tools like publish_content or list_products. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent pipeline jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| status | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read, but it doesn't state ordering (newest first?), what 'recent' means, whether results are paginated, or how status filtering behaves.
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 front-loaded sentence with no filler, so it is concise. However, the brevity comes at the cost of under-specification rather than being tight-but-complete.
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 annotations, no output schema, and 0% parameter documentation, the description is the only source of behavioral detail and it supplies almost none. An agent would have to guess at ordering, default limits, and allowed status values.
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 both 'limit' and 'status' are undocumented anywhere. The word 'recent' hints at default ordering/limit behavior, but the description never explains what 'limit' counts or what values 'status' accepts.
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 ('List') and resource ('pipeline jobs') with a scope qualifier ('recent'), so the agent knows the operation. It does not differentiate from the sibling get_job_status, which also concerns jobs, leaving ambiguity about which to pick.
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 guidance on when to use this versus get_job_status or any other sibling. No mention of pagination, filtering intent, or prerequisites for invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List staged content opportunities for a product.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| product_id | Yes | The content product id (from list_products on Product Admin). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only list but says nothing about pagination, ordering, default filtering, whether the status filter is optional, or what gets returned.
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 front-loaded sentence with no wasted words. Brevity is appropriate to the tool's small surface, though it edges into under-specification rather than tight 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 2-parameter list tool with no annotations and no output schema, the description leaves the status parameter, return shape, and pagination behavior entirely undocumented. An agent cannot reliably call it with a status filter based on this text.
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 50%: product_id is documented in the schema (with a pointer to list_products), but status has no description and no enum. The description does not compensate at all — it never mentions the status filter or its accepted values.
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 (List) and resource (staged content opportunities) scoped to a product, which is distinguishable from siblings like list_drafts, list_seeds, and list_jobs. It does not explicitly contrast with those siblings, but the resource noun is specific enough for an agent to pick 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?
No guidance on when to use this versus list_drafts, list_seeds, or list_jobs, and no prerequisites or exclusions. The word 'staged' hints at a lifecycle state but the agent is left to infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recently scanned seeds for a product.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The content product id (from list_products on Product Admin). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It implies a recency-ordered, bounded result set ("most recently scanned") but says nothing about ordering direction, result limits, pagination, whether seeds from older scans are excluded, or what happens when no scan has run — meaningful gaps for a list tool with zero annotation coverage.
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?
One sentence with the verb and scope front-loaded and no filler. Every word earns its place; the problem is under-specification, not verbosity.
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 one-parameter read tool with full schema coverage this is minimally adequate, but with no output schema the description should say what a "seed" record contains and what "most recently" means quantitatively. The domain term "seed" is also left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, which already explains product_id and even how to obtain it via list_products. The description adds nothing beyond what the schema states, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
A specific verb and resource ("List ... seeds") plus a scope ("for a product") and an implicit ordering ("most recently scanned"). It reads clearly, but it never differentiates itself from the related siblings expand_seeds or trigger_scan, so an agent must infer where listing ends and expanding begins.
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?
"Most recently scanned" hints at the situation (after a scan has run) but gives no explicit when-to-use, no exclusions, and does not name trigger_scan or expand_seeds as alternatives. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish drafts to the product's configured publish destination(s) (webhook and/or a connected X account).
| Name | Required | Description | Default |
|---|---|---|---|
| auto_index | No | ||
| product_id | Yes | The content product id (from list_products on Product Admin). | |
| article_ids | No | ||
| public_urls | No | Deprecated manual id->url map, only needed if no webhook destination is configured. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that publishing targets a webhook and/or connected X account, but omits critical mutation details: whether publishing is irreversible, what happens on partial failure, whether authentication is required beyond product config, and whether the call is synchronous or returns a job.
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 front-loaded sentence with zero waste. The destination scope is stated immediately after the action, making the definition 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?
This is a mutation tool with external side effects, no annotations, no output schema, a nested deprecated object parameter, and only 50% schema description coverage. The one-sentence description is not complete enough to tell an agent how publishing behaves or what to expect after calling 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 coverage is 50%, and the description adds context explaining that publishing uses the product's configured destinations, which clarifies the deprecated public_urls parameter. However, it says nothing about article_ids or auto_index, leaving half the parameters undocumented in both schema and description.
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: publish drafts to the product's configured destination(s), and names webhook and/or connected X account as the destinations. This is clear enough that an agent can distinguish it from generate_content or index_content, though it doesn't explicitly call out sibling differences.
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 (drafts must exist and a product must be configured) but gives no explicit when-to-use guidance, prerequisites, or alternatives. It doesn't explain when to choose publish_content versus index_content or get_job_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan trends for a product and stage candidate seeds (level 1 of the pipeline).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| product_id | Yes | The content product id (from list_products on Product Admin). | |
| country_code | No | ||
| lookback_hours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool stages candidate seeds, implying a write side effect, but does not explain whether it starts an async job, what permissions are needed, whether staging is destructive, or what happens to existing seeds.
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 definition is a single front-loaded sentence with no wasted wording. It is efficient, though its brevity leaves important details unstated for a pipeline trigger.
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 four-parameter pipeline trigger with no annotations, no output schema, and incomplete parameter descriptions, this one-sentence description is inadequate. It does not fill the gaps around parameter meanings, async behavior, output, or usage relative to sibling tools.
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 only 25%, with only product_id documented. The description does not explain limit, country_code, or lookback_hours, so it fails to compensate for the low schema coverage and leaves most parameters semantically opaque.
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 and resource: it scans trends for a product and stages candidate seeds. The parenthetical 'level 1 of the pipeline' implies a distinction from later-stage tools such as expand_seeds, but it does not explicitly name or contrast with any sibling.
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 'level 1 of the pipeline' implies this is the first step before downstream stages, but it does not explicitly say when to use this tool versus alternatives like expand_seeds or list_seeds. Usage is only indirectly inferable from pipeline ordering.
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.
delete_opportunitiesexpand_seedsgenerate_contentget_job_statusindex_contentlist_draftslist_jobslist_opportunitieslist_seedspublish_contenttrigger_scanEditorial tools for LinkedIn. Capture ideas, draft posts, build narrative arcs, manage a schedule.
Founder LinkedIn and Reddit content and founder-led AI visibility services, resources and booking.
Plan and run brand content on X, LinkedIn, TikTok, YouTube Shorts, Instagram and Hashnode.
I manage your Support Agent CRM, pipeline analytics, follow-ups, Leads Discovery, and workspace out…
Add one secure layer between your agents and this server.
