champollion-sulcal-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: launching pipeline stages (start_*), subject management (purge_subject, prune_failed_subjects), job control (get_job_status, list_jobs, cancel_job, get_job_log), and pipeline info (get_pipeline_info, preflight_check). Minimal overlap; even similar tasks like subject removal are differentiated by scope.
Naming Consistency4/5
Most tools follow a consistent pattern: launch verbs (start_*) for pipeline stages, get_* for retrieval, and descriptive verbs for actions. Deviations include 'purge_subject' vs. 'prune_failed_subjects' (different delete verbs) and 'preflight_check' (no prefix), but overall naming is clear and predictable.
Tool Count5/5
17 tools is appropriate for a multi-stage neuroimaging pipeline with job management and utility functions. Each tool earns its place, covering all stages and supporting operations without being excessive or sparse.
Completeness5/5
The tool set covers the full pipeline lifecycle: stage launches, job monitoring, subject cleanup, and configuration checks. All essential operations are present with no obvious gaps for the stated purpose.
Average 3.3/5 across 17 of 17 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits, but it lacks any mention of side effects, idempotency, error handling, destuctiveness, or authorization needs. The agent has no clue what happens when the tool runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but it sacrifices essential details. A few more sentences would improve clarity without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and an output schema, this single sentence is insufficient. The description does not explain the return value or how the configuration generation works, despite the complexity indicated by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage for its 6 parameters. The description does not explain any parameters or their roles, leaving the agent to guess from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'generate Champollion dataset YAML configuration files' and mentions 'Stage 3', which gives a clear verb and resource. However, 'Launch Stage 3' is ambiguous—it could mean initiating a pipeline step or just generating files for that stage, and it does not explicitly distinguish from other 'start_*' sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like other 'start_*' tools. There is no mention of prerequisites, order of operations, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what the tool renders. It does not disclose side effects, permissions, or whether it is destructive. The agent has no behavioral context beyond the basic rendering action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but fails to convey necessary information for a tool with 11 parameters. It is too short relative to the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and absence of schema descriptions or annotations, the description is extremely incomplete. It does not explain how parameters interact, the expected output, or prerequisites. The existence of an output schema is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the tool description does not mention any parameters. With 11 parameters including 'umap_only', 'tiles_only', 'sulcal_only', etc., the agent receives no help understanding their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch Stage 6') and the specific outputs ('render sulcal graph meshes, cortical tile masks, and UMAP scatter plots'). It provides a specific verb and resource. However, it does not distinguish from sibling tools like start_cortical_tiles, which might overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The mention of 'Stage 6' implies a pipeline sequence, but no explicit context or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey all behavioral traits. It only states that the tool launches a stage, but does not disclose side effects (e.g., file creation), blocking behavior, or error handling. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, achieving high conciseness. However, it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, 4 required, and no output schema visible, the description is insufficiently complete. It fails to indicate return value (e.g., job ID), required inputs, or how the tool fits into the pipeline, despite the pipeline context implied by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meaning beyond the schema property names. With 8 parameters (4 required), the agent has no insight into what 'input_dir', 'path_to_graph', etc., represent or how to set them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Launch Stage 2: extract') and the resource ('28 sulcal region crops with cortical_tiles'), making the purpose unambiguous and distinct from sibling tools that handle different stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. Sibling tools include many 'start_*' tools for different pipeline stages, but the description offers no context for when this specific stage should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action (compute embeddings) but omits key traits such as side effects, required permissions, idempotency, runtime expectations, or whether data is read-only or modified. This is insufficient for a computational tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise but lacks any structural elements (e.g., parameter highlights, usage notes). Given the complexity, some expansion would be beneficial without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no schema documentation, no annotations, and no parameter explanations in the description, the description is severely incomplete. It does not explain return values (even though output schema exists), parameter roles, or how this step fits into the larger pipeline. The agent would need significant external knowledge to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (none of the 11 parameters are documented beyond names/types). The description provides zero parameter-level meaning, leaving the agent to guess the role of required fields like models_path, dataset_localization, datasets_root, and short_name, as well as optional ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Launch' and clearly identifies the resource 'Stage 4: compute sulcal embeddings across all 56 model folds (28 regions × 2 hemispheres)'. It distinguishes this tool from siblings (other start_* stages and pipeline tools) by naming the exact computation and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like start_pipeline or other stages. The description does not indicate prerequisites, ordering, or when not to use it. With siblings covering different pipeline steps, the agent needs more context to decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions sending SIGTERM, which implies process termination, but lacks details on side effects (e.g., job state changes, irreversibility, resource cleanup, or impact on other jobs).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (9 words) that efficiently conveys the core action. No extraneous text; every word contributes to purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (cancelling a job), the description omits important context: is it reversible, what happens to output, does it require ownership? The output schema exists but doesn't cover behavioral context. The minimal description leaves gaps for an AI agent to make safe decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning beyond the bare schema. The parameters job_id and output_dir are not described; the agent must infer their purpose from names alone, risking misunderstanding (e.g., output_dir role is unclear).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancel', the resource 'running job', and the method 'SIGTERM'. It distinguishes itself from sibling tools like get_job_status or list_jobs by indicating an action that modifies the job state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_job_status or the start_* tools. The description does not mention prerequisites, conditions, or when not to cancel a job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool generates sulcal graphs but does not explain side effects, auth needs, or whether it modifies input data. Lack of detail on execution behavior limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (13 words) with no filler. However, it is overly minimal and could be expanded without losing conciseness to include more useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, the absence of annotations or output schema details in the description, and no examples, the description is incomplete. It does not explain what the tool returns or how to configure it beyond the basic function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies that 'input_dir' contains raw T1 MRI data, but does not explain other parameters ('output_dir', 'parallel', 'enable_sulcal_recognition') or their purposes. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Launch Stage 1: generate sulcal graphs with Morphologist from raw T1 MRI data.' It uses a specific verb ('Launch') and identifies the resource and output, distinguishing it from sibling tools like 'start_cortical_tiles' which target different stages or outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., start_pipeline, start_cortical_tiles). The description does not mention prerequisites, exclusions, or context for selection, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It does not disclose side effects (e.g., overwriting existing output), required permissions, or whether previous stages must be completed. The description only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded with the stage identifier and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists (reducing need to describe return values), the description lacks context about the pipeline stage, prerequisites, input format constraints, and any behavioral side effects. For a tool with 3 parameters and no annotations, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description partially explains 'embeddings_subpath' and 'output_path' by linking them to per-region CSVs and the output directory, but does not explain 'path_models' (optional, default null) or expected formats for the required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Launch Stage 5' and specifies the action: collecting per-region embedding CSVs into a single output directory. It distinguishes from sibling tools like start_embeddings by naming the stage and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., previous stages must be complete) or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It mentions that the pipeline runs sequentially and returns a job_id immediately, indicating async behavior. However, no annotations are provided, so the description carries the full burden but lacks details on resource usage, prerequisites, or effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) but too brief for the tool's complexity. It could list key parameters or stages.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count, many required, and numerous sibling tools, the description is incomplete. It lacks explanation of pipeline stages, parameter dependencies, and output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 18 parameters, 11 required, and 0% schema description coverage, the description provides no explanation of any parameter. This is a major gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it launches the full Champollion pipeline (all 6 stages sequentially) and returns a job ID. This distinguishes it from sibling tools that launch individual stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running the full pipeline, but does not explicitly state when to use vs alternatives like start_cortical_tiles or start_training. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions 'current status and progress' but does not disclose whether the operation is read-only, what the response contains (though an output schema exists), or any authentication or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action. It could be improved by structuring parameter details, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be described, but the description lacks parameter explanations and behavioral context. For a two-parameter tool, more detail is expected to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description to explain parameters. However, the description does not mention job_id or output_dir at all, failing to add meaning beyond the schema's field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'status and progress of a running or completed job', distinguishing it from sibling tools like list_jobs (lists all jobs) and get_job_log (gets logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking job status, but does not explicitly state when to use this versus alternatives like get_job_log or cancel_job, nor provides any exclusions or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the read-like list operation but fails to disclose limitations, ordering, pagination, or side effects. The behavioral profile is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 12 words, directly stating the core action. While efficient, it could be slightly expanded to cover key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, an output schema exists but is unused, and parameter coverage is zero, the description is too sparse. It misses expected guidance on return values, defaults, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions output_dir and status, but omits limit entirely. It adds minimal value beyond the schema—only clarifies that status is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'jobs for a given output directory', with an optional filter by status. It distinguishes from siblings like get_job_status (which targets a specific job) and cancel_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (listing jobs by directory) but does not explicitly contrast with other tools like get_job_status or specify when not to use. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions config existence requirement, but does not disclose side effects (e.g., file modifications, resource usage, idempotency, failure behavior). A mutation tool like this should state whether it overrides existing outputs or requires network access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose front-loaded. Could benefit from list format for prerequisites, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 0% schema coverage, no annotations, and minimal description, the tool is underdocumented. The output schema exists but description doesn't reference it. Missing details like what 'mode: encoder' implies or what 'overwrite' does. Insufficient for an agent to reliably invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters. It only mentions dataset, region, and config_dir. The other 6 parameters (cpu, swf, mode, njobs, overwrite, output_dir) are completely undocumented, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it launches encoder training for a specific region and model (champollion_V1). The verb 'Launch' plus resource 'encoder training' is specific and distinguishes from siblings like start_cortical_tiles or start_embeddings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides prerequisite: dataset configs must exist, and mentions run start_config first or supply config_dir. This gives clear guidance on when to use this tool. No explicit when-not-to-use, but helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a read operation (retrieve) but does not mention potential limitations (e.g., maximum lines retrievable, performance impact, availability of logs after job completion) or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not detailed but present) and only three simple parameters, the description is adequate but leaves gaps: it does not specify the format or size of the returned log, nor behavior for invalid job IDs or non-existent logs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description only implicitly references the 'tail_lines' parameter via 'last N lines'. Required parameters 'job_id' and 'output_dir' are not explained, and their meanings or constraints are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'retrieve' and the resource 'job's log output', with a specific qualifier 'last N lines'. It effectively distinguishes from sibling tools like get_job_status (status) and list_jobs (listing) by focusing on log content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to see recent log output, but provides no explicit guidance on when to use this tool vs. alternatives like get_job_status or cancel_job. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose all behavioral traits. Only states high-level purpose; fails to mention what exactly is checked, side-effects, error handling, or output nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded verb, zero waste. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with zero params and an output schema. Description is mostly complete for a check action, though could clarify what aspects of configuration are verified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (empty schema, 100% coverage). Description appropriately focuses on tool action without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'check' and resource 'pipeline configuration and accessibility'. Clearly distinguishes from sibling start/status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a pre-run validation but no explicit guidance on when to use versus alternatives or when to skip.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Get metadata' suggests a read-only operation without side effects, which is likely safe, but it does not explicitly state that the tool is non-destructive or clarify authentication requirements. The description is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the tool's purpose without unnecessary detail. Every word is relevant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently conveys the tool's role as a metadata provider. It does not explain return values, but the output schema presumably covers that. It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100% (trivially). The description adds no parameter information, which is acceptable since none exist. Baseline is high, and no additional info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'metadata about the Champollion pipeline and available MCP tools'. This distinguishes it from sibling tools, which are primarily task starters (e.g., start_training) or job management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving metadata but does not provide explicit guidance on when to use this tool versus alternatives like get_job_status or list_jobs. Given the tool has no parameters, the context is straightforward, but exclusion criteria or preferred scenarios are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes worker-per-scan processing, sequential stages, file-presence barriers, and post-processing combine stage. No annotations provided, so description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise with zero wasted sentences. Important information is front-loaded, and the structure efficiently conveys complex workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good behavioral coverage, the tool has 16 parameters with no documentation and an output schema not described. For a complex pipeline tool, this is insufficient to guide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 16 parameters, the description fails entirely to explain what each parameter does or how they relate to the pipeline behavior. Only mode constraint is mentioned implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it launches a scan-centric streaming pipeline with specific stages, distinguishing it from sibling tools that handle individual stages or other pipelines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (embeddings_only mode) and when not (training mode cannot be parallelised), providing clear context over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool deletes files (destructive), reads a QC file, and supports dry-run preview. It also specifies the scope (only cortical_tiles outputs) and the deletion condition. It could be more explicit about side effects or reversibility, but the information is sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, detailed behavior, and usage tip. It front-loads the verb-resource pair and avoids fluff. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to explain return values. It covers the input format, behavior, and a safety preview. Missing context includes dependencies (e.g., QC file must exist) and scope confirmation (ensures it only deletes cortical_tiles outputs), but overall it adequately prepares an agent for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It explains the 'qc' parameter (TSV/CSV with specific columns) and 'dry_run' (preview mode), but 'output' is not explicitly defined—only implied as the cortical_tiles output directory. This adds some value but leaves a gap for one required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (remove), resource (cortical_tiles outputs), and condition (subjects that failed QC). It explains how failure is determined (qc==0 or absent from QC file), making the tool's purpose precise and distinct from siblings like purge_subject.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool: after cortical_tiles if the QC flag was not used initially, and it offers a preview option (dry_run=True). It does not explicitly list alternatives or when not to use it, but the equivalence to a flag and the sample use case are clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully discloses the destructive behavior by listing specific files and directories deleted, and mentions the dry_run preview.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-loading the core purpose, followed by details and a usage tip, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior and parameters adequately; an output schema exists so return values are not needed, but lacks prerequisites or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains the dry_run and subject parameters implicitly through context, but the 'derivatives' parameter is not explicitly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Remove' and the specific resource 'all cortical_tiles derivatives for a single subject', distinguishing it from sibling tools like prune_failed_subjects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a dry_run option to preview deletions, guiding safe usage, but does not explicitly compare to alternatives or give when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![champollion_sulcal_mcp MCP server](https://glama.ai/mcp/servers/Barthelemy-Drabczuk/champollion_sulcal_mcp/badges/card.svg)](https://glama.ai/mcp/servers/Barthelemy-Drabczuk/champollion_sulcal_mcp)

Score Badge

Copy to your README.md:

[![champollion_sulcal_mcp MCP server](https://glama.ai/mcp/servers/Barthelemy-Drabczuk/champollion_sulcal_mcp/badges/score.svg)](https://glama.ai/mcp/servers/Barthelemy-Drabczuk/champollion_sulcal_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Barthelemy-Drabczuk/champollion_sulcal_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server