PocketBase 데이터베이스와의 상호 작용을 위한 정교한 도구를 제공하는 포괄적인 MCP 서버입니다. 이 서버는 모델 컨텍스트 프로토콜(MCP)을 통해 고급 데이터베이스 작업, 스키마 관리 및 데이터 조작을 지원합니다.
여러 레코드를 한 번에 업데이트할 수 있는 batch_update_records 도구가 추가되었습니다.
여러 레코드를 한 번에 삭제하기 위한 batch_delete_records 도구가 추가되었습니다.
실시간 이벤트 구독을 위한 subscribe_to_collection 도구가 추가되었습니다( eventsource 폴리필이 필요함).
명시적인 이메일/비밀번호 없이도 환경 변수를 통해 관리자 인증을 허용하도록 authenticate_user 에 대한 스키마를 수정했습니다.
Node.js에서 실시간 구독을 활성화하기 위해 eventsource 종속성과 폴리필을 추가했습니다.
환경 변수를 사용한 향상된 관리자 인증 지원
impersonate_user 도구를 통해 관리자 사칭에 대한 지원이 추가되었습니다.
인증 작업에 대한 오류 처리가 개선되었습니다.
더 나은 개발 경험을 위해 포괄적인 TypeScript 유형 정의가 추가되었습니다.
Cline 통합에 대한 지원이 추가되었습니다.
PocketBase 클라이언트 구현에서 TypeScript 오류가 수정되었습니다.
적절한 유형 주석을 통해 스키마 필드 처리가 개선되었습니다.
선택적 스키마 필드 속성 관련 문제가 해결되었습니다.
여러 인증 방법을 지원하도록 인증 흐름이 업데이트되었습니다.
더욱 자세한 예를 통해 문서가 개선되었습니다.
향상된 환경 변수 구성 옵션
Related MCP server: PocketBase MCP Server
사용자 정의 스키마를 사용하여 컬렉션을 만들고 관리합니다.
데이터 보존을 통한 컬렉션 스키마 마이그레이션
고급 인덱스 관리(생성, 삭제, 목록)
스키마 검증 및 유형 안전성
컬렉션 스키마 및 메타데이터 검색
레코드에 대한 CRUD 작업
필터링, 정렬 및 집계를 통한 고급 쿼리
일괄 가져오기/내보내기 기능
관계 확장 지원
페이지 매김 및 커서 기반 탐색
사용자 인증 및 토큰 관리
사용자 계정 생성 및 관리
비밀번호 관리
역할 기반 액세스 제어
세션 처리
데이터베이스 백업 및 복원
다양한 내보내기 형식(JSON/CSV)
데이터 마이그레이션 도구
인덱스 최적화
일괄 작업
create_collection : 사용자 정의 스키마를 사용하여 새 컬렉션을 만듭니다.
get_collection_schema : 컬렉션에 대한 스키마 세부 정보를 가져옵니다.
migrate_collection : 데이터 보존을 통한 컬렉션 스키마 마이그레이션
manage_indexes : 컬렉션 인덱스를 생성, 삭제 또는 나열합니다.
create_record : 컬렉션에 새 레코드를 만듭니다.
list_records : 선택적 필터와 페이지 매김을 사용하여 레코드를 나열합니다.
update_record : 기존 레코드를 업데이트합니다
delete_record : 레코드 삭제
query_collection : 필터링, 정렬, 집계 기능이 있는 고급 쿼리
batch_update_records : 단일 호출로 여러 레코드 업데이트
batch_delete_records : 단일 호출에서 여러 레코드 삭제
subscribe_to_collection : 컬렉션의 실시간 변경 사항을 구독합니다(Node.js 환경에서 eventsource 패키지가 필요함)
import_data : create/update/upsert 모드를 사용하여 컬렉션에 데이터 가져오기
authenticate_user : 사용자를 인증하고 인증 토큰을 얻습니다.
create_user : 새로운 사용자 계정을 생성합니다
list_auth_methods : 사용 가능한 모든 인증 방법을 나열합니다.
authenticate_with_oauth2 : OAuth2로 사용자 인증
authenticate_with_otp : 일회용 비밀번호로 사용자를 인증합니다.
auth_refresh : 인증 토큰 새로 고침
request_verification : 이메일 인증 요청
confirm_verification : 토큰으로 이메일 검증을 확인합니다.
request_password_reset : 비밀번호 재설정 요청
confirm_password_reset : 토큰으로 비밀번호 재설정 확인
request_email_change : 이메일 변경 요청
confirm_email_change : 토큰으로 이메일 변경 확인
impersonate_user : 다른 사용자로 가장(관리자만 가능)
backup_database : 포맷 옵션을 사용하여 PocketBase 데이터베이스의 백업을 생성합니다.
import_data : 다양한 모드(create/update/upsert)로 데이터 가져오기
서버에는 다음과 같은 환경 변수가 필요합니다.
POCKETBASE_URL : PocketBase 인스턴스의 URL(예: " http://127.0.0.1:8090 ")
선택적 환경 변수:
POCKETBASE_ADMIN_EMAIL : 특정 작업에 대한 관리자 이메일
POCKETBASE_ADMIN_PASSWORD : 관리자 비밀번호
POCKETBASE_DATA_DIR : 사용자 정의 데이터 디렉토리 경로
지엑스피1
// Query with filtering, sorting, and aggregation
await mcp.use_tool("pocketbase", "query_collection", {
collection: "posts",
filter: "created >= '2024-01-01'",
sort: "-created",
aggregate: {
totalLikes: "sum(likes)",
avgRating: "avg(rating)"
},
expand: "author,categories"
});// Import data with upsert mode
await mcp.use_tool("pocketbase", "import_data", {
collection: "posts",
data: [
{
title: "First Post",
content: "Hello World"
},
{
title: "Second Post",
content: "More content"
}
],
mode: "upsert"
});
// Backup database
await mcp.use_tool("pocketbase", "backup_database", {
format: "json" // or "csv"
});// Migrate collection schema
await mcp.use_tool("pocketbase", "migrate_collection", {
collection: "posts",
newSchema: [
{
name: "title",
type: "text",
required: true
},
{
name: "content",
type: "text",
required: true
},
{
name: "tags",
type: "json",
required: false
}
],
dataTransforms: {
// Optional field transformations during migration
tags: "JSON.parse(oldTags)"
}
});// Batch update records
await mcp.use_tool("pocketbase", "batch_update_records", {
collection: "products",
records: [
{ id: "record_id_1", data: { price: 19.99 } },
{ id: "record_id_2", data: { status: "published" } }
]
});
// Batch delete records
await mcp.use_tool("pocketbase", "batch_delete_records", {
collection: "products",
recordIds: ["record_id_3", "record_id_4"]
});
// Subscribe to collection changes (logs events to server console)
// Note: Requires 'eventsource' package installed in the Node.js environment running the server.
await mcp.use_tool("pocketbase", "subscribe_to_collection", {
collection: "products"
});
// Subscribe to a specific record
await mcp.use_tool("pocketbase", "subscribe_to_collection", {
collection: "products",
recordId: "specific_product_id"
});// List available authentication methods
await mcp.use_tool("pocketbase", "list_auth_methods", {
collection: "users"
});
// Authenticate with password
await mcp.use_tool("pocketbase", "authenticate_user", {
email: "user@example.com",
password: "securepassword",
collection: "users"
});
// Authenticate with OAuth2
await mcp.use_tool("pocketbase", "authenticate_with_oauth2", {
provider: "google",
code: "auth_code_from_provider",
codeVerifier: "code_verifier_from_pkce",
redirectUrl: "https://your-app.com/auth/callback",
collection: "users"
});
// Request password reset
await mcp.use_tool("pocketbase", "request_password_reset", {
email: "user@example.com",
collection: "users"
});
// Confirm password reset
await mcp.use_tool("pocketbase", "confirm_password_reset", {
token: "verification_token",
password: "new_password",
passwordConfirm: "new_password",
collection: "users"
});
// Refresh authentication token
await mcp.use_tool("pocketbase", "auth_refresh", {
collection: "users"
});모든 도구에는 자세한 오류 메시지와 함께 포괄적인 오류 처리 기능이 포함되어 있습니다. 오류는 올바르게 입력되며 다음을 포함합니다.
잘못된 요청 오류
인증 오류
데이터베이스 작업 오류
스키마 검증 오류
네트워크 오류
서버에는 모든 작업에 대한 TypeScript 정의가 포함되어 있어 도구 사용 시 타입 안전성을 보장합니다. 각 도구의 입력 스키마는 엄격하게 타입 지정되고 검증됩니다.
항상 try/catch 블록을 사용하여 적절한 오류 처리를 사용하세요.
작업을 수행하기 전에 데이터를 검증하세요
더 나은 쿼리 성능을 위해 적절한 인덱스를 사용하세요
정기적으로 데이터베이스를 백업하세요
스키마 변경에 마이그레이션 사용
사용자 관리를 위한 보안 모범 사례를 따르세요
데이터베이스 성능 모니터링 및 최적화
저장소를 복제합니다
종속성 설치: npm install
.env.example``.env 로 복사하고 구성하세요.
빌드: npm run build
PocketBase 인스턴스를 시작하세요
MCP 서버는 자동으로 PocketBase 인스턴스에 연결됩니다.
Smithery를 통해 Claude Desktop용 PocketBase Server를 자동으로 설치하려면:
npx -y @smithery/cli install pocketbase-server --client claude저장소를 포크하세요
기능 브랜치 생성
변경 사항을 커밋하세요
지점으로 밀어 넣기
풀 리퀘스트 만들기
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new customer in Stripe
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a write/mutation operation, but it doesn't disclose behavioral traits like required permissions, rate limits, error handling, or what happens on success/failure. It minimally meets baseline by stating the action.
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, clear sentence with zero waste. It's front-loaded with the essential action and resource, making it highly efficient and easy to parse.
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 tool with 0 parameters and no output schema, the description is minimally complete—it states what the tool does. However, as a mutation tool with no annotations, it lacks context about behavior, errors, or output, leaving gaps that could hinder effective use.
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 0 parameters, so no parameter documentation is needed. The description doesn't add parameter details, but with no parameters to explain, it appropriately avoids redundancy, earning a high baseline score.
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 action ('Create') and resource ('new customer in Stripe'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_stripe_product' or 'create_stripe_payment_intent' beyond the resource type, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or comparisons to siblings like 'create_record' or 'send_custom_email', leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Stripe payment intent for processing payments
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a write operation, but it doesn't disclose behavioral traits like authentication requirements, rate limits, idempotency, or what happens on failure. It adds minimal context beyond the basic action.
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, efficient sentence with zero waste. It's appropriately sized for a simple creation tool and front-loads the core purpose without unnecessary elaboration.
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, no output schema, and 0 parameters, the description is minimally complete. It states what the tool does but lacks context about the Stripe integration, expected outcomes, error handling, or dependencies. For a payment processing tool, more detail would be helpful despite the simple parameter structure.
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 0 parameters (properties object is empty), so there are no parameters to document. The description doesn't need to compensate for any schema gaps. Baseline 4 is appropriate since no parameters exist, though it could theoretically mention implicit requirements not in 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 action ('create') and resource ('Stripe payment intent') with the purpose 'for processing payments'. It distinguishes from siblings like create_stripe_customer or create_stripe_product by specifying the payment intent type. However, it doesn't explicitly differentiate from generic create_record or other payment-related tools that might exist.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a Stripe customer first), when not to use it (e.g., for subscriptions vs one-time payments), or refer to sibling tools like create_stripe_customer that might be needed first.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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 |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
v1.0.0create_recordcreate_stripe_customercreate_stripe_payment_intentcreate_stripe_productdiscover_toolsget_collectionget_recordhealth_checklist_collectionslist_recordssend_custom_emailsend_templated_emailsmithery_discoverytest_toolScored across 14 tools
The tools have some clear distinctions, like Stripe operations vs. PocketBase CRUD vs. email functions, but there is ambiguity within groups. For example, 'send_custom_email' and 'send_templated_email' could overlap in purpose, and 'discover_tools' vs. 'smithery_discovery' might confuse agents about their specific roles. Overall, descriptions are sparse, making it harder to differentiate tools fully.
Most tools follow a consistent verb_noun pattern, such as 'create_record', 'get_collection', and 'list_records'. However, there are minor deviations like 'health_check' (snake_case but could be 'check_health' for consistency) and 'smithery_discovery' (which uses a proper noun prefix). The naming is largely predictable but not perfectly uniform.
With 14 tools, the count is reasonable for a server that combines PocketBase database operations, Stripe integrations, and email functionalities. It's slightly on the higher side but still manageable, as each tool appears to serve a distinct purpose within its domain without obvious bloat.
For PocketBase operations, there is basic CRUD coverage (create, get, list for records and collections), but missing update and delete tools creates a notable gap. The Stripe tools cover customer, payment intent, and product creation, but lack retrieval or management functions. Email tools are present but without descriptions, it's unclear if they cover all needed scenarios. Overall, the surface is functional but has incomplete lifecycle coverage.
MCP server for interacting with the Supabase platform
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
