Polish Academic MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the repository size and output format, but lacks critical behavioral details: whether this is a read-only operation, any rate limits, authentication requirements, pagination behavior beyond the 'start' parameter, or error handling. The description doesn't contradict annotations (none exist), but provides minimal behavioral context for a search 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?

The description is efficiently structured in two sentences: first establishes the search scope and repository context, second specifies output format. Every element (repository name, dataset count, DOI prefix, return format) serves a clear purpose with zero redundant information. It's appropriately sized for a search tool.

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 annotations and no output schema, the description provides basic context about the repository scope and output format, but lacks sufficient detail for a search tool. It doesn't explain the search algorithm's behavior, result ordering, error cases, or what 'relevance scores' mean. The description is complete enough to understand what the tool accesses, but not how it behaves during execution.

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 the schema fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., how the 'query' parameter interacts with the repository's search algorithm, what 'type' restriction means in practice). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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 with specific verb ('Search') and resource ('open research datasets in RePOD'), including the repository's full name and affiliation. It distinguishes from siblings by specifying the unique content scope (~3,737 datasets with DOIs under 10.18150/ prefix) and output format (JSON with relevance scores, authors, descriptions, publication dates).

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 explicit guidance on when to use this tool versus alternatives is provided. While the description mentions the repository scope, it doesn't clarify when to choose repod_search over sibling tools like repod_get_dataset or other search tools (e.g., icm_search, rcin_search) that might access different datasets. No prerequisites or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.