Check the login endpoint to verify authentication status or access the login page for Prowlarr, enabling users to confirm or initiate secure access.
Read StaticResource.
GET /login
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, and the description's 'Read' is consistent. However, the description adds no behavioral details beyond what annotations already communicate – no auth requirements, no side effects, no rate limits, and no context about output. It earns credit only for not contradicting 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 two short lines with no filler or redundant phrasing. 'Read StaticResource' and 'GET /login' are both compact, and the content is front-loaded. It is concise, though the ambiguity of 'StaticResource' means it is not as useful as it could be at the same length.
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?
Given that an output schema exists and there are no parameters, the description does not need to explain return values, but it still leaves the core purpose vague. An agent cannot tell whether this is a health check, a login page fetch, or a resource listing. The phrase 'StaticResource' is undefined and does not resolve the ambiguity, making the description incomplete for reliable selection.
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 input schema has zero properties and schema description coverage is 100%, so there are no parameter semantics to add. The baseline for a zero-parameter tool is 4, and the description correctly avoids inventing parameter details.
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?
Description states 'Read StaticResource' and 'GET /login' but does not define what StaticResource refers to or what the response represents. The tool name 'list_login' suggests login-related data, but the description doesn't clarify whether this returns a login page, a session check, or a static asset list. It does not distinguish itself from sibling tools like list_logout or list_api.
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 guidance is provided about when to call this tool versus any alternative, no mention of login flow prerequisites, and no exclusions. The description merely combines a vague verb with an HTTP route, leaving the decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.