Check current configuration, active model, and recent image or video details to verify setup and track outputs.
Check the current configuration status, active model, and last image/video information.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The word 'Check' implies a read-only operation and the description names the data that will be retrieved, but it does not explicitly state that no configuration changes are made, whether any side effects occur, or what the response structure looks like beyond the listed categories.
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 a single concise sentence that front-loads the action and lists the key return areas without redundancy or filler. Every word contributes to understanding the tool's purpose.
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, parameterless status tool, the description covers the essential content: configuration status, active model, and last image/video information. It could be slightly more complete by explicitly noting the operation is read-only and has no side effects, but the context is adequately covered for the tool's low complexity.
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?
The tool has zero parameters, so there are no parameter semantics to clarify. The description adds value by explaining what information the tool returns, which is more useful than the empty input schema alone. This matches the baseline for a parameterless tool.
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 ('Check') with a clear resource ('current configuration status, active model, and last image/video information'). It is immediately distinct from sibling tools that configure or generate content, so an agent can identify what this tool is for without inspecting other definitions.
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 context is implied by the verb 'Check' and the read-only subject matter, but the description does not explicitly state when to use this tool versus alternatives or mention exclusions. There is no direct guidance such as 'Use configure_model to change settings instead', though such guidance is not essential given the obvious distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.