Retrieve an auto-creation intent's status and draft results. Use to check if AI-driven creation has finished and view the generated drafts.
Get an AI auto-creation intent (its status + draft results).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| frameId | No |
Changes observed during successful MCP inspections.
v1.0.1Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v0.7.1Input schema / properties / id / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "number"
- }
-]Input schema / properties / id / typeAdded value: +[
+ "string",
+ "number"
+]v0.4.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that the response carries status plus draft results, which is useful, but says nothing about authorization, error cases, or freshness of the intent.
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?
A single short sentence with the resource and return content front-loaded. Nothing is wasted, though it is minimal rather than richly structured.
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?
With no output schema and 0% parameter documentation, the description should carry more weight. It partially covers the return value (status + draft results) but leaves both parameters and the relationship to sibling auto-creation tools unexplained, which is thin for a lookup tool in a crowded namespace.
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 0%, so neither 'id' nor the optional 'frameId' is documented anywhere. The description does not compensate—it never explains what the id refers to or why a frameId would be supplied, leaving an ambiguity about whether id is global or frame-scoped.
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?
States a specific verb (Get) and resource (auto-creation intent), and clarifies the payload with 'status + draft results'. It implicitly distinguishes itself from the sibling skylight_list_auto_creation_intents by fetching a single intent, though it never names that sibling.
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 when-to-use guidance, no prerequisites, and no mention of alternatives such as list_auto_creation_intents or approve_auto_creation. The agent must infer retrieval semantics from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.