Artwork credits, figure captions and Chicago, MLA and APA citations in English and Ukrainian.
Scored across 3 tools
Each tool has a clearly distinct purpose: capability discovery, artwork URL resolution, and citation generation. There is no meaningful overlap, and the resolve_artwork description explicitly warns it is not a search tool.
All tool names follow the same pattern: a consistent still_ prefix plus an action_noun snake_case verb phrase. generate_citation, get_capabilities, and resolve_artwork are uniformly readable and predictable.
Three tools is an appropriate size for this focused server. Each tool covers a distinct capability and none feel redundant, unnecessary, or missing from the core stated scope.
The tool set supports capability discovery, artwork metadata retrieval, and citation generation, covering the primary workflow without dead ends. Gaps like artwork search, calculator features, and broader museum coverage are acknowledged limitations rather than accidental omissions.
Format website/social credits, figure captions, Chicago 18, MLA 9 or APA 7 using the same engine as the STILL website. Supply exactly one of record or supported sourceUrl. One academic style per call. Preserve warnings and separate sourceRecommendedCitation. No image-use permission is granted.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Required for academic outputs: Chicago 18, MLA 9, APA 7. One style per call. | |
| locale | No | Formatting locale; does not translate source metadata. | en |
| record | No | Supplied metadata; use exactly one of record or sourceUrl. | |
| target | No | artwork | |
| outputs | Yes | Credit outputs: website_credit, social_credit, figure_caption. Academic: bibliography, full_note (Chicago only), in_text (MLA/APA only). | |
| sourceUrl | No | Fetch an artwork record from The Met or Cleveland. Use record for other sources or museum_page targets. | |
| provenance | No | Original provenance returned by still_resolve_artwork. Pass it unchanged with record to preserve source and UTC observation evidence. |
| Name | Required | Description |
|---|---|---|
| record | Yes | |
| status | Yes | |
| toolId | Yes | |
| results | Yes | |
| version | Yes | |
| provenance | Yes | |
| schemaVersion | Yes | |
| generatedAtUtc | Yes | |
| sourceRecommendedCitation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, openWorld, idempotent, and non-destructive hints. The description adds meaningful behavioral context: 'Preserve warnings and separate sourceRecommendedCitation' and 'No image-use permission is granted'. These go beyond the annotations and clarify output handling and legal caveats.
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?
Four sentences with no filler. Purpose is front-loaded, followed by input mode, style constraint, and behavioral caveats. Every sentence 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 high schema coverage and annotations, the description captures the essential operational constraints: exclusive input, style limit, preservation, and rights disclaimer. Output schema exists, so return values need no description. The still_resolve_artwork workflow is implied via the provenance field in the schema, so no gap is significant.
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 86%, so the schema does the heavy lifting. The description restates the mutual exclusivity of record/sourceUrl and the one-style-per-call rule, both already present in the schema. It does not add new parameter-level meaning beyond the schema, so a baseline of 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 states a specific action ('Format'), resource ('website/social credits, figure captions, Chicago 18, MLA 9 or APA 7'), and a distinguishing trait ('using the same engine as the STILL website'). It is clearly distinct from siblings still_get_capabilities and still_resolve_artwork.
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 explicit call constraints: 'Supply exactly one of record or supported sourceUrl' and 'One academic style per call'. It also notes the engine context. It doesn't explicitly name alternatives or exclusion conditions, but the schema's provenance field and sibling names make the workflow evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover currently connected STILL modules, supported formats, locales and limitations. Search and calculators are not available yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds meaningful behavioral context: results reflect 'currently connected' modules (implying dynamic state), and it openly states limitations (search/calculators unavailable). This goes beyond what annotations provide.
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 total: the first delivers the core purpose, the second scopes expectations with the limitation note. No fluff, no redundant detail, and the most important 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?
For a zero-parameter, read-only capability discovery tool, this description is sufficient. It states what will be returned (modules, formats, locales, limitations) and what is explicitly not yet available. The lack of an output schema is acceptable because the description already sets expectations.
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 tool has zero parameters and the schema is an empty object. The description needs no parameter explanation, and the baseline for 0-parameter tools is 4. Nothing is left undocumented.
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 the specific verb 'Discover' and names the resource: connected STILL modules, supported formats, locales, and limitations. It clearly differentiates from sibling tools like still_generate_citation and still_resolve_artwork, which perform actions rather than report capabilities.
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 clear context: use this tool to learn what modules, formats, and locales are available before invoking other STILL tools. It also pre-empts misuse by stating that search and calculators are not available yet. It does not explicitly name alternatives, but the sibling tools are distinct enough that the usage context is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a known artwork URL from The Met or Cleveland Museum of Art. Not artwork search. Returns source metadata and exact UTC observation time. Source statements are not legal clearance. Use manual record input for other museums.
| Name | Required | Description | Default |
|---|---|---|---|
| sourceUrl | Yes |
| Name | Required | Description |
|---|---|---|
| record | Yes | |
| status | Yes | |
| provenance | Yes | |
| schemaVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent hints, so the bar is lower. The description adds context about returning source metadata and exact UTC observation time, which is valuable. It also warns that source statements are not legal clearance, a non-obvious caveat. Lacks detail on rate limits or error handling but combined with annotations, this is above average.
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?
Three sentences, each packed with unique value: action and scope, disambiguation from search, output characteristics, legal caveat, and alternative routing. No fluff, front-loaded with the core action. Exceptional efficiency.
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 a single parameter, an output schema, and supportive annotations, the description covers most essential aspects. It clarifies the source limitation, the output nature, and the non-legal status. Minor gaps include typical error cases or what happens if the URL is unknown, but overall it's quite complete for its 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?
With schema description coverage at 0%, the description must compensate. It defines 'sourceUrl' implicitly as the URL to retrieve, but doesn't specify format or constraints beyond the schema's maxLength. The description mentions 'known artwork URL', adding some meaning, but detailed semantics are limited. Baseline 3 is appropriate as the description provides minimal enrichment over 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 retrieves a known artwork URL from specific museums and explicitly distinguishes it from search ('Not artwork search'). It names the resource (artwork record) and the supported sources, making its 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?
It explicitly says when to use (known URL from The Met or Cleveland Museum of Art) and when not (not search, not legal clearance, use manual record input for other museums). This provides both positive and negative usage contexts, far above typical descriptions.
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.
still_generate_citation1 field changedInput schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "description": "Original provenance returned by still_resolve_artwork. Pass it unchanged with record to preserve source and UTC observation evidence.",
+ "properties": {
+ "metadataFetchedAtUtc": {
+ "type": "string"
+ },
+ "method": {
+ "enum": [
+ "supplied_metadata",
+ "source_api"
+ ],
+ "type": "string"
+ },
+ "objectId": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "rawRights": {},
+ "rightsCheckedAtUtc": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "type": "string"
+ },
+ "sourceUrl": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "sourceUrl",
+ "rightsCheckedAtUtc"
+ ],
+ "type": "object"
+}still_generate_citation1 field changedInput schema / properties / provenanceRemoved value: -{
- "additionalProperties": false,
- "description": "Original provenance returned by still_resolve_artwork. Pass it unchanged with record to preserve source and UTC observation evidence.",
- "properties": {
- "metadataFetchedAtUtc": {
- "type": "string"
- },
- "method": {
- "enum": [
- "supplied_metadata",
- "source_api"
- ],
- "type": "string"
- },
- "objectId": {
- "type": "string"
- },
- "provider": {
- "type": "string"
- },
- "rawRights": {},
- "rightsCheckedAtUtc": {
- "type": [
- "string",
- "null"
- ]
- },
- "scope": {
- "type": "string"
- },
- "sourceUrl": {
- "type": "string"
- }
- },
- "required": [
- "method",
- "sourceUrl",
- "rightsCheckedAtUtc"
- ],
- "type": "object"
-}still_generate_citation1 field changedInput schema / properties / provenanceAdded value: +{
+ "additionalProperties": false,
+ "description": "Original provenance returned by still_resolve_artwork. Pass it unchanged with record to preserve source and UTC observation evidence.",
+ "properties": {
+ "metadataFetchedAtUtc": {
+ "type": "string"
+ },
+ "method": {
+ "enum": [
+ "supplied_metadata",
+ "source_api"
+ ],
+ "type": "string"
+ },
+ "objectId": {
+ "type": "string"
+ },
+ "provider": {
+ "type": "string"
+ },
+ "rawRights": {},
+ "rightsCheckedAtUtc": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "type": "string"
+ },
+ "sourceUrl": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "method",
+ "sourceUrl",
+ "rightsCheckedAtUtc"
+ ],
+ "type": "object"
+}still_generate_citationstill_get_capabilitiesstill_resolve_artworkMET Museum collection via MCP — 500K+ artworks, metadata, provenance, open-access images.
Digital-crisis playbooks as tools, 9 languages, country-anchored reporting channels. CC BY 4.0.
Add one secure layer between your agents and this server.