Get Video Ads campaign
get_vads_campaignRetrieve details of a VADS campaign by campaign ID to review its settings and status.
Instructions
[READ] OpenAPI: GET /campaigns/{campaign}
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes |
get_vads_campaignRetrieve details of a VADS campaign by campaign ID to review its settings and status.
[READ] OpenAPI: GET /campaigns/{campaign}
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes |
Changes observed during successful MCP inspections.
v0.5.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the "[READ]" tag merely duplicates readOnlyHint. Nothing is said about authentication requirements, behavior when the campaign ID does not exist, or whether the response is a single object. It adds no behavioral context beyond the structured fields.
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?
It is a single short fragment with no wasted words and the read-only nature is front-loaded. However, brevity here reflects under-specification rather than tight editing.
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 single-parameter read tool with no output schema, the description should at least state what the call returns and the expected ID form. It leaves both the parameter meaning and the response shape entirely undocumented, so an agent cannot confidently construct or interpret the call.
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 is one required parameter at 0% schema description coverage, and the description only surfaces the path placeholder "{campaign}" without clarifying that it maps to campaign_id, what format an ID takes, or whether it accepts a slug or name. The schema's minLength:1 constraint is the only real specification.
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 is essentially the name restated as an HTTP call ("[READ] OpenAPI: GET /campaigns/{campaign}"). It says nothing about what a VADS campaign is or how this differs from siblings like list_vads_channel_campaigns or get_vads_channel. The title carries all the actual meaning.
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?
No guidance on when to use this tool versus list_vads_channel_campaigns (to enumerate campaigns) or get_vads_channel (to fetch the parent). No prerequisites, no conditions, no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.