Skip to main content
Glama
Sign In
Meertrack MCP

Meertrack MCP

Official
by meertrack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get activity items

get_activity_items
Read-only

Fetches full section detail for up to 100 activity rows—blog text, key points, pricing tables, tech stack—that the lean list_activities feed omits. Batch row ids in one call.

Instructions

Wraps GET /activity/items. Returns the full payload for one or more activity rows — the section-specific detail (full blog description, key points, pricing table, leadership-change summary, full tech stack, etc.) that the list_activities feed omits to stay lean.

Pass a list of row ids from a list_activities result (1–100). Resolving several at once is one call / one rate-limit hit — prefer it over many single lookups. Partial success is normal: ids that don't resolve (unknown, in another workspace, from an inactive period, or malformed) come back in not_found, not as an error. data order is not guaranteed — match results back by id. Digest ids are NOT activity rows: they land in not_found. Use get_digest for those. Errors: unauthorized, rate_limited, invalid_parameter (no ids / too many).

Input Schema

NameRequiredDescriptionDefault
row_uuidsYes1–100 activity row ids to resolve in one batch.

Output Schema

NameRequiredDescriptionDefault
dataYes
not_foundYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.3.0
    • addedOutput schema / properties / data / items / properties / section / description
      Added value: +"Section slug: blog-posts, press-posts, job-listings, ads, pricing, case-studies, linkedin-posts, x-posts, reviews, youtube-videos, events, messaging, metrics-claimed, logos, sitemap-urls, leadership, web-technologies. New sections may appear; treat an unknown value as an opaque label."
    • removedOutput schema / properties / data / items / properties / section / enum
      Removed value: -[
-  "blog-posts",
-  "press-posts",
-  "job-listings",
-  "ads",
-  "pricing",
-  "case-studies",
-  "linkedin-posts",
-  "x-posts",
-  "reviews",
-  "youtube-videos",
-  "events",
-  "messaging",
-  "metrics-claimed",
-  "logos",
-  "sitemap-urls"
-]
  2. First observedv2.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well past `readOnlyHint`: documents partial success semantics (`not_found` instead of an error, with the reasons ids may not resolve), warns that `data` order is not guaranteed and must be matched by `id`, and lists the error classes including the invalid-batch cases. This is the kind of non-obvious behavior an agent would otherwise discover only by failing.

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

Conciseness5/5

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

Front-loaded with what the tool returns and why it exists, then batching advice, then the failure modes. Short paragraphs with emphatic bolding on the one fact most likely to be missed (result ordering). No filler sentences.

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?

Single-parameter read tool with an output schema, and the description still covers the parts the schema can't: why batching matters, how partial failures surface, and that order is unstable. Nothing an agent needs in order to call it correctly is absent.

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 value by naming the provenance of the ids (activity rows from `list_activities`), restating the 1–100 batch bound in context, and warning that digest ids silently degrade to `not_found`. It does not add format-level detail beyond the schema, which is unnecessary here.

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 plus the endpoint it wraps, and frames the tool's role as hydrating the section-specific detail that `list_activities` deliberately omits. An agent can immediately tell it apart from `list_activities` and `get_digest` 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?

Explicitly says where the ids come from (`list_activities` results), instructs batching over repeated single lookups for one rate-limit hit, and gives an exclusion rule: digest ids go to `get_digest`, not here. Use/no-use conditions and the alternative are both named.

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