Read-only MCP server over the JENRIKS daily photoblog: one photo per day since 2006. No auth.
Scored across 5 tools
Each tool targets a distinct retrieval mode: latest photo, specific photo by date/path, site overview stats, random selection, and search. No overlap in their primary functions, despite random and search both supporting filters; descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern (get_latest_photo, get_photo, get_site_overview, random_photo, search_photos), using snake_case throughout. The verbs clearly indicate the action (get, random, search), making the naming predictable and intuitive.
With only 5 tools, the server is lean and focused, covering retrieval, search, browsing, and overview. The scope fits a single-purpose photo archive server; no bloat or redundancy.
The surface covers primary needs: browsing by latest/specific/random, searching, and site overview. Minor gaps exist, such as no tool for fetching photos by category directly (though search can filter), and no pagination for lists like latest, but these are workable via search/cursor.
Return today's JENRIKS photo (the newest post), or the newest post by one photographer when photographer is set. A new photo appears every day at 00:00 Europe/Berlin.
| Name | Required | Description | Default |
|---|---|---|---|
| photographer | No | Latest post by this photographer; omit for the newest post overall |
| Name | Required | Description |
|---|---|---|
| photo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavior beyond annotations: the daily publication cadence, the exact timezone (Europe/Berlin), and the 'newest post' selection rule. No contradiction.
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 with no wasted words: the core return value is front-loaded, followed by the optional filter and the update schedule. Every sentence adds necessary context.
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 read-only tool with one optional enum parameter and an output schema, the description is nearly complete: it explains selection logic and update timing. It only lacks explicit routing relative to sibling tools, but that is a minor gap given the tool's simplicity.
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 100% and the single photographer parameter is already documented with an enum and explanation. The description mostly restates the photographer condition without adding new syntax or format detail, so baseline 3 is appropriate.
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 uses a specific verb ('Return') and a specific resource ('today's JENRIKS photo / the newest post'), and the photographer condition further clarifies scope. It is clear on its own but does not explicitly differentiate itself from siblings like get_photo or search_photos.
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 main use case: retrieve the newest/daily photo, optionally filtered by photographer. It does not name alternatives or state when not to use this tool, so guidance is present but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one JENRIKS post by publication date (YYYY-MM-DD) or by page URL / path (/YYYY/MM/DD/slug/).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Page URL or path, e.g. /2026/09/04/liminal-space/ | |
| date | No | YYYY-MM-DD |
| Name | Required | Description |
|---|---|---|
| url | No | |
| date | No | |
| hint | No | |
| found | Yes | |
| photo | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds the return type (one JENRIKS post) and lookup modes, but does not disclose what happens if neither parameter is provided, which is a gap given both are optional in 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?
A single, front-loaded sentence that states the purpose and the two lookup modes with no wasted words. It is concise and to the point.
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 output schema exists, so return values are covered. However, the description does not clarify that exactly one of date or url should be provided, nor what happens if both are given or none are given. This is a minor but real completeness gap for a tool with optional parameters.
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 100%, so baseline is 3. The description repeats the date format and URL example, but the schema already documents these clearly. No additional meaning is added beyond what the schema provides.
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 one JENRIKS post and specifies two lookup methods (date or URL/path). It distinguishes from siblings like get_latest_photo and random_photo by focusing on a single post with known identifiers, though it does not explicitly name the alternatives.
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 when to use the tool: when you have a publication date or a page URL/path. However, it gives no explicit guidance on when NOT to use it or when to prefer siblings like search_photos or get_latest_photo. The optional nature of both parameters is left ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Totals, photographers, categories with counts, posts per year, section URLs, URL pattern and license terms. Pass include to keep only some of those blocks next to the totals and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Blocks to keep besides site, description, totals and dates; omit for everything |
| Name | Required | Description |
|---|---|---|
| site | Yes | |
| years | Yes | |
| license | Yes | |
| sections | Yes | |
| categories | Yes | |
| first_date | Yes | |
| description | Yes | |
| latest_date | Yes | |
| url_pattern | Yes | |
| total_photos | Yes | |
| photographers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by listing the return blocks and explaining how the include parameter filters them, which is useful beyond the annotations. No contradictions exist.
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 with zero waste. The first sentence front-loads the primary content (what the tool returns), and the second explains the optional parameter. 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 low complexity (one optional parameter), the presence of an output schema (so return format is documented elsewhere), and annotations covering safety, the description is complete. An agent can call this tool correctly without missing information.
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% for the only parameter (include), with a clear description of its enum values and default behavior. The description's sentence about include essentially restates the schema ('Pass include to keep only some of those blocks') without adding new meaning. Per the rubric, baseline 3 applies when the schema does the heavy lifting.
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 resource (site overview) and enumerates the content blocks (totals, photographers, categories, years, sections, license). It is specific and unambiguous, and the name + description make it distinct from the photo-focused sibling tools (get_photo, search_photos, etc.).
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 implicitly signals usage context by focusing on site-wide statistics, which contrasts with the photo-specific siblings. However, it does not explicitly state 'use this for site overview, not individual photos' or mention any exclusions. The context is clear enough for an agent to route correctly, but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a random JENRIKS photo, optionally limited to a photographer, category or year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| category | No | ||
| photographer | No |
| Name | Required | Description |
|---|---|---|
| hint | No | |
| found | Yes | |
| photo | No | |
| pool_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the context that the result is randomly selected and scoped to JENRIKS photos, which aligns with idempotentHint=false. It does not disclose edge-case behavior such as what happens when no photo matches the optional filters, but given the annotations, the description provides adequate additional context.
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 front-loaded sentence with no redundant words. It leads with the action and resource, then immediately lists the optional modifiers. Every word serves a purpose, making it easy for an agent to parse quickly.
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 and read-only annotations covering safety, the description does not need to explain return values or mutation risks. The main gaps are the lack of guidance on when to use this tool versus search_photos/get_photo, and ambiguity about whether filters combine or are mutually exclusive. These are noticeable but not critical for a simple random-photo tool.
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 compensate for parameter meaning. It does mention all three parameters by name ('photographer, category or year') and marks them as optional, but it adds no value about accepted values, constraints, or how filters combine. The schema already shows the photographer enum and year minimum, and category remains unexplained in both schema and description.
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 a specific verb and resource: 'Return a random JENRIKS photo'. The word 'random' directly differentiates this tool from siblings like get_latest_photo, get_photo, and search_photos, which imply deterministic or filtered retrieval. It also names the optional filtering dimensions (photographer, category, year), making the tool's purpose 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?
The phrase 'random JENRIKS photo' implies the tool is for exploratory or arbitrary selection, and 'optionally limited' tells the agent filters can be applied. However, it gives no explicit guidance on when to choose this tool over the sibling tools, such as search_photos or get_latest_photo, and does not state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the JENRIKS archive (one photo per day since 2006). Free-text query matches title, place, categories, tags and photographer; filters narrow by photographer, category, year and location. Returns permanent page URLs, credits, coordinates and image URLs, newest first. Page with offset, or with the opaque cursor from next_cursor (cursor wins when both are sent).
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Four-digit publication year | |
| limit | No | ||
| query | No | Free text, e.g. "harbour", "Barcelona", "fog" | |
| cursor | No | Opaque page token from next_cursor; overrides offset | |
| offset | No | ||
| category | No | One of: Abstract, Architecture, B&W, Humans, Landscapes, Macro, Nature, News, Street, Studio, Time exposure | |
| location | No | City or country name, e.g. "Iceland" | |
| photographer | No |
| Name | Required | Description |
|---|---|---|
| links | No | |
| cursor | No | Echo of the cursor this page was fetched with, when one was sent |
| offset | Yes | Offset of the first returned row; 0 when a cursor was used |
| photos | Yes | |
| has_more | Yes | True when another page exists |
| returned | Yes | |
| next_cursor | Yes | Opaque token for the next page; null on the last page. Send it back as cursor. |
| next_offset | No | Kept for offset paging; present when more matches exist |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, and the description adds substantial behavioral detail: match fields, return contents, newest-first ordering, permanent URLs, and the precise cursor/offset precedence rule. This is beyond what annotations alone convey and helps an agent predict results and pagination 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 short and information-dense. Each sentence adds value: scope of the archive, query/filter capabilities, result contents and ordering, and pagination. It is front-loaded with the core purpose and contains no filler.
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 search tool with 8 optional parameters, an output schema, and safety annotations already present, the description covers the essential semantics: what is searched, what can be filtered, what the results look like, and how paging works. The only notable omission is a direct mention of the limit parameter, but that is partially covered by the schema.
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 63% and the description compensates by defining query behavior (matches title, place, categories, tags, photographer), the role of filters, and the cursor/offset relationship. It does not explicitly mention the limit parameter, but the existing schema exposes default/max values, so the added semantics are still meaningful.
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 uses a specific verb ('Search'), a named resource ('JENRIKS archive'), and describes what the query matches and how filters narrow. It clearly differentiates the tool from siblings like get_latest_photo and random_photo, which are singular or random rather than archive-wide 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?
The context is clear: use this tool when you need to search or filter the archive, and the description explains the query/filter options and pagination. It does not explicitly contrast with siblings like get_latest_photo or get_photo, but the search-oriented purpose and wording provide adequate guidance.
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.
get_latest_photoget_photoget_site_overviewrandom_photosearch_photosAgent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Read-only MCP server exposing a user ORANO library to their own AI agent.
Public MCP server for summaries, DNS lookup, catalog, replies, and JSON checks.
Add one secure layer between your agents and this server.
