lsth-mcp

by TranNhatPhi

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
file_search and file_tree both accept queries and return file matches, and file_list overlaps with simple enumeration. The descriptions clarify flat list versus tree output, but an agent may still hesitate when choosing among the three discovery tools.
Naming Consistency4/5
Most tools follow a predictable resource-first snake_case pattern like file_read, csv_write, identity_resolve, and bom_extract. A few names such as excel_sheets, program_status, and audit_tail are noun phrases rather than command-style, but the overall convention is readable and consistent.
Tool Count3/5
16 tools sits in the borderline-heavy range, and the three file-discovery tools plus three format-specific writers add some redundancy. The domain-specific tools for identity, templates, techpack/BOM processing, status, and audit appear purposeful, so the count is not excessive for the intended workflow.
Completeness3/5
File discovery, read/write, format export, parsing, and audit coverage are present. Obvious gaps remain: no file delete/move/update, no template listing, and truncated file searches have no continuation mechanism, so agents may hit dead ends in larger scans.
Average 2.8/5 across 16 of 16 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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?
Annotations are not provided, so the description carries the full burden of behavioral disclosure. It only says 'list files,' which implies a read operation, but it does not describe recursion behavior, access permissions, side effects, or the output format. The description is severely inadequate for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It omits essential information about behavior and parameters, making it more of a placeholder than an effective description.
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 presence of multiple file-related sibling tools and no annotations, this description is completely inadequate. It does not explain the tool's behavior, parameters, or usage context. The output schema exists but does not compensate for the lack of narrative guidance.
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 of the three parameters (root, limit, pattern). An agent cannot infer the meaning or purpose of these parameters from the description, so it adds no value beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Liệt kê file trong vùng dữ liệu cho phép' translates to 'List files in the allowed data area.' It names a verb and resource, but 'allowed data area' is vague and does not differentiate from sibling tools like file_tree or file_search. It is not a tautology but lacks the specificity needed for an agent to understand what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like file_tree (likely a directory listing) or file_search (likely pattern-based search). No conditions, exclusions, or prerequisites are mentioned, leaving the agent to guess.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'write JSON' and gives no indication of side effects, overwrite behavior, file creation, server interaction, dry-run semantics, or response behavior. An agent cannot predict what happens when the tool is invoked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but this is under-specification rather than effective conciseness. The single clause adds almost no actionable information and does not earn its place because it only restates the tool's purpose in vague terms.
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?
For a tool with 4 parameters, 0% schema coverage, no annotations, and multiple sibling write tools, the description is far too incomplete. It does not explain what to provide, what the tool will do, what side effects may occur, or when it should be selected. The presence of an output schema does not compensate for the missing invocation guidance.
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 mentions none of them: 'data', 'path', 'server', and 'dry_run' are all undocumented in the description. The agent is left without any explanation of the required data shape, path semantics, server default, or dry-run behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ghi JSON' translates to 'write JSON', which largely restates the tool name. The added phrase about server-to-server exchange format and contract F2 hints at a domain but does not specify what resource is written, whether it writes to a file or server, or how it differs from file_write, csv_write, or excel_write.
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 about when to use this tool versus alternatives. The mention of 'contract F2' and 'server exchange' weakly implies a context, but there are no conditions, exclusions, or comparisons to sibling tools such as file_write or csv_write.
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?
Annotations are completely absent, so the description carries full responsibility for behavioral disclosure. It does not mention whether the operation is read-only, what happens on failure, any side effects, or response format. The description adds nothing beyond the bare conversion statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but critically under-specified. It front-loads the core purpose but omits all essential operational details. This is not efficient conciseness; it is insufficient specification.
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?
With 5 parameters (3 required) and no schema descriptions or annotations, the description is grossly incomplete. It does not clarify the expected input values, the meaning of market/customer, or the output structure. Even though an output schema exists, the description fails to provide any context needed to call the 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%, and the description does not explain any of the five parameters (value, from_system, to_system, market, customer). The description only lists system names, giving no clue about expected value formats or the role of optional parameters. It fails to compensate for the missing schema descriptions.
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 states a specific action: converting codes between systems (LS-style, customer style, UPC, material code). It names the exact resource types, which clearly distinguishes it from file/Excel siblings. However, it does not explicitly contrast with any alternative, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of which systems are supported or any constraints. The one-line description only states the core function, leaving the agent to infer usage context.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does not mention output format, side effects, required permissions, or what the '17 thành phần' refers to. The metaphorical language adds no concrete behavioral detail.
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 short sentence, which is concise in length, but it is not front-loaded with useful information. The metaphor does not 'earn its place' because it fails to communicate the tool's purpose clearly.
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 no annotations, and the description is extremely incomplete. It does not explain what the 17 components are, what 'built' and 'waiting to fill the gap' mean in concrete terms, or what the output schema contains. For a status tool, this is critically insufficient.
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 zero parameters, so the schema already covers everything. The description adds no parameter information, but since there are no parameters to explain, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is metaphorical and vague: 'Bức tranh 17 thành phần: cái nào đã dựng, cái nào đang chờ lấp khoảng trống.' It implies a status overview of 17 components but does not clearly state the tool's action (e.g., 'Returns status of program components') or specify what those components are. It is not a precise verb+resource statement and offers no differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus any alternatives. No mention of prerequisites, conditions, or typical scenarios. The description is entirely silent on usage 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 carries the full burden. It discloses the default draft banner behavior but fails to mention whether files are overwritten, how errors are handled, or what the return value looks like. For a write operation, this is incomplete.
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 in Vietnamese, easy to parse and free of unnecessary detail. It is efficient but very short, so it does not waste words.
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?
With 6 parameters, 2 required, no schema descriptions, and no annotations, the description is severely incomplete. It does not explain the expected structure of rows, the meaning of path, or the effect of dry_run, making it inadequate for correct 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?
Schema description coverage is 0%, and the description does not explain any of the parameters. It only alludes to the draft banner default without naming draft_banner, and provides no meaning for path, rows, server, dry_run, or sheet_name.
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 exports a table to Excel and mentions a default draft stamp, giving a specific verb and resource. However, it does not differentiate from sibling tools like csv_write or json_write, which also write data files, so it lacks sibling distinction.
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 such as csv_write or json_write. It does not mention exclusions, conditions, or contexts that would help an agent decide between them.
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 carry the full burden of behavioral disclosure. It mentions 'Đi qua cổng quyền ghi' (go through write permission gateway), implying a permission check, but does not explain overwrite behavior, directory creation, the effect of dry_run, or what the output schema contains. For a write operation, this is insufficient.
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 extremely short – a single sentence. While conciseness is good, this is under-specification rather than efficient writing. It lacks structure and does not front-load critical details like parameters or behavior. It is short, but not 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?
Given that there are 4 parameters, an output schema (not described), and no annotations, the description is severely incomplete. It does not explain the purpose of dry_run, the meaning of server='gateway', or what the response looks like. An agent would struggle to call this tool correctly without inspecting the schema further, and even then the schema lacks descriptions.
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%, meaning the description must explain all parameters. It does not mention path, content, server, or dry_run at all. The schema itself provides only titles, no descriptions. The agent has no additional meaning beyond the parameter names, which is very poor for a 4-parameter tool.
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 states a specific verb ('Ghi file chữ' – write text file) and a clear target location (data/work or data/out). However, it does not distinguish this from sibling write tools like csv_write, json_write, or excel_write, which all write files but with different formats. The purpose is clear but not differentiated.
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. It does not mention that csv_write should be used for CSV files, json_write for JSON, etc. The description only states where to write, not why an agent would choose this tool over its siblings.
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 states that parsing occurs from a PDF to a Style entity, but does not mention error behavior, required file access, page-limit semantics, or any side effects/assumptions.
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 very short and contains no filler, but it is under-specified. The 'S1 —' prefix adds little value and the brevity comes at the cost of missing important guidance.
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?
Even with an output schema present, the description omits parameter semantics, usage context, and relationship to sibling parsing/extraction tools. For a 2-parameter tool with zero annotation coverage, this is insufficient for an agent to confidently select and invoke it 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 does not mention either parameter ('file' or 'max_pages'). The agent gains no additional meaning beyond the bare schema types, so it cannot infer how the file should be provided or how max_pages affects parsing.
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 'bóc' (parse/extract), names the resource 'tech pack PDF', and specifies the output entity 'Style'. This makes the core action and target clear, though it does not explicitly distinguish it from sibling tools like bom_extract or bom_diff.
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 about when to use this tool versus alternatives. It only states what the tool does, with no mention of file types, prerequisites, or scenarios where another tool should be preferred.
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 the full burden. It states the core transformation (xlsx to BomLine[] per the F2 contract) but does not disclose error behavior, file requirements, limit/sheet handling, or side effects. It is more informative than a tautology but leaves behavioral questions unanswered.
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 compact sentence with no filler. However, the cryptic 'S1' and 'F2' add noise for uninitiated agents, and the structure front-loads a label rather than the core value.
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 three parameters, no annotations, and an output schema not shown, the description is incomplete: it does not explain the F2 contract, parameter meanings, prerequisites (e.g., file already uploaded), or when to choose this over excel_sheets/bom_diff.
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 for the three parameters. It provides no explanation of 'file', 'limit', or 'sheet' semantics beyond implying the file is an xlsx BOM. The parameter names are self-suggestive but not described.
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 identifies a specific action ('bóc' = extract) on a specific resource (BOM xlsx) with a defined output (BomLine[]), making it distinguishable from siblings like bom_diff and excel_sheets. However, the cryptic prefixes 'S1' and 'F2' are unexplained, which slightly reduces self-contained 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 guidance is provided about when to use bom_extract versus alternatives such as excel_sheets or bom_diff. There is no mention of preconditions, which contract version applies, or exclusions. The implication is only from the name and action.
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 carries the full burden. It discloses the content of the audit trail (who, when, file, result) but does not state whether this is a read-only operation, any permission requirements, or side effects. The verb 'xem' implies viewing but does not explicitly confirm safety or lack of 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 short sentence with no wasted words, front-loaded with the purpose. It is concise and efficient, though it is so minimal that it lacks detail. This is still appropriately sized for the simplicity of the tool.
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 one optional parameter and an output schema, but the description does not explain the parameter or provide usage context. It is adequate for a simple tool, but the missing parameter explanation and lack of behavioral context leave gaps that could confuse an agent. The output schema likely covers the return format, so that is not a major concern.
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 the 'limit' parameter at all. The agent is left to guess that 'limit' controls the number of recent calls returned, which is not obvious from the description alone. The description fails to add any meaning beyond the schema.
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 'xem' (view) and resource 'lệnh gọi gần nhất' (recent calls), and elaborates on the content: who called, when, which file was read, and the result. This clearly distinguishes it from siblings like file_read or file_list, which focus on file operations rather than audit logs.
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 provided on when to use this tool or how it compares to alternatives. The description only states what it does, leaving the agent to infer usage context. There are no exclusions, prerequisites, or references to sibling 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?
No annotations are provided, so the description carries the full burden. It discloses the encoding (utf-8-sig) and Excel compatibility, which is useful, but does not mention side effects like overwriting, file creation behavior, or error conditions. Since an output schema exists, return format is covered elsewhere, but the description is thin on 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?
The description is a single sentence with zero waste. It is front-loaded with the core purpose and the key encoding detail, making it efficient and easy to parse.
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 4 parameters, no annotations, and a minimal description, the tool is not fully specified. The description omits any guidance on optional parameters like server and dry_run, and does not explain the behavior beyond encoding. An agent would struggle to call this correctly without additional schema or tool knowledge.
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 parameter (path, rows, server, dry_run) or their meaning. The description fails to compensate for the schema's lack of documentation, leaving the agent to guess parameter semantics.
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 exports CSV with utf-8-sig encoding for Excel compatibility. This is a specific verb+resource that differentiates it from file_write, excel_write, and json_write, though it doesn't explicitly mention writing to a path.
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 a use case (Excel compatibility for Vietnamese diacritics) but does not explicitly contrast with alternatives or state when not to use it. It gives context but no exclusions.
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?
With no annotations provided, the description carries the full behavioral burden. It implies a non-mutating read operation ('lấy') and adds the useful 'approved' filtering trait, but it does not disclose error cases, authorization needs, or other behavioral details beyond what the verb itself suggests.
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 efficient sentence with no filler, and the core meaning is front-loaded after the brief 'F4' label. The only minor issue is that 'F4' is unexplained, though it does not prevent understanding.
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?
For a simple retrieval tool with an output schema, the description is minimally viable: an agent can infer the primary call using 'kind'. However, without semantics for market/customer and without sibling-routing guidance, the agent may not know how to use the optional parameters effectively.
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?
The description partially clarifies that 'kind' corresponds to the document type ('loại tài liệu'), but it gives no meaning for 'market' or 'customer'. Since schema description coverage is 0%, the description does not compensate enough for these two optional 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 uses a specific verb ('lấy' = get) and a specific resource ('file khuôn đã duyệt' = approved template file), scoped to a document type. It distinguishes the tool from generic file siblings by the 'approved template' concept, though it does not explicitly name an alternative sibling.
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 'cho một loại tài liệu' gives clear context for when to use this tool: when an approved template file for a document type is needed. However, it provides no guidance about when to supply optional market/customer parameters and no explicit when-not-to-use or alternative-tool routing.
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?
With no annotations provided, the description carries the burden of disclosing behavior. 'Read' implies a non-destructive operation and the format list adds useful scope. However, it does not mention output behavior, error cases, size limits, or how formats are parsed beyond the verb itself.
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 zero filler. It immediately states the action and then the supported scope. Every word earns its place.
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 four parameters, no annotations, and no parameter explanations, a one-line description is inadequate. While an output schema exists and may cover return values, the description omits important invocation context such as when to use it, what the optional parameters control, and how unsupported files are handled.
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 of the four parameters (path, limit, pages, sheet). It only lists supported file formats, which indirectly hints at pages and sheet but does not add explicit meaning beyond the schema's parameter names and defaults.
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 ('Đọc' / 'read') with a clear resource ('file') and enumerates supported formats: xlsx, pdf, csv, json, docx, txt. This distinguishes it from sibling write tools (file_write, csv_write, excel_write, json_write) and listing tools (file_list, file_tree), so an agent can tell it apart without opening schema.
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 the tool is for reading file contents and lists supported formats, but it does not explicitly state when to prefer this over siblings like file_search or file_list, nor does it mention any exclusions or alternative routing. Usage context is present but left to inference.
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?
With no annotations provided, the description must carry behavioral disclosure. It adds one useful trait: it reports conflicts rather than auto-selecting a value. But it does not mention side effects, required permissions, or failure 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?
One compact sentence with the core information front-loaded. The internal references 'S1' and 'nguyên tắc 3' are cryptic, but they do not prevent the main message from being delivered efficiently.
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?
There is an output schema, so return details are not required. Still, for a 3-parameter tool with no annotations, the description leaves bom_sheet undefined and relies on unexplained 'principle 3' context, making it minimally viable rather than 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 description coverage is 0%, so the description must explain parameters. It loosely maps 'tech pack' and 'BOM' to the two required file parameters, but it does not explain the optional bom_sheet parameter or specify expected input format (paths vs content).
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 ('so' – compare) and resource ('tech pack với BOM'), and states the outcome ('báo mâu thuẫn' – report contradictions). This clearly differentiates it from siblings like techpack_parse and bom_extract, which parse/extract rather than diff.
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 'S1' implies a step in a workflow, and the compare-and-report purpose gives an implicit use case. However, it does not explicitly state when to prefer this tool over alternatives, nor any when-not-to-use situations.
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?
With no annotations provided, the description carries the full burden. It states the tool lists sheets, implying a read-only operation, but does not explicitly disclose whether it is non-destructive or any side effects. It also does not mention error behavior (e.g., missing file) or return format, but given the existence of an output schema, some of that may be covered. The description is not misleading but is minimal in behavioral disclosure.
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 is front-loaded with the action ('Liệt kê sheet') and immediately followed by the purpose ('trước khi quyết định đọc sheet nào'). Every word serves a purpose, and there is no 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 tool's simplicity (one parameter, list operation) and the presence of an output schema (which likely defines the return format), the description is largely sufficient. It clearly states what it does and when to use it. The only missing piece is explicit error/edge-case handling, but for a list operation, this is a minor gap.
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 clarify the parameter. It mentions 'một file Excel', which tells the agent that the 'path' parameter should point to an Excel file. However, it does not specify format details, absolute/relative path requirements, or accepted extensions. This is partial compensation but not complete.
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 ('Liệt kê' = list) and a clear resource ('sheet của một file Excel' = sheets of an Excel file). It also adds context by indicating it should be used before deciding which sheet to read, which helps distinguish it from file_read or excel_write. This is unambiguous and specific.
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 implicitly gives usage guidance: use this tool to list sheets before reading one. It does not explicitly mention alternatives or when not to use it, but the phrase 'trước khi quyết định đọc sheet nào' clearly positions it in a workflow. It lacks explicit exclusions, but the context is sufficient for an agent to select it appropriately.
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?
With no annotations provided, the description carries the full burden. It discloses case-insensitivity and diacritics-insensitivity, the all-words-must-match requirement, the metadata-only scope, the scan_limit cap, and the meaning of truncated=true. This is exceptionally transparent for a search tool and goes well beyond minimal expectations.
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 structured into short, purposeful sentences that front-load the primary purpose and then detail matching rules, scope, and limitations. It is efficient without being terse, though it could be slightly tightened. The information density is high and each sentence 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 4 parameters, no annotations, and an existing output schema, the description covers the essential behavioral and semantic context: matching logic, root formats, metadata-only scope, and truncation. It does not explain the output structure (covered by the output schema) or edge cases like null root, but overall it equips an agent to call the tool 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?
Schema description coverage is 0%, so the description must compensate. It explains 'root' with concrete values (region names, S3 URIs, local folders) and defines query semantics with examples. It also indirectly explains scan_limit via truncation behavior, but 'limit' is not addressed. Overall, it adds substantial meaning for the key parameters, though not all.
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 and resource: 'Tìm file theo tên/đường dẫn' (Find files by name/path). It also explicitly clarifies scope with 'Chỉ tìm metadata, không tìm nội dung file' (only metadata, not content), distinguishing it from content-reading siblings like file_read. This makes the tool's purpose unmistakable.
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 query-construction rules (every word must appear in the path) and examples, which helps usage. However, it does not explicitly mention when to prefer this tool over file_list or file_tree, nor does it state when not to use it. The 'metadata only' note implies alternatives for content, but without naming them, guidance remains implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains case-insensitive and accent-insensitive matching, the meaning of limit and max_depth (with collapsed=true), matched_count, and scan_truncated, and notes that empty directories are excluded. This is a thorough disclosure of 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?
The description is front-loaded with purpose and then efficiently details parameters with line breaks for readability. Every sentence adds value, and the structure aids quick scanning. It is appropriately sized for a tool with five parameters and a rich output.
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?
Given the tool's complexity (5 optional parameters, output schema present), the description covers all parameters and key output fields (matched_count, scan_truncated). It explains the query matching logic, depth behavior, and truncation semantics. Nothing essential for an agent to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so exceptionally well: it explains root (as region name, S3 URI, or local path), query (with example and matching rules), limit, max_depth, and scan_limit, adding substantial meaning beyond the bare schema.
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's purpose: it searches a directory tree (MinIO/S3 or local) and returns a tree JSON plus a readable tree_text. It specifies the resource (directory tree) and the action (search/return), and distinguishes itself from flat-file listing or content search siblings by emphasizing the tree structure.
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 detailed usage guidance for each parameter, including examples for query and root, and explains behaviors like keeping parent branches of matched files and omitting empty directories. However, it does not explicitly state when to prefer this tool over alternatives like file_search or file_list, so it falls short of full exclusion guidance.
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:

[![lsth-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/TranNhatPhi/MCP_server_LS/badges/card.svg)](https://glama.ai/mcp/servers/TranNhatPhi/MCP_server_LS)

Score Badge

Copy to your README.md:

[![lsth-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/TranNhatPhi/MCP_server_LS/badges/score.svg)](https://glama.ai/mcp/servers/TranNhatPhi/MCP_server_LS)

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/TranNhatPhi/MCP_server_LS'

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