Skip to main content
Glama

Shared link login

immich_shared_link_login

Authenticate to a password-protected Immich shared link by submitting its key or slug and password, enabling access to the shared content.

Instructions

Shared link login

Login to a password protected shared link

Immich operation: POST /shared-links/login · tag: Shared links

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNo
slugNo
passwordYespassword (request body)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the write/non-idempotent profile is covered. The description adds essentially nothing behavioral beyond the annotation set: it does not say what a successful login yields (session/token), whether it can fail on wrong password, or any rate-limit/auth behavior. With annotations carrying the safety profile, the description still leaves the operation's effect opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short and front-loads the operation, but the first line simply repeats the title and the second restates the same idea, so two of three lines are redundant. The Immich operation/endpoint line is useful metadata and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and the description never explains what the login returns or how the caller should use it, which matters for an authentication step. Combined with 33% parameter coverage and a non-idempotent write operation, the definition is not complete enough for an agent to invoke it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%: key and slug are undocumented in both schema and description, and the description explains none of the three parameters. It does not clarify the relationship between key and slug or that password is required, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (login) and resource (password protected shared link), which is more precise than the bare title. It implicitly distinguishes itself from the account-level immich_login and the shared-link CRUD siblings, though it never names them. Purpose is clear without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisite context (e.g. that you must already hold the link key/slug), and no alternatives named. The only usage signal is the implied condition that the link is password protected, which is closer to restated purpose than guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools