tcs-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes (jobs, files, resources, modules, etc.). However, validate_job and render_job both handle structured job definitions, creating minor ambiguity about which to use for validation only. submit_job also performs a preview, but its confirmation token makes its role clear.
Naming Consistency4/5
The vast majority of tools follow a clear verb_noun pattern (list_jobs, get_job, submit_job, read_file, etc.). The only outlier is 'system_status', which uses noun_noun instead of a verb-based name, breaking the otherwise consistent convention.
Tool Count4/5
With 18 tools, the set is slightly above the ideal 3-15 range, but the breadth of functionality (job management, file operations, system status, and the preview/confirm flow) justifies the count. It is not bloated to the point of being overwhelming.
Completeness4/5
The tool surface covers the core HPC workflow: job submission/validation/cancellation/statistics, file reading/writing/searching/transfer, resource and module queries, and system status. Minor gaps exist, such as no direct job output/error viewing (though read_file can access output paths) and no job modification (update/alter), but these are workable.
Average 3.5/5 across 18 of 18 tools scored. Lowest: 2/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
This repository is licensed under MIT License.
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?
Annotations mark this as destructive (destructiveHint: true) and not read-only (readOnlyHint: false), but the description says 'Preview', which strongly implies a non-destructive, informational action. This is a direct contradiction. No additional behavioral traits are disclosed, such as whether files are moved/copied, whether overwrite behavior is risky, or how SSH authentication is handled. Score is 1 per the annotation contradiction rule.
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 with no filler, front-loading the action and resource. It is easy to read and parse. The brevity, however, comes at the cost of important detail, but the dimension judges whether it is appropriately sized; for a tool with this ambiguity, it is slightly too terse, so not a 5.
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?
The tool has five parameters, a destructive hint, and no output schema. The description does not explain return values, side effects, prerequisites, or the meaning of 'Preview' in the context of an actual transfer. It is far from complete for an agent to safely invoke this tool, especially given the destructive potential.
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 the description must explain the parameters. It only vaguely aligns 'upload or download' with the 'direction' enum, but fails to explain the roles of 'source' and 'destination' (e.g., which is local vs. remote), or the effects of 'overwrite' and 'recursive'. With five parameters and no meaningful elaboration, the description does not compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Preview') and a resource ('SSH-mode upload or download between configured local and remote roots'), which distinguishes it from sibling tools that read/write/search files. However, 'Preview' is ambiguous: it could mean a dry-run or an actual transfer, especially given the destructiveHint annotation. This ambiguity hurts clarity.
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 explicit guidance is given on when to use this tool vs. alternatives like manage_files, write_file, or run_command. It does not mention prerequisites, such as having SSH configured, nor does it explain which direction (upload/download) would be appropriate. The only implicit hint is the 'SSH-mode' qualifier, which is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Preview writing or appending', which contradicts the annotation destructiveHint=true and readOnlyHint=false. If the tool actually writes, calling it a 'preview' is misleading; if it only previews, the destructive annotation is wrong. This is a serious contradiction that obscures the tool's true destructive behavior.
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 with no fluff, which is efficient. However, the brevity contributes to the ambiguity around 'Preview', so it is not flawless.
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 has 4 parameters, no output schema, and conflicting annotations, the description is severely incomplete. It fails to clarify overwrite/append semantics, path restrictions, or return values, leaving major gaps for an agent to operate 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%, and the description provides no parameter-level detail. It does not explain the semantics of append versus overwrite, the meaning of path, or content constraints like maxLength, leaving agents to infer critical behavior from 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 clearly states the tool writes or appends a UTF-8 text file within configured remote roots, which distinguishes it from read_file and list_files. However, the verb 'Preview' introduces ambiguity about whether the tool actually performs the write or merely simulates it, preventing a perfect score.
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 provides context by mentioning 'configured remote roots', implying the tool is scoped to specific directories. It does not explicitly state when to prefer this tool over alternatives like manage_files, transfer_files, or run_command, nor does it give exclusions, so guidance is only implied.
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?
The description is consistent with read-only annotations and adds the scoping detail of current vs completed jobs. However, it discloses no additional behavior such as pagination, filtering semantics, or response format.
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 one short sentence with no redundant phrases, making it highly concise and front-loaded.
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 moderate complexity with five optional filters and no output schema, the description is too sparse to fully convey usage. It omits the meaning of parameters and the nature of the structured output.
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 mention any of the five parameters (limit, states, historyDays, resourceGroup, includeSubjobs). The agent receives no semantic guidance for these parameters.
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 tool lists the account's current jobs or completed history, using a specific verb and resource. It distinguishes the plural listing from single-job retrieval but doesn't explicitly differentiate from job stats or other list variants.
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 choose this over alternatives like get_job or get_job_stats. The description provides no exclusions or contextual cues beyond 'current or completed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description says 'Preview' suggesting a non-destructive read-only operation, but annotations have destructiveHint=true and readOnlyHint=false. This is a critical contradiction, and no additional behavioral details are provided to clarify the actual 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?
Two concise sentences, front-loaded with the primary purpose and a useful constraint. No wasted words, though the term 'constrained' is ambiguous.
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 tool has six parameters, no output schema, and annotations that contradict the description, the text is far from complete. It doesn't explain what 'preview' means mechanically, expected output, or how it differs from validate_job or render_job.
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 schema description coverage of 0%, the description carries no parameter information. None of the six parameters (executable, cwd, args, env, modules, timeoutSeconds) are mentioned or explained in the text.
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?
Purpose is clear: 'Preview a constrained build or pre/post-processing command' identifies a specific action and resource. It distinguishes from submit_job by noting heavy computation must be submitted as a job.
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 states 'Heavy computation must be submitted as a job,' providing a clear exclusion for when not to use this tool. It implies this tool is for lightweight, preview-only commands, though it doesn't name an alternative tool explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says the tool does not submit until confirm_action, implying a non-destructive preview operation. Yet annotations declare destructiveHint=true, which contradicts this. This is a serious inconsistency because the description suggests no state change while the annotation warns of destructive behavior.
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?
Two sentences, no filler, front-loaded with the key action. It conveys the core behavior and the confirmation step efficiently.
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?
The tool has a complex nested parameter and no output schema, yet the description does not explain the input schema, return format, or usage nuances. The contradiction with annotations further undermines its completeness; the description is insufficient for an agent to confidently invoke this tool.
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?
The description provides no information about the two parameters (definition and scriptPath) or the nested structure of definition. With schema description coverage at 0%, the description must compensate but does not, leaving the agent without guidance on constructing inputs.
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 tool previews a normal-batch pjsub operation and returns a confirmation token, distinguishing it from actual submission. It explicitly notes it does not submit until confirm_action, differentiating it from a direct submission tool.
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 explains the tool is a preview step that returns a token for later confirmation. It names confirm_action as the required next step, providing a clear usage flow. However, it does not explicitly contrast with siblings like validate_job or render_job, which could also serve as pre-submission checks.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the constraint 'inside configured remote roots,' which is useful, but it does not mention return format, pagination, or limit behavior. Beyond the annotations and the remote-roots constraint, transparency is limited.
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 that states the core function in a front-loaded manner. Every word contributes meaning, with no fluff or repetition. It is appropriately sized for a simple read-only listing operation.
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?
With two parameters, strong annotations, and no output schema, the description provides a minimal viable baseline. It tells the agent this is a scoped directory listing, but omits practical details like how remote roots are referenced in the path, whether the listing is recursive, and what the response structure looks like. Given the sibling tools, some ambiguity about edge cases remains.
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 carries the full burden for explaining parameters. However, it does not explain what 'path' should be relative to, how the 'limit' interacts with listing, or any other parameter semantics. The schema only provides types and defaults, which is insufficient given the complete absence of descriptive text.
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 uses the specific verb 'List' with the resource 'one directory' and scopes it to 'configured remote roots,' which distinguishes it from siblings like read_file (file content) and search_files. However, it could be more explicit that it lists directory entries rather than the directory itself, so a small clarity gap remains.
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 manage_files, transfer_files, or search_files. The description only states what it does without any contextual or exclusionary hints, leaving the agent to infer use cases from the tool name and sibling list.
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?
Annotations cover read-only, idempotent, and non-destructive behavior, so the description needs only add context beyond that. It adds that the search uses ripgrep and operates on a configured remote root, which is useful. However, it doesn't disclose return format, default glob behavior, or interaction with .gitignore, so transparency is limited.
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 of 10 words, directly starting with the action 'Search text'. No filler or repetition, achieving high 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?
With no output schema and 0% parameter documentation, the description is insufficient for an agent to understand the tool's full behavior. It lacks details on what results look like (matches vs filenames), how glob and limit work, and any usage caveats, making it incomplete for a 4-parameter tool.
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 the description must explain parameter semantics, but it doesn't mention path, pattern, glob, or limit at all. The names are reasonably self-evident, but the description adds no meaning beyond the schema's type/constraint details.
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 uses a specific verb ('search') and resource ('files via ripgrep'), clearly indicating a text search operation. It distinguishes from sibling tools like list_files and read_file by focusing on content search. However, it doesn't explicitly name alternatives or contrast with other search-like commands.
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 searching text, but provides no explicit guidance on when to use this tool versus alternatives such as run_command or read_file. It mentions 'remote root' as a scoping constraint but doesn't explain when this is preferred over local search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description says 'Preview,' which strongly implies a non-destructive dry-run, yet annotations declare destructiveHint=true. This is a direct contradiction. The description adds no further context about the nature of the operation, such as whether changes are staged or require confirmation.
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 that conveys the core purpose without extraneous words. It is highly concise and well-structured.
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 4-parameter tool with no output schema and minimal annotations, the description is too terse. It does not explain the workflow (prepare vs. execute), parameter dependencies, what 'configured remote roots' means, or how to safely use a destructive operation. Users would need external knowledge to invoke it correctly.
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 lists the operation types (mkdir, copy, move, delete) but does not explain the roles of source, destination, or recursive, nor their interdependencies (e.g., destination needed for copy/move). It fails to compensate for the missing schema documentation.
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 'Preview' and the resource 'mkdir, copy, move, or delete inside configured remote roots.' It distinguishes the tool from siblings like write_file or transfer_files by indicating it is a preview/preparation step.
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 implies usage for previewing file operations before execution, providing clear context. However, it does not explicitly mention when to use this tool over alternatives (e.g., write_file for content, transfer_files for bulk), nor does it state that confirm_action may be needed to execute the prepared operation.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds that it validates without writing, consistent with annotations. However, it does not describe return format, error behavior, or any limitations beyond the annotation safety profile. The addition of 'normal-batch' gives minor context, but overall the description adds little beyond structured data.
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, front-loaded with the verb and object, with no filler or repetition. Every word contributes to the core purpose, making it highly 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?
The tool has 15 parameters, nested objects, enums, and no output schema. The one-sentence description gives no information about return values, usage context, parameter interplay, or typical scenarios. While annotations cover safety, the description is inadequate for an agent to know what to expect or how to construct a valid call for a complex tool.
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 mention any parameters or how they influence rendering/validation. With 15 parameters and 4 required, the lack of any parameter semantics in the description forces the agent to rely solely on schema, which is insufficient for understanding relationships, defaults, or constraints beyond basic types.
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 ('Render and validate'), the resource ('a structured normal-batch job definition'), and the key scope ('without writing it'), distinguishing it from sibling submit/write tools. It explicitly differentiates from a writing operation, making purpose unambiguous.
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 phrase 'without writing it' implies use for a dry-run/preview, but there is no explicit guidance on when to choose this over validate_job or submit_job, nor any exclusions or alternatives named. Usage must be inferred.
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?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the 'login node' scope and mentions the dual list/search functionality, but does not explain search semantics or output format, which would be valuable beyond annotations.
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 that directly states purpose and scope. No redundant or filler content; every word earns its place.
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?
Despite its simplicity, the description lacks explicit details on return values or parameter behavior, and there is no output schema to compensate. It is minimally viable but leaves gaps for an agent to know what to expect when invoking the tool.
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 indirectly implies the 'query' parameter via the word 'search', without explaining format, wildcard support, or case sensitivity. This is insufficient for a parameter-heavy tool, even with one 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 tool lists or searches environment modules available on the login node. This specific verb+resource combination (list/search modules) distinguishes it from sibling tools like list_jobs or list_files.
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: if you need to know which environment modules are available, use this tool. However, it does not explicitly mention alternatives or when not to use it, leaving room for ambiguity among sibling list tools.
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?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description does not need to restate that. It adds the scope of what is checked (profile, connection, runtime, TCS commands, path limits), which is useful, but it gives no further behavioral insight such as return format, potential latency, or whether a connection is required.
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 of 13 words, front-loaded with the verb 'Check'. Every word earns its place, listing exactly what the tool examines. It is appropriately sized for a status-check tool and avoids redundancy or filler.
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?
For a tool with no parameters, strong annotations, and no output schema, the description is fairly complete. It clearly states what is checked. However, it does not explicitly mention what the tool returns (e.g., a status report, errors, or success indicator), which could be ambiguous. Still, the tool name and 'Check' imply it retrieves status, so it is nearly complete.
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?
The tool has 0 parameters, so the baseline is 4. The input schema is empty, and the description correctly does not attempt to explain parameters. The listed items (profile, connection, etc.) are aspects of status, not parameters, so the description adds no parameter semantics but none are 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 verb 'Check' and specifies the resource as TCS system status, listing concrete aspects: profile, connection, runtime, TCS commands, and configured path limits. This distinguishes it clearly from sibling tools focused on jobs, files, or commands, and the title 'TCS system status' reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios. The sibling list offers context, but the description itself lacks any 'use this when' or 'for other details use X' statements, leaving usage entirely implicit.
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?
Annotations indicate destructiveHint: true, but the description clarifies this is a 'preview' and returns a token, adding crucial context that no actual cancellation occurs. This goes beyond the annotations and helps avoid misinterpretation.
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?
A single, front-loaded sentence with no redundancy. Every word adds value and the structure is clear.
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 2 parameters, no output schema, and a sibling confirm_action, the description leaves the 'reason' parameter undocumented and doesn't explain the workflow with confirm_action. The tool is simple but the description does not fully cover what the agent needs for 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%, so the description must explain parameters. It only hints at jobId with 'current owned job' and omits the 'reason' parameter entirely.
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 'Preview' and identifies the resource as 'cancellation of a current owned job', also stating the output is a confirmation token. This clearly distinguishes it from sibling tools like submit_job or confirm_action.
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 implies a preview step before actual cancellation and notes the job must be 'current owned', providing clear context. However, it does not explicitly mention alternatives or when not to use, such as referencing confirm_action for finalizing.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the key safety profile. The description adds 'without submitting it,' which reinforces the read-only nature but does not disclose additional behavioral traits such as error handling, return format, or permission requirements. It is consistent with annotations but not overly informative.
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, well-structured sentence. It leads with the verb 'Validate' and immediately specifies both input modes and the non-submission behavior. No unnecessary words.
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's complexity (nested definition object, no output schema, and multiple sibling tools), the description is quite terse. It clarifies what is validated but does not explain what validation entails (e.g., syntax check, resource availability) or what the response/error behavior will look like. Adequate for a simple validator, but more context would improve completeness.
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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does map the two top-level parameters: scriptPath to an existing PJM script and definition to a structured normal-batch job definition. However, it does not elaborate on any nested fields within the definition object, leaving the schema to carry that burden. Minimal compensation.
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 purpose: to validate job definitions without submitting them. It explicitly names the two target input types (PJM script and structured normal-batch job definition), distinguishing it from sibling tools like submit_job and render_job.
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 phrase 'without submitting it' establishes a clear use case: pre-submission validation. While it does not explicitly mention alternative tools, the contrast with submit_job is implied, and the context is sufficiently clear for an agent to know when to use this tool.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context by specifying it returns output paths and supports both current and historical jobs. It does not discuss rate limits, authentication, or potential errors, but for a read-only get operation with strong annotation coverage, the added context is adequate.
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 that is front-loaded with the core action ('Get details and output paths') and includes a crucial qualifier ('current or historical'). No wasted words.
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?
For a simple get operation with one parameter and strong annotations, the description covers the core function and return focus (details and output paths). There is no output schema, but the description hints at the return content. It does not provide exhaustive details, but the tool's simplicity does not demand more.
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?
There is one parameter, jobId, which is self-explanatory from the name. The schema provides a pattern for allowed formats. The description does not explicitly explain the parameter, but given the tool name and the phrase 'one job,' the meaning is unambiguous. Schema description coverage is 0%, but the single parameter's purpose is evident.
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 resource 'details and output paths for one current or historical job.' This distinguishes it from sibling tools like list_jobs (list all) and get_job_stats (statistics) by specifying it targets one job and includes output paths.
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 implies usage for retrieving details of a specific job, and the phrase 'current or historical' clarifies temporal scope. It does not explicitly name alternatives like get_job_stats, but the 'one job' phrasing clearly differentiates from list_jobs. Clear context without explicit exclusions.
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?
Annotations already declare read-only, idempotent, non-destructive. The description adds the completed-job constraint and the two output modes, which are useful behavioral hints. It doesn't describe error behavior or return format, but annotations lower the bar.
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 with verb and resource, no filler words.
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?
The description is adequate for a simple read-only tool with strong annotations, but it lacks parameter details and return value structure. With no output schema and 0% param coverage, more explanation of 'basic' vs 'node-level' and 'detailed' would make it complete.
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 descriptions cover 0% of parameters, and the description does not explain jobId or detailed. The tool name and description imply jobId references a job, but the exact format and the effect of 'detailed' are not documented.
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?
Clearly states the tool gets statistics for a completed job, distinguishing it from sibling tools like get_job (job details) and list_jobs (job lists). The phrase 'basic or node-level' adds specificity.
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 conveys it is for completed jobs, implying it should not be used for running/pending jobs. However, it doesn't explicitly name alternatives or contrast with get_job, so not a perfect 5.
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?
The 'Read' verb aligns with the readOnlyHint and destructiveHint annotations, and the description adds specific context about what data is accessed (PJM resource-group availability, account limits). However, it does not disclose any additional behavioral traits such as rate limits, permission requirements, or potential side effects, though annotations already cover safety adequately.
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 front-loads the verb 'Read' and immediately specifies the exact resources. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with strong annotations, the description fully captures the scope and expected data. It indicates what will be returned (availability and limits) even without an output schema, making it sufficiently complete for an agent to select and invoke correctly.
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?
The input schema has no parameters, and the description does not need to explain parameters. With 0 parameters, the baseline score is 4, and the description adds no conflicting or redundant parameter information.
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 tool reads 'PJM resource-group availability' and 'this account's scheduler limits', which is a specific verb+resource combination. This distinguishes it from sibling tools like list_jobs, list_files, and list_modules, which focus on other entity types.
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 resource availability and scheduler limits, but does not explicitly say when to use this tool over alternatives or provide exclusions. It relies on the reader to infer context from the resource scope mentioned.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description adds meaningful behavior beyond annotations: it supports reading from the beginning or tailing a specified number of lines, and it operates within configured roots, which aligns with openWorldHint=false. It does not mention return format or error behavior, but the core behavioral modes are disclosed.
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 that front-loads the action ('Read') and packs both usage modes without waste. Every phrase earns its place; no filler.
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?
For a simple read tool with readOnly/idempotent annotations, the description covers the primary behaviors (head/tail) and the root restriction. It lacks an explicit mention of return content or error handling, but given the tool's simplicity and the presence of a clear name and schema, it is reasonably complete.
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?
Schema has zero description coverage, so the description must compensate. It explains that tailLines controls the number of lines to tail, and that the tool reads from the beginning by default. However, it leaves maxBytes unexplained (its role in limiting the beginning read) and does not clarify the path format, so parameter semantics are only partially addressed.
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 'Read' and identifies the resource ('remote text file') and key scope ('inside configured roots'). It distinguishes from siblings like write_file, search_files, and list_files by specifying both head and tail reading modes.
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?
It clearly implies when to use this tool (reading file contents within configured roots), which sets context. However, it does not explicitly name alternative tools like search_files for content searching or list_files for directory listing, nor does it state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations by disclosing that the token is short-lived and single-use, implying the action will execute only once and the token will be consumed. It complements the destructiveHint (true) annotation without contradicting it.
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?
A single sentence, front-loaded with the primary verb and resource, containing no fluff. Every word contributes to understanding the tool's purpose and usage.
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?
For a simple one-parameter tool with destructiveHint and no output schema, this description is largely complete. It covers what to supply (token) and the precondition (previewed action), though it could slightly benefit from mentioning where the token originates or what 'TCS' stands for, but such details are not critical.
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?
The schema only defines 'token' as a string with minLength 20. The description adds essential semantics: the token is short-lived, single-use, and tied to a previously previewed action. With 0% schema description coverage, this compensation makes the parameter's purpose clear.
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 a specific verb ('Execute') and resource ('previously previewed action'), clearly differentiating this tool from siblings by requiring a token from a prior preview. It precisely identifies what the tool does and its unique scope.
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 implies usage context: it should be used only when you have a short-lived, single-use token from a previous preview. It does not explicitly mention alternatives or when not to use it, but the condition 'previously previewed' provides clear guidance without excluding alternatives.
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:

[![tcs_mcp_codex MCP server](https://glama.ai/mcp/servers/exthnet/tcs_mcp_codex/badges/card.svg)](https://glama.ai/mcp/servers/exthnet/tcs_mcp_codex)

Score Badge

Copy to your README.md:

[![tcs_mcp_codex MCP server](https://glama.ai/mcp/servers/exthnet/tcs_mcp_codex/badges/score.svg)](https://glama.ai/mcp/servers/exthnet/tcs_mcp_codex)

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/exthnet/tcs_mcp_codex'

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