Skip to main content
Glama
competlab

competlab-mcp-server

by competlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_content_run_detail

Read-only

Retrieve full competitor-by-competitor content data for any historical Content Intelligence run using its runId. Shows every tracked competitor and flags missing data with exact reasons.

Instructions

Get full competitor-by-competitor data for a specific historical Content Intelligence run. Use runId values from get_content_history. Same reading rule as get_content_dashboard. Every tracked competitor appears — rows we could not measure carry a contentDataAvailable reason with null counts rather than being omitted, so never report one as having no content. A row's contentDataAvailable.reason of 'no_sitemap_published' means no working sitemap was FOUND at the locations we know of — report it as 'no sitemap we can find', never as 'they publish no sitemap'. We re-discover sitemap locations periodically, so a competitor who moved theirs reads this way until we re-check. 'sitemap_fetch_failed' means our fetch failed and nothing was measured — derive no content verdict at all from that row. An empty programmaticExampleUrls is not a finding of its own — it restates that row's categorizedCounts.programmatic being 0, and never means 'they publish no templated pages'. A run that finished but produced no summary answers 404 run_not_summarized. That is different from run_not_found: the run exists, it simply has nothing to report. Say the run produced no data; do not describe it as missing, and do not fill it in with zeros.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runIdYesRun ID (from get_content_history)
projectIdYesProject ID (from list_projects)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.0.1
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond the readOnlyHint/openWorldHint annotations: it explains that every tracked competitor appears even when unmeasurable, defines the contentDataAvailable.reason values, prescribes how to phrase findings, and distinguishes 404 run_not_summarized from run_not_found. This is exactly the behavioral detail an agent needs to avoid misreporting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and the runId provenance before the interpretive rules, and every clause carries real guidance. It is dense and slightly repetitive around the sitemap/programmatic caveats, costing it the top mark.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and delivers: it describes row structure, null-count handling, reason enums, and the error semantics. An agent has everything needed to read and report the response correctly.

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 description coverage is 100%, so both runId and projectId are already documented at their source. The description reinforces where runId comes from but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get full competitor-by-competitor data for a specific historical Content Intelligence run') and distinguishes itself from siblings by pointing at get_content_history as the source of runId and at get_content_dashboard for reading rules. An agent can tell it apart from the history and dashboard tools without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent ('Use runId values from get_content_history') and binds the interpretation conventions to get_content_dashboard ('Same reading rule'). It gives clear context for invocation but stops short of stating when NOT to use it or why to pick this over the dashboard variant.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools