Call any /uapi endpoint when a model ships before this MCP server is updated. Send GET, POST, or DELETE requests with query or form fields to access new Snapgen paths.
Call any snapgen path under /uapi. Use when a model ships before this server is updated. path must start with /uapi/.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path beginning with /uapi/, e.g. /uapi/v1/video-gen/veo | |
| query | No | ||
| fields | No | Form fields for POST | |
| method | No | POST |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about authentication, rate limits, whether calls may mutate or delete data, or what errors look like. It only implies a generic HTTP call, leaving significant safety and side-effect behavior undocumented.
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?
The description is short and front-loaded, with the tool's role stated first. The final sentence repeats a constraint already in the schema, which is minor redundancy but does not bloat the text.
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 generic HTTP passthrough with no annotations and no output schema, the description omits critical context: how method, query, and fields interact, what side effects are possible, and how responses or failures should be interpreted. The usage context is helpful but insufficient for correct and safe invocation.
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?
Schema description coverage is only 50%, and the description repeats the path constraint ('path must start with /uapi/') that is already present in the schema. It adds no meaning for query, fields, or method, leaving half the parameters without useful semantic guidance.
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 states a generic verb (call) and resource (any snapgen path under /uapi), but it is effectively a catch-all proxy and does not name a specific operation. The fallback context ('when a model ships before this server is updated') gives some differentiation from the specific generation siblings, but the core purpose remains vague.
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?
It explicitly says when to use the tool: when a model ships before this server is updated. It does not state when not to use it or name the specific sibling alternatives, but the context is clear enough for an agent to understand the fallback role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.