What can you do with this server?

This is a read-only MCP server that lets AI agents query privacy-friendly web analytics data from a Takt instance. * List sites – Retrieve the domains/sites belonging to an organization. * Get summary metrics – Fetch top-line stats (visitors, sessions, pageviews, bounce rate, avg. visit duration) for a time period, with optional comparison to the previous period. * Get time series data – Retrieve visitors and pageviews over time, bucketed by hour or day, with optional previous-period comparison. * Get dimension breakdowns – Rank top values for pages, traffic sources, countries, regions, cities, devices, browsers, OS, UTM parameters, entry/exit pages — with optional country filtering and row limits. * Get realtime visitors – See visitors active on a site in the last 5 minutes. * Get goal conversions – View conversion counts per defined goal for a site. * Get funnel reports – Analyze step-by-step funnel conversion data. * Get revenue data – Retrieve revenue figures grouped by currency for a specific revenue event. * List event properties – Discover custom property keys recorded for a given event. * Get property breakdowns – Break down a custom event property by its values (e.g., signups per plan type). * Sites as MCP resource – When TAKT_ORG is set, organization sites are exposed as a takt://sites resource without a tool call. Most tools support flexible time filtering via preset periods (day, 7d, 30d, month, 6mo, 12mo) or explicit from/to date ranges, with IANA timezone support. All operations are read-only.

How do I use @vskstudio/takt-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@vskstudio/takt-mcp Show me the summary stats for today" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@vskstudio/takt-mcp

Official

by vskstudio

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@vskstudio/takt-mcp

WARNING

Deprecated. This static-key stdio package is no longer the recommended way to connect an AI agent to Takt. Takt now hosts a remote MCP server with OAuth 2.1 — no API key to generate or copy, per-team and per-scope consent, and one-click revocation. Point your MCP client at https://taktlytics.com/mcp instead:

claude mcp add --transport http takt https://taktlytics.com/mcp

See the MCP docs. This repository is archived and no longer maintained.

License: MIT

Model Context Protocol server for Takt — query your sites' privacy-friendly analytics from any MCP-aware AI agent (Claude Desktop, Claude Code, Cursor, …).

The server is a thin, read-only client over the Takt public API. It runs on your machine and talks to a Takt instance using your API key — by default the hosted origin https://taktlytics.com, or your own self-hosted instance via TAKT_BASE_URL.

┌─────────────┐   stdio (MCP)   ┌────────────┐   HTTPS + Bearer   ┌──────────────┐
│  AI agent   │ ───────────────▶│  takt-mcp  │ ──────────────────▶│ Takt instance│
│ (Claude, …) │ ◀────────────── │ (this pkg) │ ◀───── JSON ────── │  /api/v1     │
└─────────────┘                 └────────────┘                    └──────────────┘

Requirements

Node.js ≥ 18
A Takt account on the hosted service (https://taktlytics.com), or a self-hosted Takt instance (set TAKT_BASE_URL)
A Takt API key (Dashboard → Settings → API keys) with the permissions for the tools you want to use:
- stats:read — every reporting tool (summary, timeseries, breakdown, realtime, goals, funnels, revenue, event properties, property breakdown)
- sites:read — list_sites

A Takt API key is bound to a single site. So list_sites returns just that one site, and the domain you pass to the other tools must be the key's own domain (any other domain returns "site not found"). To cover several sites, mint one key per site and run one server instance per key.

Related MCP server: plausible-whenever-mcp

Quick start

The server runs straight from npm with npx — nothing to install or build. Every client below boils down to the same command, npx -y @vskstudio/takt-mcp, plus your TAKT_BASE_URL / TAKT_API_KEY in the environment.

Claude Code

One command, no file to edit (use -s user for a global install instead of the current project):

claude mcp add takt \
  -e TAKT_BASE_URL=https://taktlytics.com \
  -e TAKT_API_KEY=takt_sk_… \
  -e TAKT_ORG=my-org \
  -- npx -y @vskstudio/takt-mcp

Claude Desktop

Edit claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "takt": {
      "command": "npx",
      "args": ["-y", "@vskstudio/takt-mcp"],
      "env": {
        "TAKT_BASE_URL": "https://taktlytics.com",
        "TAKT_API_KEY": "takt_sk_…",
        "TAKT_ORG": "my-org"
      }
    }
  }
}

Codex CLI

Add a block to ~/.codex/config.toml:

[mcp_servers.takt]
command = "npx"
args = ["-y", "@vskstudio/takt-mcp"]
env = { TAKT_BASE_URL = "https://taktlytics.com", TAKT_API_KEY = "takt_sk_…", TAKT_ORG = "my-org" }

Cursor / Windsurf

Use the same mcpServers JSON as Claude Desktop, in ~/.cursor/mcp.json (Cursor) or ~/.codeium/windsurf/mcp_config.json (Windsurf).

VS Code (Copilot / Cline)

code --add-mcp '{"name":"takt","command":"npx","args":["-y","@vskstudio/takt-mcp"],"env":{"TAKT_BASE_URL":"https://taktlytics.com","TAKT_API_KEY":"takt_sk_…","TAKT_ORG":"my-org"}}'

Or commit a .mcp.json (Cline) / .vscode/mcp.json (Copilot, under a "servers" key) with the same fields.

Any other MCP client

The package ships a takt-mcp binary speaking MCP over stdio, so any client that can launch a command works:

TAKT_BASE_URL=https://taktlytics.com TAKT_API_KEY=takt_sk_… npx -y @vskstudio/takt-mcp

Useful flags:

npx @vskstudio/takt-mcp --version   # print the version
npx @vskstudio/takt-mcp --help      # print usage and the full environment reference

Configuration

The server is configured entirely through environment variables:

Variable	Required	Default	Description
`TAKT_BASE_URL`	no	`https://taktlytics.com`	Base URL of the Takt instance. Defaults to the hosted origin; set it to point at a self-hosted instance. Must be `http(s)`.
`TAKT_API_KEY`	yes	—	API key, sent as a `Bearer` token. Never logged.
`TAKT_ORG`	no	—	Default organization slug for `list_sites` and the `takt://sites` resource.
`TAKT_TIMEOUT_MS`	no	`15000`	Per-request timeout in ms (range `1000`–`120000`).
`TAKT_MAX_RETRIES`	no	`2`	Retries on transient failures — `429`/`5xx`/network (range `0`–`10`).
`TAKT_DEBUG`	no	`false`	Set to `1`/`true` to log diagnostics to stderr (the API key is never logged).

Invalid values fail fast at startup with a clear message on stderr.

Tools

Tool	Description	Permission
`list_sites`	List the sites (domains) in an organization.	`sites:read`
`get_summary`	Top-line metrics: visitors, sessions, pageviews, bounce, duration.	`stats:read`
`get_timeseries`	Visitors/pageviews over time, bucketed by hour or day.	`stats:read`
`get_breakdown`	Top values of a dimension (pages, sources, countries, devices, …).	`stats:read`
`get_realtime`	Visitors active in the last 5 minutes.	`stats:read`
`get_goals`	Conversions per goal.	`stats:read`
`get_funnels`	Step-by-step funnel reports.	`stats:read`
`get_revenue`	Revenue grouped by currency for a revenue event.	`stats:read`
`list_event_properties`	List the custom property keys recorded for an event.	`stats:read`
`get_property_breakdown`	Break down a custom property of an event by value.	`stats:read`

Most tools accept a time filter:

period — one of day, 7d, 30d, month, 6mo, 12mo (default 7d),
or an explicit from/to range (YYYY-MM-DD),
plus an optional tz (IANA timezone, e.g. Europe/Paris).

get_summary and get_timeseries also accept compareToPrevious to return the previous period of equal length. get_breakdown accepts dimension, an optional country (ISO-3166 alpha-2), and limit.

See the Tools reference for the full parameter list of each tool.

Resources

When TAKT_ORG is set, the server exposes one MCP resource:

URI	Description
`takt://sites`	The sites in your organization, as JSON — context without a tool call.

How it works

