Skip to main content
Glama
competlab

competlab-mcp-server

by competlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_tech_trust_run_detail

Read-only

Retrieve full competitor-by-competitor data for a historical Tech & Trust run using its runId. Returns same summary shape as dashboard for detailed analysis.

Instructions

Full competitor-by-competitor data for one historical Tech & Trust run (runId from get_tech_trust_history), in the same summary shape as get_tech_trust_dashboard.

  • 404 run_not_summarized: the run finished with nothing to report. Say it produced no data; never call it missing and never fill in zeros. run_not_found is a different error.

  • A null security grade means their bot protection blocked the header check: a fact about their protection, not their security. Null robots.txt fields mean the file could not be retrieved.

  • aiAccess: read measurement.status first. could_not_measure: the verdicts are absent; say nothing about their AI access either way. measured_no_policy_found: a real 404, no robots.txt, which under the standard allows every crawler; reportable. In both, quote measurement.explanations rather than writing your own. In measurement.sourcesRead, not_attempted is a limit of our check, never a property of their site.

  • technologyStack.partialDetection (the same blocked headers): the technologies listed are real, but hosting and CDN went undetected and totalCount is a floor. Never report an absence from it and never compare its count with another competitor's.

  • robotsTxt.exists false with no availability marker is MEASURED: they publish no robots.txt, which allows all crawlers. The exception is this field only; a missing marker elsewhere does not make a value measured.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runIdYesRun ID (from get_tech_trust_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?

Annotations only cover readOnlyHint and openWorldHint; the description adds substantial beyond-schema behavior: the 404 run_not_summarized meaning vs run_not_found, that null security grades and robots.txt fields reflect blocked headers or fetch failure, and the aiAccess/technologyStack.partialDetection interpretation rules. For a read tool with no output schema, this is exactly the interpretive context that prevents misuse.

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 purpose is front-loaded in the first sentence, followed by tightly scoped bullets that each prevent a specific misinterpretation. It is longer than typical, but nearly every line earns its place; density is high rather than padded.

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 does so: it names the response shape, the error cases, and the null/partial-field semantics. Nothing an agent needs to call this tool correctly and report its output accurately is missing.

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% and both parameters are documented there, so the baseline is 3. The description reinforces that runId comes from get_tech_trust_history, which mildly adds sourcing context but does not go beyond the schema in syntax or format.

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+resource+scope: full competitor-by-competitor data for one historical Tech & Trust run. It also distinguishes itself from siblings by naming get_tech_trust_history as the runId source and get_tech_trust_dashboard as the shape it mirrors, so an agent can place it without opening a 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?

It clearly routes the agent to get_tech_trust_history to obtain the runId and identifies the dashboard tool whose shape it matches, giving strong context for when this tool is the right one. It stops short of an explicit when-not/alternative clause (e.g. when to prefer the dashboard over a single run), so it is clear context rather than full routing.

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