Skip to main content
Glama
competlab

competlab-mcp-server

get_briefing

Read-only

Get the synthesized competitive briefing: what changed, what it means, and what actions to take. Returns analyzed intelligence with hub digest and deep-dive options.

Instructions

Get the project's Strategic Briefing — the synthesized, prioritized competitive read across all dimensions: what changed, what it means, and what to do about it. This is the ANALYZED, as-of intelligence output, NOT raw monitoring — for live per-dimension data use the get__dashboard tools (e.g. get_pricing_dashboard), and for the monitored-competitor roster use list_competitors. Defaults to the executive 'hub' section — a cheap digest (headline, top moves, and per-dimension verdicts that each name the deeper 'deep-' section to open next) that answers most questions in a single call; this is the intended hub→deep drill-down flow, so request additional 'sections' only when a question actually needs them. Always branch on meta.availability before reading: 'ready' (a finished briefing is returned), 'ready-refreshing' (a finished briefing is returned AND a newer edition is generating right now), 'preparing' (the first edition is still building, so item is null), 'none' (no briefing exists yet). Only the latest FINISHED edition is ever returned; briefings regenerate automatically per project roughly every 30 days. meta, coverage, and dimensionHealth are returned regardless of which sections you request — read 'coverage' (methodology + honest-degradation caveats) before quoting any number, and check 'dimensionHealth' to see which deep- analyses this edition actually contains (a skipped dimension reads as 'absent', never as an empty finding). A missing/inaccessible project returns 404 project_not_found; the briefing lifecycle itself never 404s. Read-only. Returns a JSON briefing envelope { item (nullable), meta: { runId, briefingDate, availability }, coverage (nullable), dimensionHealth }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sectionsNoWhich briefing sections to return. Default ['hub'] — the executive digest that orients you and names the deeper sections by their verdicts; this alone answers most questions in one cheap call. Add sections only when the question needs them: 'actions' (the prioritized to-do list), 'competitors' (the rival-by-rival read), any 'deep-<dimension>' for a full dimension dive (13 available, e.g. 'deep-pricing', 'deep-ai-visibility' — the hub's verdicts tell you which one to open, so you needn't guess), or 'all' for the entire briefing (large — full-read/export only).
projectIdYesProject ID (from list_projects)
includeChartsNoDefault false — sections return prose plus a compact data-summary of each chart. Set true to include full chart series (time-series points, bar values); larger payload — use only when you need the underlying numbers, e.g. to reason over a trend.
Behavior5/5

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

The description discloses key behaviors beyond annotations: it is read-only (consistent with readOnlyHint), explains the availability states (ready, ready-refreshing, preparing, none), mentions regeneration every 30 days, describes the envelope structure, and notes 404 behavior for missing projects. No contradiction with annotations.

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?

The description is lengthy but well-structured, front-loading the core purpose and then detailing usage guidance and behavioral notes. Every sentence adds value, though some parts could be slightly more concise. Overall it is efficiently organized for its complexity.

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?

Given the absence of an output schema, the description thoroughly explains return values (meta, coverage, dimensionHealth, item) and the JSON envelope. It covers the lifecycle, availability, and caveats (e.g., coverage methodology, dimensionHealth absent). Completeness is high.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant meaning for all parameters. For 'sections', it explains the default ['hub'], the hub→deep flow, and when to add other sections. For 'includeCharts', it clarifies default false and when to set true. For 'projectId', it references list_projects. This goes beyond schema.

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?

The description clearly states the tool's purpose: retrieving the synthesized Strategic Briefing. It specifically contrasts with raw monitoring tools and the competitor roster tool, distinguishing it from siblings. The verb 'Get' plus resource 'project's Strategic Briefing' is specific.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use and when-not-to-use guidance, including alternatives like get_<dimension>_dashboard and list_competitors. It explains the hub→deep drill-down flow, recommends defaulting to 'hub' and adding sections only as needed, and advises branching on meta.availability. This is comprehensive.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/competlab/competlab-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server