MIT
Eyevinn Open Source Cloud MCP Server
by EyevinnOSC
Eyevinn 오픈소스 클라우드 MCP 서버
이 MCP 서버는 로컬 컴퓨터 액세스가 필요한 Eyevinn 오픈 소스 클라우드 용 MCP 도구를 제공합니다. 예를 들어 OSC의 스토리지 버킷에 파일을 업로드하는 경우처럼 말입니다. OSC를 사용하여 솔루션을 설계하고 구축하기 위한 MCP 도구는 OSC 원격 MCP 클라이언트를 통해 액세스할 수 있는 원격 MCP 엔드포인트에서 제공됩니다.
로컬 MCP 서버에서 제공하는 기능
OSC의 MinIO 스토리지 버킷에 파일을 업로드합니다.
설정
Smithery를 통해 설치
Smithery를 통해 Claude Desktop에 Eyevinn 오픈 소스 클라우드 MCP 서버를 자동으로 설치하려면:
지엑스피1
개인 액세스 토큰
아직 Eyevinn OSC 계정 에 가입하지 않으셨다면 지금 가입하세요.
Eyevinn OSC 웹 콘솔에서 API 설정 으로 이동합니다(설정 > API 설정).
개인 액세스 토큰을 복사하세요
Claude Desktop과 함께 사용
Claude Desktop과 함께 사용하려면 claude_desktop_config.json 에 다음을 추가하세요.
{
"mcpServers": {
"local-mcp-osc": {
"command": "npx",
"args": ["-y", "@osaas/mcp-server"],
"env": {
"OSC_ACCESS_TOKEN": "<YOUR_TOKEN>"
}
},
"remote-mcp-osc": {
"command": "npx",
"args": ["-y", "@osaas/client-mcp"],
"env": {
"OSC_ACCESS_TOKEN": "<YOUR_TOKEN>"
}
}
}
}Related MCP server: Maasy MCP
개발
npx @modelcontextprotocol/inspector \
-e OSC_ACCESS_TOKEN=<osc-access-token> \
npx tsx src/index.ts특허
이 MCP 서버는 MIT 라이선스에 따라 라이선스가 부여됩니다. 즉, MIT 라이선스의 약관에 따라 소프트웨어를 자유롭게 사용, 수정 및 배포할 수 있습니다. 자세한 내용은 프로젝트 저장소의 LICENSE 파일을 참조하세요.
Available Tools
4 toolsosc_create_bucketA
Create a new bucket on Eyevinn Open Source Cloud Storage (OSC) Minio instance
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the minio instance | |
| bucket | Yes | Name of the bucket to create |
TDQS
A3.6/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description does not disclose behavioral traits such as idempotency (behavior if bucket already exists), required permissions, or side effects. A create operation modifies state, so transparency is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and resource, making it efficient.
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 no output schema and no annotations, but the description does not mention what the tool returns (e.g., success indicator) or any post-creation behavior. For a simple creation tool, this omission reduces 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 100% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Create') and the resource ('bucket') on a specific service. The sibling tools (osc_list_buckets, osc_list_files, osc_upload_file) are distinct, making this tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use guidance is given, the purpose is straightforward for creating a bucket, and siblings cover different operations (listing, uploading). This implicitly clarifies usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
osc_list_bucketsB
List all buckets on Eyevinn Open Source Cloud Storage (OSC) Minio instance
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the minio instance |
TDQS
B3.3/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details beyond listing. It does not mention permissions, pagination, error handling, or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 15 words, front-loaded with the verb and object. No wasted words, efficient and clear.
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 list operation with one required parameter and no output schema, the description is adequate but lacks information about the return format or any additional context needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema, which already describes the 'name' parameter with a pattern. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), resource (buckets), and context (Eyevinn Open Source Cloud Storage Minio instance). It distinguishes from sibling tools like osc_create_bucket and osc_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 Guidelines2/5
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. There is no mention of prerequisites or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
osc_list_filesA
List files in a bucket on Eyevinn Open Source Cloud Storage (OSC) Minio instance
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the minio instance | |
| bucket | Yes | Name of the bucket |
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It states the operation is to list files, which implies a read-only behavior, but it does not mention authorization needs, rate limits, error handling, or the format of the output. The description is minimally transparent.
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 directly states the tool's purpose. It is front-loaded with the key action and resource, and contains no extraneous information.
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 tool is simple with two parameters and no output schema. The description provides the essential purpose but lacks details on the return type (e.g., list of file names or metadata) and any specific behavior like pagination. It is adequate but not fully complete for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning beyond the schema; it does not elaborate on constraints like the name pattern or what constitutes a valid bucket.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'files in a bucket', and the specific service (Eyevinn OSC Minio instance). It effectively distinguishes itself from sibling tools like osc_create_bucket and osc_list_buckets by specifying the action on files within a bucket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when wanting to list files in a bucket, but it does not provide explicit guidance on when to use this tool versus alternatives, or mention prerequisites (e.g., bucket must exist). No exclusions or context for selection are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
osc_upload_fileC
Upload a file to Eyevinn Open Source Cloud Storage (OSC) Minio instance
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the minio instance | |
| bucket | Yes | Name of the bucket | |
| objectKey | Yes | Object key for the uploaded file | |
| file | Yes | File to upload |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'upload'. It does not disclose behavioral traits like whether the upload overwrites existing objects, required permissions, file size limits, or asynchronicity.
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, succinct sentence that immediately conveys the action and target. Every word is necessary; no redundancy.
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 complexity (4 required parameters, no output schema, no annotations), the description is too minimal. It fails to explain return values, success/failure signals, or error handling, leaving an AI agent undersupported.
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 coverage is 100% with each parameter described. The description adds no additional meaning beyond the schema's descriptions, so it meets the baseline but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload a file') and the target resource ('Eyevinn Open Source Cloud Storage (OSC) Minio instance'). It is specific and distinguishable from sibling tools (bucket/list operations), though it does not explicitly differentiate.
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 (e.g., listing files or creating buckets). There is no mention of prerequisites (e.g., bucket must exist) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v1.2.0- First observed
osc_create_bucket - First observed
osc_list_buckets - First observed
osc_list_files - First observed
osc_upload_file
TDQS
A3.5/5.0
Scored across 4 tools
Disambiguation5/5
Each tool targets a distinct action (create bucket, list buckets, list files, upload file) with no overlap. An agent can clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent 'osc_verb_noun' pattern (e.g., osc_create_bucket, osc_list_files), making the naming predictable and easy to navigate.
Tool Count4/5
With 4 tools covering basic bucket and file operations, the count is slightly low but reasonable for a focused storage interface. It avoids being overly thin or heavy.
Completeness3/5
The set includes create, list, and upload operations but lacks delete and download capabilities for both buckets and files, representing notable gaps in the lifecycle.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
The official MCP Server for the Mux API
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
MCP server for Product Management
MCP server for the Seline Analytics API
Related MCP Servers
- AlicenseBqualityDmaintenanceMCP server for Maasy AI Marketing Copilot2140 npmMIT
- AlicenseAqualityCmaintenanceMCP server for the Influencers Club API — creator enrichment, discovery, audience analysis, content data, batch operations, and account management.22129 PyPI13MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for the Golpo AI video API, enabling video generation, listing, and downloading from any MCP-compatible client.MIT
