Skip to main content
Glama
PiwikPRO

Piwik PRO MCP Server

Official
by PiwikPRO

analytics_goals_list

Read-only

List all goals for a specific website to retrieve their UUIDs, then use them as filters in analytics queries. Match goals by exact name for precise conversion tracking.

Instructions

    List all goals for a website.

    Use this before goal conversion queries when the user names a specific goal.
    Match the goal by exact name in `data[].attributes.name`, then use the goal's
    `id` as the `goal_uuid` filter value in `analytics_query_execute`. Do not put
    `goal_uuid` in query columns when filtering to a single goal.

    Args:
        website_id: Website/App UUID
        limit: Maximum number of rows to return (default: 10, min: 1, max: 100000)
        offset: Number of rows to skip (default: 0, min: 0)

    Returns:
        Goals list with metadata. Each goal has `id` (UUID) and `attributes.name`.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
website_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesList of goals
metaNoMetadata such as total count

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable workflow context: exact name matching in data[].attributes.name, using the returned id as goal_uuid, and the warning not to include goal_uuid in query columns. Minor ambiguity remains because 'List all goals' could suggest unbounded results while the default limit is 10.

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 front-loaded with the core purpose, then provides a focused workflow, parameter notes, and return shape. Every sentence serves a purpose, and the Args section is compact despite covering all three parameters.

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 the output schema exists, the description still provides enough context on parameters, return shape, and downstream usage to let an agent select and invoke the tool correctly. It covers the full workflow from listing goals to querying them, which is sufficient for this tool's complexity.

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 description coverage is 0%, but the Args section fully compensates by documenting all three parameters: website_id as Website/App UUID, limit with default/min/max, and offset with default/min. This adds real semantic meaning beyond the bare 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?

The description opens with 'List all goals for a website,' which clearly states the verb, resource, and scope. It also distinguishes this tool from siblings like analytics_goals_get by framing it as the list operation used to resolve a named goal to an ID.

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 explicitly says 'Use this before goal conversion queries when the user names a specific goal' and explains the exact workflow: match by name, then use the ID in analytics_query_execute. It does not explicitly describe when not to use it or compare it to analytics_goals_get, so it falls just short of the full alternatives/exclusions bar.

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