List every prompt ever attached to a scene, across all slots and revisions
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"sceneId": "<sceneId>"
},
"name": "prompt.list_for_scene"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| sceneId | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List every prompt ever' usefully signals an unfiltered, history-wide read that may return retired or superseded entries, but it says nothing about ordering, pagination, size limits, permissions, or what happens if the scene has no prompts.
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 front-loaded sentence with no filler; the scope constraint ('all slots and revisions') follows immediately after the verb and resource.
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 simple one-parameter list tool with no annotations and no output schema, the description conveys the essential scope of the result. It is still thin on result characteristics (ordering, volume, whether detached prompts are included) that an agent would want before calling it repeatedly.
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?
With a single parameter at 0% schema description coverage, the description must supply meaning, and it does imply that the scene is the scoping key for the listing. However, it never explicitly states that sceneId is the required identifier or what form it takes, so the compensation is partial.
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 uses a specific verb ('List') and a precise resource ('every prompt ever attached to a scene'), and the qualifier 'across all slots and revisions' clarifies the breadth versus a single-prompt or single-revision lookup. It does not name a sibling such as prompt.list_revisions or prompt.get, so the differentiation is inferable rather than explicit.
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: 'ever attached ... across all slots and revisions' suggests an audit/history use case when you need the full set rather than one current prompt. There is no explicit when-to-use or when-not-to-use statement and no pointer to prompt.list_revisions for a narrower query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.