Meertrack MCP

Official

by meertrack

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Get competitor

get_competitor

Read-only

Retrieve a single competitor's full profile with the most recent items from each tracked section, such as blog posts, ads, pricing, job listings, and reviews. Use the competitor id from list_competitors to view overview snapshots.

Instructions

Wraps GET /competitors/{id}. Returns a single competitor's full profile plus the most recent items from each tracked section. Sections returned (with per-section item caps):

blog-posts (up to 3), press-posts (3), case-studies (3)
job-listings (5), ads (5), pricing (1), messaging (5)
metrics-claimed (5), logos (5)
linkedin-posts (3), x-posts (3), reviews (3), youtube-videos (3), events (3)
leadership (5), web-technologies (1)

leadership items are leadership change events, not the current team; the people found on the first scan have initial_run: true (their headline may read "New …" but they are not new appointments). The web-technologies item is the latest complete homepage scan, even one that changed nothing (then added/updated/removed are all empty); its technologies list is the current stack. More sections may appear over time as extra keys under items.

These are overview caps — for the full list in any section call list_activities with competitor_ids=[id] sections=['<slug>'] and NO from/to, which returns the complete all-time roster (paginated).

Chaining: Use after list_competitors — pass the id from a result row. For an activity timeline across sections, call list_activities with competitor_ids=[id] instead. Errors: not_found (no such competitor in this workspace), competitor_inactive (archived — reactivate in dashboard), forbidden_competitor (different workspace), unauthorized, rate_limited.

Input Schema

Name	Required	Description	Default
`id`	Yes	Competitor id from `list_competitors`.

Output Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed15 schema fields changedv2.3.0Oct 26, 2026

changedOutput schema / properties / data / properties / items / additionalProperties

Previous value: -falseNew value: +{
+  "items": {
+    "additionalProperties": {},
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / data / properties / items / properties / ads / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / blog-posts / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / events / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / job-listings / items / additionalProperties
```
Previous value: -falseNew value: +true
```

addedOutput schema / properties / data / properties / items / properties / leadership

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "competitor": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/competitor"
+      },
+      "discovered_at": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/discovered_at"
+      },
+      "event": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "headline": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "initial_run": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/initial_run"
+      },
+      "linkedin_url": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "new_company_name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "person_name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "previous_person_name": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "previous_title": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "summary": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "tags": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/tags"
+      },
+      "title": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "url": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "competitor",
+      "tags",
+      "discovered_at"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / data / properties / items / properties / linkedin-posts / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / logos / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / messaging / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / metrics-claimed / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / pricing / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / reviews / items / additionalProperties
```
Previous value: -falseNew value: +true
```

addedOutput schema / properties / data / properties / items / properties / web-technologies

Added value: +{
+  "items": {
+    "additionalProperties": true,
+    "properties": {
+      "added": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "competitor": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/competitor"
+      },
+      "discovered_at": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/discovered_at"
+      },
+      "initial_run": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/initial_run"
+      },
+      "removed": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "tags": {
+        "$ref": "#/properties/data/properties/items/properties/blog-posts/items/properties/tags"
+      },
+      "technologies": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "updated": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "url": {
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "competitor",
+      "tags",
+      "discovered_at"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / properties / data / properties / items / properties / x-posts / items / additionalProperties
```
Previous value: -falseNew value: +true
```
changedOutput schema / properties / data / properties / items / properties / youtube-videos / items / additionalProperties
```
Previous value: -falseNew value: +true
```

First observedv2.1.0Jul 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnlyHint, yet the description discloses non-obvious semantics: per-section item caps, that `leadership` items are change events and first-scan people carry `initial_run: true`, and that a `web-technologies` item can be an unchanged scan with empty added/updated/removed. It also enumerates concrete error codes (`not_found`, `competitor_inactive`, `forbidden_competitor`, `unauthorized`, `rate_limited`) with their meanings.

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-loaded with the core operation, then organized into scannable blocks (section caps, caveats, chaining, errors) that each serve a purpose. The long section/cap enumeration is the closest thing to padding, since an output schema exists and the caps could arguably live there, but it still informs interpretation of the response.

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?

For a single-parameter read tool with an output schema, the description covers everything left open: response shape, per-section truncation limits, ambiguous field semantics, failure modes, and routing to siblings. Nothing an agent needs to invoke or interpret it 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 coverage is 100% and the single `id` parameter is already documented as 'Competitor id from `list_competitors`', so the description's chaining line largely restates the schema. It adds no format, validation, or edge-case detail beyond that. Baseline 3 is appropriate.

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 ('Returns a single competitor's full profile') and immediately names what the payload includes (recent items per tracked section). Sibling differentiation is explicit: list_activities is named for the full-list and timeline cases, so the agent can tell the two apart 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 Guidelines5/5

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

Gives the precondition ('Use after list_competitors — pass the `id` from a result row') and two explicit alternatives with the exact parameters that select them (`list_activities` with `competitor_ids=[id]` and `sections=[...]` for full lists; `list_activities` with `competitor_ids=[id]` for a timeline). When-to-use is fully resolved.

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

Deploy Server