This server lets LLMs interact with XRootD file systems through MCP tools for browsing, reading, searching, analyzing, and monitoring files and datasets.
File operations: list directories, read files with byte ranges, get metadata, check existence, and calculate directory sizes.
Search & filtering: find files by glob or regex, filter by size/extension/date/name, and locate recently modified files.
Statistics & analytics: get directory statistics and aggregate usage reports.
Campaign & dataset discovery: list production campaigns, datasets, and summarize recent file additions.
ROOT file analysis: inspect ROOT file structure, extract Podio metadata, get event/collection statistics, aggregate stats across datasets, and fill branch histograms with optional cuts.
Multi-server support: choose among multiple configured XRootD servers via a server parameter.
Flexible access: prefers HTTP-based ROOT reading and can fall back to xrdcp copying when needed.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@XRootD MCP Server list the available production campaigns and recent datasets"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to XRootD file systems. This server allows LLMs to interact with XRootD servers to list directories, read file metadata, access file contents, and more.
List directories: Browse XRootD file system hierarchy
File metadata: Get detailed information about files (size, modification time, permissions)
Read file contents: Access file data from XRootD servers with byte-range support
File operations: Check file existence, calculate directory sizes
Search & filtering: Find files by pattern (glob/regex), filter by size/date
Statistics & analytics: Comprehensive directory statistics and usage reports
Campaign discovery: List available production campaigns and datasets
Recent changes: Track newly added files and monitor production progress
ROOT file analysis: Inspect ROOT file structure, extract metadata, analyze events and collections
Dataset aggregation: Aggregate event statistics across multiple ROOT files
Protocol support: Connect to XRootD servers via root:// protocol
Related MCP server: rucio-mcp
docker pull ghcr.io/eic/xrootd-mcp-server:latest
docker run -i --rm \
-e XROOTD_SERVER="root://dtn-eic.jlab.org" \
-e XROOTD_BASE_DIR="/volatile/eic/EPIC" \
ghcr.io/eic/xrootd-mcp-server:latestSee Docker Usage Guide for detailed instructions.
npm install
npm run buildSet the XRootD server URL using the XROOTD_SERVER environment variable:
export XROOTD_SERVER="root://dtn-eic.jlab.org"Optionally, set a base directory to restrict access and simplify paths:
export XROOTD_BASE_DIR="/volatile/eic/EPIC"When XROOTD_BASE_DIR is set:
Relative paths are resolved relative to the base directory
Absolute paths must be within the base directory (access control)
For example, with base /volatile/eic/EPIC, the path EVGEN refers to /volatile/eic/EPIC/EVGEN
The server speaks stdio by default (for clients that spawn it
themselves). Two HTTP transports are available via MCP_TRANSPORT:
# Streamable HTTP: MCP endpoint at http://127.0.0.1:9102/mcp
MCP_TRANSPORT=http XROOTD_SERVER="root://dtn-eic.jlab.org" node build/src/index.js
# Legacy SSE: endpoints at /sse and /messages
MCP_TRANSPORT=sse XROOTD_SERVER="root://dtn-eic.jlab.org" node build/src/index.jsMCP_HOST (default 127.0.0.1) and MCP_PORT (default 9102) control the
bind address. The server binds loopback by default; binding any other
address prints a warning because the tools carry no authentication.
An HTTP client config then looks like:
{
"mcpServers": {
"xrootd": {
"type": "http",
"url": "http://127.0.0.1:9102/mcp"
}
}
}Directory listing results are cached for improved performance:
export XROOTD_CACHE_ENABLED=true # default: true
export XROOTD_CACHE_TTL=60 # minutes, default: 60
export XROOTD_CACHE_MAX_SIZE=1000 # max entries, default: 1000The cache uses a time-based expiration strategy (TTL):
Directory listings are cached in memory
Cache entries expire after the configured TTL
Automatic cleanup removes expired entries every 15 minutes
LRU eviction when cache size exceeds 1000 entries
Note: Cached data may be up to TTL minutes old. For production data that changes infrequently, a 60-minute TTL provides good performance with acceptable staleness.
Add to your MCP client configuration:
{
"mcpServers": {
"xrootd": {
"command": "node",
"args": ["/path/to/xrootd-mcp-server/build/index.js"],
"env": {
"XROOTD_SERVER": "root://dtn-eic.jlab.org",
"XROOTD_BASE_DIR": "/volatile/eic/EPIC",
"XROOTD_CACHE_ENABLED": "true",
"XROOTD_CACHE_TTL": "60"
}
}
}
}Basic File Operations:
list_directory: List contents of an XRootD directory
get_file_info: Get detailed metadata about a file
read_file: Read contents of a file (with optional byte range)
check_file_exists: Check if a file or directory exists
get_directory_size: Calculate total size of a directory
Advanced Search & Analysis:
search_files: Search for files by glob pattern or regex
list_directory_filtered: List directory with advanced filtering (size, date, extension, pattern)
find_recent_files: Find files modified within a time period
get_statistics: Get comprehensive statistics about files in a directory
Campaign & Dataset Discovery:
list_campaigns: List available production campaigns
list_datasets: List datasets within a specific campaign
summarize_recent_changes: Summarize files added in a time period with detailed statistics
# Build
npm run build
# Watch mode
npm run watchNode.js 18 or higher
Access to an XRootD server
xrdfs command-line tool installed (from xrootd-client package)
MIT
Analyze ROOT file structure, trees, and branches. Prefers HTTP-based access; if unavailable, set allow_copy: true to fall back to xrdcp.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to ROOT file | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| allow_copy | No | Fall back to a full xrdcp file copy if HTTP access fails (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the fallback behavior (HTTP preference vs. xrdcp copy). However, it does not specify whether the tool is read-only or describe any side effects, leaving some behavioral gaps.
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 concise sentences with front-loaded purpose. No wasted words; 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?
The description fails to mention that no output schema is available, leaving the agent uncertain about what the tool returns (e.g., a structured JSON representation of the file). It also does not explain the output format or contents, which is critical for tool invocation.
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%, so the baseline is 3. The description adds no new parameter meaning beyond the schema's descriptions, essentially restating the allow_copy behavior already documented.
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 action ('Analyze') and specific resource ('ROOT file structure, trees, and branches'), distinguishing it from siblings like check_file_exists or get_file_info that serve different purposes.
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 provides guidance on when to set allow_copy (if HTTP-based access fails), but does not offer explicit context on when to choose this tool over siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a file or directory exists on an XRootD server
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to check | |
| server | No | Name of the XRootD server to use (default: first configured server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It only states existence checking but omits critical details like return format (boolean? error?), behavior on non-existent paths, side effects, or authentication needs. This gap harms transparency.
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 concise sentence that efficiently conveys the core purpose. However, it is somewhat under-specified for a tool with no annotations or output schema, but the brevity itself is not flawed.
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 absence of an output schema and annotations, the description should explain what the tool returns (e.g., boolean, error message). It does not, leaving the agent uncertain about the response format. This is a significant gap for a simple existence check.
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?
Input schema has 100% coverage, describing both parameters ('path' and 'server'). The description adds no extra meaning beyond the schema, so a baseline score 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 clearly states the tool's purpose: checking existence of a file or directory on an XRootD server. It uses a specific verb ('Check if exists') and resource, distinguishing it from sibling tools like get_file_info or list_directory.
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 provides no guidance on when to use this tool versus alternatives, such as get_file_info for details or list_directory for listings. No usage context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract metadata from podio_metadata tree in ROOT file. Prefers HTTP-based access; if unavailable, set allow_copy: true to fall back to xrdcp.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to ROOT file | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| allow_copy | No | Fall back to a full xrdcp file copy if HTTP access fails (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the fallback mechanism (xrdcp) and HTTP preference, but does not state whether the tool is read-only, what happens on failure, or required permissions. Moderate transparency.
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 extremely concise: two sentences with no fluff. The key action and fallback condition are front-loaded, making it easy to scan.
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 tool with 3 parameters and no output schema, the description covers the core purpose and the key parameter detail. However, it lacks information about the return format or potential side effects, which might be necessary for full contextual completeness.
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%, so parameters are already documented. The description adds value by explaining the fallback behavior for allow_copy, but does not significantly enhance understanding of path and server beyond 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 specifies extracting metadata from the podio_metadata tree in a ROOT file, which is specific and clear. However, it does not explicitly distinguish from sibling tools like get_file_info or analyze_root_file, which could also extract metadata.
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 provides guidance on when to set allow_copy: true (if HTTP fails), indicating a preference for HTTP. But it does not mention when to use this tool versus other metadata-related sibling tools, such as when to use get_branch_histogram instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find files modified within a time period
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to search | |
| hours | No | Number of hours to look back (default: 24) | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| recursive | No | Search recursively (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions time filtering, omitting details on default behavior, error handling, server selection, or limitations (e.g., max hours, recursive behavior). This is insufficient for a mutation-like operation.
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 sentence of 7 words, extremely concise with no wasted words. However, for a tool with 4 parameters and complex behavior, slightly more detail could improve clarity without losing conciseness.
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 description lacks information about return values, error cases, and default behaviors. Given the absence of an output schema, it should explain what the tool returns (e.g., list of file paths, metadata). It also does not mention the role of the server parameter or any prerequisites.
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 adds no additional meaning beyond the schema definitions. It does not elaborate on any parameter, but the schema already specifies each parameter's purpose clearly.
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 'Find files modified within a time period' uses a specific verb and resource, clearly stating the tool's action and condition. It distinguishes itself from sibling tools like list_directory and check_file_exists by focusing on modification time filtering.
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 guidance is provided on when to use this tool versus alternatives such as search_files or list_directory. The description implies a use case but does not explicitly state when-not-to-use or offer context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a histogram of a TTree branch and return bin edges and counts. Prefers HTTP-based access; if unavailable, set allow_copy: true to fall back to xrdcp.
| Name | Required | Description | Default |
|---|---|---|---|
| cut | No | Optional selection criterion applied per event, e.g. "ReconstructedParticles.momentum.z > 0" | |
| bins | No | Number of histogram bins (default: 100) | |
| path | Yes | Path to ROOT file | |
| tree | No | TTree name to read from (default: "events") | |
| xmax | No | Upper bound of histogram range (auto-detected if omitted, requires xmin) | |
| xmin | No | Lower bound of histogram range (auto-detected if omitted, requires xmax) | |
| branch | Yes | Branch name (or expression) to histogram, e.g. "ReconstructedParticles.momentum.x" | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| allow_copy | No | Fall back to a full xrdcp file copy if HTTP access fails (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the preference for HTTP access and the fallback mechanism, but lacks details on failure modes, permissions, or side effects. This is adequate but not comprehensive.
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 two sentences, front-loaded with the core action, and no unnecessary words. It is concise and efficient.
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 tool has 9 parameters and no output schema or annotations, the description is somewhat incomplete. It does not explain the output format (bin edges and counts structure), error handling, or performance characteristics. Adequate but has gaps.
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 baseline is 3. The description adds no extra parameter information beyond the schema, except implicitly for 'allow_copy' via the fallback explanation.
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 verb 'Fill a histogram', the resource 'TTree branch', and the output 'bin edges and counts'. It is specific and distinguishes from sibling tools like 'analyze_root_file' which may perform broader analysis.
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 provides context on HTTP vs xrdcp fallback, guiding when to set 'allow_copy: true'. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate event statistics across all ROOT files in a dataset. Prefers HTTP-based access; if unavailable, set allow_copy: true to fall back to xrdcp.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to dataset directory | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| allow_copy | No | Fall back to full xrdcp file copies if HTTP access fails (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the HTTP preference and fallback behavior, but does not mention if the operation is safe (read-only), destructive, or requires any authentication or permissions.
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, no wasted words, front-loaded with the core purpose. Every sentence adds value.
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?
No output schema, so description should hint at what is returned. It does not. Parameters are well-covered, but the return type/value is not mentioned. For a moderate-complexity tool with 3 parameters, it is partially complete.
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 input schema has 100% coverage, so baseline is 3. The description adds specific meaning for 'allow_copy' (fallback to xrdcp if HTTP fails) and implies that 'server' uses a default if not specified, enhancing understanding beyond 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 the tool aggregates event statistics across all ROOT files in a dataset, using a specific verb ('Aggregate') and resource ('event statistics across all ROOT files in a dataset'). This distinguishes it from siblings like 'get_event_statistics' or 'get_statistics'.
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 provides a usage hint for the allow_copy parameter (HTTP preference and fallback), but does not explicitly state when to use this tool versus alternatives like 'get_event_statistics' or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate total size of a directory (recursively)
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the directory | |
| server | No | Name of the XRootD server to use (default: first configured server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions 'recursively', indicating traversal of subdirectories. However, it does not mention return format (e.g., bytes, human-readable), potential performance issues for large directories, or required permissions.
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, very concise sentence of seven words. It is appropriately sized and front-loaded with the core action.
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 two parameters and no output schema, the description is minimal. It lacks details on return value, units, and potential side effects. For a simple query tool, it is adequate but not fully informative.
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%, so the baseline is 3. The description adds no extra meaning beyond the schema descriptions for 'path' and 'server'. Thus, no additional value.
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 function: 'Calculate total size of a directory (recursively)'. The verb 'calculate' and resource 'total size of a directory' are specific, and the inclusion of 'recursively' distinguishes it from siblings like list_directory or get_file_info.
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 guidance is provided on when to use this tool versus alternatives. The sibling list includes many file/directory tools, but the description does not specify contexts where this tool is preferred or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get event statistics and collection info from ROOT file. Prefers HTTP-based access; if unavailable, set allow_copy: true to fall back to xrdcp.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to ROOT file | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| allow_copy | No | Fall back to a full xrdcp file copy if HTTP access fails (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses access behavior (HTTP vs xrdcp) but does not mention whether the tool is read-only, performance implications, error modes, or what happens to the file. Partial transparency.
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 concise sentences with front-loaded purpose. No redundant or unnecessary content. Every sentence adds value.
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?
No output schema exists, but description fails to explain what the tool returns (statistics format, collection info). No annotations provide safety or side-effect info. With 3 parameters and no output description, the tool definition feels incomplete.
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 covers all parameters with descriptions (100% coverage). Description adds context on allow_copy usage (fallback condition) but does not add new parameter semantics beyond the schema. 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?
Description clearly states the tool gets event statistics and collection info from a ROOT file. It also specifies the access methods (HTTP preferred, xrdcp fallback). However, it does not explicitly differentiate from sibling tools like get_dataset_event_statistics or get_statistics, leaving some ambiguity.
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 guidance on when to set allow_copy (when HTTP fails), but no guidance on when to use this tool versus siblings like get_statistics or get_dataset_event_statistics. No when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed metadata about a file or directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the file or directory | |
| server | No | Name of the XRootD server to use (default: first configured server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the full burden. It implies a read operation but does not specify safety (e.g., read-only), prerequisites, or constraints beyond the parameters.
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, clear sentence with no waste. While not structured with sections, it is appropriately concise for a simple 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?
The tool has no output schema, so the description should hint at return values. It only says 'detailed metadata' without specifics (e.g., size, type, permissions), leaving agents to guess the output format.
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%, so the baseline is 3. The description adds no meaning beyond the schema; it merely restates 'path' and 'server' implicitly.
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 verb 'Get' and resource 'file or directory' with specific outcome 'detailed metadata'. It is distinct from siblings like 'check_file_exists' or 'get_directory_size', though it does not explicitly differentiate.
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 guidance is provided on when to use this tool versus alternatives like 'check_file_exists' or 'get_statistics'. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive statistics about files in a directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to analyze | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| recursive | No | Include subdirectories (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description lacks detail on what 'comprehensive statistics' includes, potential performance impact, or any side effects. It only states the basic verb and target without behavioral 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 concise sentence, but it is vague and does not fully utilize the space to provide useful context. It is not overly long but could be more informative.
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?
No output schema is provided, and the description omits return value details. For a tool claiming 'comprehensive statistics', more information about output format or scope is needed for complete understanding.
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%, so the description adds little beyond what the schema already provides. The description does not clarify parameter semantics further, such as the format of 'path' or the effect of 'recursive'.
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 retrieves 'comprehensive statistics about files in a directory', which distinguishes it from sibling tools like 'get_branch_histogram' or 'get_event_statistics' that focus on specific data types.
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 guidance on when to use this tool versus alternatives (e.g., get_directory_size, list_directory). The description does not mention when not to use it or provide criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available production campaigns
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the XRootD server to use (default: first configured server) | |
| recoPath | No | Path to RECO directory (default: "RECO") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'list', implying a read operation, but does not disclose any behavioral traits such as side effects, authentication requirements, or error handling. The response format or any limitations are not mentioned.
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, concise sentence that communicates the core function. However, it may be too brief given the lack of other context; still, it is front-loaded and efficient.
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 absence of an output schema and annotations, the description should compensate by explaining what the tool returns and any important behavior. It does not, leaving significant gaps for the agent.
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 input schema covers both parameters fully (100% coverage), so the baseline is 3. The description does not add any additional meaning beyond the parameter names and types; it does not explain, for example, what a RECO directory is or how server selection works.
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 verb 'List' and the resource 'available production campaigns'. It is specific enough to convey the tool's function, and none of the sibling tools appear to list campaigns, so differentiation is not a concern.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List datasets within a campaign
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the XRootD server to use (default: first configured server) | |
| campaign | Yes | Campaign name (e.g., "25.10.2") | |
| recoPath | No | Path to RECO directory (default: "RECO") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether the operation is read-only, what is returned (e.g., just names or metadata), or any side effects. For a read tool, minimal behavioral info.
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?
Single sentence, no wasted words. However, it is overly concise and could benefit from slightly more detail without becoming verbose.
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?
Without annotations or output schema, the description should explain what 'datasets' are (e.g., names, metadata) and any constraints. It is too brief for effective use, especially given the three parameters with defaults.
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% (all 3 parameters have descriptions in the input schema). The description adds no additional parameter information, so baseline score 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 'List datasets within a campaign' clearly states the action (list) and the resource (datasets within a campaign). It distinguishes from sibling tools like list_campaigns (which lists campaigns) and list_directory (which lists files).
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 guidance on when to use this tool versus alternatives like list_directory or search_files. The description lacks context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contents of a directory on an XRootD server
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to the directory to list | |
| limit | No | Maximum number of entries per page (default: 1000). Use with offset for pagination through large directories. | |
| offset | No | Starting index for pagination (default: 0). Use with limit to retrieve subsequent pages. | |
| server | No | Name of the XRootD server to use (default: first configured server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must bear full behavioral burden. It only states the function without disclosing that it is a read-only operation, pagination behavior, or any side effects.
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 concise sentence with no fluff. It is front-loaded and structured well, though it could be slightly more informative without losing conciseness.
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 output schema, the description should hint at the return format (e.g., list of filenames) or mention pagination behavior, but it does not. The context of sibling tools also suggests a need for differentiation that is absent.
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 already documents all parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score of 3.
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 verb 'List' and the resource 'contents of a directory on an XRootD server', providing a specific purpose. However, it does not distinguish from sibling tool 'list_directory_filtered' which may indicate a filtered version exists.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like 'list_directory_filtered' or any context-specific restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List directory with advanced filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Directory path | |
| server | No | Name of the XRootD server to use (default: first configured server) | |
| maxSize | No | Maximum file size in bytes | |
| minSize | No | Minimum file size in bytes | |
| extension | No | Filter by file extension (e.g., ".root") | |
| namePattern | No | Glob pattern for filename (e.g., "DEMP*") | |
| modifiedAfter | No | ISO date string - only files modified after this date | |
| modifiedBefore | No | ISO date string - only files modified before this date |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only says 'list directory with advanced filtering', failing to disclose any behavioral traits like read-only nature, performance implications, or required permissions.
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 concise sentence, which is efficient but lacks structure or additional context that could be helpful.
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 8 parameters and no output schema or annotations, the description is very minimal and does not cover return format, filtering behavior, or usage examples, leaving substantial gaps.
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?
All 8 parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
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 lists directories with advanced filtering, which distinguishes it from the basic list_directory sibling. However, it does not explicitly mention the added filtering 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?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured XRootD servers
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the action without mentioning safety (e.g., read-only), authentication needs, or output format, which is insufficient for a no-annotation scenario.
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 sentence that immediately states the tool's purpose with no extraneous words. It is optimally concise and 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?
While the tool is simple with no parameters, the description omits output details (e.g., what fields are returned). Given no output schema, the agent might need more context to use the results correctly.
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?
There are zero parameters, and schema coverage is 100% via the empty schema. The description adds no parameter details, but none are needed. Baseline for no params is 4.
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 'List all configured XRootD servers' clearly states the verb (list) and resource (servers), distinguishing it from sibling list tools that operate on different resources like campaigns or datasets.
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 or avoid this tool, nor mention of alternatives. However, the context of siblings and the specific resource 'servers' makes its purpose self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read contents of a file from an XRootD server (supports byte ranges)
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional: End byte position for partial read | |
| path | Yes | Path to the file to read | |
| start | No | Optional: Start byte position for partial read | |
| server | No | Name of the XRootD server to use (default: first configured server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions XRootD and byte ranges, omitting critical details like error handling (missing file, permissions), return format (raw bytes vs string), size limits, or synchronous behavior. This is insufficient for an AI agent.
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 concise sentence (14 words) with no extraneous text. Every word is necessary and directly conveys the core functionality.
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 tool has 4 parameters and no output schema, the description should cover return format, error states, and file handling details. It only provides the basic purpose and byte range support, leaving significant gaps for an AI agent to infer correct usage.
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%, so baseline is 3. The description adds minimal value beyond the schema: it mentions byte range support, which contextualizes 'start' and 'end' parameters, but does not provide new constraints or semantics not already in the parameter descriptions.
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 reads file contents from an XRootD server with byte range support. It effectively distinguishes itself from sibling tools like check_file_exists (existence check) and get_file_info (metadata), making its purpose unambiguous.
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. The mention of byte range support implies a use case for partial reads, but there is no context about when not to use it or how it compares to other tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files by pattern (glob or regex)
| Name | Required | Description | Default |
|---|---|---|---|
| server | No | Name of the XRootD server to use (default: first configured server) | |
| pattern | Yes | Search pattern (glob like "*.root" or regex if useRegex=true) | |
| basePath | No | Base path to search from (default: current directory) | |
| useRegex | No | Treat pattern as regex instead of glob (default: false) | |
| recursive | No | Search recursively (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It only mentions pattern types (glob/regex) but omits default paths, recursion behavior, server usage, or network dependencies. The schema provides defaults but the description adds no extra 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 sentence, front-loaded with the core purpose. It is concise and every word is meaningful, though it could benefit from additional context without becoming verbose.
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 tool has 5 parameters, no output schema, and no annotations. The description fails to explain return format, error handling, or performance considerations. It is insufficient for an agent to use correctly in all scenarios.
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 baseline is 3. The description's mention of glob or regex aligns with the schema but adds no new meaning beyond what the parameter descriptions already provide.
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 verb (search), resource (files), and method (by pattern with glob or regex). It distinguishes from sibling tools like list_directory (no pattern) and check_file_exists (single file existence).
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 guidance on when to use this tool versus alternatives. For example, it doesn't mention that check_file_exists is better for a single file check or that find_recent_files is for time-based searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize files added in a time period with statistics
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Path to analyze | |
| hours | No | Number of hours to look back (default: 24) | |
| server | No | Name of the XRootD server to use (default: first configured server) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation (summarize), but does not explicitly state safety or side effects. Moderate transparency.
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 one short sentence, which is concise but omits important detail like what statistics are produced. It is adequately sized but could be more informative without losing brevity.
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 presence of 3 parameters and no output schema, the description should clarify the nature of the statistics returned. It does not, leaving the agent uncertain about the output format or content.
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% and each parameter has a description. The tool description adds no additional meaning beyond the schema, so baseline score 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 clearly states the verb 'summarize' and the resource 'files added in a time period', making the tool's purpose obvious. It distinguishes from siblings like find_recent_files by implying aggregated statistics rather than a list.
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 guidance on when to use this tool versus alternatives like find_recent_files or get_statistics. The description does not mention prerequisites or preferred scenarios.
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. Dates show when Glama detected each change.
analyze_root_file2 fields changedInput schema / properties / allow_copyAdded value: +{
+ "description": "Fall back to a full xrdcp file copy if HTTP access fails (default: false).",
+ "type": "boolean"
+}Input schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}check_file_exists1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}extract_podio_metadata2 fields changedInput schema / properties / allow_copyAdded value: +{
+ "description": "Fall back to a full xrdcp file copy if HTTP access fails (default: false).",
+ "type": "boolean"
+}Input schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}find_recent_files1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}get_branch_histogramget_dataset_event_statistics2 fields changedInput schema / properties / allow_copyAdded value: +{
+ "description": "Fall back to full xrdcp file copies if HTTP access fails (default: false).",
+ "type": "boolean"
+}Input schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}get_directory_size1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}get_event_statistics2 fields changedInput schema / properties / allow_copyAdded value: +{
+ "description": "Fall back to a full xrdcp file copy if HTTP access fails (default: false).",
+ "type": "boolean"
+}Input schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}get_file_info1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}get_statistics1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}list_campaigns1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}list_datasets1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}list_directory3 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Maximum number of entries per page (default: 1000). Use with offset for pagination through large directories.",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Starting index for pagination (default: 0). Use with limit to retrieve subsequent pages.",
+ "type": "number"
+}Input schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}list_directory_filtered1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}list_serversread_file1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}search_files1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}summarize_recent_changes1 field changedInput schema / properties / serverAdded value: +{
+ "description": "Name of the XRootD server to use (default: first configured server)",
+ "type": "string"
+}v0.1.0analyze_root_filecheck_file_existsextract_podio_metadatafind_recent_filesget_dataset_event_statisticsget_directory_sizeget_event_statisticsget_file_infoget_statisticslist_campaignslist_datasetslist_directorylist_directory_filteredread_filesearch_filessummarize_recent_changesEach tool has a distinct purpose, covering file operations, ROOT file analysis, and dataset management. Overlap is minimal or non-existent.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to navigate.
18 tools is well-scoped for XRootD file access and ROOT analysis, covering all essential operations without being excessive.
The tool set covers core CRUD-like operations (read, list, search) and ROOT analysis. Minor gaps like file creation or advanced queries are acceptable given the focus on access and analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
Browse and manage files in your Moxt AI workspace from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/eic/xrootd-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
