get_departmentsReturn the full list of Metropolitan Museum of Art curatorial departments (e.g., 'Egyptian Art', 'Modern and Contemporary Art'), each with its numeric department ID.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | Total number of departments | |
| departments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds the behavioral nuance of returning the 'full list' (implying no pagination), but otherwise focuses on return content rather than deeper behavioral traits like ordering or limits.
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 immediately states the action and resource. Every word adds value—no filler, 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?
For a zero-parameter, read-only list tool with rich annotations and an output schema, the description is fully adequate. It includes the institution (Metropolitan Museum of Art), the entity type (curatorial departments), and the return format (numeric ID), leaving no essential gap.
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 zero parameters, schema coverage is trivially 100% and there is no parameter semantic burden. The description adds a helpful example of department names, which is the kind of contextual enrichment expected for a parameterless tool.
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'), names the resource ('full list of Metropolitan Museum of Art curatorial departments'), and provides examples plus the output format (numeric department ID). This clearly distinguishes it from sibling tools like get_artwork or search_artworks.
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 tells an agent when to use this tool: whenever a complete list of Met department IDs/names is needed. It does not explicitly mention alternatives or exclusions, but the context is clear enough given sibling names and the straightforward purpose.
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.
Tools are a mix of art-related and Pipeworx data tools, with no clear boundary. Many Pipeworx tools overlap in functionality (e.g., ask_pipeworx, deep_research, bet_research), causing confusion. Art tools are distinct but sparse.
Tool names mostly use snake_case but follow inconsistent patterns: some are verb-based (ask_pipeworx, search_artworks), others are noun-based (entity_profile, pipeworx_feedback). There is no unified convention across the server.
33 tools is excessive for an art-focused server; only 4 tools (search_artworks, get_artwork, get_departments, generate_llms_txt) relate to art. The rest are from a different domain (Pipeworx), creating a severe scope mismatch.
For the art domain, only basic search and retrieval are provided; missing browsing, filtering, or creation tools. The Pipeworx tools are comprehensive but irrelevant to the server's stated purpose, leaving the art surface incomplete.