stdio transport. stdout carries the MCP protocol; all diagnostics go to stderr.
Resilient HTTP. Each request has a timeout (TAKT_TIMEOUT_MS) and retries transient 429/5xx/network errors with exponential backoff and jitter, honouring Retry-After.
Clean errors. Non-2xx responses are normalised to a Takt API error (status code): message, including the 402 quota_api_depasse billing case.
Safe by construction. The base URL is validated; org/domain inputs are URL-encoded so they can't inject path segments; the API key never appears in any output.

See docs/architecture.md for the module layout and design rationale.

Troubleshooting

Symptom	Likely cause / fix
`TAKT_BASE_URL is not a valid URL`	If set, it must be a full URL — e.g. `https://taktlytics.com`. Leave it unset to use the hosted origin.
`TAKT_BASE_URL must use http:// or https://`	Include the scheme, e.g. `https://taktlytics.com`.
`Takt API error (401 …)`	The key is wrong or revoked.
`Takt API error (403 …)`	The key lacks the required permission (`stats:read` / `sites:read`).
`site not found`	The `domain` is not the key's site — keys are single-site bound.
`Takt API error (402 quota_api_depasse)`	The API quota for your plan is exhausted.
`request timed out after …ms`	Raise `TAKT_TIMEOUT_MS`, or check connectivity to your instance.

Set TAKT_DEBUG=1 to see each request (method, path, query) and retry decisions on stderr.

Development

pnpm install
pnpm test         # vitest
pnpm typecheck    # tsc --noEmit
pnpm lint         # eslint
pnpm build        # tsup → dist/

The full gate (what CI runs): pnpm lint && pnpm typecheck && pnpm test && pnpm build. See CONTRIBUTING.md.

Documentation

Tools reference — every tool and parameter
Configuration — env vars and tuning
Architecture — modules and design
Recipes — example prompts and flows
Project wiki

License

MIT © VSK Studio

Available Tools

10 tools

get_breakdownB

Top values of a dimension for a site (e.g. top pages, traffic sources, countries, devices, browsers).

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`limit`	No	Max rows (default 10).
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.
`country`	No	Restrict to one country (ISO-3166 alpha-2, e.g. FR).
`dimension`	Yes	Dimension to rank.

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and description omits behavioral traits such as default ordering, limit behavior, time zone handling, or what 'top' means. It only states the basic purpose without operational details.

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?

Single sentence, zero waste, and front-loaded with purpose. However, it could be improved by adding a brief usage context without sacrificing conciseness.

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 no annotations, the description should compensate more. It provides only the core purpose, missing return format, pagination, and error handling. Adequate for simple expected behavior but not complete.

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%, so each parameter already has a description. The tool description adds no additional meaning beyond the schema, thus baseline of 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?

Description clearly states it returns top values of a dimension (verb 'top values' + resource 'dimension for a site'), with concrete examples (pages, sources, etc.) that differentiate it from siblings like get_funnels or get_timeseries.

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?

No explicit guidance on when to use this tool vs alternatives. The examples imply context but lack when-not or alternative pointers. For a tool with many siblings, this is a gap.

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

get_funnelsC

Funnel reports (step-by-step conversion) for a site. Requires a key with the stats:read permission.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.

TDQS

C2.9/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 disclose behavioral traits. It states a read permission is required, implying the tool is read-only, but it does not explicitly confirm that, nor does it add context about rate limits, destructive side effects, or what happens when the permission is missing.

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 description is short (two sentences) and front-loads the main purpose. While it is concise, it could include more details without being verbose; no wasted words.

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

Completeness2/5

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

Given that there is no output schema and no annotations, the description is insufficient. It does not explain what the funnel report response contains (e.g., conversion steps, metrics), how funnel steps are defined, or any limitations. The tool likely returns complex data, but the description leaves the agent guessing.

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?

Input schema coverage is 100% and parameter descriptions are clear. The tool description does not add extra meaning beyond what the schema already provides, so the baseline score of 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?

Description clearly identifies the tool as providing funnel reports (step-by-step conversion) for a site. It specifies the resource (funnels) and action (reports), which is clear. However, it does not differentiate from siblings like get_timeseries or get_breakdown, but the funnel concept is sufficiently distinct.

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?

