Skip to main content
Glama

Content Pipeline Agent by Nova (CIVAI)

publish_content

Publish drafts to the product's configured publish destination(s) (webhook and/or a connected X account).

Input Schema

NameRequiredDescriptionDefault
auto_indexNo
product_idYesThe content product id (from list_products on Product Admin).
article_idsNo
public_urlsNoDeprecated manual id->url map, only needed if no webhook destination is configured.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources