Skip to main content
Glama
deenesjakoruzh
grovs-io

Grovs

by grovs-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

What is Grovs?

Grovs is an open-source, privacy-first growth platform for mobile apps — a self-hostable alternative to Branch.io and AppsFlyer. It provides:

  • Deep Linking — one link that routes users to the right content across iOS, Android, and web. Deferred deep links survive the install flow so users land on the right screen on first open.

  • Attribution — deterministic, first-party install and event attribution. No fingerprinting, no data sharing with ad networks.

  • Revenue Analytics — in-app purchases, subscriptions, and custom revenue events matched back to the campaign that drove the install.

  • Campaigns — group links, track performance, and compare results across channels.

EU-hosted, open-source SDKs, 20M+ daily active users in production. See the backend repo for self-hosting.

Related MCP server: cc-plugin-mcp

What is this MCP server?

This is an MCP (Model Context Protocol) server that lets AI assistants manage your Grovs platform through natural language. Create deep links, check analytics, configure redirects, run campaigns — without leaving your editor.

Quick Start

Claude Code

/plugin marketplace add grovs-io/mcp
/plugin install grovs@grovs

Installs the MCP server and skills that teach Claude how to use Grovs. On first use, a browser window opens for OAuth — no API keys needed.

Cursor

Open Settings > MCP and add a new server:

{
  "mcpServers": {
    "grovs": {
      "url": "https://mcp.grovs.io/mcp"
    }
  }
}

Windsurf

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "grovs": {
      "serverUrl": "https://mcp.grovs.io/mcp"
    }
  }
}

VS Code (GitHub Copilot)

Add to your .vscode/mcp.json:

{
  "servers": {
    "grovs": {
      "type": "http",
      "url": "https://mcp.grovs.io/mcp"
    }
  }
}

ChatGPT Desktop

Open Settings > MCP Servers > Add Server and enter:

https://mcp.grovs.io/mcp

Self-Hosted

If you're running your own Grovs backend, run the MCP server locally and point your client to it:

git clone https://github.com/grovs-io/mcp.git
cd mcp
npm install && npm run build
npm start

Or with Docker:

docker build -t grovs-mcp .
docker run -p 8080:8080 grovs-mcp

Then use http://localhost:8080/mcp as the server URL in any of the client configs above.

All clients will trigger an OAuth flow on first use — a browser window opens to authenticate with your Grovs account.

Configuration

Variable

Default

Description

PORT

8080

Server port

GROVS_API_URL

https://mcp.grovs.io

Grovs backend URL (override for self-hosted)

PUBLIC_URL

http://localhost:8080

Public URL of this MCP server (used for OAuth callbacks)

Copy .env.example to .env for local development.

Tools

Tool

Description

get_status

Account info, instances, projects, and domains

get_usage

Usage metrics and subscription status for an instance

create_project

Create a new instance with production and test projects

create_link

Create a deep link with metadata, tags, and custom data

get_link

Get full details of a link by path

update_link

Update a link's metadata, tags, or redirects

archive_link

Deactivate a link (irreversible)

search_links

Search and list links with pagination and filters

get_analytics_overview

Project-level metrics: views, installs, opens, revenue

get_link_analytics

Per-link daily metrics

get_top_links

Top performing links ranked by views

create_campaign

Create a campaign to group related links

list_campaigns

List campaigns with aggregated metrics

archive_campaign

Archive a campaign and deactivate its links

configure_redirects

Set per-platform redirect behavior (App Store, Play Store, web)

configure_sdk

Configure iOS/Android SDK settings (bundle ID, team ID, etc.)

Architecture

MCP Client (Claude Code, Cursor, etc.)
    │
    │  MCP protocol over HTTP
    ▼
Express app (src/app.ts)
    │
    ├── OAuth flow (/authorize, /callback, /register)
    │
    └── MCP endpoint (/mcp)
            │
            ├── Tool registration (src/server.ts)
            │       Zod schema validation + runWithAuth error boundary
            │
            ├── Handlers (src/tools/handlers.ts)
            │       Business logic, plain functions, throw on error
            │
            ├── Formatters (src/tools/formatters.ts)
            │       Convert API JSON to human-readable text
            │
            └── API client (src/api-client.ts)
                    HTTP calls to Grovs backend

Development

npm run dev          # start with auto-reload
npm run build        # compile TypeScript
npm test             # run tests (186 tests)
npm run test:watch   # run tests in watch mode
npm run lint         # ESLint
npm run format       # Prettier

See CONTRIBUTING.md for project structure and PR guidelines.

SDKs

Platform

Repository

iOS

grovs-io/grovs-ios

Android

grovs-io/grovs-android

React Native

grovs-io/grovs-react-native

Flutter

grovs-io/grovs-flutter

License

MIT

Available Tools

16 tools
archive_campaignArchive CampaignAInspect

Archive a campaign and deactivate all its links. This action cannot be undone. Always confirm with the user before calling.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProd or Test Project ID from get_status (use the Prod/Test Project ID columns, NOT the instance ID)
campaign_idYesCampaign ID from list_campaigns

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description discloses key behavioral traits: 'This action cannot be undone' (irreversibility) and 'deactivate all its links' (side effect). Adds significant context beyond the schema.

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?

Two concise sentences: first states the action, second adds irreversible consequence and user confirmation requirement. No redundant information; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers action, side effects, irreversibility, and user validation. Lacks explicit mention of return value, but given the destructive nature and absence of output schema, the description is sufficiently complete for agent invocation.

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

Parameters5/5

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

Schema coverage is 100% with detailed parameter descriptions. The tool description enhances understanding by specifying that project_id must use 'Prod or Test Project ID columns, NOT the instance ID' and that campaign_id comes from list_campaigns, adding crucial usage nuance.

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?

The description clearly states 'Archive a campaign' (verb + resource) and mentions 'deactivate all its links', distinguishing it from sibling tools like 'archive_link' (archives a single link) and 'update_link' (modifies without archiving).

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?

Explicitly instructs 'Always confirm with the user before calling', which is essential given the irreversible nature. Provides clear contextual guidance but does not list alternative tools for non-archiving scenarios.

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

configure_redirectsConfigure RedirectsAInspect

Set where users are sent when they open a deep link — per platform (iOS App Store, Google Play, desktop website) and a global fallback URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProd or Test Project ID from get_status (use the Prod/Test Project ID columns, NOT the instance ID)
ios_redirectNoiOS redirect URL (e.g. App Store link)
android_redirectNoAndroid redirect URL (e.g. Play Store link)
desktop_redirectNoDesktop fallback URL
web_redirectNoWeb fallback URL
fallback_urlNoGlobal fallback URL for all platforms

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the action and per-platform nature but does not mention side effects, permissions, or behavior on invalid URLs.

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?

Single sentence, front-loaded with the core purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool is straightforward with 6 params, no output schema. Description covers purpose and parameter roles but lacks usage guidelines and behavioral notes, leaving gaps for full agent guidance.

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% with descriptions for each parameter. The description adds value by grouping parameters per platform and clarifying the fallback URL as global, which is not explicit in the schema.

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?

Description clearly states the verb 'Set' and the resource 'where users are sent when they open a deep link', specifying per-platform and global fallback. This distinguishes it from sibling tools like create_link or update_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage for configuring redirects but does not explicitly state when to use this vs. alternatives, nor does it mention when not to use it.

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

configure_sdkConfigure Platform SDKAInspect

Configure platform-specific SDK settings for an instance — iOS bundle ID, Android package name, desktop app URLs. Required for deep links to open the correct app.

ParametersJSON Schema
NameRequiredDescriptionDefault
instance_idYesInstance ID from get_status
ios_bundle_idNoiOS bundle identifier (e.g. com.myapp.ios)
ios_team_idNoApple Developer Team ID
ios_app_store_idNoiOS App Store ID
android_package_nameNoAndroid package name (e.g. com.myapp.android)
android_sha256_fingerprintsNoAndroid SHA256 certificate fingerprints for App Links
desktop_urlNoDesktop app download URL

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. While it explains the purpose, it does not disclose side effects, required permissions, or whether changes take effect immediately. This is a moderate gap for a configuration tool.

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?

The description is extremely concise: two sentences totaling about 20 words. It front-loads the action and follows with the necessity, with no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 7 parameters, the description could be more complete. It mentions the purpose and high-level parameter categories but omits behavioral details like idempotency or effect on existing settings. It is adequate but not comprehensive.

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%, so baseline is 3. The description lists parameter categories but does not add significant insight beyond what the schema already provides. No examples or additional context are given.

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?

The description clearly states that the tool configures platform-specific SDK settings for an instance, listing specific parameters (iOS bundle ID, Android package name, desktop app URLs). It also explains the purpose (required for deep links), making it distinct from sibling tools like configure_redirects.

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?

The description provides context ('Required for deep links to open the correct app'), implying when the tool should be used. However, it does not explicitly mention when not to use it or suggest alternatives among siblings.

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

create_campaignCreate CampaignAInspect

Create a campaign to group related deep links. After creating, use create_link with campaign_id to add links to this campaign.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProd or Test Project ID from get_status (use the Prod/Test Project ID columns, NOT the instance ID)
nameYesCampaign name

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden of explaining behavior. It states the creation action and implies the campaign is immediately available for linking. However, it lacks details on side effects, authorization requirements, or what happens if a campaign with the same name exists. The description is adequate but not comprehensive.

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?

The description consists of two short sentences that are front-loaded with the core purpose. Every word serves a function—no redundancy or fluff. It is highly concise while still providing essential workflow guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, the description should ideally mention what is returned (e.g., campaign ID). It implies the return of a campaign_id by referencing it in the follow-up step, but it does not explicitly state the return value. For a simple 2-parameter tool, the description covers the main actions but lacks explicit return information.

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?

The input schema has high description coverage (100%), with both parameters described in detail. The description does not add extra meaning beyond the schema—it only mentions 'project_id' without additional context. According to the guideline, high schema coverage leads to a baseline of 3, which is appropriate 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?

The description clearly states that the tool 'Create a campaign to group related deep links.' It specifies the verb (create), resource (campaign), and purpose (grouping deep links). This distinguishes it from sibling tools like create_link (adds links to a campaign) and archive_campaign.

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?

The description provides direct guidance: 'After creating, use create_link with campaign_id to add links to this campaign.' This outlines the workflow and suggests when to use the tool (when creating a new campaign) and what to do next. It does not explicitly state when not to use it, but the context is clear given sibling tools.

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

create_projectCreate ProjectAInspect

Create a new Grovs project. This provisions a production and test environment with their own domains for deep links.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesProject name (e.g. 'My App')

TDQS

A4/5.0
Behavior3/5

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

Reveals that it provisions production and test environments with domains, but no mention of other side effects, permissions, or irreversibility. No annotations to supplement.

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?

Two sentences, no fluff, front-loaded with core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple creation tool with one parameter and no output schema. Could mention return value or next steps but not strictly necessary.

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 description adds no additional parameter information beyond the schema.

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?

Clearly states 'Create a new Grovs project' with specific verb and resource, and adds detail about provisioning environments. Distinguishes from siblings like create_campaign, create_link.

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?

Clear context for creating a project, but no explicit when-not-to-use or alternatives mentioned.

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

get_analytics_overviewProject AnalyticsAInspect

Get aggregated analytics for a project: views, opens, installs, new/returning users, revenue. Compares current period vs previous period. Defaults to last 30 days.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProd or Test Project ID from get_status (use the Prod/Test Project ID columns, NOT the instance ID)
start_dateNoStart date (YYYY-MM-DD), defaults to 30 days ago
end_dateNoEnd date (YYYY-MM-DD), defaults to today
platformNoFilter by platform: ios, android, desktop, web

TDQS

A4/5.0
Behavior4/5

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

The description discloses key behaviors: it compares current vs previous period and defaults to last 30 days. However, with no annotations, it does not explicitly state that it is a read-only operation or mention any permissions or rate limits, though such detail is often assumed for analytics tools.

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?

Two concise sentences, front-loaded with purpose and metrics. No unnecessary words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While there is no output schema, the description lists expected metrics (views, opens, installs, users, revenue), which compensates. It does not explain the return structure but is adequate for an overview tool. No reference to sibling tools.

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?

Input schema covers 100% of parameters with descriptions. The description adds value by clarifying the default date range and the comparative analysis (current vs previous period), which is not in the schema. However, parameter descriptions mostly suffice.

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?

The description clearly states the tool retrieves aggregated analytics for a project and lists specific metrics (views, opens, installs, users, revenue). It implicitly distinguishes from sibling tools like get_link_analytics by specifying 'project' vs individual links.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives such as get_link_analytics or get_usage. The description implies it is for project-level overview but does not provide exclusions or contextual recommendations.

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

get_statusGet Account & ProjectsAInspect

Returns the authenticated user's account info and all their Grovs projects with domains. Call this first to discover available project IDs before using other tools.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

Since no annotations exist, the description carries full burden. It correctly indicates read behavior for authenticated user, but could explicitly state it's read-only and safe to call repeatedly. No annotation contradiction.

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?

Single sentence conveying purpose and usage suggestion with zero redundancy. Every word earns its place.

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?

Given zero parameters, no output schema, and a rich set of sibling tools that depend on project IDs, the description fully equips an agent to use this tool correctly by explaining its output and invocation priority.

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?

No parameters in schema, so baseline is 4. Description adds no parameter info, but none needed since schema coverage is 100% with zero parameters.

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?

The description clearly states the tool returns account info and all projects with domains, distinguishing it from siblings that operate on specific projects. 'Call this first' emphasizes its unique role.

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 advises to call this tool first to discover project IDs before using other tools, providing clear when-to-use guidance and identifying its prerequisite function.

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

