Skip to main content
Glama
deenesjakoruzh
mentu-ai

MetaMCP

Official
by mentu-ai
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

MetaMCP

npm version Node.js License CI

MetaMCP는 MCP 서버의 긴 꼬리(long tail)를 위한 안전한 온디맨드 게이트웨이입니다. MCP 클라이언트에 세 가지 안정적인 도구를 제공합니다:

  • mcp_discover는 모든 하위 프로세스를 시작하지 않고 구성된 서버, 캐시된 도구 스키마, 검토된 Methods를 찾습니다.

  • mcp_call은 명시적으로 이름이 지정된 하위 도구 하나를 지연 호출합니다.

  • mcp_run은 제한된, 스키마 검증된 선언적 Method를 실행합니다.

MetaMCP는 의도적으로 모든 직접 MCP 연결을 대체하지 않습니다. 중요하고 자주 사용되며 간결하거나 강력한 인증을 사용하는 MCP는 직접 연결로 유지하세요. 불규칙한 긴 꼬리 서버는 MetaMCP 뒤에 두고, 반복되는 다단계 의식(ritual)은 Methods로 승격하세요.

                               ┌─ direct: GitHub / Codex Apps / core runtime
MCP client ────────────────────┤
                               └─ MetaMCP (3 tools)
                                    ├─ discover cached capabilities
                                    ├─ call one lazy child
                                    └─ run reviewed Methods

각 경로를 사용하는 경우

경로

가장 적합한 경우

이유

직접 MCP

고빈도, 간결, 보안 민감, 또는 기반 서버

타입이 지정된 스키마, 기본 인증, 명시적 승인을 보존합니다

mcp_discover + mcp_call

긴 꼬리 또는 불규칙한 기능

어셈블리 언어를 숨기지 않으면서 클라이언트 표면을 작게 유지합니다

mcp_run

반복되는 획득 → 정규화 → 분석 워크플로

제한된 동작을 테스트 가능하고, 버전 관리되며, 증거를 생성하도록 만듭니다

도구 수를 줄이기 위해 청구, 인프라 변경, ID, 또는 다른 고영향 서버를 MetaMCP를 통해 라우팅하지 마세요. 올바른 경계는 운영적이지 이념적이지 않습니다.

Related MCP server: mcp-gateway

빠른 시작

Node.js 20 이상이 필요합니다.

npx @mentu/metamcp@latest --config .mcp.json

클라이언트를 구성하기 전에 완전한 모델 노출 표면을 검사하세요:

npx @mentu/metamcp@latest tools
npx @mentu/metamcp@latest tools --json

검사기는 MCP tools/list가 반환하는 것과 동일한 정의를 읽은 다음, 구성을 로드하거나, 저장소를 열거나, 하위 프로세스를 시작하거나, 전송을 바인딩하기 전에 종료됩니다. --json은 자동 검토 및 버전 간 차이를 위해 완전한 입력 스키마를 포함합니다.

.mcp.json을 만드세요:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem@2026.7.10", "/path/to/allowed/files"]
    },
    "internal-api": {
      "command": "node",
      "args": ["./servers/internal-api.js"],
      "env": { "API_TOKEN": "${INTERNAL_API_TOKEN}" },
      "inheritEnv": ["HTTP_PROXY"]
    }
  }
}

하위 서버는 명시적으로 새로 고침, 호출, 또는 Method에서 사용될 때만 시작됩니다. 일반 검색은 구성과 캐시된 스키마를 읽습니다. 모든 하위 프로세스를 생성하지 않습니다.

서버 이름은 안정적인 캐시 ID이며 1-128자의 문자, 숫자, 점, 밑줄 또는 하이픈을 포함해야 합니다. 경로 구분자 및 탐색과 유사한 이름은 거부됩니다.

안전한 클라이언트 설정

init는 --yes가 제공되지 않으면 미리보기 전용입니다. 명명된 클라이언트가 없으면 기존 클라이언트 구성 파일만 고려합니다.

metamcp init                         # preview, no writes
metamcp init --client Codex          # preview one client
metamcp init --client Codex --yes    # apply atomically and write a .bak

잘못된 JSON은 거부되고 변경되지 않은 채로 남습니다. 명명된 클라이언트는 명시적으로 생성될 수 있습니다. MetaMCP는 기본적으로 지원되는 모든 클라이언트 구성을 생성하지 않습니다.

수동 클라이언트 구성의 경우 절대 경로를 사용하여 게이트웨이가 클라이언트의 작업 디렉터리에 의존하지 않도록 하세요:

{
  "mcpServers": {
    "metamcp": {
      "command": "npx",
      "args": [
        "-y",
        "@mentu/metamcp@latest",
        "--config",
        "/absolute/path/to/.mcp.json"
      ]
    }
  }
}

@latest는 평가에 편리합니다. 통제된 환경에서는 @mentu/metamcp@1.0.0을 고정하여 업그레이드가 의도적이고 검토 가능하도록 하세요.

세 가지 도구

Discover

{ "query": "capture screenshot", "kind": "tool" }

검색은 라이브 또는 캐시된 스키마만 검색합니다. 하나의 서버를 라이브 도구 목록에서 새로 고치려면:

{ "server": "browser", "refresh": true }

서버 없이 refresh는 거부되므로 에이전트가 실수로 전체 구성에 걸쳐 팬아웃할 수 없습니다.

Call

{
  "server": "browser",
  "tool": "capture_page",
  "args": { "url": "https://example.com" },
  "timeoutMs": 60000
}

MetaMCP는 시간 초과 또는 전송 실패 후 하위 호출을 자동으로 재생하지 않습니다. 하위 프로세스가 응답이 손실되기 전에 변경을 완료했을 수 있습니다. 이후 Method는 매니페스트가 해당 단계 idempotency: "safe"를 명시적으로 선언하는 경우에만 재시도할 수 있습니다.

Method 실행

JSON 매니페스트를 .metamcp/methods/에 넣거나 --methods <directory>를 전달하세요. 아래 하위 서버 및 도구 이름은 예시입니다. 자체 구성에서 검토된 서버에 바인딩하세요:

{
  "apiVersion": "metamcp.io/v1alpha1",
  "kind": "Method",
  "metadata": {
    "name": "content.acquire-and-normalize",
    "version": "1.0.0",
    "description": "Acquire content and normalize it into a stable record"
  },
  "spec": {
    "effects": "read",
    "inputSchema": {
      "type": "object",
      "properties": { "url": { "type": "string" } },
      "required": ["url"],
      "additionalProperties": false
    },
    "steps": [
      {
        "id": "acquire",
        "server": "fetch",
        "tool": "fetch",
        "args": { "url": "${input.url}" }
      },
      {
        "id": "normalize",
        "server": "content",
        "tool": "normalize",
        "dependsOn": ["acquire"],
        "args": { "document": "${steps.acquire.structuredContent}" }
      }
    ],
    "output": "${steps.normalize.structuredContent}"
  }
}

그런 다음 호출하세요:

{ "method": "content.acquire-and-normalize", "input": { "url": "https://example.com" } }

Methods는 임의의 JavaScript가 아닌 선언적입니다. 제한된 단계 수, 마감 시간 및 출력 크기; 입력/출력 JSON 스키마; 명시적 읽기/쓰기 효과; 안전한 보간; 타입이 지정된 갭; 단계별 추적이 있습니다. 쓰기 또는 혼합 효과 Methods는 게이트웨이 운영자가 --allow-writes로 MetaMCP를 시작하지 않는 한 비활성화됩니다.

Method Mode, 매니페스트 스키마, 예제 Method를 참조하세요. 이 설계는 Crawlio Method Mode가 문서화한 일관성 계층을 일반화합니다.

구성 및 비밀

env 및 HTTP headers의 ${NAME} 참조는 기본적으로 호스트 환경에서 해석됩니다. 해석되지 않은 참조는 시작 시 실패합니다. 리터럴 자리 표시자로 하위 프로세스에 전달되지 않습니다.

MetaMCP는 주변 환경을 stdio 하위 프로세스에 복사하지 않습니다. 소규모 런타임 허용 목록(PATH, 홈/임시/로케일 변수 및 플랫폼 등가물), inheritEnv에 명명된 변수, 하위 env 블록에 명시적으로 설정된 값만 상속합니다. 임베더는 키체인 또는 볼트용 사용자 정의 SecretProvider를 설치할 수 있습니다.

검색은 기본적으로 로컬 키워드 검색입니다. Voyage 기반 의미 검색을 선택하려면 METAMCP_VOYAGE_API_KEY를 명시적으로 설정하세요. 그러면 검색 쿼리가 Voyage로 전송되고 선택적 로컬 SQLite 벡터 인덱스가 활성화됩니다. 주변 ANTHROPIC_API_KEY 또는 VOYAGE_API_KEY 변수는 네트워크 호출을 활성화하지 않습니다.

원격 하위 서버는 url, transportType, headers 및 기존 OAuth 필드를 사용합니다:

{
  "mcpServers": {
    "remote": {
      "url": "https://mcp.example.com/mcp",
      "transportType": "http",
      "headers": { "Authorization": "Bearer ${REMOTE_TOKEN}" }
    }
  }
}

HTTP 게이트웨이

HTTP 모드는 기본적으로 127.0.0.1에 바인딩됩니다:

metamcp --transport http --port 8080 --config .mcp.json

인증되지 않은 비루프백 바인딩은 실패로 종료됩니다. 리스너를 노출하기 전에 OAuth 리소스 서버 검증 또는 METAMCP_HTTP_BEARER_TOKEN을 구성하세요. Origin 헤더가 있는 브라우저 요청은 정확한 출처가 --allow-origin 또는 METAMCP_ALLOWED_ORIGINS로 제공되지 않으면 거부됩니다.

MetaMCP는 stdio 및 Streamable HTTP를 통해 레거시 MCP 클라이언트와 2026-07-28 무상태 요청 봉투를 제공합니다. 지원되는 경계 및 배포 지침은 Architecture를 참조하세요.

증거

완료된 mcp_call 및 mcp_run 시도는 .metamcp/ledger.jsonl에 직렬화됩니다. 휴대용 해시 연결 번들을 내보내세요:

metamcp export-evidence \
  --ledger .metamcp/ledger.jsonl \
  --out .metamcp/evidence-bundle.json

metamcp export-evidence --out .metamcp/evidence-bundle.json --verify

운영 원장은 원격 증명 시스템이 아닙니다. 내보내기는 번들 내부의 이후 변경을 감지합니다. 손상된 호스트가 모든 이벤트를 기록했음을 증명하지 않습니다.

선택적 갤러리

패키지에는 여전히 사람이 운영하는 서버 갤러리가 포함되어 있습니다:

metamcp add --list
metamcp add playwright sentry --config .mcp.json

런타임은 MCP 도구 호출에 응답하여 패키지를 설치하지 않습니다. 설치는 명시적 CLI/사용자 작업으로 유지됩니다.

0.x에서 업그레이드

버전 1.0은 의도적으로 모델 노출 프로비저닝, 스킬 조언 및 JavaScript 실행 도구를 제거합니다. 또한 HTTP 바인딩, 하위 환경 상속, 재시도 및 init를 변경합니다. 업그레이드 전에 Migration to 1.0을 읽으세요.

보안

하위 MCP 서버는 자체 권한이 있는 신뢰할 수 있는 로컬 또는 원격 코드입니다. MetaMCP는 정책 및 수명 주기 경계이지 신뢰할 수 없는 패키지용 OS 샌드박스가 아닙니다. 명령을 검토하고, 적절한 곳에서 패키지를 고정하고, 하위 프로세스별로 자격 증명을 범위 지정하고, 위험한 직접 서버를 클라이언트 측 인간 승인 뒤에 유지하세요.

취약점은 SECURITY.md에 설명된 대로 비공개로 보고하세요.

개발

npm ci
npm run typecheck
npm test
./scripts/smoke-test.sh
npm run check:release
npm pack --dry-run

npm publish는 전체 verify:release 게이트를 다시 실행합니다. 게이트는 빌드된 CLI에서 공개 도구 표면을 파생하고 패키지, 잠금 파일, 변경 로그 및 공식 MCP 레지스트리 메타데이터의 버전 드리프트를 확인합니다.

Apache-2.0 라이선스. Mentu AI가 유지 관리합니다.

Available Tools

6 tools
mcp_callB

Forward a tool call to a specific child MCP server. Retries once on crash.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoArguments to pass to the tool
toolYesTool name to call
serverYesTarget server name

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses retry behavior once on crash, which is useful. But with no annotations, the description does not mention side effects, permissions, or whether the operation is destructive. The retry detail is positive but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The main action and key behavior (retry) are front-loaded. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and subjective complexity medium, the description omits important context: what happens if the server is unreachable, what the return value is, and any rate limits or error handling details. Only minimal forwarding and retry are covered.

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%, so the schema already describes all parameters. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.

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 forwards a tool call to a child MCP server and retries on crash. It uses a specific verb and resource, but does not explicitly contrast with sibling tools like mcp_execute or mcp_discover.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, alternatives, or scenarios where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_discoverA

Search tool catalogs across all child MCP servers + list server status. If no query, returns server list with status and tool counts.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoSearch query for tools
serverNoFilter to a specific server

TDQS

A4/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 full burden. It describes the tool as performing read operations (search and list), but does not disclose any behavioral traits like authentication requirements, rate limits, or potential side effects. It is adequate but lacks depth.

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 two sentences, concise, and front-loaded with the core purpose. Every sentence adds value, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers both modes of the tool (search and list server status) and explains what happens when no query is provided. No output schema is given, but the description implies the return structure sufficiently.

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 both parameters described. The description adds some context by explaining the no-query behavior, but does not substantially enhance the parameter definitions beyond what the schema provides.

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 searches tool catalogs across child MCP servers and lists server status. It uses the verb 'discover' and distinguishes from siblings like mcp_call (which likely calls a tool) and mcp_skill_discover (which discovers skills).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains two usage modes: with a query (search) and without a query (list server status). It provides context on when to use each, though it does not explicitly say when not to use or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_executeA

Code-mode execution in V8 sandbox. Access provisioned servers via servers.<name>.call(tool, args). Supports async/await, sleep(ms), console.log.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesCode to execute

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description shoulders full burden. It discloses sandboxing, async/await, sleep, and server access, but omits details like error handling, return value format, persistence, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, every sentence adds value. No redundant or extraneous information.

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?

Lacks critical details for a code execution tool: what is returned (execution result), restrictions (network, filesystem), lifecycle (one-shot), and output capture. Relies heavily on inferred context from sibling tools.

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 only describes 'code' as 'Code to execute'. Description adds significant context: V8 sandbox, ability to use async/await, sleep, console.log, and call provisioned servers. This goes 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?

Description clearly states it executes code in a V8 sandbox, with explicit mention of accessing provisioned servers. This distinguishes it from sibling tools like mcp_call which directly call server tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for running arbitrary JavaScript with sandbox access, and contrasts with direct server calls by showing servers.<name>.call syntax. However, it lacks explicit when-to-use vs. alternatives guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_provisionB

Intent-based provisioning. Describe what you need, MetaMCP resolves and provisions the right server.

ParametersJSON Schema
NameRequiredDescriptionDefault
intentYesWhat capability you need
contextNoAdditional context for resolution
autoProvisionNoAuto-provision if trusted (default: false)

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must fully explain behavior. It mentions intent-based provisioning but lacks details on side effects (e.g., resource creation, persistence), permissions required, or potential destructive actions.

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?

Single sentence is concise and front-loaded with core purpose. However, for a provisioning tool, it may be too terse, lacking necessary detail.

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 only 3 simple parameters and no output schema, the description is too brief for a provisioning action. It does not describe return values, success indicators, or consequences, leaving the agent to infer too much.

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%, so baseline is 3. Description adds no extra meaning beyond the schema descriptions; no examples or clarifications on intent format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it is for provisioning servers based on intent ('Describe what you need, MetaMCP resolves and provisions the right server'). Distinct from siblings like mcp_discover or mcp_call which focus on discovery or execution.

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?

No explicit guidance on when to use vs alternatives. Usage is implied: for provisioning when you know the desired capability. Lacks 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.

mcp_skill_adviseA

Pre-flight readiness check for a skill. Returns MCP server availability and recommendations.

ParametersJSON Schema
NameRequiredDescriptionDefault
skillYesSkill name to check

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It reveals that the tool returns 'MCP server availability and recommendations', which is useful. However, it does not disclose edge cases (e.g., skill not found), permissions needed, or potential 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?

The description is a single concise sentence that effectively conveys the purpose and output without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (1 param, no output schema), the description is mostly adequate. It explains the return value, but could be more complete by mentioning that it is non-destructive or clarifying what 'recommendations' entails.

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% for the single parameter 'skill'. The description adds no extra meaning beyond what the schema already provides, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a 'Pre-flight readiness check for a skill', specifying the verb and resource. It distinguishes from siblings like mcp_skill_discover (discovery) and mcp_call (execution) by focusing on readiness checking.

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 use before calling or executing a skill, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned despite having several sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mcp_skill_discoverA

Search Claude Code skills with MCP readiness status. Returns skills matching query with their required MCP servers and availability.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query for skills
domainNoFilter by domain (e.g. browser_automation, monitoring)

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and discloses that results include required MCP servers and availability—key behavioral traits. It does not mention auth or rate limits, which is acceptable for a read-only search tool.

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, efficient sentence that immediately conveys the core purpose and key output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with no output schema, the description provides reasonable completeness by listing what is returned (skills, required servers, availability). It could be improved by noting pagination or result limits.

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% and the schema descriptions for 'query' and 'domain' are adequate. The tool description adds no additional meaning beyond the schema, so a 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 tool searches Claude Code skills, specifies the 'MCP readiness status' criterion, and indicates the return includes required MCP servers and availability. This distinguishes it from sibling tools like mcp_skill_advise and mcp_discover.

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 should be used when searching for skills with MCP readiness, but provides no explicit guidance on when not to use it or how it compares to other search/discovery tools.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.5.0
    • First observedmcp_call
    • First observedmcp_discover
    • First observedmcp_execute
    • First observedmcp_provision
    • First observedmcp_skill_advise
    • First observedmcp_skill_discover
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: discovery of servers/tools, provisioning, forwarding tool calls, code execution, skill discovery, and skill readiness checking. No two tools have overlapping functionality.

Naming Consistency5/5

All tools follow the 'mcp_<verb>' pattern, with skill-specific tools adding 'skill_' for clarity. The naming is consistent and predictable.

Tool Count5/5

With 6 tools, the set is well-scoped for a meta-server. It covers the essential operations without being excessive or insufficient.

Completeness4/5

The tool surface covers discovery, provisioning, calling, execution, and skill support. Minor gaps exist (e.g., no explicit unprovisioning or server management), but core agent workflows are well-supported.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcp-gateway

    jj13jp
    F
    license
    Not graded
    quality
    B
    maintenance
    Aggregates multiple child MCP servers into a single MCP server endpoint, enabling clients to use various tools (e.g., filesystem, Brave Search) through one interface.
    19
    -

  • MCP Server Proxy

    hr98w
    A
    license
    Not graded
    quality
    D
    maintenance
    Aggregates multiple MCP servers into a single endpoint, enabling LLM clients to access tools, resources, and prompts from various backends through one connection.
    18
    MIT

Latest Blog Posts

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/mentu-ai/metamcp'

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