Skip to main content
Glama
competlab

competlab-mcp-server

by competlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_ai_sources_history

Read-only

Retrieve paginated AI Sources check history for a project, showing per-engine figures for answers, pages read, and host coverage gaps. Pass a checkId to view full check details.

Instructions

Get paginated history of AI Sources checks. Uses checkId, not runId — the unit of this dimension is a check, one cycle of every buying question against every engine. Each row carries, per engine, the four measured figures for that check — answersReceived, answersNamingCustomer, pagesRead, and independentPagesNamingCustomer (a floor/ceiling range, over pagesRead) — and the funnel from core hosts to hosts the customer is genuinely missing from. Nothing is summed across engines: quote each engine's figures with their own universe, and never add the engines' page counts together. An engine absent from a row was not asked on that check or produced nothing usable on it — absent means not measured, never zero. Only published checks are listed: an abandoned check (no engine produced a usable answer, or the page stage could not be closed) never publishes and is not here. Pass a row's checkId to get_ai_sources_check_detail for its full summary. Check pagination.hasMore for more pages, and watch truncated: when true the page hit a size cap and whole rows were dropped from the end, and hasMore does not account for them — lower limit rather than paging forward.Counts are counts, never rates: report figures as n of N answers and never as a percentage or a share — the question set is small by design, and a share computed from it is false precision.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed, default: 1)
limitNoItems per page (default: 20, max: 100)
projectIdYesProject ID (from list_projects)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv4.0.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / page / maximum
      Added value: +9007199254740991
  2. Addedv3.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only supply readOnlyHint and openWorldHint, and the description goes far beyond them: it discloses the checkId-vs-runId identifier model, the truncated size-cap behavior (whole rows dropped, hasMore does not account for them), that absent engines mean 'not measured, never zero', that only published checks appear (abandoned checks never publish), and that figures are counts not rates. This is exactly the kind of non-obvious behavioral context an agent needs.

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 is free of filler, with each sentence carrying a usage or interpretation rule. It is dense and slightly repetitive (the per-engine universe point is made twice), and the run-on final block is heavier than necessary, but given the semantic complexity it stays close to appropriately sized.

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?

There is no output schema, yet the description fully specifies the return shape (each row carries per-engine measured figures and a funnel from core hosts to missing hosts) plus pagination and truncation semantics. For a history tool with no structured output definition, nothing an agent needs in order to interpret results is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning beyond the schema by tying the limit parameter to truncated behavior ('lower limit rather than paging forward') and explaining what pagination.hasMore does and does not reflect. It does not restate or clarify the projectId pattern, but the added limit/truncated interplay lifts it above baseline.

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 paginated history of AI Sources checks') and immediately nails the unit of the dimension ('the unit of this dimension is a check, one cycle of every buying question against every engine'). It distinguishes itself from get_ai_sources_check_detail, which it explicitly routes to, so an agent can tell the two apart without opening either 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?

Gives clear routing to a sibling ('Pass a row's checkId to get_ai_sources_check_detail for its full summary') and a concrete when-not for pagination ('lower limit rather than paging forward' when truncated). It does not, however, contrast itself against get_ai_sources_dashboard for current-state vs historical use, leaving one obvious alternative unaddressed.

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