get_usageGet Instance UsageAInspect

Check usage metrics and subscription status for an instance. Returns current MAU count, MAU limit, and whether the quota is exceeded. Call get_status first to find instance IDs.

ParametersJSON Schema
NameRequiredDescriptionDefault
instance_idYesInstance ID from get_status

TDQS

A3.8/5.0
Behavior3/5

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

No annotations exist, so the description must cover behavioral traits. It implies a read-only operation ('Check'), but does not explicitly state it is non-destructive or mention authentication or rate limits. The description is adequate but could be more transparent.

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?

Two sentences, each adding value. The first sentence states purpose and outputs; the second provides usage guidance. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description covers what it returns and the prerequisite. It could optionally specify the output format, but the listed fields (MAU count, MAU limit, quota exceeded) provide sufficient context.

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% for the single parameter 'instance_id', which the schema already describes as 'Instance ID from get_status'. The description reinforces that but adds no new semantic meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks usage metrics and subscription status, returning specific data like MAU count and limit. It uses a specific verb ('Check') and resource ('usage metrics and subscription status'), but does not explicitly differentiate itself from sibling tools.

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?

Explicit prerequisite guidance is provided: 'Call get_status first to find instance IDs.' While it doesn't specify when to use versus alternatives, the tool's unique function makes context clear.

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

list_campaignsList CampaignsBInspect

List campaigns with aggregated metrics (views, opens, installs, revenue). Supports pagination, search by name, date range filtering, and sorting.

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesProd or Test Project ID from get_status (use the Prod/Test Project ID columns, NOT the instance ID)
pageNoPage number (default: 1)
per_pageNoResults per page (default: 20)
termNoSearch by campaign name
sort_byNoSort by: name, created_at, views, opens, installs, revenue
ascendentNoSort ascending (default: false = descending)
start_dateNoMetrics start date (YYYY-MM-DD, default: 30 days ago)
end_dateNoMetrics end date (YYYY-MM-DD, default: today)
platformNoFilter metrics by platform: ios, android, desktop, web
archivedNoFilter by archived status

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must cover behavioral traits. It only states the high-level purpose (listing campaigns) without disclosing details like data freshness, rate limits, response size limits, or whether metrics are real-time. The description adds little beyond the tool's name.

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?

A single, well-structured sentence that front-loads the core action and key features. Every element is meaningful and efficiently communicates the tool's functionality with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters with full schema descriptions and no output schema, the description adequately summarizes the tool's capabilities. It covers the main features (metrics, pagination, search, filtering, sorting). Could mention pagination behavior (e.g., total pages or response structure) but is otherwise complete for a list tool.

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%, so the input schema already documents all parameters well. The description adds a general summary of capabilities (pagination, search, filtering, sorting) but does not provide additional meaning for individual parameters beyond what schema descriptions already offer. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists campaigns with aggregated metrics, mentioning specific metrics (views, opens, installs, revenue) and capabilities (pagination, search, filtering, sorting). It distinguishes itself from sibling tools like get_analytics_overview or get_top_links by its broad scope, though it could explicitly note when to prefer this over others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as get_analytics_overview or get_top_links. The description does not mention prerequisites, when not to use it, or alternative tools for different scenarios.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 16 tool updatesv0.1.0
    • First observedarchive_campaign
    • First observedarchive_link
    • First observedconfigure_redirects
    • First observedconfigure_sdk
    • First observedcreate_campaign
    • First observedcreate_link
    • First observedcreate_project
    • First observedget_analytics_overview
    • First observedget_link
    • First observedget_link_analytics
    • First observedget_status
    • First observedget_top_links
    • First observedget_usage
    • First observedlist_campaigns
    • First observedsearch_links
    • First observedupdate_link
Deploy Server
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

TDQS

A4/5.0

Scored across 16 tools

Disambiguation5/5

Each tool targets a distinct resource and action. Links, campaigns, projects, analytics, and configuration are clearly separated with no overlapping functionality. Similar tools like search_links vs get_link serve different querying purposes.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., create_campaign, get_link_analytics, archive_link). Verbs are descriptive and nouns match the resource. No style mixing or vague names.

Tool Count5/5

16 tools is appropriate for a deep-linking service, covering project setup, campaign management, link CRUD, analytics, and configuration. Each tool serves a distinct need without redundancy or bloat.

Completeness4/5

The tool surface covers the essential lifecycle: create, read, update, and delete (via archive) for links, plus campaign and project management. Analytics and configuration are well-represented. Missing hard delete for campaigns/projects, but archiving covers deactivation.

Maintenance

ActivityInactive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers