Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@flickr-mcp list my albums"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English ｜ 繁體中文
Give Claude direct access to your Flickr — browse your photostream, pull direct image URLs for embedding, upload, and manage albums. A thin Model Context Protocol wrapper around Flickr's official API (OAuth 1.0a signed, read + write).
Status: 🟢 all 10 tools live-verified (6 read + 4 write) against a real
~1500-photo account. The first live upload test surfaced two real bugs in
upload_photo — an OAuth multipart-signing failure (401) and a non-ASCII
title signing crash — both now fixed (HMAC-SHA1 signed by hand, UTF-8 safe).
Read
whoami — verify auth succeeded (returns the logged-in user id / name)
list_albums — list your albums (photosets)
list_album_photos — list photos in an album (each with a ready-to-use 1024px URL)
search_photos — search (defaults to your own photos only)
get_photo_info — full metadata for one photo (title / description / tags / taken date / visibility / page URL)
get_photo_sizes — every available size with its direct source URL (the reliable source for embed URLs)
Write
upload_photo — upload a local image (private by default, nothing goes public by accident)
create_album — create an album (Flickr requires an existing photo as the cover)
add_photo_to_album — add a photo to an album
set_photo_meta — update a photo's title / description
delete_photo — permanently delete a photo (irreversible)
delete_album — delete an album (removes only the set; the photos stay in your photostream)
⚠️
delete_photo/delete_albumneeddeletepermission. If you authorized withwrite, re-runpython authorize.pyfor a fresh token (it now requests thedeletescope).
Related MCP server: WhatsApp MCP for macOS
git clone https://github.com/vulture-s/flickr-mcp.git
cd flickr-mcp
python -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txtCreate an app at https://www.flickr.com/services/apps/create/ (non-commercial is fine) and copy its Key and Secret.
Exchange them for an access token:
export FLICKR_API_KEY=your_key
export FLICKR_API_SECRET=your_secret
python authorize.pyOpen the printed URL → approve → paste the 9-digit code Flickr shows back into
the terminal. The script prints the four FLICKR_* variables.
Requests
writepermission (covers read + upload + album management). The script never writes to disk — you paste the tokens into your config yourself.
Use claude mcp add, or add to your MCP config JSON:
{
"mcpServers": {
"flickr": {
"command": "python",
"args": ["-m", "flickr_mcp.server"],
"cwd": "/absolute/path/to/flickr-mcp",
"env": {
"FLICKR_API_KEY": "...",
"FLICKR_API_SECRET": "...",
"FLICKR_OAUTH_TOKEN": "...",
"FLICKR_OAUTH_TOKEN_SECRET": "..."
}
}
}
}Once it's connected, ask Claude to run whoami to confirm auth works.
list_albums → find the album_id you want
list_album_photos or get_photo_sizes → get each photo's direct URL
Drop the URLs into your own HTML/CSS (images live on Flickr, you control the look)
Upload defaults to private: upload_photo's is_public defaults to False;
you must explicitly set it to go public.
Credentials never touch git: .env is gitignored; only .env.example is
tracked. Prefer passing the four vars via your MCP config's env block.
write perms exclude deletion: Flickr's write scope covers upload and
album management but not deleting photos — a test upload can only be removed
from the Flickr website. Think before you upload.
The OAuth token is long-lived; you won't need to re-run authorize.py unless
you revoke it in Flickr's account settings.
MIT — see LICENSE.
Add an existing photo to an existing album.
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | Yes | ||
| photo_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Add'. No information on idempotency, errors if photo already in album, or required permissions.
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?
Single sentence, extremely concise and front-loaded. Loses a point for being overly terse missing important details.
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?
Tool has 2 params, no annotations, but has output schema (not described). Minimal description leaves gaps for an AI agent to understand behavior and prerequisites.
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 has 0% description coverage. The description adds no info beyond parameter names. It does not explain what format or source of IDs is expected.
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 clearly states the action 'Add' and the resources 'existing photo' and 'existing album'. It distinguishes from siblings like 'upload_photo' (adds new photo) and 'create_album' (creates album).
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 on when to use this tool versus alternatives (e.g., 'upload_photo' then 'add_photo_to_album'). No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new album (photoset). Flickr requires an existing photo id to be the album cover (primary_photo_id). Returns the new album id.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| description | No | ||
| primary_photo_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the requirement that primary_photo_id must be an existing photo, which is a key behavioral constraint. However, it does not mention authentication, rate limits, or error handling.
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?
Two sentences, no wasted words, front-loaded with the action. Every sentence adds value.
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?
Output schema exists, so return info is partially covered. The description covers the key constraint but lacks details on error scenarios, permissions, and the 'description' parameter. Adequate but not complete.
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 coverage is 0%, so the description must compensate. It adds meaning for primary_photo_id (must be existing photo), but does not describe 'title' or 'description' parameters. Partial coverage leaves gaps.
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 clearly states the tool creates a new album (photoset), mentions the required primary photo id, and notes the return value. It distinguishes itself from sibling tools like delete_album and add_photo_to_album.
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 description does not explicitly state when to use this tool versus alternatives. It implies usage for creating albums but lacks guidance on prerequisites or comparisons with siblings like 'add_photo_to_album'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an album (photoset). Removes only the album — the photos it held are NOT deleted, they stay in your photostream. Needs 'delete' permission.
| Name | Required | Description | Default |
|---|---|---|---|
| album_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that only the album is removed and photos remain in the photostream, and that 'delete' permission is needed. This provides key behavioral context beyond the schema.
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 very concise (three sentences) and front-loaded with the main action. Every sentence adds value without redundancy.
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 only one parameter, no annotations, and an output schema present, the description covers the essential aspects: purpose, behavior, and permissions. It is complete enough for safe usage, though minor details like irreversibility could be added.
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 0% description coverage, so the description must compensate. However, it only implicitly associates album_id with an album (via 'Delete an album'), without adding explicit meaning about the string format, source, or usage beyond the schema title.
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 clearly states the action 'delete' and the resource 'album (photoset)', and it distinguishes from sibling tools like create_album and delete_photo by specifying that photos are not deleted.
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 description explains what happens to photos (not deleted) and the required permission ('delete'), which helps decide when to use this tool versus alternatives like delete_photo. It does not explicitly list when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a photo from Flickr. IRREVERSIBLE. Needs the token to carry 'delete' permission — re-run authorize.py if you only granted 'write'.
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and does well: 'Permanently delete' and 'IRREVERSIBLE' clarify the action's nature. It also mentions authentication requirements ('needs token to carry delete permission'), which is an important behavioral constraint. However, it does not disclose potential side-effects (e.g., removal from albums or sets) or error scenarios, so not exhaustive.
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 extremely concise: two sentences, no filler. The first sentence immediately states the action, the second adds critical irreversible and permission details. Every sentence earns its place, and key information is front-loaded.
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 the tool's simplicity (1 parameter, output schema exists), the description covers the essential: what it does, irreversibility, and permission required. It does not elaborate on return values, but output schema exists so that is handled. Missing a note on error handling (e.g., if photo_id invalid) but not strictly necessary. Overall, adequate for a straightforward delete operation.
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 1 parameter (photo_id) with 0% description coverage, meaning the schema itself provides no explanation. The description adds no information about the parameter beyond its implicit role. A description like 'ID of the photo to delete' would be minimal but acceptable. Instead, the parameter is entirely unexplained, failing to add value to the schema.
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 clearly states it permanently deletes a photo from Flickr. 'IRREVERSIBLE' emphasizes the action's finality, and 'delete' is a specific verb. Although it does not explicitly differentiate from sibling tools, the action is unique among the listed siblings (e.g., delete_album deletes an album, not a photo), so purpose is unmistakable.
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?
Specifies that the token must carry 'delete' permission, with actionable advice to re-run authorize.py if only 'write' was granted. This provides important context for when to use the tool. However, it does not discuss alternatives or conditions when not to use it (e.g., if photo is required elsewhere), so slightly lacking in explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full metadata for one photo: title, description, tags, dates, visibility, and the Flickr page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the returned fields but does not mention authentication requirements, rate limits, or error handling. Adequate for a simple read tool.
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?
Single sentence that is front-loaded with the tool's purpose ('Full metadata for one photo') and lists key fields. Every word adds value.
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?
With an output schema present, the description does not need to detail return structure. It covers the main use case and listed fields, though it omits edge cases or error scenarios.
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%, and the description does not explain the photo_id parameter beyond implying it identifies the photo. No format or source guidance is given.
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?
Clearly states it returns full metadata for one photo, listing specific fields (title, description, tags, etc.). Distinguishes from siblings like get_photo_sizes (sizes only) and search_photos (search).
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?
Implies usage for retrieving all metadata of a single photo, but does not explicitly state when not to use it or provide alternatives. However, context from sibling names helps differentiate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authoritative list of available sizes for a photo, each with its direct source URL and pixel dimensions. This is the reliable source for embed URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes output but does not disclose behavioral traits like permissions, side effects, or limitations beyond being 'authoritative'.
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?
Two sentences, front-loaded with key information, no wasted words. Every sentence adds value.
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?
Despite an output schema being present, the description lacks parameter documentation and usage nuances. For a simple tool with one param, it is minimally adequate but not fully complete.
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 only parameter 'photo_id' is not explained in the description. With 0% schema coverage, the description fails to add meaning beyond the schema's minimal type and required flag.
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 clearly states the tool returns an authoritative list of available sizes for a photo with direct source URLs and pixel dimensions, distinguishing it from siblings like get_photo_info.
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 description implies usage for obtaining embed URLs ('reliable source for embed URLs'), providing context for when to use it, but lacks explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List photos in an album. Each photo includes id, title, and a ready-to-use 1024px static URL for embedding.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| album_id | Yes | ||
| per_page | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the URL format (1024px static) which is helpful, but fails to disclose pagination behavior (page, per_page), ordering, or any constraints. The description adds some value but lacks important behavioral details.
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?
Two concise sentences: first states purpose, second adds return details. No unnecessary words. Front-loaded with the primary action.
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 3 parameters with pagination, the description omits pagination details. Output schema exists, so return fields are likely covered, but the description should mention that results are paginated and how to control it. Adequate but not complete.
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%, so the description must explain parameters. It does not describe 'album_id', 'page', or 'per_page' beyond what the schema provides. The description only covers return values, leaving parameter semantics unclear.
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 clearly states the verb 'List' and resource 'photos in an album', and specifies the returned fields (id, title, URL). It distinguishes from sibling tools like 'list_albums' (list albums) and 'search_photos' (search).
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: use to list photos in an album. No explicit when-to-use, when-not-to-use, or alternative tools mentioned. The description lacks guidance for differentiation from siblings like 'get_photo_info'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's albums (photosets): id, title, photo count, and primary photo id. Use list_album_photos to drill into one.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates this is a read-only operation (listing), but provides no details on pagination behavior, rate limits, or side effects. Without annotations, it partially carries the burden but misses some behavioral aspects like how page/per_page parameters affect results.
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?
Two concise sentences. The first sentence states the purpose and return fields; the second provides a usage hint. No redundant information, front-loaded with key action.
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?
The description covers the main purpose and return fields, and with an output schema present, it doesn't need to detail every return field. However, it omits mention of pagination even though the parameters imply it, which could be clarified for completeness.
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 coverage is 0% (no parameter descriptions), and the tool description does not mention the 'page' and 'per_page' parameters or explain how they control pagination. The description adds no value beyond the schema, leaving agents to infer meaning from parameter names alone.
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 clearly states the tool 'List the authenticated user's albums' with a specific verb and resource. It also differentiates from sibling tool 'list_album_photos' by noting it returns summary fields (id, title, photo count, primary photo id) and suggests using the sibling for drilling into a specific album.
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?
Provides guidance on when to use this tool versus the sibling 'list_album_photos' for drilling into an album's photos. However, it does not explicitly mention alternatives like 'search_photos' or discuss limitations, though the context is clear enough for a simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search photos. By default restricted to the authenticated user's own photos (mine_only). Provide text and/or comma-separated tags.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| tags | No | ||
| text | No | ||
| per_page | No | ||
| mine_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose pagination behavior, rate limits, idempotency, or whether the operation is read-only. The default mine_only behavior is mentioned, but other behavioral traits are missing.
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?
Two sentences, front-loaded with the action, no redundant information. Every sentence adds value.
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 5 parameters, 0% schema coverage, and no annotations, the description adequately covers search criteria but omits pagination details. Since an output schema exists (not shown), return values may be covered there, but pagination context is needed for correct usage.
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 coverage is 0%, so description must compensate. It adds meaning by stating tags are 'comma-separated' and mentions mine_only default. However, it does not describe 'page' or 'per_page' parameters, leaving gaps for the agent.
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 clearly states 'Search photos' and specifies the resource and action. It distinguishes from siblings like list_albums and list_album_photos by mentioning default scope (mine_only) and supported filters (text, tags).
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 description implies usage for searching photos by text/tags with a default mine_only restriction, but does not explicitly state when to use this versus alternatives like get_photo_info or list_album_photos. No guidance on when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a photo's title and/or description. Flickr's setMeta requires the title, so an existing title is fetched when only description is supplied.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| photo_id | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that Flickr's setMeta requires the title, prompting a fetch when only description is supplied, which is a key behavioral trait. However, it lacks details on permissions, idempotency, or return behavior.
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 sentences with no fluff. The first sentence states the core purpose, and the second adds a crucial behavioral note. Every word earns its place.
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 the tool's simplicity and the presence of an output schema, the description covers the essential behavioral nuance (title fetch). It is sufficient for an agent to use the tool correctly, but lacks any mention of errors or prerequisites beyond the required parameter.
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 schema has 0% description coverage, so the description must compensate. It clarifies that title and/or description can be updated, adding meaning beyond the schema's nullable defaults. However, it provides no further constraints or formats, leaving some ambiguity.
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 clearly states 'Update a photo's title and/or description,' identifying the specific action and resource. This distinguishes it from siblings like get_photo_info and delete_photo, which serve different purposes.
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 description implies usage for updating metadata and explains the behavior when only description is supplied, but it does not explicitly state when to use this tool versus alternatives or provide preconditions beyond the required photo_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local image file to Flickr. Defaults to PRIVATE so nothing goes public by accident. Returns the new photo id.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | No | ||
| is_public | No | ||
| photo_path | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the upload action, privacy default, and return of photo id, but omits behavioral details such as whether existing photos are overwritten, file size/format limits, or authentication needs. It provides some transparency but not comprehensive.
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?
Two sentences, no redundancy, efficient. The key behavioral traits (default private) and return value are front-loaded. Every word adds value.
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 5 parameters, 0% schema coverage, and no annotations, the description is somewhat sparse. It covers the required parameter and one optional (is_public) but leaves others unexplained. An output schema exists, so return value note suffices. Overall, it is adequate but not comprehensive.
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 coverage is 0%, so description must supplement. It explains the is_public parameter via the privacy default, and implicitly the photo_path as the file to upload. However, it gives no details for tags, title, or description beyond the parameter names. Partial compensation but sufficient for core usage.
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 clearly states the action (upload), the target (a local image file to Flickr), and distinguishes from sibling tools which are about listing, searching, or managing albums. It also notes the privacy default and return value, making the purpose highly specific.
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 description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that it should be used to add new photos, nor does it contrast with sibling tools like set_photo_meta or delete_photo. Usage context is only implied by the privacy default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify credentials by calling flickr.test.login. Returns the logged-in user's id and username, or a clear error if auth is not set up.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns credentials on success or a clear error if auth fails. This is transparent about its read-only, validation-like nature.
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?
Two sentences, no redundant words. Front-loaded with the action 'Verify credentials'. Every sentence adds value.
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 no parameters, an output schema exists (not shown but assumed), and the description covers what the tool does, returns, and error behavior. No gaps.
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 schema has 0 parameters, so schema coverage is 100%. Baseline is 4, and the description adds no parameter info (none needed).
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 clearly states the tool's purpose: 'Verify credentials' via flickr.test.login, and explicitly lists the return values (user id and username) and error condition. This distinguishes it from all sibling tools, which deal with photos and albums.
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 description implies the tool should be used to check authentication status, but does not explicitly state when to use it versus alternatives. Given sibling tools are all for content operations, the usage context is clear but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_photo_to_albumcreate_albumdelete_albumdelete_photoget_photo_infoget_photo_sizeslist_album_photoslist_albumssearch_photosset_photo_metaupload_photowhoamiScored across 12 tools
Each tool targets a distinct resource and action: auth, albums, album photos, search, photo metadata, sizes, upload, album creation, album membership, metadata update, and deletions. Even similarly named tools like get_photo_info and get_photo_sizes are clearly separated by their descriptions.
The vast majority of tools follow a clear verb_noun snake_case pattern such as list_albums, upload_photo, and delete_album. The only real deviation is whoami, which is a conventional auth command but not a verb_noun name.
Twelve tools is a well-scoped size for a Flickr server covering auth, photo operations, and album operations. Each tool has a clear purpose and none feel redundant or excessive.
The photo lifecycle is well covered with upload, read, update, and delete, plus size and metadata retrieval. Album coverage has meaningful gaps: no album metadata update and no way to remove a photo from an album, though the core album workflow is still usable.
Holiday photo MCP server: list and fetch personal holiday photos inline in Claude chat.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Give Claude only the Google Drive files you choose. Every action logged.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
