nuvio_inspect_addonFetch and summarize a Stremio/Nuvio addon manifest, displaying name, version, resources, and catalog types before installation to inform your install decision.
Fetch and summarise a Stremio/Nuvio addon manifest (name, version, resources, catalog types) before installing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, open-world, and idempotent, so the description is not required to restate safety guarantees. It adds useful detail about what is retrieved and summarized, though it does not address potential network failures or invalid manifest behavior. The description does not contradict the annotations.
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, well-structured sentence that front-loads the action and purpose, then compactly lists the returned information. There is no redundant filler, and every part contributes to understanding the tool.
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 read-only tool with one parameter and no output schema, the description covers the purpose, the input, and the key contents of the output. It does not describe failure modes or exact response formatting, but these are not critical for a straightforward inspection tool whose safety profile is covered by annotations.
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%, but there is only one parameter, 'url', which is self-explanatory and has a URI format. The description implies the URL points to the addon manifest, adding a little semantic context, but it could more explicitly state what kind of URL is expected and whether it should be a manifest endpoint.
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 specific action ('Fetch and summarise'), a clear resource ('Stremio/Nuvio addon manifest'), and enumerates the summary contents (name, version, resources, catalog types). It distinguishes itself from sibling tools like nuvio_add_addon or nuvio_list_addons by framing this as pre-install inspection.
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?
The phrase 'before installing' gives a clear context for when this tool should be used, distinguishing it from installation or management operations. It does not explicitly mention alternatives or state when not to use it, but the intended usage is still evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.