InspireHEP MCP Server

Search by Collaboration

search_by_collaboration

Read-onlyIdempotent

Retrieve publications from a named experimental collaboration, with options for sorting by recency or citations and filtering by year.

Instructions

Find publications from a specific experimental collaboration.

Handles common name variations (e.g. "lhcb" → "LHCb").

Args: collaboration_name: Collaboration name (e.g. "ATLAS", "CMS", "LHCb", "Belle-II"). sort: Sort order — "mostrecent" or "mostcited". size: Number of results to return (1–100, default 20). year: Optional year filter (e.g. 2024).

Returns publication list, year distribution, total citations, and top-cited papers from the returned set.

Input Schema

TableJSON Schema

Name	Required	Default
`size`	No
`sort`	No	mostrecent
`year`	No
`collaboration_name`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.3.0Sep 8, 2026

addedOutput schema / additionalProperties
```
Added value: +true
```

removedOutput schema / properties

Removed value: -{
-  "result": {
-    "title": "Result",
-    "type": "string"
-  }
-}

removedOutput schema / required
```
Removed value: -[
-  "result"
-]
```

changedOutput schema / title

Previous value: -"search_by_collaborationOutput"New value: +"search_by_collaborationDictOutput"

First observedv0.1.4Jun 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The readOnlyHint and idempotentHint already cover safety characteristics, and the description goes beyond by noting normalization behavior and the returned set (publication list, year distribution, total citations, top-cited papers). This gives the agent a good sense of what to expect without needing to infer from schema alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. The parameter list is concise, each line adding meaningful detail without unnecessary verbosity or restating obvious type information already in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the primary input parameters and the expected return contents, which is sufficient for a read-only search tool. It does not mention error cases or pagination, but given the output schema is present and the operation is straightforward, this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the schema has no parameter descriptions, the description compensates thoroughly by documenting all four parameters. It adds concrete examples for collaboration_name, valid sort values, the size range (1–100), and the optional nature of year, providing meaning well beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Find publications from a specific experimental collaboration', identifying both the action and the resource scope. It does not explicitly name a sibling tool to contrast with, but the collaboration-specific scope distinguishes it from general search or author-based tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to use this tool versus alternatives like search_papers or get_author_papers. The normalization example ('lhcb' → 'LHCb') hints at one use case, but there is no clear when-to-use/when-not-to-use direction.

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

Deploy Server