Skip to main content
Glama
Sign In

WisePPC

by com.wiseppc.mcp
OverviewDiscussionsAdmin

run_query

Read-onlyIdempotent

Raw SELECT SQL against analytics tables (ClickHouse), for joins across tables, arrays (groupArray), window functions, or arithmetic across metrics. Available tables:

  • ads_olap: Amazon Ads analytics - daily performance data with campaigns, targets, search terms, and metrics.

  • product_catalog: Product catalog — current pricing, availability, BSR, ad eligibility per ASIN.

  • product_changes: Product change log — price movements, stock flips, BSR shifts, eligibility updates. Every time-series scan needs a literal lower date bound: time_window_date for ads_olap and changed_at for product_changes. A closed literal range meets the bound. product_catalog is a current snapshot and is exempt. ads_olap time_window_month is 1-12 and time_window_week is a week number; neither includes the year. Buckets: toStartOfMonth(time_window_date), toYYYYMM(time_window_date), or toStartOfWeek(time_window_date, 1) (Monday). ads_olap holds daily, weekly, and monthly granules. time_granularity is 'daily', 'weekly', or 'monthly'; omitted means daily. business_profile_id and profile_id are injected by the server and are not WHERE predicates. Money metrics are sums. Ratio form is if(x=0,null,x); nullIf is blocked. LIMIT defaults and caps by credential: MCP 100/500, API key 500/5,000, first-party frontend 1,000/50,000. Money is the profile's native currency (get_session_context(section="accounts") currency_code). Column schema and enums are returned by describe(kind='tables').

Input Schema

NameRequiredDescriptionDefault
sqlYesSELECT query against enabled tables (e.g., ads_olap). Every time-series table scan must include its physical date column with a literal lower bound or closed range.
roundNoDecimals, default 2.
formatNoDefault compact {columns,rows}; tsv smallest.
targetNoFrom get_session_context targets: kind:account[:unit].
columnsNo
max_rowsNoMaximum rows. Absent: the credential tier's default (100 MCP, 500 API key, 1,000 first-party). Caps are 500, 5,000, and 50,000. Larger values are clamped silently, not rejected. Responses are also bounded by a byte budget.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 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"
-  ]
-}
    • removedInput schema / properties / profileId
      Removed value: -{
-  "description": "Amazon advertising profile ID (from list_profiles). Accepts integer or numeric string.",
-  "type": [
-    "integer",
-    "string"
-  ]
-}
    • addedInput schema / properties / target
      Added value: +{
+  "description": "From get_session_context targets: kind:account[:unit].",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "sql",
-  "profileId"
-]New value: +[
+  "sql"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, and the description adds real operational context beyond them: LIMIT defaults and caps per credential tier (100/500, 500/5,000, 1,000/50,000), silent clamping rather than rejection, a byte budget on responses, server-injected predicate columns, and that nullIf is blocked while `if(x=0,null,x)` is the sanctioned ratio form. These are non-obvious constraints an agent could not infer from annotations or schema.

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 capability and table list, then ordered into date-bound rules, granularity, injection rules, and limit tiers — a sensible progression. It is dense but nearly every clause is load-bearing; only the granularity enumeration (time_window_month 1-12, week number without year, bucket functions) runs a little long relative to the rest.

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 complex, no-output-schema SQL tool this covers the essentials an agent needs to call it correctly: table inventory, mandatory date-bound rules, granularity semantics, reserved columns, ratio-expression restrictions, and result-size limits. Remaining gaps are minor — no guidance on malformed-SQL error behavior and no explicit deferral pattern to the sibling 'query' tool.

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 already 83%, so the baseline is 3; the description still adds value by explaining that max_rows values larger than the tier cap are clamped silently rather than erroring, and that money values are in the profile's native currency resolvable via get_session_context. It does not add anything for `target` or `columns`, but the schema handles those adequately.

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 opens with a specific verb+resource ('Raw SELECT SQL against analytics tables (ClickHouse)') and enumerates the exact tables available, so the agent knows precisely what it does. It also implicitly routes schema discovery to describe(kind='tables'). It does not, however, distinguish this from the sibling tool 'query', leaving the agent to guess which query entry point to use.

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?

Strong conditional guidance: it states that every time-series scan needs a literal lower date bound (naming time_window_date and changed_at), that product_catalog is exempt, and that business_profile_id/profile_id must not appear in WHERE clauses. What is missing is explicit when-to-use-this-vs-'query' routing and any statement about when to prefer get_report or get_events instead of raw SQL.

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