Provides tools for interacting with PocketBase databases, including listing collections, retrieving collection schemas, and performing CRUD operations on records.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pocketbase-mcp-server list all records in the 'articles' collection"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for interacting with PocketBase databases.
This server allows you to inspect collections and query, create, update, and delete records inside a PocketBase instance.
You can use this server directly via npx (recommended) or install it globally.
To run the server without installing it locally, configure your MCP client to use:
npx @yhauxell/pocketbase-mcp-servernpm install -g @yhauxell/pocketbase-mcp-serverThen run the command:
pocketbase-mcp-serverRelated MCP server: PocketBase MCP Server
To register the server, add the following to your MCP client settings file (e.g., claude_desktop_config.json):
npx (Recommended)Using admin email & password:
{
"mcpServers": {
"pocketbase-mcp-server": {
"command": "npx",
"args": ["-y", "@yhauxell/pocketbase-mcp-server"],
"env": {
"POCKETBASE_URL": "http://127.0.0.1:8090",
"POCKETBASE_ADMIN_EMAIL": "your_email@example.com",
"POCKETBASE_ADMIN_PASSWORD": "your_password"
}
}
}
}Using an auth token:
{
"mcpServers": {
"pocketbase-mcp-server": {
"command": "npx",
"args": ["-y", "@yhauxell/pocketbase-mcp-server"],
"env": {
"POCKETBASE_URL": "http://127.0.0.1:8090",
"POCKETBASE_AUTH_TOKEN": "your_auth_token_here"
}
}
}
}If you are developing locally, run npm run build and use:
{
"mcpServers": {
"pocketbase-mcp-server": {
"command": "node",
"args": ["/absolute/path/to/pocketbase-mcp-server/dist/index.js"],
"env": {
"POCKETBASE_URL": "http://127.0.0.1:8090",
"POCKETBASE_ADMIN_EMAIL": "your_email@example.com",
"POCKETBASE_ADMIN_PASSWORD": "your_password"
}
}
}
}Clone the repository and install dependencies:
npm installBuild the project:
npm run buildConfigure environment variables in a .env file:
POCKETBASE_URL=http://127.0.0.1:8090
POCKETBASE_ADMIN_EMAIL=your_email@example.com
POCKETBASE_ADMIN_PASSWORD=your_passwordpb_list_collections: List all collections in the PocketBase database.
pb_get_collection: Get schema details of a specific collection.
pb_list_records: Retrieve paginated, filtered, and sorted records from a collection.
pb_view_record: Retrieve a single record by its ID.
pb_create_record: Create a new record in a collection.
pb_update_record: Update an existing record in a collection.
pb_delete_record: Delete a record from a collection.
Contributions are welcome! Please read CONTRIBUTING.md for details on how to get started.
This project is licensed under the MIT License - see the LICENSE file for details.
Create a new record in a collection
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Key-value pairs representing the record fields | |
| collectionIdOrName | Yes | The name or ID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as idempotency, side effects, authentication requirements, or return value behavior. The description is too minimal to aid agent understanding beyond the obvious.
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 very short (one sentence), which is concise but may be under-specified. It front-loads the core action, but lacks supporting details that would make it useful without relying on the tool name and schema.
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 the complexity of a creation operation (2 required params, no output schema, no annotations), the description is incomplete. It does not explain return values, error conditions, or required permissions, leaving significant gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new meaning beyond what the schema provides. Baseline score of 3 is appropriate; no extra value or clarification on parameter usage or constraints.
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 'Create a new record in a collection' clearly specifies the verb (create) and resource (record in a collection). It distinguishes itself from siblings like pb_delete_record and pb_update_record by implying creation rather than mutation or deletion, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., pb_update_record for updating existing records). No prerequisites or context for invocation are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a record from a collection
| Name | Required | Description | Default |
|---|---|---|---|
| recordId | Yes | The ID of the record to delete | |
| collectionIdOrName | Yes | The name or ID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states the action without disclosing behavioral traits like irreversibility, cascade effects, auth requirements, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste, front-loaded with verb and resource. Ideal structure for a simple operation.
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 deletion tool, critical context is missing: no mention of irreversibility, soft-delete behavior, or what happens to related records. No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the schema already documents them. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('record from a collection'), clearly distinguishing it from sibling tools like pb_create_record, pb_update_record, and pb_view_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., pb_update_record for soft-delete). No prerequisites, error conditions, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get schema details and metadata of a specific collection by its name or ID
| Name | Required | Description | Default |
|---|---|---|---|
| collectionIdOrName | Yes | The name or ID of the collection to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the core function (reading schema/metadata), which implies a safe read operation. However, it does not explicitly state read-only nature, auth requirements, or any side effects, leaving some ambiguity about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys all essential information without extraneous words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-schema tool with one parameter and no output schema, the description adequately covers what the tool does and how to call it. It could be enhanced by hinting at what the returned metadata includes, but given the simplicity, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, with a description that already explains it accepts a name or ID. The tool description merely echoes this by saying 'by its name or ID', adding no additional semantic detail beyond the input 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 'Get schema details and metadata of a specific collection by its name or ID', specifying the verb (get), resource (collection details), and how to identify the collection. It distinguishes from sibling tools like pb_list_collections (which lists all collections) and record operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing details of a specific collection, but lacks explicit guidance on when not to use it or comparison with alternatives like pb_list_collections. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collections in the PocketBase database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it lists collections; it does not explicitly confirm it's a read-only operation or disclose any potential side effects, though the name implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no extraneous information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is sufficient; however, it could add context about return format or global scope, but given the simplicity, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is fully covered; the description adds no parameter detail but that is acceptable since none exist.
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 'List all collections in the PocketBase database' clearly states the verb (list) and resource (collections), and it distinguishes itself from siblings that focus on records or single collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like pb_get_collection or pb_list_records; context from sibling names provides implicit differentiation but not enough for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a paginated list of records from a collection with optional filtering, sorting, and relations expansion
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | The page number to fetch (1-indexed) | |
| sort | No | PocketBase sort expression (e.g. '-created,id') | |
| expand | No | Comma-separated relations to expand (e.g. 'user,category') | |
| filter | No | PocketBase filter expression (e.g. 'status = "active" && created > "2022-01-01"') | |
| perPage | No | Number of records per page | |
| collectionIdOrName | Yes | The name or ID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions pagination and optional filtering/sorting/expand but omits details like authentication requirements, error handling, response structure, or side effects. It provides adequate but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence (14 words) with no wasted words. It is front-loaded with the core action and efficiently lists optional features.
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 the tool has 6 parameters and no output schema or annotations, the description covers the essential behavior (list, paginate, filter, sort, expand) but lacks details on response format, error conditions, or usage context. It is minimally complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond summarizing the parameter purposes (e.g., 'optional filtering, sorting, and relations expansion'), which is already covered by parameter descriptions. No new semantics added.
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 ('Retrieve') and the resource ('paginated list of records from a collection'), and it distinguishes this tool from siblings like pb_view_record (single record) and pb_list_collections (list of collections) by focusing on records and listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching lists with optional features but does not explicitly state when to use this tool vs. alternatives or provide exclusion criteria. It lacks guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing record in a collection
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Key-value pairs representing the fields to update | |
| recordId | Yes | The ID of the record to update | |
| collectionIdOrName | Yes | The name or ID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It does not disclose whether updates are partial or full, idempotency, error behavior (e.g., missing record), or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence but lacks structure. Could benefit from being front-loaded with key details.
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?
Missing critical context: no return value description, no error handling hints, and no mention of update behavior. Given 3 parameters with nested objects and no output schema, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The tool description adds no extra meaning beyond the schema; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update an existing record in a collection'—a specific verb and resource. It distinguishes from sibling tools like pb_create_record (create) and pb_delete_record (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites (e.g., record must exist) or when to consider pb_view_record or pb_list_records instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a single record from a collection by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| expand | No | Comma-separated relations to expand | |
| recordId | Yes | The ID of the record to retrieve | |
| collectionIdOrName | Yes | The name or ID of the collection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states basic retrieval, no details on side effects, errors, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded with key information.
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?
No output schema, but description doesn't explain return format or error behavior. Adequate for a simple read tool but incomplete for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameter meaning is already clear. Description adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Retrieve', resource 'a single record from a collection', and method 'by its ID'. Distinguishes from sibling tools like pb_list_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like pb_list_records or pb_get_collection. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation (create, read, update, delete records, list collections, get collection schema) with no overlapping functionality.
All tools follow a consistent 'pb_verb_noun' pattern (e.g., pb_create_record, pb_list_records) with clear verbs and nouns.
Seven tools is an appropriate number for performing core CRUD operations on records and exploring collection metadata without being excessive.
Covers all standard record operations and collection schema queries, but lacks tools for creating, updating, or deleting collections, which may be needed for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read, create, update and delete records; inspect objects, fields and schema in your Knack database.
Create, search, update, and manage data in OnePageCRM.
Access and edit your Craft documents.
Read and write a CRM built for agents. Every change carries who asserted it and how.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yhauxell/pocketbase-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
