Skip to main content
Glama
Sign In

WisePPC

by com.wiseppc.mcp
OverviewDiscussionsAdmin

query

Read-onlyIdempotent

Structured analytics query on a catalog dataset. Metrics and dimensions are ids from describe(kind='datasets'); the server writes the SQL (curated path; SEPARATE from run_query's raw SQL). Metrics are additive (summed) or ratio (ratio-of-sums after aggregation, not an average of ratios). Dimensions: attributes label at the existing grain; segments fan rows. filters select dimensions before aggregation; having selects metrics after aggregation. Seller datasets (domain 'seller') use target amazon_sp; Ads datasets (domain 'ads', e.g. ads_performance) use target amazon_ads; eBay datasets (domain 'ebay') use target ebay — all validated against your account. A rejected request returns the legal vocabulary.

Input Schema

NameRequiredDescriptionDefault
sortNoOrder-by list: [{field, dir: 'asc'|'desc'}]. field must be a selected metric or dimension.
limitNoMax rows (default 100). Clamped to the caller tier's max.
roundNoDecimals, default 2.
formatNoDefault compact {columns,rows}; tsv smallest.
havingNoPost-aggregation filter on metrics (incl. ratios). Same shape as `filters`.
offsetNoRow offset for pagination (default 0).
targetNoFrom get_session_context targets: kind:account[:unit].
compareNoPeriod-over-period. Either the string 'previous_period' (same-length window immediately before time_range) or an explicit {start, end} (ISO dates). Adds <metric>_prev and <metric>_delta columns. Requires total granularity.
datasetYesDataset id from describe(kind='datasets') (e.g. 'sales_traffic').
filtersNoPre-aggregation filter on dimensions. A condition {field, op, value} or a boolean tree {and|or|not:[...]}, or a list (implicit AND). Metrics belong in `having`.
metricsNoMetric ids from describe(kind='datasets') (additive or ratio).
dimensionsNoAttribute and/or segment ids to SELECT + GROUP BY. Each segment fans rows.
time_rangeYesRequired date window {start, end} (ISO YYYY-MM-DD), clamped to your account's live available data.
granularityNoTime bucket (default 'total' = one row per dimension over the whole window). 'daily'/'weekly'/'monthly' add a time column = the granule start (weekly = Monday). Must be one of the dataset's time.granularities.
marketplace_idNoAmazon marketplace id (e.g. 'ATVPDKIKX0DER') — required for seller datasets (MCP: in target) and search_term_results. eBay: optional (e.g. 'EBAY_US'), omit for all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / marketplace_id / description
      Previous value: -"Amazon marketplace id (e.g. 'ATVPDKIKX0DER') — required for seller datasets (MCP: in target) and search_term_results."New value: +"Amazon marketplace id (e.g. 'ATVPDKIKX0DER') — required for seller datasets (MCP: in target) and search_term_results. eBay: optional (e.g. 'EBAY_US'), omit for all."
  2. Changed8 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / businessProfileId
      Removed value: -{
-  "description": "Business profile ID. Auto-resolved from session if not provided.",
-  "type": [
-    "integer",
-    "string"
-  ]
-}
    • changedInput schema / properties / dataset / description
      Previous value: -"Dataset id from describe_dataset (e.g. 'sales_traffic')."New value: +"Dataset id from describe(kind='datasets') (e.g. 'sales_traffic')."
    • changedInput schema / properties / marketplace_id / description
      Previous value: -"Amazon marketplace id (e.g. 'ATVPDKIKX0DER') — required for seller datasets."New value: +"Amazon marketplace id (e.g. 'ATVPDKIKX0DER') — required for seller datasets (MCP: in target) and search_term_results."
    • changedInput schema / properties / metrics / description
      Previous value: -"Metric ids from describe_dataset (additive or ratio)."New value: +"Metric ids from describe(kind='datasets') (additive or ratio)."
    • removedInput schema / properties / profileId
      Removed value: -{
-  "description": "Amazon advertising profile id — required for Ads datasets (domain 'ads', e.g. ads_performance). Validated against your business profile.",
-  "type": [
-    "integer",
-    "string"
-  ]
-}
    • removedInput schema / properties / seller_id
      Removed value: -{
-  "description": "Amazon selling_partner_id — required for seller datasets. Validated against your business profile.",
-  "type": "string"
-}
    • addedInput schema / properties / target
      Added value: +{
+  "description": "From get_session_context targets: kind:account[:unit].",
+  "type": "string"
+}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real value beyond that: the server validates targets against the account and a rejected request returns the legal vocabulary, which tells the agent how to recover from errors. It does not describe result volume or cost characteristics, keeping it short of a 5.

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?

Front-loaded with the core purpose and the run_query distinction, and every subsequent sentence carries operational content (metric types, dimension vs segment, filters vs having, target routing). The density of backticked terms makes it feel compressed, but little is wasted.

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?

For a 15-parameter tool with nested objects and no output schema, the definition covers the hard parts: where ids come from, what the server does (writes SQL), target selection per domain, aggregation order, and error recovery. Remaining gaps — row shape and the interaction of sort/limit/offset with compare output — are mostly handled by the schema's own parameter descriptions.

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 descriptions for filters, having, dimensions, compare and granularity already carry their own semantics ("Pre-aggregation filter on dimensions", "Each segment fans rows"). The description exceeds baseline mainly by explaining metric arithmetic — additive sums vs ratio-of-sums rather than average-of-ratios — which the schema only gestures at with "(additive or ratio)".

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

Purpose5/5

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

States a specific verb+resource ("Structured analytics query on a catalog dataset") and immediately scopes it against the sibling: "the server writes the SQL (curated path; SEPARATE from run_query's raw SQL)". An agent can distinguish this from run_query without opening either schema.

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 clear routing: ids come from describe(kind='datasets'), target selection is mapped per domain (seller→amazon_sp, ads→amazon_ads, ebay→ebay). The run_query separation implies when to prefer the curated path, but there is no explicit "do not use when" statement or guidance on choosing between datasets.

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

All WisePPC 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