Skip to main content
Glama
flin-agency

flin-gmp-mcp

by flin-agency

list_dv360_reports

Read-onlyIdempotent

Lists existing runs of a DV360 report query and returns run metadata and report URLs. Use an existing query ID; it does not run reports or fetch CSV files.

Instructions

List existing runs of a DV360 report query, including available report metadata/URLs.

Does not run reports or fetch report CSVs. Use a query ID from list_dv360_report_queries.

Input Schema

NameRequiredDescriptionDefault
accountNo
query_idYes
page_sizeNo
page_tokenNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful behavioral context by clarifying that the tool lists existing runs and metadata/URLs but does not execute reports or fetch CSVs. It does not discuss pagination behavior or auth requirements, but the annotations carry much of that burden.

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 short and front-loaded: it states the purpose first, then the exclusion, then where to get the required query ID. Every sentence contributes useful routing or scoping information.

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?

The tool has an output schema, so return values need not be explained, and the annotations cover safety and idempotency. However, with 0% schema description coverage, the description should say more about account, page_size, and page_token to fully support correct invocation.

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 0%, so the description must compensate for all four parameters. It only explains the source of query_id and says nothing about account, page_size, or page_token, leaving most parameter semantics undocumented.

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 uses a specific verb and resource: list existing runs of a DV360 report query. It further clarifies the return scope by mentioning report metadata and URLs, and explicitly differentiates the tool from running reports or fetching report CSVs. This is enough for an agent to identify the tool's purpose without opening the 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?

It clearly states the prerequisite for query_id by directing the agent to list_dv360_report_queries, and it explicitly says what the tool does not do: run reports or fetch CSVs. However, it does not name the alternate tool for actually running or retrieving reports, so it lacks a fully explicit alternative routing.

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