Un servidor MCP integral que proporciona herramientas sofisticadas para interactuar con bases de datos de PocketBase. Este servidor permite operaciones avanzadas de bases de datos, gestión de esquemas y manipulación de datos mediante el Protocolo de Contexto de Modelo (MCP).
Se agregó la herramienta batch_update_records para actualizar varios registros a la vez.
Se agregó la herramienta batch_delete_records para eliminar varios registros a la vez.
Se agregó la herramienta subscribe_to_collection para suscripciones a eventos en tiempo real (requiere polyfill eventsource ).
Se corrigió el esquema para authenticate_user para permitir la autenticación de administrador a través de variables de entorno sin correo electrónico o contraseña explícitos.
Se agregó la dependencia eventsource y polyfill para habilitar suscripciones en tiempo real en Node.js.
Soporte mejorado de autenticación de administrador con variables de entorno
Se agregó soporte para la suplantación de administrador a través de la herramienta impersonate_user
Manejo mejorado de errores para operaciones de autenticación
Se agregaron definiciones de tipos de TypeScript completas para una mejor experiencia de desarrollo
Se agregó soporte para la integración de Cline
Se corrigieron errores de TypeScript en la implementación del cliente PocketBase
Manejo mejorado de campos de esquema con anotaciones de tipo adecuadas
Se solucionaron problemas con las propiedades de campos de esquema opcionales
Se actualizó el flujo de autenticación para admitir múltiples métodos de autenticación.
Documentación mejorada con ejemplos más detallados
Opciones de configuración de variables de entorno mejoradas
Related MCP server: PocketBase MCP Server
Crear y administrar colecciones con esquemas personalizados
Migrar esquemas de recopilación con preservación de datos
Gestión avanzada de índices (crear, eliminar, listar)
Validación de esquemas y seguridad de tipos
Recuperar esquemas de colección y metadatos
Operaciones CRUD para registros
Consultas avanzadas con filtrado, ordenación y agregación
Capacidades de importación y exportación por lotes
Apoyo para la expansión de relaciones
Paginación y navegación basada en cursor
Autenticación de usuarios y gestión de tokens
Creación y gestión de cuentas de usuario
Gestión de contraseñas
Control de acceso basado en roles
Manejo de sesiones
Copia de seguridad y restauración de bases de datos
Múltiples formatos de exportación (JSON/CSV)
Herramientas de migración de datos
Optimización de índices
Operaciones por lotes
create_collection : Crea una nueva colección con un esquema personalizado
get_collection_schema : Obtener detalles del esquema para una colección
migrate_collection : Migrar el esquema de colección con preservación de datos
manage_indexes : Crea, elimina o enumera índices de colección
create_record : Crea un nuevo registro en una colección
list_records : Lista de registros con filtros y paginación opcionales
update_record : Actualizar un registro existente
delete_record : Eliminar un registro
query_collection : consulta avanzada con filtrado, ordenación y agregación
batch_update_records : Actualizar varios registros en una sola llamada
batch_delete_records : elimina varios registros en una sola llamada
subscribe_to_collection : Suscribirse a los cambios en tiempo real en una colección (requiere el paquete eventsource en el entorno Node.js)
import_data : Importa datos a una colección con modos de creación, actualización y actualización.
authenticate_user : Autenticar un usuario y obtener el token de autenticación
create_user : Crea una nueva cuenta de usuario
list_auth_methods : enumera todos los métodos de autenticación disponibles
authenticate_with_oauth2 : Autenticar un usuario con OAuth2
authenticate_with_otp : Autenticar un usuario con una contraseña de un solo uso
auth_refresh : Actualizar el token de autenticación
request_verification : Solicitar verificación de correo electrónico
confirm_verification : Confirmar la verificación del correo electrónico con el token
request_password_reset : Solicitar restablecimiento de contraseña
confirm_password_reset : Confirmar el restablecimiento de contraseña con token
request_email_change : Solicitar cambio de correo electrónico
confirm_email_change : Confirmar el cambio de correo electrónico con el token
impersonate_user : Suplantar la identidad de otro usuario (solo administrador)
backup_database : Crea una copia de seguridad de la base de datos de PocketBase con opciones de formato
import_data : Importa datos con varios modos (crear/actualizar/insertar)
El servidor requiere las siguientes variables de entorno:
POCKETBASE_URL : URL de su instancia de PocketBase (por ejemplo, " http://127.0.0.1:8090 ")
Variables de entorno opcionales:
POCKETBASE_ADMIN_EMAIL : Correo electrónico de administrador para ciertas operaciones
POCKETBASE_ADMIN_PASSWORD : Contraseña de administrador
POCKETBASE_DATA_DIR : Ruta del directorio de datos personalizado
// 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"
});Todas las herramientas incluyen un completo sistema de gestión de errores con mensajes detallados. Los errores se tipifican correctamente e incluyen:
Errores de solicitud no válida
Errores de autenticación
Errores de operación de la base de datos
Errores de validación del esquema
Errores de red
El servidor incluye definiciones de TypeScript para todas las operaciones, lo que garantiza la seguridad de tipos al usar las herramientas. El esquema de entrada de cada herramienta está estrictamente tipado y validado.
Utilice siempre un manejo de errores adecuado con los bloques try/catch
Validar datos antes de realizar operaciones
Utilice índices apropiados para un mejor rendimiento de las consultas
Realice copias de seguridad periódicas de su base de datos
Utilice migraciones para cambios de esquema
Siga las mejores prácticas de seguridad para la gestión de usuarios
Supervisar y optimizar el rendimiento de la base de datos
Clonar el repositorio
Instalar dependencias: npm install
Copiar .env.example a .env y configurar
Construir: npm run build
Inicie su instancia de PocketBase
El servidor MCP se conectará automáticamente a su instancia de PocketBase
Para instalar PocketBase Server para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli install pocketbase-server --client claudeBifurcar el repositorio
Crear una rama de características
Confirme sus cambios
Empujar hacia la rama
Crear una solicitud de extracción
| 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…
