PocketBaseデータベースと連携するための高度なツールを提供する包括的なMCPサーバーです。このサーバーは、モデルコンテキストプロトコル（MCP）を通じて、高度なデータベース操作、スキーマ管理、データ操作を可能にします。
複数のレコードを一度に更新するためのbatch_update_recordsツールを追加しました。
複数のレコードを一度に削除するためのbatch_delete_recordsツールを追加しました。
リアルタイム イベント サブスクリプション用のsubscribe_to_collectionツールを追加しました ( eventsource polyfill が必要です)。
明示的な電子メール/パスワードなしで環境変数を介して管理者認証を許可するために、 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 : 1回の呼び出しで複数のレコードを更新する
batch_delete_records : 1回の呼び出しで複数のレコードを削除する
subscribe_to_collection : コレクション内のリアルタイムの変更をサブスクライブします (Node.js 環境ではeventsourceパッケージが必要です)
import_data : 作成/更新/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 : さまざまなモード（作成/更新/upsert）でデータをインポートします
サーバーには次の環境変数が必要です。
POCKETBASE_URL : PocketBaseインスタンスのURL（例：" http://127.0.0.1:8090 "）
オプションの環境変数:
POCKETBASE_ADMIN_EMAIL : 特定の操作の管理者メールアドレス
POCKETBASE_ADMIN_PASSWORD : 管理者パスワード
POCKETBASE_DATA_DIR : カスタムデータディレクトリパス
// Create a new collection
await mcp.use_tool("pocketbase", "create_collection", {
name: "posts",
schema: [
{
name: "title",
type: "text",
required: true
},
{
name: "content",
type: "text",
required: true
}
]
});
// Manage indexes
await mcp.use_tool("pocketbase", "manage_indexes", {
collection: "posts",
action: "create",
index: {
name: "title_idx",
fields: ["title"],
unique: true
}
});// 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…
