CERN ROOT MCP Server

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: it writes output_path, may overwrite existing content, and in central deployments requires an artifact-relative path plus export permission. It stops short of stating what happens on a failed or partial write.

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, front-loaded with purpose, then the mutation risk, then the deployment prerequisite. Every clause carries distinct information with no repetition.

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 destructive write tool with no output schema and 71% parameter coverage, the description covers the critical unknowns: overwrite risk, path constraints, and permissions. It could still say what the tool returns or how large exports behave, but nothing essential for a correct call is missing.

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 71%, so most parameters are already documented. The description reinforces format choices (JSON/CSV/Parquet) and the output_path branch selection, but adds nothing about selection cut syntax, compress semantics, or the relationship between path and tree_name, so it does not compensate for the remaining gap.

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?

Specific verb plus resource: "Export selected ROOT branches to a JSON, CSV or Parquet file" tells the agent exactly what is produced and in what formats, which separates it from read-only siblings like read_branches and inspect_file. It does not explicitly name the sibling it replaces, so it stays short of a 5.

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?

Usage is implied by the write-to-file framing and the note that central deployments require artifact-relative paths and export permission, which is real context. However, there is no explicit "use this instead of read_branches when..." guidance or statement of when not to export, leaving the agent to infer the boundary with read_branches/get_branch_stats.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds only that derived variables are supported via defines, but says nothing about what statistics are computed, the return shape, or any error conditions.

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 single sentence is front-loaded and free of filler. It is efficient, though the parenthetical is the only extra detail provided.

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?

With five parameters, a nested defines object, and no output schema, the description is too thin to explain what statistics are returned or how defines, selection, and tree_name interact. It leaves significant gaps for a tool of this complexity.

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 80%, so the schema already documents most parameters. The description's mention of derived variables via defines largely restates the schema and adds no new meaning about selection, tree_name, or path.

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 verb and resource: 'Get statistics for branches.' It is clear what the tool returns at a high level, but it does not distinguish itself from sibling tools such as list_branches or read_branches.

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 instead of list_branches or read_branches, and no prerequisites or exclusions are mentioned. The only implied usage is that it computes statistics rather than listing branches.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add context — and it does: it discloses that request limits exist and that native ROOT availability depends on a separate installation. It does not describe the shape of the returned capability data, which is the main remaining gap given there is no output schema.

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 tight sentences with the payload enumeration front-loaded and the sequencing advice second. Every clause carries information; nothing is padded or restated from the title.

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?

With no output schema, the description must convey what comes back, and it does at a high level by naming mode, capabilities, resources, and limits. A short note on the response format or whether limits are static or per-session would close the remaining 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies the call needs no arguments to enumerate server state.

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?

States a specific verb (Discover) plus the concrete payload: ROOT analysis mode, capabilities, accessible named resources, and request limits. This clearly separates it from siblings like list_files or export_data, which operate on data rather than server configuration, though it never names a sibling it is not.

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?

'Use before choosing analysis tools' gives explicit ordering guidance that an agent can act on when planning a session. The prerequisite note about native ROOT requiring a separate installation is genuinely useful gating information, but there are no when-not-to-use conditions or named alternative discovery tools.

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

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

Annotations already supply readOnlyHint, destructiveHint=false, idempotentHint and openWorldHint, so the safety profile is covered. 'Does not modify files' merely restates destructiveHint=false, and the only genuinely additive behavioral detail is the accepted path-reference format. Nothing is said about what the inspection output contains or how large it may be for complex files.

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 short sentences, front-loaded with purpose, then accepted input form, then the safety note. The final sentence duplicates the destructiveHint=false annotation and would be better spent on output/behavior detail, but nothing is padded or buried.

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 one-parameter read-only tool with full annotation coverage and no output schema, the description covers purpose, usage timing and accepted path forms. The remaining gap is that an agent is not told what the inspection response looks like, which matters given the enumerated variety of ROOT objects it reports.

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 a single parameter at 100% schema coverage, the schema already documents 'path' as a string file path, so the baseline is 3. The description does add value by clarifying that the path may be a returned path or an @resource/relative.root reference, which is meaning the schema's bare 'File path' does not convey.

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 names a specific verb (inspect) and resource (a ROOT file) and enumerates what is surfaced: directories, TTrees, RNTuples, histograms. That is far more informative than the tool name alone, though it never explicitly contrasts itself with close siblings such as list_branches or validate_file.

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 states a clear usage window: 'before reading data', which tells the agent this is a discovery/orientation step preceding data reads. It gives no exclusions or explicit pointer to the alternative siblings (list_branches, get_branch_stats) for narrower lookups, so it stops short of a full when/when-not statement.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true. The description adds that it does not modify files, which reinforces safety but largely repeats the annotations; it does not add details about output size, permissions or error behavior.

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 short and front-loaded, moving from purpose to usage to safety. The sentence 'Does not modify files' is slightly redundant with annotations, but it is not wasteful enough to hurt readability.

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 read-only listing tool with full schema coverage and rich annotations, the description covers purpose, workflow timing and safety adequately. Minor gaps remain around the optional pattern parameter and output characteristics, but the core information needed to invoke it correctly is present.

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 path, tree_name and pattern are already documented in the schema. The description adds no parameter-specific meaning beyond the general subject of branch listing.

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 verb and resource: list branch names and types in a ROOT TTree or RNTuple. This makes the operation clear, but it does not explicitly distinguish this tool from siblings like read_branches or get_branch_stats beyond the preparatory usage note.

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 gives clear contextual guidance: use before selecting branches for reads, statistics or histograms. It does not name alternative tools or state when not to use it, but the intended workflow position is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so 'Does not modify files' largely restates structured data. The one piece of added context is that the resource must be pre-configured and named, implying a setup prerequisite. It says nothing about result volume, truncation, or what happens when limit is hit, which the schema's maximum of 1000 hints at but does not explain.

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 short clauses, front-loaded with the core action, and no filler. The final sentence 'Does not modify files' is mostly redundant with the read-only annotations and is the one element that does not earn 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?

For a small three-parameter read tool with no output schema, the description covers what it returns implicitly (paths to inspect), the knobs that bound results, and the safety profile. It could state the return shape (a list of paths) explicitly, but an agent has enough to call it 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?

Schema description coverage is 67%, and the schema itself only documents pattern as 'Optional glob pattern' and resource as 'Resource name'. The description adds purpose for both pattern and limit ('to bound discovery'), which is meaningful guidance the schema lacks. It does not explain the limit default or the 1000 cap, so it adds value but not fully.

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 gives a specific verb and resource ('List CERN ROOT files') scoped to 'a configured named resource', which clearly separates it from siblings like inspect_file, list_branches, or validate_file. It stops short of explicitly naming a sibling to disambiguate against, so it is clear but not maximally differentiated.

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 tells the agent how to bound the call ('Use pattern and limit') and routes the next step explicitly ('inspect a returned path next'), which is genuine workflow guidance pointing at inspect_file. It does not state when not to use this tool (e.g. for non-ROOT files or unconfigured resources), so it falls short of a full when/when-not treatment.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so 'Does not modify files' mainly restates them. The description usefully flags a performance consideration for large datasets and the optional cut expression, but says nothing about return shape or memory behavior for wide branch selections.

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 short sentences with no waste: purpose first, then row-bounding, then the large-dataset alternative, then the safety note. Every sentence carries distinct information.

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?

With 10 parameters, nested objects (defines), and no output schema, the description covers invocation adequately but leaves the returned data structure unexplained. An agent cannot predict the shape of results, only how to bound them.

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 90%, so parameters are already well documented. The description reinforces entry_start/entry_stop and the cut expression but adds no clarification on the limit/offset vs. entry_start/entry_stop relationship or on defines/flatten, so it stays at the baseline.

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?

States a specific verb and resource ('Read selected branches from a ROOT TTree or RNTuple') and names an alternative (get_branch_stats) for one case. It is not fully differentiated from siblings like export_data or list_branches, but the core operation is 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?

Gives concrete when-to-use guidance: bound rows with entry_start/entry_stop, and prefer get_branch_stats or histograms for large datasets. It omits when to choose this over export_data or list_branches, so alternatives are only partially covered.

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

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

Annotations already declare it non-read-only, idempotent and non-destructive, so the description's job is to add scope and side effects, which it does: the change is server-wide and affects all calls to the process, and the tool surface must be re-listed afterward. It does not say whether the setting persists across restarts or whether it requires elevated permission, which are the remaining unknowns for a process-wide mutation.

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 short sentences, front-loaded with the action and scope, followed by side effect and restriction. No filler or 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 one-parameter mutation with annotations covering the safety profile and no output schema, the description covers scope, blast radius, follow-up and deployment restriction. The only substantive omission is the semantic difference between the two tiers and persistence behavior.

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 0%, but the single parameter is a self-documenting two-value enum, and the description echoes both values. However, it never explains what 'core' versus 'extended' actually enables, so the agent cannot reason about the consequence of its choice beyond the label.

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 names a specific verb ('Change') and resource ('local server-wide analysis tier') and enumerates the two valid states (core, extended), so the agent knows exactly what the tool does. It does not need sibling differentiation because none of the listed siblings (list_files, inspect_file, export_data, etc.) overlap with mode switching.

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 states the applicable context ('local server-wide') and an explicit exclusion ('Disabled in central deployments'), plus a follow-up instruction to re-list tools. What is missing is any guidance on when an agent should prefer extended over core, which is the real decision the caller faces.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. Beyond that, the description says nothing about what "integrity" means (checksums, structural parse, branch/entry sanity), how failures are surfaced, or whether the check is a costly full scan of a potentially large file — meaningful gaps for a validation 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?

Five words, front-loaded, with zero filler or repetition. It is terse to the point of under-specification, but nothing in the sentence is wasted.

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?

With no output schema, the description must explain what a successful versus failed validation returns (boolean, error list, exception), and it does not. Combined with the missing sibling differentiation and undefined notion of "integrity," an agent cannot predict the result shape or cost before calling.

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% with a single required "path" parameter, so the schema already documents the input and a baseline 3 applies. The description adds only the implied constraint that the path should reference a ROOT file, with no detail on accepted path forms (local vs remote) beyond that.

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?

"Validate ROOT file integrity" gives a specific verb (validate) and resource (ROOT file), so the agent knows this checks a file rather than listing or reading it. It does not explicitly distinguish itself from the closest sibling, inspect_file, leaving the boundary between inspecting and validating to inference.

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 choose this over inspect_file, list_files, or read_branches, and no stated prerequisites (e.g., file must be closed, accessible, or local versus remote). The agent must guess the trigger condition for validation from the name alone.

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