recentMost recent public uploads, optionally tag-filtered.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Comma-sep tags, e.g. "sunset,beach" | |
| limit | No | 1-20 (Flickr caps the feed at 20). | |
| tagmode | No | all | any (default all) |
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Array of photo items from the feed | |
| title | No | Feed title from Flickr |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "limit": 10,
+ "tagmode": "all",
+ "tags": "sunset,beach"
+ },
+ {
+ "limit": 20,
+ "tags": "landscape"
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "items": {
+ "description": "Array of photo items from the feed",
+ "items": {
+ "description": "Photo item object",
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "description": "Feed title from Flickr",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds the 'public uploads' scope and tag-filtering behavior, but does not disclose additional details like pagination limits or time windows. With annotations carrying safety, a 3 is appropriate.
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, efficient sentence: 'Most recent public uploads, optionally tag-filtered.' It is front-loaded with the core purpose and every word contributes value. No 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?
This is a simple read-only feed tool with only three optional parameters, full schema documentation, a defined output schema, and comprehensive annotations. The brief description is adequate for understanding the tool's basic behavior, though it could mention the 'public' scope more explicitly. Given the low complexity and rich structured metadata, the completeness is high.
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 100% with each parameter documented (tags, limit, tagmode) and examples. The description adds the concept of 'tag-filtered' which maps to tags/tagmode, but provides no additional meaning beyond what the schema already offers. Baseline 3 applies.
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 'most recent public uploads' with optional tag filtering. This is a specific verb+resource+scope construction that distinguishes it from siblings like by_user and by_group, which filter by user/group rather than recency.
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 provides no explicit guidance on when to use this tool versus alternatives. It implies usage (when you want recent public uploads) but does not name alternatives or state when not to use it, such as when user/group-specific uploads are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tool set is extremely confusing because the server name 'Flickr Public' suggests a photo-sharing focus, but the vast majority of tools are for financial data, prediction markets, and other unrelated domains. Only 3 out of 33 tools are about Flickr, making it nearly impossible for an agent to understand the server's purpose or select appropriate tools.
Tool names are all in snake_case, which is consistent, but there is no semantic pattern across the set. Verbs vary widely (ask, bet, by, compare, deep, discover, etc.) and many tools have descriptive but overly long names, mixing different styles. The lack of a common naming framework adds to the confusion.
With 33 tools, the count is far too high for a server that should be about Flickr. The scope is massively overextended, covering multiple unrelated domains like SEC filings, Polymarket betting, and drug data. This mismatch makes the tool count feel bloated and inappropriate for the server's stated purpose.
For a Flickr server, the tool surface is severely incomplete. It only offers basic read operations (by_group, by_user, recent) and lacks core Flickr functionality such as uploading, editing, searching photos, or managing albums. The addition of hundreds of unrelated tools does not compensate for this gap, leaving the server's primary domain largely unaddressed.