AI 에이전트가 MCP 도구를 사용할 때 소비하는 토큰을 최대 98%까지 절감합니다 — 아무것도 잃지 않으면서요.
서버 | 도구 수 | 이전 | 이후 | 감소율 |
filesystem (Anthropic) | 14 | 1,892 tok | 236 tok | −88% |
sequential-thinking | 1 | 926 tok | 20 tok | −98% |
Google Calendar | 5 | 5,010 tok | 660 tok | −87% |
Enterprise (Cal + Gmail + Drive) | 12 | 8,649 tok | 882 tok | −90% |
sample_app.js (JavaScript) | — | 799 tok | 284 tok | −64.5% |
sample_app.ts (TypeScript) | — | 378 tok | 266 tok | −29.6% |
ast_extractor.py (Python) | — | 3,633 tok | 890 tok | −75.5% |
전송되는 토큰이 적어지면 API 비용이 낮아지고 응답 속도가 빨라집니다. 그리고 아무것도 잃지 않습니다. 모든 검사에서 압축 후에도 도구가 100% 사용 가능함을 확인했습니다.
직접 재현해 보세요 — 모든 입력은 저장소에 정적 픽스처로 있으며, 토큰은 tiktoken cl100k_base로 계산했습니다:
python benchmarks/run_benchmark.py # the table above
python benchmarks/run_benchmark.py --json # machine-readable
python benchmarks/run_benchmark.py --fixture path/to/your_schemas.jsonRelated MCP server: Bifrost-MCP Gateway
한 줄 설치 (macOS / Linux) — 패키지를 설치하고 Claude Desktop을 구성합니다:
curl -sSL https://raw.githubusercontent.com/LoudiliMed/Refract/main/install-refract.sh | sh인터넷에서 셸로 스크립트를 파이핑하는 것은 먼저 빠르게 확인해 보세요: GitHub에서 install-refract.sh 검사. sudo를 사용하지 않습니다.
또는 pip로 직접 설치:
pip install refract-mcp선택적 추가 기능:
pip install refract-mcp[semantic] # semantic tool routing with embeddings
pip install refract-mcp[multilang] # JavaScript, TypeScript, JSX, TSX support에이전트와 MCP 서버 사이에 위치합니다. 도구 스키마를 실시간으로 압축하여 에이전트가 매 요청마다 전체 카탈로그를 로드하지 않도록 합니다.
로컬 서브프로세스 (stdio):
refract-proxy --target "npx @modelcontextprotocol/server-filesystem /tmp" --verbose원격 HTTP/SSE 서버:
# --url implies SSE transport (explicit, recommended for remote endpoints)
refract-proxy --url https://my-mcp-server.com/sse
# or with --transport flag (auto-detection can be overridden)
refract-proxy --target https://my-mcp-server.com/sse --transport sse프록시 플래그:
플래그 | 기본값 | 설명 |
| 필수 | MCP 대상: stdio 명령어, HTTP URL 또는 JSON 파일 |
| — | stdio 명령어용 |
| — | 원격 SSE/HTTP 엔드포인트 — |
| 자동 | 대상으로의 전송 방식 강제: |
| 30 | SSE 대상 연결 타임아웃 (3회 재시도) |
| stdio | 프록시가 에이전트에 서비스를 제공하는 방식 |
| 8080 |
|
| 꺼짐 | 요청당 토큰 수 출력 |
| WARNING | DEBUG / INFO / WARNING / ERROR |
Claude Desktop에 추가:
{
"mcpServers": {
"my-server-via-refract": {
"command": "/path/to/refract-proxy",
"args": [
"--target",
"npx @modelcontextprotocol/server-filesystem /path/to/folder",
"--verbose"
]
}
}
}원격 MCP 서버(SSE)의 경우:
{
"mcpServers": {
"remote-via-refract": {
"command": "/path/to/refract-proxy",
"args": ["--url", "https://my-mcp-server.com/sse"]
}
}
}항목을 하나씩 편집하거나 서버마다 refract-install을 실행하는 대신, refract-wrap-all은 claude_desktop_config.json에 있는 모든 stdio 서버를 단일 명령어로 refract-proxy를 통해 실행되도록 다시 작성합니다:
# Preview what would change — writes nothing
refract-wrap-all --dry-run
# Wrap every stdio server not already going through refract
refract-wrap-all
# Restore the original commands
refract-wrap-all --unwrap예: 이 항목이
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["@modelcontextprotocol/server-filesystem", "/tmp"],
"env": {"MY_VAR": "1"}
}
}
}다음과 같이 바뀝니다
{
"mcpServers": {
"filesystem": {
"command": "/path/to/refract-proxy",
"args": ["--stdio-cmd", "npx @modelcontextprotocol/server-filesystem /tmp"],
"env": {"MY_VAR": "1"}
}
}
}보장 사항:
설정 파일의 백업은 매 쓰기 전에 생성됩니다 (claude_desktop_config.json.bak, 그 다음 .bak2, .bak3… — 기존 백업은 절대 덮어쓰지 않습니다).
env, cwd 및 기타 서버 필드는 보존됩니다.
이미 refract-proxy 또는 refract-server를 통해 실행 중인 서버는 건너뜁니다 (already wrapped).
원격 SSE/HTTP 서버(url 항목)는 건너뜁니다 — stdio 서버만 래핑됩니다.
--unwrap은 정확한 왕복입니다: 래핑 후 언래핑하면 모든 원래 명령어, 인수 및 필드가 복원됩니다.
플래그 | 값 | 설명 |
| Streamable HTTP | 현재 표준 (MCP 사양 2025-03-26). 원격 MCP 서버와 함께 사용. |
| SSE | 레거시 전송 방식, 호환성을 위해 유지. 서버가 Streamable HTTP를 지원하지 않는 경우 사용. |
| stdio 서브프로세스 | 로컬 명령어 ( |
(생략) | 자동 감지 |
|
sse와 http 모두 --target에 HTTP(S) URL이 필요합니다.
# Connect to a remote MCP server via Streamable HTTP (recommended)
refract-proxy --target "https://my-mcp-server.com/mcp" --transport http
# Connect via SSE (legacy)
refract-proxy --target "https://my-mcp-server.com/sse" --transport sse
# Local subprocess (auto-detected, --transport stdio optional)
refract-proxy --target "npx @modelcontextprotocol/server-filesystem /tmp"코드베이스를 MCP 서버로 노출합니다. 에이전트가 저장소를 인덱싱하고, 압축된 파일 컨텍스트를 가져오고, 특정 함수를 확장하고, 영향을 분석하고, 변경 사항을 감지하고, 보안 위험을 매핑할 수 있습니다.
refract-server --root /path/to/your/repoClaude Desktop에 추가:
{
"mcpServers": {
"refract-code": {
"command": "/path/to/refract-server",
"args": ["--root", "/path/to/your/repo"]
}
}
}50권의 책이 있는 도서관을 상상해 보세요.
Refract 없이: 에이전트는 모든 질문에 대해 50권의 책에 대한 상세 요약을 받습니다. 답변에 단 한 권만 필요하더라도 말이죠.
Refract와 함께: 에이전트는 먼저 제목 목록(색인)을 받습니다. 필요한 책을 알게 되면, 그 책의 내용만 받습니다.
기술적으로:
색인 (항상 전송): 도구 이름과 각 도구에 대한 짧은 설명만 포함.
세부 정보 (필요할 때만 전송): 실제로 사용되는 도구의 전체 설명, 올바르게 사용하는 데 필요한 모든 것, 그 이상은 없음.
검증: 매 압축 후, Refract는 중요한 내용이 제거되지 않았는지 자동으로 확인합니다. 의심스러운 점이 있으면 위험을 감수하지 않고 전체 버전을 전송합니다.
이 과정에는 AI 모델이 관여하지 않습니다. 완전 자동, 빠르고 결정적입니다.
도구 | 기능 |
압축 | 도구 스키마를 실시간으로 압축, 최대 98% 감소 |
신호 확인 | 매 압축 후 호출 가능 계약 검증 |
의미 라우팅 | 임베딩을 사용하여 올바른 도구 식별 (선택 사항) |
프롬프트 캐싱 | 반복 요청에 Anthropic cache_control 주입 |
도구 | 입력 | 출력 |
index_repo | 저장소 경로 | 모든 Python, JS, TS 파일의 집계된 색인 |
get_compressed | 파일 경로 | 압축된 구조 + 토큰 통계 |
expand | 파일 경로 + 함수 이름 | 원본 소스 + 의존성 컨텍스트 |
blast_radius | 파일 경로 + 함수 이름 | 대상이 변경될 때 깨지는 모든 함수 |
semantic_diff | 파일 경로 + 이전 소스 + 새 소스 | 변경 사항이 API를 깨는지 vs 본문만 변경하는지 |
semantic_diff_branches | 저장소 경로 + 파일 + 함수 + 기준/대상 git 참조 | 두 브랜치/커밋 사이 한 함수의 semantic_diff |
security_surface | 저장소 경로 | 위험한 호출 맵 (subprocess, eval, pickle, requests) |
refract-status --root /path/to/repo
refract-status --root /path/to/repo --json플래그 | 설명 |
| 분석할 경로 (기본값: 현재 디렉터리) |
| 기계가 읽을 수 있는 출력 |
표시: 언어별 파일 수, 원시 vs 압축 토큰, 인덱싱된 함수/클래스, 카테고리별 위험한 호출, tree-sitter를 지원하지 않는 언어.
Claude에게 대상 함수를 변경하면 어떤 함수가 깨지는지 물어보세요.
예시 결과:
{
"target": "authenticate",
"direct_callers": ["login_user"],
"all_impacted": ["login_user", "verify_session", "admin_access"],
"impacted_count": 3,
"risk_level": "MEDIUM"
}위험 수준: LOW (02개 영향), MEDIUM (35개), HIGH (6개 이상).
함수 본문이 아닌 인터페이스를 비교하여 API 변경 사항을 감지합니다. CI 게이트로 사용하세요.
예시 결과:
{
"breaking": ["authenticate"],
"body_only": ["logout"],
"added": ["new_function"],
"removed": [],
"unchanged": ["hash_password"],
"is_breaking": true
}is_breaking이 true이면 PR이 공개 API를 변경한 것이므로 검토가 필요합니다.
저장소 전체에서 위험한 기본 요소를 호출하는 모든 함수를 매핑합니다.
HIGH 위험: subprocess, os.system, eval, exec, pickle, ctypes
MEDIUM 위험: open (쓰기 모드), socket, requests, httpx, urllib
예시 결과:
{
"high_risk": [
{
"file": "src/llm_client.py",
"function": "run_command",
"calls": ["subprocess.run"]
}
],
"summary": {
"high_risk_count": 1,
"medium_risk_count": 3,
"total_functions_scanned": 87,
"clean_files": 8
}
}Python (ast 모듈 사용), JavaScript, TypeScript, JSX, TSX (tree-sitter 사용, pip install refract-mcp[multilang]로 선택 설치).
언어는 파일 확장자에서 자동 감지됩니다. tree-sitter가 설치되지 않은 경우 우아하게 대체됩니다.
Refract는 Anthropic 프롬프트 캐싱과 통합됩니다. as_anthropic_tools()는 압축된 카탈로그를 자동으로 캐시 가능으로 표시하여 반복 요청 시 비용을 더욱 절감합니다.
30일 동안 하루 100회 요청, 스키마 5,000 토큰 기준 예시:
시나리오 | 비용 |
Refract 없음, 캐시 없음 | $45.00 |
Refract + 캐시 사용 | $1.49 |
Claude Desktop에서 "Failed to spawn process: No such file or directory" 오류
Claude Desktop이 PATH에서 refract-proxy를 찾을 수 없습니다. 절대 경로를 찾아 직접 사용하세요:
which refract-proxy그런 다음 claude_desktop_config.json에서 전체 경로를 사용하세요:
{
"mcpServers": {
"my-tool-via-refract": {
"command": "/full/path/to/refract-proxy",
"args": [
"--target",
"npx @modelcontextprotocol/server-filesystem /path/to/folder"
]
}
}
}Claude Desktop, Cursor, MCP 표준을 따르는 모든 클라이언트, 모든 기존 MCP 서버.
MIT — 상업적 사용을 포함하여 자유롭게 사용 가능합니다.
Reverse-call-graph impact analysis for a Python function: BFS over inverted call edges to find every function transitively affected by changing target_function. Returns direct_callers, all_impacted, impacted_count, total_functions and a risk_level. Python files only.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to a .py file (relative to --root or absolute). | |
| target_function | Yes | Function/method name to analyze the blast radius of. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: BFS algorithm, inverted call edges, returns specific fields (direct_callers, all_impacted, etc.), and scope (Python files only). No hidden side effects or destructive actions are implied.
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-loads the purpose, and includes all essential information without verbosity. Every sentence earns its place.
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 no annotations or output schema, the description covers purpose, algorithm, input parameters, return fields, and file type restriction. It is complete for an agent to understand and use this tool correctly.
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% (both params described), so baseline is 3. The description adds value by explaining the algorithm context (BFS over inverted call edges) and linking the parameters to the analysis process, though the schema already defines them clearly.
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 'Reverse-call-graph impact analysis for a Python function', specifying the verb (analyze impact), resource (Python function), and methodology (BFS over inverted call edges). It distinguishes from sibling tools like index_repo and security_surface which have different 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 implicitly defines usage: when you need to know which functions are affected by changing a target function in a Python file. It does not explicitly compare with siblings, but the context is clear. The restriction 'Python files only' provides a clear constraint, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given function/class names in a .py file, return them verbatim (full source) plus their compressed dependency context.
| Name | Required | Description | Default |
|---|---|---|---|
| targets | Yes | Function/class names to expand. | |
| file_path | Yes | Path to a .py file (relative to --root or absolute). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description carries full burden. It states it returns 'full source' and 'compressed dependency context', which is a key behavioral trait. However, it does not disclose read-only nature, auth requirements, or potential performance implications (e.g., large files). Adequate but not comprehensive.
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, front-loaded with purpose. No wasted words; all information is necessary and directly conveys the tool's action and output.
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 that there is no output schema and no annotations, the description is somewhat vague about the exact format of 'compressed dependency context'. While the tool is simple, the description could be more complete by clarifying what 'compressed' means. Sufficient but leaves room for ambiguity.
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 description coverage is 100%, so the schema already documents both parameters adequately. The tool description adds no new meaning beyond restating the schema descriptions, meeting the baseline but not adding value.
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?
Description uses specific verb 'expand' on function/class names in a .py file, clearly indicating it returns full source plus dependency context. Differentiates from siblings like 'get_compressed' (which likely returns compressed content) and 'blast_radius' (impact analysis).
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 like 'get_compressed' or 'blast_radius'. Usage is implied by the description (to get full source of specific definitions with dependencies), but lacks when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
S5-compress a single source file — Python or JS/TS (signatures + dependency contracts, bodies stripped) — and return the compressed structure plus token stats (tokens_before, tokens_after, reduction_pct).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to a .py file (relative to --root or absolute). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behaviors. It does not state whether the operation is read-only or modifies files, nor does it mention side effects, auth requirements, or rate limits. The word 'compress' might imply mutation, but the return of a 'compressed structure' suggests the original file is unchanged. This ambiguity is a gap.
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. It front-loads the action ('S5-compress a single source file'), specifies file types, details the compression behavior, and lists the output. No unnecessary 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?
Without output schema, the description should explain the return value structure, but it does mention 'compressed structure plus token stats (tokens_before, tokens_after, reduction_pct),' which is helpful. However, it lacks behavioral context (read/write), does not resolve the file type inconsistency, and does not address how this relates to sibling tools like 'expand.' The minimal viable information is present, but gaps reduce 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% (one parameter with description). The description adds that the tool supports Python and JS/TS, but the schema's parameter description says 'Path to a .py file,' which contradicts the broader file types stated in the tool description. This inconsistency misleads the agent and detracts from the value added 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 a single source file (Python or JS/TS) by stripping bodies while keeping signatures and dependency contracts, and returns token stats. The verb 'compress' and resource 'source file' are specific, and it distinguishes from siblings like 'blast_radius' or 'expand' implicitly.
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 does not mention when to choose compression over expansion or other sibling tools, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk a repo (Python + JavaScript/TypeScript) and return an aggregated structural index: every function, class, import and dependency. Max depth 3; skips pycache, .git, venv, node_modules.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Repo path (relative to --root or absolute). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses maximum depth 3 and skipped directories (__pycache__, .git, venv, node_modules), but fails to mention behavior for unsupported file types, invalid paths, or performance implications for large repos. Additional context would improve 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?
The description is two concise sentences with front-loaded purpose and clear constraints. Every word adds value, no 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 no output schema, the description partially explains return value as 'aggregated structural index' listing functions, classes, imports, dependencies. However, it lacks details on output format (e.g., JSON structure, list vs. dict) and does not address edge cases like empty repos or mixed languages. It is acceptable but not fully 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% with a single required 'path' parameter described adequately. The description adds no extra parameter details beyond the schema, so baseline 3 is appropriate. The description's main value is in explaining the tool's overall function, not parameter specifics.
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 walks a repo and returns a structural index of functions, classes, imports, and dependencies, explicitly specifying supported languages (Python and JavaScript/TypeScript). This distinguishes it from sibling tools like 'blast_radius' or 'security_surface', which likely have different 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 does not provide explicit guidance on when to use this tool versus alternatives like 'blast_radius' or 'expand'. It only implies usage for structural indexing, but lacks when-to-use, when-not-to-use, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Walk a Python repo and find functions that call dangerous primitives — pure AST analysis, zero LLM calls. Classifies calls as HIGH risk (subprocess/os.system/eval/exec/pickle/import/ctypes …) or MEDIUM risk (sockets/requests/httpx/urllib/paramiko/smtplib and write-mode open()). Also scans for potential secrets: hardcoded keys/tokens (AKIA…, sk-…, ghp_…, token=/password=/api_key= assignments), .env/environment loading, and high-entropy token-looking literals. Returns high_risk, medium_risk, secrets, clean files and a summary. Max depth 3; skips pycache, .git, venv, node_modules.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | Repo path (relative to --root or absolute). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states pure AST analysis, zero LLM calls, risk classification levels, secret detection, max depth 3, and skipped directories. Could mention whether the tool is read-only (likely yes) but overall quite transparent.
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?
Description is front-loaded with the main action and packed with relevant details in three sentences. Minimal redundancy, though length could be trimmed slightly without losing meaning.
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 no output schema, description adequately explains return values (high_risk, medium_risk, secrets, clean files, summary). Covers key behaviors and limitations. Could mention file type filtering but sufficient for an agent to understand scope.
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?
Only one parameter (repo_path) with 100% schema coverage. Description adds no extra detail beyond the schema's description of the path. Baseline score 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?
Description clearly states it walks a Python repo using AST analysis to find dangerous function calls and secrets, with specific risk classifications. No sibling tool overlaps, making its unique purpose unmistakable.
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 when to use (security scanning of Python repos) but does not explicitly state when not to use or mention alternatives among siblings. More precise guidance would improve this dimension.
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.
v0.7.0blast_radiusexpandget_compressedindex_reposecurity_surfaceScored across 5 tools
Each tool has a distinct purpose: impact analysis, source retrieval, file compression, repo indexing, and security scanning. No two tools overlap in functionality.
All tools use snake_case, but 'expand' is a lone verb while others follow a verb_noun pattern (e.g., get_compressed, index_repo). Minor inconsistency but still clear.
5 tools is a well-scoped set for a static analysis toolkit. Neither too few nor too many, each tool serves a clear need.
Covers core static analysis needs (impact, source, compression, indexing, security). Missing a dedicated diff or test analysis tool, but the surface is reasonably complete for the domain.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
