Read aggregate Microsoft Advertising metrics and save normalized campaigns, spend, and conversions to local SQLite without writing to Microsoft Ads.
Read aggregate Microsoft Advertising metrics and persist normalized campaigns, spend and conversions into local SQLite. This never writes to Microsoft Ads.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| from | No | ||
| preset | No | ||
| currency | No | ||
| module_id | No | ||
| tool_name | No | ||
| account_id | No | ||
| project_id | No | ||
| customer_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It usefully discloses the external side-effect boundary ('never writes to Microsoft Ads') and that it does write locally, but it omits auth requirements, idempotency/overwrite semantics for SQLite, rate limits, and pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no filler. The second sentence adds a genuinely useful scoping constraint about external writes, though the first sentence packs several concepts together without separating read vs persist behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter, no-annotation, no-output-schema tool, the description is too thin. It communicates the high-level flow and external safety, but leaves parameters, local DB target, idempotency, and error behavior entirely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are nine parameters with 0% schema description coverage, and the description mentions none of them. It does not clarify the from/to vs preset date logic, currency, account_id/customer_id, or the module/tool/project identifiers, leaving the agent to guess at all parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Microsoft Advertising metrics) and a concrete outcome (persist normalized campaigns, spend, conversions into local SQLite). It clearly distinguishes a sync/persist operation from a pure read, though it does not explicitly name sibling ads_microsoft_ads_report as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'persist into local SQLite' – an agent can infer this is for refreshing local data rather than ad-hoc reporting. However, there is no explicit when-to-use guidance versus ads_microsoft_ads_report or the other sync tools, and no prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.