Skip to main content
Glama
Sign In

Replo

by app.replo.api
OverviewDiscussionsAdmin

Get brand activity

sightglass_get_company_activity
Read-onlyIdempotent

How one brand's advertising has moved: its daily active-ad trend, ads launched per week, how long its ads stay live (longevity buckets), and the technology stack on its site with when each tool was first seen. Use it for 'is this brand scaling up or pulling back' and 'what did they change'. The trend window and the launch and longevity charts depend on the plan. Fields the user's Replo plan doesn't include come back null and are named in that item's locked list (estimates = sales, visits and traffic); lockedCount is how many more results a higher plan shows. Say the data is on a higher plan; never estimate it yourself. Returns data only: nothing is shown to the user yet. Once you know the answer, call sightglass_show once with this call's resultId to show it as cards; the show call does not search again.

Input Schema

NameRequiredDescriptionDefault
daysNoTrend window in days; defaults to 90. Capped by the plan.
weeksNoWeeks of launches; defaults to 26.
projectIdNoReplo project id, from list_projects: where the charge or the asset lands. Its workspace's plan applies.
companyRefYesCompany id or slug. Users call companies 'brands'.
workspaceIdNoReplo workspace id, from list_workspaces. Sets which workspace's plan applies; required when the user has more than one workspace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / properties / projectId / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
    • removedInput schema / properties / workspaceId / pattern
      Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
  2. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Well beyond the readOnly/idempotent annotations, it discloses plan-based gating (fields outside the plan return null and appear in an item's `locked` list, with `lockedCount` for the remainder), the instruction never to estimate locked data, that results are data-only and invisible to the user until a separate sightglass_show call, and that the show call does not re-run the search.

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?

Capabilities are front-loaded in the first sentence and the critical two-step show flow closes it. The middle sentences are dense and stacked with caveats, but each carries real operational information rather than filler.

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 tool with no output schema, the description covers what comes back (trend, launches, longevity buckets, tech stack, locked fields), how plan limits manifest in the payload, and the required display handoff. An agent has everything needed to call it and act on the result correctly.

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 each parameter already documents its bounds, defaults and plan interaction, so the schema does the heavy lifting. The description adds no per-parameter meaning (it discusses output fields `locked`/`estimates` rather than inputs), which is the baseline-3 case.

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?

Opening sentence names a specific verb and resource (how one brand's advertising has moved) and enumerates the concrete outputs: daily active-ad trend, launches per week, longevity buckets, tech stack with first-seen dates. This distinguishes it immediately from siblings like sightglass_get_company (profile), sightglass_find_ads (ad search) and sightglass_get_rankings.

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 explicit triggering questions ('is this brand scaling up or pulling back', 'what did they change') and states the mandatory follow-up step: call sightglass_show once with resultId to display results. It stops short of naming when NOT to use it versus close siblings such as sightglass_research_company or sightglass_get_xray.

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

All Replo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources