Skip to main content
Glama
Sign In
Podyx MCP

Podyx MCP

by Studio-Red-Barcelona
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

podyx_v1_reports_summary

Read-onlyIdempotent

Retrieve a read-only compact business performance summary for a selected date range or calendar preset, with optional comparison periods, to review studio reports.

Instructions

Read compact business summary GET /api/v1/reports/summary. Requires current reports:read. Customer identities and signed client filters require clients:read. Evidence rechecks all resource permissions. Typed input, complexity and recorded allocation coverage errors are 422 with no partial headline; invalid or inaccessible references are opaque 404. Busy analysis capacity returns 429 analysis_busy with Retry-After: 1 and no partial headline. Ordinary infrastructure faults retain the native 500/503 contracts. Read/preview only. Follow all pagination; a quote does not reserve a slot or lock a price.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "podyx_v1_reports_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: permission model, evidence-based rechecks, 422 classes with no partial headline, opaque 404 for inaccessible references, and 429 analysis_busy with Retry-After: 1. The trailing 'a quote does not reserve a slot or lock a price' is boilerplate that doesn't fit a summary read and slightly muddies an otherwise strong behavioral profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading the verb, resource and endpoint is good, and the error/permission sentences are dense with value. However, generic boilerplate about 500/503 native contracts and pricing/quote slot reservation adds length without helping this particular read tool.

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?

Error taxonomy, permissions and pagination guidance are covered well for a read tool with no output schema. What is missing is what the 'compact business summary' actually returns (headline metrics, sections) and any guidance on the nested date-window parameters, which are the main source of misuse risk.

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

Parameters2/5

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

Schema description coverage is reported at 0% for a nested query object containing preset, from_date/to_date and the comparison bounds. The description says nothing about date windows, preset defaults, or how comparison ranges pair with the primary range, so an agent must reverse-engineer the nesting and pairing rules entirely from 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?

States a specific verb and resource ('Read compact business summary') and pins it to the endpoint GET /api/v1/reports/summary, which separates it from the other report siblings such as reports_metrics or reports_revenue. It does not explicitly say how it differs from those siblings, but the resource noun does the distinguishing work.

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?

Provides real prerequisites (reports:read, plus clients:read for customer identities and signed client filters) and states 'Read/preview only', which implicitly tells the agent this is a safe read. It gives no explicit when-to-use-vs-alternative routing among the many other reports_* tools, leaving that to inference.

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

Deploy Server

Other Tools