The description only mentions a required permission (stats:read) but gives no guidance on when to use this tool versus alternatives such as get_timeseries or get_goals. There is no qualification of typical use cases or exclusions.

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

get_goalsB

Conversions per goal for a site. Requires a key with the stats:read permission.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.

TDQS

B3.3/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 the full burden. It correctly identifies the need for a permission but does not disclose other behavioral traits like whether the tool is read-only (implied but not stated), rate limits, or error handling. It is adequate but lacks depth.

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 with two sentences that front-load the main purpose. Every word earns its place with no redundancy or fluff.

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 5 parameters (1 required) and no output schema or annotations, the description is minimal. It covers the core functionality and permission, but lacks details about the return format, pagination, or error cases. 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 the baseline is 3. The description adds no additional meaning beyond what the schema already provides. It does not explain parameter relationships or provide usage examples.

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 retrieves 'Conversions per goal for a site.' This is a specific verb ('get') and resource ('goals'), distinguishing it from siblings like get_summary or get_timeseries. However, it does not explicitly contrast with other similar tools like get_funnels or get_revenue.

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?

The description mentions a permission requirement ('Requires a key with the stats:read permission') but provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios where get_goals is preferable to get_breakdown or get_timeseries.

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

get_property_breakdownC

Break down a custom property of an event by value (e.g. counts per plan for a Signup event).

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`key`	Yes	Custom property key, e.g. plan.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`event`	Yes	Event name.
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.

TDQS

C2.9/5.0

Behavior1/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication requirements, rate limits, side effects, or error conditions. The agent gets no insight into tool behavior beyond the action.

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 description is a single sentence with a helpful example, front-loaded effectively. However, it could include more context without being verbose. It is concise but minimally informative.

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

Completeness2/5

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

Given 7 parameters, 3 required, and no output schema, the description is sparse. It does not explain return values, pagination, date range behavior, or error handling. Schema covers parameter meaning but description lacks broader 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 coverage is 100% with all parameters described. The description adds an example but does not deepen semantic understanding beyond what the schema already provides. 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?

The description clearly states the action ('Break down'), the resource ('a custom property of an event'), and provides a concrete example (counts per plan for Signup event). It distinguishes from siblings like get_breakdown by specifying custom property breakdown.

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 like get_breakdown. The description implies usage for custom property breakdown but does not specify context or exclude cases.

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

get_realtimeA

Number of visitors active on a site in the last 5 minutes.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Site domain.

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description discloses the time window (last 5 minutes) and the metric (number of visitors). This is transparent for a simple tool, though it omits potential limitations like data freshness or authentication requirements.

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 a single concise sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the tool's 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?

Given the tool's simplicity (1 param, no nested objects, no output schema), the description adequately explains the output (number of visitors) and the data window. Some minor details about return type could improve completeness, but it's generally sufficient.

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%, with the 'domain' parameter described as 'Site domain.' The description adds no additional meaning beyond the schema, so 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?

The description clearly states the function: returning the number of active visitors in the last 5 minutes. It uses a specific verb and resource, distinguishing it from sibling tools like get_breakdown or get_funnels.

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 real-time visitor data but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_summary, get_timeseries). No when-not or alternative conditions are provided.

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

get_revenueB

Revenue grouped by currency for a given revenue event on a site.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`event`	Yes	Revenue event name, e.g. Purchase.
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.

TDQS

B3.3/5.0

Behavior3/5

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

No annotations exist, so the description must compensate. It discloses that the tool groups by currency and filters by event, adding behavioral context beyond schema. However, it omits traits like read-only nature, permissions, or side effects. This is adequate but not rich.

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 description is a single sentence of 11 words, very concise and front-loaded. No redundant information. Slightly vague but efficient.

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

Completeness2/5

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

With 6 parameters and no output schema, the description is too brief. It doesn't explain the output format, required parameters, or limitations. It leaves significant gaps for an agent to infer correct usage.

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%, so baseline is 3. The description adds no extra meaning to parameters beyond their schema descriptions. For example, it doesn't clarify the difference between 'event' and 'domain' or how 'period' interacts with date ranges.

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 specifies a clear verb ('get'), resource ('revenue'), grouping ('by currency'), and filter ('for a given revenue event on a site'). It distinguishes from siblings like 'get_summary' or 'get_breakdown' which have different scopes.

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 is given on when to use this tool versus alternatives. It lacks any mention of context, prerequisites, or exclusions. The description is purely functional.

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

get_summaryA

Top-line metrics for a site over a period: unique visitors, sessions, pageviews, bounce rate, average visit duration. Set compareToPrevious to also get the previous period figures.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`domain`	Yes	Site domain, e.g. example.com.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.
`compareToPrevious`	No	Also return the previous period of equal length.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided. Description states it returns metrics but does not disclose any side effects, rate limits, or error scenarios. Acceptable for a read-only tool, but lacks full transparency.

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 sentence front-loads the purpose and lists metrics. Second sentence adds parameter guidance. No extraneous content.

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?

Lists the specific metrics returned, but output format is not described. With no output schema, some information about the response structure is missing, though the description is adequate for simple usage.

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%, baseline 3. Description adds useful context for compareToPrevious parameter but no additional meaning beyond the schema for others.

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 the tool retrieves top-line metrics (unique visitors, sessions, etc.) for a site over a period. Distinct from siblings like get_breakdown or get_funnels.

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?

Provides clear context for use: getting summary metrics. Though it does not explicitly mention when not to use or list alternatives, the description implies the appropriate scenario.

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

get_timeseriesB

Time series of visitors and pageviews for a site, bucketed by hour or day.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.
`interval`	No	Bucket size (default day).
`compareToPrevious`	No	Also return the previous period series.

TDQS

B3.3/5.0

Behavior2/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 fails to disclose behavioral traits such as data aggregation, pagination, auth requirements, or limits. The description only states the basic output without behavioral context.

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 description is a single concise sentence that front-loads the core purpose without waste. However, it could benefit from additional structure given the tool has 7 parameters.

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

Completeness2/5

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

Given the tool's complexity (7 parameters, no output schema, no annotations), the description is incomplete. It does not explain parameter interactions (e.g., period vs from/to) or the effect of compareToPrevious. More detail is needed for adequate completeness.

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 schema already documents all parameters. The description adds only minimal context (bucketing by hour or day) which is already covered by the interval enum. At baseline 3, no additional semantic value is provided.

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 a time series of visitors and pageviews for a site, bucketed by hour or day. This specific verb+resource combination distinguishes it from sibling tools like get_breakdown or get_funnels.

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 implicitly indicates usage for retrieving time series data, but it does not provide explicit guidance on when to use this tool versus alternatives like get_realtime or get_summary. No exclusions or when-not-to-use advice is given.

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

list_event_propertiesC

List the custom property keys recorded for a given event on a site.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date YYYY-MM-DD (use with `from`).
`tz`	No	IANA timezone for bucketing, e.g. Europe/Paris.
`from`	No	Start date YYYY-MM-DD (use with `to` for a custom range).
`event`	Yes	Event name, e.g. Signup.
`domain`	Yes	Site domain.
`period`	No	Preset period (default 7d). Ignored when both `from` and `to` are set.

TDQS

C2.9/5.0

Behavior2/5

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

The description only says 'list', implying a read operation, but provides no additional behavioral traits beyond the schema. With no annotations, the description should disclose more, like whether it returns a list of keys, pagination, or required permissions.

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 description is a single sentence with no unnecessary words, making it concise. However, it could be structured to include more detail without losing conciseness.

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

Completeness2/5

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

The description lacks information about the return format or any additional context. With no output schema, the description should explain what the output looks like. It also fails to mention the relationship between 'period' and 'from'/'to' parameters, which is only in the schema.

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 baseline is 3. The description does not add any extra meaning beyond what the schema already provides for each parameter.

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 verb 'list' and the resource 'custom property keys' for a given event on a site. It is specific, but it does not explicitly differentiate from sibling tools like 'get_property_breakdown'.

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 is provided on when to use this tool versus alternatives, such as 'get_property_breakdown' or 'get_revenue'. There is no mention of prerequisites or context.

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

list_sitesA

List the sites (domains) in an organization. Requires a key with the sites:read permission.

ParametersJSON Schema

Name	Required	Description	Default
`org`	No	Org slug. Defaults to TAKT_ORG if set.

TDQS

A3.5/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 mentions a permission requirement. It does not describe other behaviors such as pagination, sorting, rate limits, or what happens when no sites exist.

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 description is concise with two sentences, each providing useful information. It is front-loaded with the purpose. However, it could be expanded slightly without becoming verbose.

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

Completeness2/5

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

The tool is simple but lacks output format description, error handling, or any additional context beyond listing sites. No output schema exists, so the description should compensate but does not.

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% with a description for the 'org' parameter. The description adds no meaning beyond the schema, so a baseline of 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?

The description clearly states 'List the sites (domains) in an organization' using a specific verb and resource. It distinguishes itself from sibling tools that focus on analytics reports (get_breakdown, get_funnels, etc.).

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 includes a prerequisite ('Requires a key with the sites:read permission') and the context is clear given the sibling tools have different purposes. However, it does not explicitly state when not to use this tool or mention alternatives.

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. Dates show when Glama detected each change.

2 tool updatesv0.2.1Jun 27, 2026
- Addedget_property_breakdown
- Addedlist_event_properties
8 tool updatesv0.1.0Jun 27, 2026
- First observedget_breakdown
- First observedget_funnels
- First observedget_goals
- First observedget_realtime
- First observedget_revenue
- First observedget_summary
- First observedget_timeseries
- First observedlist_sites

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct analytics metric or resource (funnels, goals, revenue, realtime, etc.). Despite many 'get_' prefixed tools, the descriptions clearly differentiate their purposes, leaving no ambiguity for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case with 'get_' for data retrieval and 'list_' for enumeration. This creates a predictable and easy-to-understand naming convention.

Tool Count5/5

With 10 tools, the server is well-scoped for its purpose of providing analytics data. The count covers essential metrics without being excessive or sparse.

Completeness4/5

The tool set covers core analytics needs: top metrics, breakdowns, funnels, goals, revenue, realtime, time series, and property listing. Minor gaps exist, such as no tool for filtering or segmentation, but the core retrieval functionality is comprehensive.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
AgentCatOAuth
com.agentcat
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Monitoring Observability
2
Measure.events Analytics A
io.github.meetclawdius
Privacy-first web analytics. Query pageviews, referrers, trends, and AI insights.
Monitoring Search Data Platforms
622
Clamp AnalyticsOAuth
sh.clamp
Clamp Analytics MCP server: traffic, revenue, funnels, cohorts, errors, and search, for AI agents.
Monitoring Search
2

Related MCP Servers

Umami MCP Server
Monitoring Observability
Mzaxd
A
license
A
quality
D
maintenance
Read-only MCP server for Umami analytics. It talks to the Umami REST API directly over HTTP, supporting self-hosted and cloud setups.
Updated 4 months ago (2026-04-30 02:05 UTC)
8
17
MIT
plausible-whenever-mcp
Monitoring Observability
Schneckenhausmann
A
license
A
quality
C
maintenance
MCP server that provides read access to Plausible Analytics data with natural-language date resolution, enabling users to query analytics like 'yesterday' or 'last week' without needing to know exact date formats.
Updated 3 months ago (2026-06-18 09:05 UTC)
8
MIT
openpanel-mcp
Search
neverhunt
F
license
Not graded
quality
B
maintenance
Minimal MCP server for OpenPanel analytics, enabling queries for landing pages, page events, and tracked event names.
Updated 3 months ago (2026-06-19 16:59 UTC)
-
plausible-mcp-server
Monitoring Marketing
friendlygeorge
A
license
B
quality
F
maintenance
MCP server for Plausible Analytics, enabling querying of traffic, conversions, sources, and device breakdowns from any MCP-compatible AI assistant.
Updated 3 months ago (2026-06-06 13:06 UTC)
12
53
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vskstudio/takt-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server