Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AMEVA MCP Advanced Toolkit scan this source file for hardcoded secrets"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This repository provides a set of high-performance, WebAssembly (WASM) based Model Context Protocol (MCP) tools designed to enable secure, sandboxed, and zero-host-pollution operations directly within local runtime environments.
All operations are executed within the virtual memory of WASM runtimes compiled from Rust and C, ensuring zero-footprint local processing without host pollution or external network dependency.
Detailed tool-specific specifications, API schemas, and interface structures are available in the WASM Engines Specification (Local File Link) and WASM Engines Specification (GitHub Relative Link).
# | Tool Name | Engine/Language | Functional Description |
1 |
| C (QuickJS) | Zero-dependency, isolated JavaScript execution environment. |
2 |
| C (Capstone) | Local binary disassembler for x86/ARM machine code analysis. |
3 |
| Rust | Raw byte structure parsing and reconstruction for damaged ZIP/PNG/JPEG/SQLite files. |
4 |
| Rust | Least Significant Bit (LSB) steganographic encoder. |
5 |
| Rust | Steganographic decoder to extract hidden payload from images. |
6 |
| Rust | High-speed, local image compression and format conversion (WebP/AVIF). |
7 |
| Rust (Polars) | In-memory massive CSV/DataFrame query engine with SQL support. |
8 |
| Rust | Secure personal identifiable information (PII) masking tool for PDF documents. |
9 |
| Rust | Static analysis scanner for hardcoded API keys, tokens, and credentials. |
10 |
| Rust (ONNX) | In-browser semantic vector similarity search via local ONNX embeddings. |
Related MCP server: Code Context Provider MCP
Rust and target wasm32-unknown-unknown
Node.js 18 or higher
rustup target add wasm32-unknown-unknown
npm installnpm run build:allTo integrate this toolkit into Cursor, Claude Desktop, or other MCP clients, add the following configuration to your mcpServers profile:
{
"mcpServers": {
"ameva-advanced": {
"command": "node",
"args": ["C:/ameva/AMEVA-MCP-Advanced-Toolkit/src/proxy.js"]
}
}
}mcp_manifest.json : System-wide MCP tool schema definitions.
package.json : Build automation pipeline and dependencies.
src/proxy.js : JSON-RPC bridge handler bridging MCP clients to WASM modules.
wasm/ : Sub-directory housing the source code and build workflows of the WASM engines.
Zero Host Pollution: No temporary or persistent files are written to the host filesystem during operations.
Offline First: All computations are performed strictly inside the runtime's memory layout; network traffic is disabled.
Sandboxed Execution: Virtual execution domains isolate operations, mitigating host-level security vulnerabilities.
AMEVA Universe — uno-km
의심스러운 .exe나 기계어 바이너리 파일을 호스트 PC에서 직접 실행하지 않고 WASM 격리 환경에서 x86_64/ARM64 어셈블리로 디스어셈블하여 분석합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| binary_base64 | Yes | 분석할 바이너리 파일의 Base64 인코딩 문자열 | |
| arch | Yes | 타겟 아키텍처: x86_64 | arm64 | x86 | |
| mode | No | 출력 모드: disasm | strings | imports | headers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the key behavioral trait: analysis in a WASM isolated environment without host execution. However, it does not address other important aspects like response format, rate limits, or data handling. Minimal but adequate for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence in Korean, concise and front-loaded with the main purpose. No unnecessary text, but could be slightly more structured (e.g., bullet points for clarity).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and isolation context, but lacks details about output (e.g., what the disassembly looks like, what 'strings' mode returns) despite having no output schema. For a tool with 3 parameters and no output schema, more contextual completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% parameter coverage with descriptions (binary_base64, arch with enums, mode with enums). The description adds no extra parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool disassembles suspicious binaries (exe/machine code) in a WASM-isolated environment without execution, outputting x86_64/ARM64 assembly. It distinguishes from siblings like execute_sandbox which likely executes rather than disassembles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to analyze a binary without executing it, but lacks explicit guidance on when not to use it or alternatives (e.g., execute_sandbox for execution). No explicit when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Docker 설치 없이 브라우저 WASM 메모리 내 격리된 가상 환경에서 JavaScript 코드를 안전하게 실행하고 즉시 소멸시킵니다. 파일시스템/네트워크 접근이 완전히 차단됩니다.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | 실행할 JavaScript 소스 코드 | |
| timeout_ms | No | 최대 실행 시간 (ms, 기본값: 5000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses isolation, immediate destruction after execution, and blocked file/network access. However, it omits details about output format, error handling, or memory management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action and includes key constraints. It is concise without being overly terse, though it could be split into two sentences for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing code in a sandbox) and no output schema, the description covers execution environment and restrictions. Missing details include error handling, async execution behavior, and what the output looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no parameter-specific details beyond what the schema provides (e.g., code is JS source, timeout has default 5000ms). The general safety context is helpful but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes JavaScript code in a sandboxed WASM environment, distinct from all sibling tools. It uses specific verbs ('execute', 'destroy') and specifies the resource ('JavaScript code in isolated virtual environment').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for safe JS execution without file/network access, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PNG/JPEG 이미지를 외부 서버로 전송하지 않고 100% 로컬 WASM 환경에서 무손실/유손실 압축하고 WebP/AVIF 등 원하는 포맷으로 일괄 변환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| images | Yes | 처리할 이미지 목록 | |
| target_format | No | 출력 포맷: webp | avif | png | jpeg | |
| quality | No | 압축 품질 (0-100, 기본값: 85) | |
| lossless | No | 무손실 압축 여부 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the disclosure of local WASM execution and no external transfer is key. However, it does not mention format-specific constraints (e.g., lossless not for JPEG), performance, or input format restrictions beyond PNG/JPEG.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, front-loaded with all critical information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output description. With no output schema, the description should explain what the tool returns (presumably converted images), which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The description adds context but does not provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compresses PNG/JPEG images locally using WASM, supports lossless/lossy, and converts to WebP/AVIF. It distinguishes from sibling tools which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies local processing for privacy but doesn't state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
수백만 줄의 CSV/TSV 데이터를 Rust 기반 Polars 엔진으로 브라우저 내에서 초고속 처리합니다. 필터링, 정렬, 집계, JOIN 등 SQL 쿼리를 지원합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_data | Yes | 처리할 CSV 데이터 문자열 (또는 파일 경로) | |
| query | Yes | 실행할 SQL 쿼리 또는 DataFrame 연산 체인 | |
| output_format | No | 출력 포맷: csv | json | markdown_table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions in-browser processing and speed, but does not disclose data privacy, limits, error handling, or whether data stays local. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are efficient and front-loaded with the core purpose. Every sentence adds value: first sentence states technology and scope, second lists capabilities. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description covers functionality, technology, and supported operations. However, it lacks details on error handling, performance bounds, or return format (though output_format param exists). Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context (CSV/TSV processing) but does not significantly expand on parameter meanings beyond the schema. The query parameter is already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool processes CSV/TSV data using a Rust-based Polars engine in-browser with SQL support, which is a specific verb-resource combination. It distinguishes itself from unrelated siblings like disassemble_binary or optimize_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tabular data processing and lists supported operations (filtering, sorting, aggregation, JOIN), but does not explicitly state when not to use it or mention alternatives. Context is clear given sibling tools are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
손상된 ZIP, PNG, JPEG, SQLite 파일의 원시 바이트 구조를 Rust 복구 엔진으로 역추적하여 복구합니다. 파일 시그니처를 재건하고 가능한 데이터를 카빙합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| file_base64 | Yes | 복구할 손상된 파일의 Base64 인코딩 문자열 | |
| file_type | No | 파일 포맷 힌트: zip | png | jpeg | sqlite | auto | |
| strategy | No | 복구 전략: carve | header_fix | deep_scan |
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 explains the recovery approach (reverse-tracking raw bytes, rebuilding signatures, carving) but does not disclose potential side effects, authentication needs, or rate limits. This is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key information, and contains no unnecessary words. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description could explain return values or failure modes. It does not. However, given the sufficient schema coverage and focused purpose, it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description adds no additional parameter-specific meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'recover' and the resource 'damaged ZIP, PNG, JPEG, SQLite files', distinguishing it from sibling tools like disassemble_binary or steg_decode, which have unrelated purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when files are corrupted, but does not explicitly state when to use or avoid this tool vs alternatives. However, the sibling tools are clearly unrelated, making the context sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
대외비 PDF 문서에서 주민번호, 계좌번호, 이메일, 전화번호 등 개인정보를 오프라인 WASM 환경에서 완전히 마스킹한 새 PDF를 생성합니다. 외부 서버로 1바이트도 전송하지 않습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| pdf_base64 | Yes | 처리할 PDF 파일의 Base64 인코딩 문자열 | |
| patterns | No | 탐지할 패턴 목록 | |
| custom_regex | No | custom_regex 선택 시 사용할 정규표현식 | |
| mode | No | 처리 모드: redact(마스킹) | extract(텍스트 추출) | report(탐지 보고서만) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: offline WASM processing, complete masking of personal information, and zero external data transmission. It does not detail error handling or performance constraints, but the core safety profile is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in Korean, front-loaded with purpose and key operational characteristic (offline, no data transmission). No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains purpose and privacy behavior but does not specify the return format (e.g., base64 string or file path) or mention error handling. Given the absence of an output schema, this missing detail reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds context about which data types are targeted (e.g., Korean SSN, bank accounts) that aligns with enum values, but does not provide additional parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new PDF with fully masked personal information (e.g., Korean SSN, account numbers, email, phone) from confidential PDFs in an offline WASM environment. It explicitly distinguishes itself from sibling tools like scan_secrets by focusing on redaction rather than detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for privacy-sensitive redaction, mentioning offline operation and no data transmission. However, it does not explicitly specify when to use this tool versus alternatives (e.g., scan_secrets for scanning only) or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
소스코드 파일이나 디렉토리를 커밋 전에 스캔하여 하드코딩된 AWS/GCP/Slack API 키, DB 비밀번호, JWT 토큰 등을 탐지하고 파일명 및 라인 번호를 포함한 경고 보고서를 생성합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | 스캔할 소스코드 파일 목록 | |
| entropy_threshold | No | 엔트로피 임계값 (기본값: 4.5, 높을수록 민감도 낮음) | |
| output_format | No | 출력 포맷: report | json | sarif |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It states the tool scans and generates a report but omits details like whether it modifies files, performance impact, or file size limits. This is adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and output. Every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema parameter coverage and the description explaining the output (warning report with file names and line numbers), the description is largely complete. Minor missing details (e.g., report format structure) prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage). The tool description adds no additional semantic meaning beyond providing the overall context of pre-commit scanning. Thus, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a scanner for secrets in source code, specifically mentioning targeted types (AWS/GCP/Slack API keys, DB passwords, JWT tokens) and the output (warning report with file names and line numbers). This specificity distinguishes it from sibling tools like disassemble_binary or execute_sandbox.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool should be used 'before commit,' providing clear context for its usage. However, it does not explicitly mention when not to use it or alternative tools, which would further aid decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
소스코드나 문서에서 자연어 질문으로 의미 기반(Semantic) 검색을 수행합니다. ONNX 임베딩 모델을 WASM으로 구동하여 외부 API 없이 로컬에서 벡터 유사도 검색합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 자연어 검색 질문 (예: '계좌 이체 처리하는 부분 어디야?') | |
| documents | Yes | 검색할 문서/파일 목록 | |
| top_k | No | 반환할 최상위 결과 수 (기본값: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the behavioral trait of running an ONNX embedding model locally as WASM without external APIs. This is good transparency. However, it omits potential limitations like language restrictions or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two compact sentences, front-loading the core purpose (semantic search) and then providing technical detail (local ONNX/WASM execution). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the search mechanism but does not describe what the tool returns (e.g., similarity scores, ranked documents). Since there is no output schema, this is a notable gap. The document parameter structure is detailed in schema, so that part is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 3 parameters described). The description adds minimal additional semantic value beyond the schema: it mentions 'natural language question' for query and 'documents/files list' for documents, which are already in schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies it performs semantic search on source code or documents using natural language queries. It distinguishes the local execution via ONNX/WASM, setting it apart from any API-based search. No sibling tools perform similar semantic search, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives or when not to use it. While sibling tools are largely unrelated, some could be confused (e.g., process_dataframe for data processing). No guidance on preferred contexts or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
스테가노그래피로 인코딩된 이미지에서 숨겨진 기밀 데이터를 추출합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| steg_image_base64 | Yes | 기밀 데이터가 숨겨진 이미지의 Base64 문자열 | |
| password | No | 인코딩 시 사용한 비밀번호 (선택) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits like file size limits, supported image formats, or that the password parameter may be required for extraction, despite being marked optional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of return values. For a data extraction tool, the output format (e.g., string, file) is critical but omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds minimal value beyond the schema, only specifying 'hidden confidential data'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'extracts' and the resource 'hidden confidential data from steganography-encoded images'. It distinguishes from sibling tool steg_encode by implying the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like steg_encode or other extraction methods. Lacks context such as prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
임의의 기밀 텍스트나 바이너리 데이터를 PNG/BMP 이미지의 픽셀 LSB에 육안으로 식별 불가능하게 숨깁니다 (스테가노그래피 인코딩).
| Name | Required | Description | Default |
|---|---|---|---|
| cover_image_base64 | Yes | 커버 이미지(PNG/BMP)의 Base64 문자열 | |
| secret_data | Yes | 숨길 기밀 텍스트 또는 Base64 인코딩된 바이너리 | |
| password | No | 데이터 암호화에 사용할 비밀번호 (선택) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses LSB insertion and invisibility, but omits important behaviors like output format, image capacity limits, potential quality degradation, and requirement for steg_decode to retrieve data. Since no annotations exist, description could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the core functionality. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a steganography tool with no output schema, the description lacks return value details (e.g., encoded image format), capacity constraints, and prerequisites. It is minimally adequate but could better support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds limited value. It echoes parameter descriptions (e.g., 'secret text or binary', 'password for encryption') but does not provide additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (hide/inject), resource (PNG/BMP image pixel LSBs), and technique (steganography). It distinguishes itself from siblings like steg_decode and other unrelated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. No mention of prerequisites, limitations, or when not to use it (e.g., for non-image data, or if detection avoidance is critical).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0disassemble_binaryexecute_sandboxoptimize_imagesprocess_dataframerecover_fileredact_pdfscan_secretssemantic_searchsteg_decodesteg_encodeEach tool has a clearly distinct purpose: binary disassembly, sandboxed JS execution, image optimization, dataframe processing, file recovery, PDF redaction, secret scanning, semantic search, and steganography encode/decode. No two tools overlap in functionality, making selection unambiguous.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., disassemble_binary, execute_sandbox, steg_decode). The naming convention is uniform and predictable.
With 10 tools, the set is well-scoped for an 'Advanced Toolkit' covering security, data processing, and file analysis. Each tool serves a distinct and useful purpose, and the count is neither too sparse nor overwhelming.
The tool surface covers a broad range of security and data processing tasks (binary analysis, sandboxed execution, image optimization, dataframe processing, file recovery, PDF redaction, secret scanning, semantic search, steganography). Minor gaps exist, such as the absence of general encryption/decryption or network analysis tools, but the set is comprehensive for its intended scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
84+ free local-first tools: image, PDF, docs, dev utils. Wasm, zero upload, x402 API.
Convert and compress PDFs and images, redact personal data, and run text and data utilities.
144 deterministic file tools: PDF, image, media, convert, analyze. Connect in one click (OAuth).
Sandbox workspace tools: search, file read, DB queries, integrations. Returns synthetic data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/uno-km/MCP-Advanced-Toolkit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
