The PocketBase MCP Server provides comprehensive tools for interacting with PocketBase databases through the Model Context Protocol, enabling advanced database operations, schema management, and data manipulation.
Collection Management: Create, update, delete, and list collections with custom schemas supporting various field types (text, number, date, email, URL, JSON, relations, files, rich text editors, auto-dates). Configure API rules for CRUD operations and set up different collection types (base, view, auth).
Record Operations: Perform full CRUD operations with pagination, filtering, and sorting capabilities. Import bulk data with create/update/upsert modes.
Authentication & User Management: Authenticate users via email/password (including admin), OAuth2 providers (Google, Facebook, GitHub, etc.), or one-time passwords. Create user accounts, refresh authentication tokens, impersonate users (admin only), and list available authentication methods.
Email & Password Management: Handle email verification requests and confirmations, password reset workflows, and email change requests with token-based verification.
Database Operations: Create database backups with custom naming options.
Configuration & Integration: Connect to PocketBase instances via environment variables with support for local setup, Docker, and Docker Compose deployments. Integrate with AI assistants like Claude, Cursor, and VS Code with auto-approval configuration options.
Provides sophisticated tools for interacting with PocketBase databases, enabling collection management, record operations (CRUD with relationship support), user authentication, and database backup capabilities.
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 the last 10 users created in the past week"
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 very much in progress MCP server based off of the Dynamics one that I have been testing and refining. That provides sophisticated tools for interacting with PocketBase databases. This server enables advanced database operations, schema management, and data manipulation through the Model Context Protocol (MCP).
Here is a video of me using it: https://www.youtube.com/watch?v=ZuTIO3I7rTM&t=345s
This has actually been tested on the latest version. Currently 26.1 of PocketBase and is built off of the type definitions in the JS-SDK and not the arbitrary and wrong definitions found in the Dynamics one. Many of the methods don't even work.
Related MCP server: Xano MCP Server
To set up the MCP server locally, you'll need to configure it within your cline_mcp_settings.json or whatever you use (claude, cursor, the config looks identical you just need to find where it is stored) file. Here's how:
Locate your cline_mcp_settings.json file: This file is usually located in your Cursor user settings directory. For example:
/Users/yourusername/Library/Application Support/Cursor/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Configure the server: Add a new entry to the mcpServers object in your cline_mcp_settings.json file. The key should be a unique name for your server (e.g., "pocketbase-server"), and the value should be an object containing the server's configuration.
{
"mcpServers": {
"pocketbase-server": {
"command": "node",
"args": ["build/index.js"],
"env": {
"POCKETBASE_URL": "http://127.0.0.1:8090",
"POCKETBASE_ADMIN_EMAIL": "admin@example.com",
"POCKETBASE_ADMIN_PASSWORD": "admin_password"
},
"disabled": false,
"autoApprove": ["create_record", "create_collection"]
}
}
}command: The command to start the server (usually node).
args: An array of arguments to pass to the command. This should point to the compiled JavaScript file of your MCP server (e.g., build/index.js). Make sure the path is correct.
env: An object containing environment variables.
POCKETBASE_URL: The URL of your PocketBase instance. This is required.
POCKETBASE_ADMIN_EMAIL: The admin email for your PocketBase instance (optional, but needed for some operations).
POCKETBASE_ADMIN_PASSWORD: The admin password for your PocketBase instance (optional, but needed for some operations).
disabled: Whether to disable to server on startup.
autoApprove: list of tools to auto approve.
Adjust the values in the env object to match your PocketBase instance's settings.
Setup in vscode is similar , find or create .vscode/mcp.json and add
{
"inputs": [
{
"type": "promptString",
"id": "pocketbase-admin-email",
"description": "PocketBase Admin Email",
"password": false
},
{
"type": "promptString",
"id": "pocketbase-admin-password",
"description": "PocketBase Admin Password",
"password": true
}
],
"servers": {
"pocketbaseServer": {
"type": "stdio",
"command": "node",
// replace this with the path to your compiled MCP server (git clone the repo and run `npm run build` to compile)
"args": ["~/Desktop/code/mcp/pocketbase-mcp/build/index.js"],
"env": {
"POCKETBASE_URL": "http://127.0.0.1:8090",
"POCKETBASE_ADMIN_EMAIL": "${input:pocketbase-admin-email}",
"POCKETBASE_ADMIN_PASSWORD": "${input:pocketbase-admin-password}"
}
}
}
}Start the server: After configuring the cline_mcp_settings.json file, you can start using the MCP server with the configured tools.
You can run the PocketBase MCP server using Docker. A Dockerfile is included in the repository.
# Build the Docker image
docker build -t pocketbase-mcp .# Run the container with environment variables
docker run -d \
--name pocketbase-mcp \
-e POCKETBASE_URL=http://127.0.0.1:8090 \
-e POCKETBASE_ADMIN_EMAIL=your_admin@example.com \
-e POCKETBASE_ADMIN_PASSWORD=your_admin_password \
pocketbase-mcpTo use the Dockerized MCP server with your AI assistant (Cursor, Claude, etc.), configure it in your MCP settings:
For Cline/Cursor (cline_mcp_settings.json):
{
"mcpServers": {
"pocketbase-docker": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"POCKETBASE_URL=http://host.docker.internal:8090",
"-e",
"POCKETBASE_ADMIN_EMAIL=your_admin@example.com",
"-e",
"POCKETBASE_ADMIN_PASSWORD=your_admin_password",
"pocketbase-mcp"
],
"disabled": false,
"autoApprove": ["list_collections", "list_records", "get_collection"]
}
}
}For VS Code (.vscode/mcp.json):
{
"inputs": [
{
"type": "promptString",
"id": "pocketbase-admin-email",
"description": "PocketBase Admin Email",
"password": false
},
{
"type": "promptString",
"id": "pocketbase-admin-password",
"description": "PocketBase Admin Password",
"password": true
}
],
"servers": {
"pocketbaseDocker": {
"type": "stdio",
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"POCKETBASE_URL=http://host.docker.internal:8090",
"-e",
"POCKETBASE_ADMIN_EMAIL=${input:pocketbase-admin-email}",
"-e",
"POCKETBASE_ADMIN_PASSWORD=${input:pocketbase-admin-password}",
"pocketbase-mcp"
]
}
}
}-i: Interactive mode (required for stdio communication)
--rm: Automatically remove container when it exits
host.docker.internal: Use this to access PocketBase running on your host machine from within Docker
Environment Variables: Replace placeholder values with your actual PocketBase credentials
Network: If your PocketBase is also running in Docker, use Docker networking (e.g., --network host or custom bridge network)
Create a docker-compose.yml for easier management:
version: "3.8"
services:
pocketbase-mcp:
build: .
environment:
- POCKETBASE_URL=http://host.docker.internal:8090
- POCKETBASE_ADMIN_EMAIL=your_admin@example.com
- POCKETBASE_ADMIN_PASSWORD=your_admin_password
stdin_open: true
tty: trueThen configure your MCP settings to use:
{
"mcpServers": {
"pocketbase-docker": {
"command": "docker-compose",
"args": ["run", "--rm", "pocketbase-mcp"],
"disabled": false
}
}
}Create and manage collections with custom schemas
Retrieve collection schemas and metadata
CRUD operations for records
Relationship expansion support
Pagination and cursor-based navigation
User authentication and token management
User account creation and management
Password management
Database backup
create_collection: Create a new collection with custom schema
get_collection: Get schema details for a collection
create_record: Create a new record in a collection
list_records: List records with optional filters and pagination
update_record: Update an existing record
delete_record: Delete a record
authenticate_user: Authenticate a user and get auth token
create_user: Create a new user account
backup_database: Create a backup of the PocketBase database with format options
The server requires the following environment variables:
POCKETBASE_URL: URL of your PocketBase instance (e.g., "http://127.0.0.1:8090")
Optional environment variables:
POCKETBASE_ADMIN_EMAIL: Admin email for certain operations
POCKETBASE_ADMIN_PASSWORD: Admin password
POCKETBASE_DATA_DIR: Custom data directory path
// 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,
},
],
});
// Authenticate with password
await mcp.use_tool("pocketbase", "authenticate_user", {
email: "user@example.com",
password: "securepassword",
collection: "users",
});Fork the repository
Create a feature branch
Commit your changes
Push to the branch
Create a Pull Request
Authenticate a user with email and password
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email | ||
| password | Yes | User password | |
| collection | No | Collection name (default: users) | users |
| isAdmin | No | Whether to authenticate as an admin (uses _superusers collection) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as what happens on success/failure (e.g., returns token, sets session), security implications, rate limits, or error handling. For an authentication tool with zero annotation coverage, this leaves critical gaps in understanding its operation.
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 front-loads the core purpose ('Authenticate a user') and adds necessary detail ('with email and password'). Every word earns its place, making it appropriately sized and well-structured.
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 authentication (security-sensitive, no annotations, no output schema), the description is incomplete. It lacks details on return values, error cases, side effects, and how it fits with sibling tools. For a tool with 4 parameters and significant behavioral implications, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond implying 'email' and 'password' are used. It doesn't explain parameter interactions or provide context beyond what's in the schema, meeting the baseline for high coverage.
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 ('authenticate') and target ('a user'), specifying the method ('with email and password'). It distinguishes from sibling tools like 'authenticate_with_oauth2' and 'authenticate_with_otp' by naming the authentication method, but doesn't explicitly contrast them. The purpose is specific but could be more differentiated.
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 is provided on when to use this tool versus alternatives like 'authenticate_with_oauth2' or 'authenticate_with_otp'. The description implies usage for email/password authentication but doesn't mention prerequisites, error conditions, or typical scenarios. Without explicit when/when-not instructions, it offers minimal usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate a user with OAuth2
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | OAuth2 provider name (e.g., google, facebook, github) | |
| code | Yes | The authorization code returned from the OAuth2 provider | |
| codeVerifier | Yes | PKCE code verifier | |
| redirectUrl | Yes | The redirect URL used in the OAuth2 flow | |
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions authentication but doesn't explain what happens (e.g., token generation, session creation, user record updates), permissions required, error handling, or side effects. This leaves critical behavioral traits unspecified for a security-sensitive operation.
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 no wasted words. It's front-loaded with the core action, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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 OAuth2 authentication, lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, return values, or usage context, leaving significant gaps for a tool with 5 parameters and security implications.
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%, providing clear parameter details. The description adds no additional semantic context beyond implying OAuth2 usage, which is already covered by parameter names and schema descriptions. This meets the baseline for high schema coverage without enhancing understanding.
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 states the action ('Authenticate a user') and mechanism ('with OAuth2'), which is clear but vague. It doesn't specify what authentication entails (e.g., obtaining tokens, creating sessions) or differentiate from sibling tools like 'authenticate_user' or 'authenticate_with_otp', leaving ambiguity about when to use this specific OAuth2 method.
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 is provided on when to use this tool versus alternatives like 'authenticate_user' or 'authenticate_with_otp'. The description implies it's for OAuth2 flows but doesn't specify prerequisites (e.g., needing an authorization code from a provider) or exclusions, offering minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate a user with one-time password
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email | ||
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs authentication but doesn't mention whether it's a read-only operation, what permissions are required, how it handles errors, or what the output looks like. For an authentication tool with zero annotation coverage, this is a significant gap in safety and operational context.
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 wasted words. It's front-loaded with the core purpose and appropriately sized for a straightforward tool, making it easy for an agent to parse quickly.
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 authentication (which involves security and state changes) and the lack of annotations and output schema, the description is insufficient. It doesn't cover behavioral aspects like side effects, error handling, or return values, leaving critical gaps for an agent to operate this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('email' and 'collection') adequately. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between email and OTP or the purpose of the collection parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('authenticate') and the method ('with one-time password'), which distinguishes it from sibling tools like 'authenticate_user' or 'authenticate_with_oauth2'. However, it doesn't specify what resource or system is being authenticated against, leaving some ambiguity about the target.
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 like 'authenticate_with_oauth2' or 'authenticate_user'. It lacks context about prerequisites (e.g., whether OTP must be pre-generated) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh authentication token
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Refresh authentication token' implies a mutation operation that likely requires valid credentials, but the description doesn't specify prerequisites, rate limits, security implications, or what happens to the old token. For a security-sensitive tool with zero annotation coverage, this is inadequate.
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 perfectly concise at three words, front-loading the essential action and resource with zero wasted language. Every word earns its place in communicating the core functionality.
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 this is an authentication tool with no annotations, no output schema, and security implications, the description is incomplete. It should explain what 'refresh' entails, what credentials are needed, whether this invalidates previous tokens, and what format the response takes, but provides none of this context.
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 schema has 100% description coverage for its single parameter ('collection'), so the schema already documents this parameter adequately. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the high schema coverage but doesn't add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Refresh authentication token' clearly states the verb ('Refresh') and resource ('authentication token'), making the tool's purpose immediately understandable. However, it doesn't differentiate this from sibling authentication tools like 'authenticate_user' or 'authenticate_with_oauth2', which would require explaining what makes token refresh distinct from initial authentication.
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. With multiple authentication-related siblings (authenticate_user, authenticate_with_oauth2, authenticate_with_otp), the description should specify that this is for refreshing existing tokens rather than obtaining new ones, but it offers no such context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a backup of the PocketBase database
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | backup name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create a backup' implies a write operation that likely requires admin permissions and may impact database performance, but none of this is mentioned. The description doesn't disclose whether the backup is immediate or scheduled, if it locks the database, what format it creates, or where backups are stored. For a potentially disruptive operation with zero annotation coverage, this is inadequate.
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 that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple backup operation and front-loads the core functionality. Every word earns its place in this minimal but complete statement of purpose.
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 database backup tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address critical context like permission requirements, performance impact, backup location, format, restoration procedures, or what happens if a backup with the same name exists. Given the potential complexity and risk of backup operations, more behavioral context is needed.
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 100% description coverage, with the single parameter 'name' documented as 'backup name'. The description doesn't add any parameter information beyond what the schema provides, but with complete schema coverage, the baseline is 3. The description doesn't explain naming conventions, constraints, or default behavior if no name is provided.
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 a backup') and the resource ('PocketBase database'), making the tool's purpose immediately understandable. It doesn't distinguish from sibling tools, but since backup operations are unique among the listed siblings, this is adequate. The description avoids tautology by specifying what kind of backup is created.
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, prerequisites, or timing considerations. While it's obvious this is for database backup, there's no mention of when backups should be created, what happens during backup, or whether other operations should be paused. This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm email change with token
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Email change token | |
| password | Yes | Current password for confirmation | |
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action is a confirmation but doesn't reveal critical traits: whether this is a write operation (likely yes), what gets modified (e.g., user email), authentication requirements beyond the password parameter, error conditions, or side effects. The description is too minimal for a mutation tool with zero annotation coverage.
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 extremely concise—a single, clear sentence with zero wasted words. It's front-loaded with the core action and required input, making it easy to parse. Every word earns its place, achieving ideal brevity for such a simple statement.
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's complexity (a mutation with security implications), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens on success (e.g., email updated, confirmation sent), error responses, or dependencies on other tools. For a sensitive operation like email change confirmation, more context is needed to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (token, password, collection). The description adds no additional meaning about parameters beyond implying a token is needed. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't compensate with extra context like token format or password requirements.
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 ('confirm email change') and the required input ('with token'), making the purpose understandable. It distinguishes itself from siblings like 'request_email_change' by focusing on confirmation rather than initiation. However, it doesn't specify what resource is being modified (e.g., user account), 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 (e.g., that 'request_email_change' must be called first), exclusions, or relationships with sibling tools like 'confirm_verification' or 'confirm_password_reset'. This leaves the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm password reset with token
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Reset token | |
| password | Yes | New password | |
| passwordConfirm | Yes | Confirm new password | |
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a mutation (implied by 'confirm'), what permissions are needed, whether it invalidates the token, or any rate limits/errors, leaving significant gaps for a security-sensitive operation.
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 no wasted words, making it easy to parse. However, it could be more front-loaded with key details (e.g., 'Finalize password reset for a user account'), but it's appropriately sized for its limited content.
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 password reset operation (security-sensitive, no annotations, no output schema), the description is incomplete. It lacks details on behavior, error cases, or output expectations, which are critical for safe tool invocation in this context.
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 parameters are well-documented in the schema. The description adds minimal value by mentioning 'token', but doesn't explain parameter interactions (e.g., password matching) or the optional 'collection' parameter beyond the schema's default, meeting the baseline.
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 states the action ('confirm password reset') and mentions the token parameter, which gives a basic understanding. However, it doesn't specify what resource is being modified (e.g., user account) or differentiate from siblings like 'request_password_reset' or 'confirm_email_change', making it somewhat vague.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after 'request_password_reset'), exclusions, or how it relates to sibling tools like 'authenticate_user' or 'create_user', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirm email verification with token
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Verification token | |
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It implies a write operation ('confirm') but doesn't disclose permissions needed, side effects (e.g., updates user status), error conditions, or response format. For a mutation tool with zero annotation coverage, this is inadequate.
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 front-loads the core purpose ('confirm email verification') and includes the essential constraint ('with token'), making it appropriately sized and well-structured.
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's complexity (a mutation with security implications), lack of annotations, and no output schema, the description is incomplete. It fails to explain what 'confirm' does behaviorally, what happens on success/failure, or any dependencies, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('token' and 'collection'). The description adds no additional meaning beyond implying 'token' is for verification, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('confirm') and resource ('email verification'), specifying it requires a token. It distinguishes from siblings like 'request_verification' (which initiates) and 'confirm_email_change' (which handles different verification). However, it doesn't explicitly mention what 'confirm' entails (e.g., marking email as verified), keeping it from 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?
No guidance on when to use this tool versus alternatives is provided. It doesn't mention prerequisites (e.g., must be called after 'request_verification'), exclusions, or how it differs from similar tools like 'confirm_email_change' or 'confirm_password_reset'. The description alone offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new collection in PocketBase note never use created and updated because these are already created
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique collection name (used as a table name for the records table) | |
| type | No | Type of the collection | base |
| fields | Yes | List with the collection fields | |
| createRule | No | API rule for creating records | |
| updateRule | No | API rule for updating records | |
| deleteRule | No | API rule for deleting records | |
| listRule | No | API rule for listing and viewing records | |
| viewRule | No | API rule for viewing a single record | |
| viewQuery | No | SQL query for view collections | |
| passwordAuth | No | Password authentication options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create a new collection' implies a write/mutation operation, the description doesn't disclose any behavioral traits: no information about permissions required, whether this is idempotent, what happens on conflicts, rate limits, or what the response looks like. The confusing note about 'created and updated' adds noise rather than useful behavioral context.
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 technically concise but poorly structured. The first part 'Create a new collection in PocketBase' is clear, but the second part 'note never use created and updated because these are already created' is confusing, appears to be a developer note that doesn't help the AI agent, and doesn't earn its place in the description. The two parts don't form a coherent whole.
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 complex mutation tool with 10 parameters (including nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'collection' represents in PocketBase context, doesn't describe the outcome or response format, and the confusing note about 'created and updated' creates more questions than answers. The agent would struggle to use this tool effectively based solely on this 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?
The schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly with descriptions, enums, and required fields. The description adds no parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify the confusing 'never use created and updated' note in relation to the schema parameters.
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 a new collection') and the target system ('in PocketBase'), which provides a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update_collection' or 'delete_collection' beyond the basic action, and the second part about 'never use created and updated' is confusing rather than clarifying.
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 like 'update_collection' or 'get_collection'. The confusing note about 'never use created and updated' appears to be a usage warning but is unclear and doesn't help the agent understand appropriate contexts or prerequisites for this creation operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new record in a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection name | |
| data | Yes | Record data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it creates a record, implying a write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, error handling, or what happens on success/failure. This is inadequate for a mutation tool with zero annotation coverage.
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 no wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial context like what the tool returns, error conditions, or how it interacts with other tools (e.g., 'list_records' or 'delete_record'), leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('collection' and 'data'). The description doesn't add meaning beyond what the schema provides, such as examples or constraints, but the baseline is 3 when schema coverage is high.
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 verb ('Create') and resource ('new record in a collection'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'create_collection' or 'create_user', which also create resources but different types.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or how it relates to siblings like 'create_collection' or 'update_record'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new user account
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email | ||
| password | Yes | User password | |
| passwordConfirm | Yes | Password confirmation | |
| name | No | User name | |
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Create') which implies a write/mutation operation, but doesn't mention permissions required, whether it's idempotent, what happens on duplicate emails, or what the response looks like. For a user creation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 that gets straight to the point. Every word earns its place - 'Create' (action), 'new' (state), 'user account' (resource). No wasted words or unnecessary elaboration. Perfectly front-loaded and concise.
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 user creation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address authentication requirements, error conditions, return values, or how this differs from similar creation tools. The agent lacks critical context needed to use this tool effectively in a real system.
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 all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain relationships between parameters (like password/passwordConfirm validation) or provide additional context. Baseline 3 is appropriate when schema does the heavy lifting.
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 user account'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'create_record' or 'create_collection', but the specificity of 'user account' provides reasonable distinction. No tautology or misleading elements are present.
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 (like authentication), when not to use it, or how it differs from similar tools like 'create_record' or 'create_collection'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a collection from PocketBase (admin only)
| Name | Required | Description | Default |
|---|---|---|---|
| collectionIdOrName | Yes | ID or name of the collection to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'admin only', indicating permission requirements, but lacks details on destructive effects (e.g., whether deletion is permanent, impacts on related records), rate limits, or error handling. This is a significant gap for a mutation tool with zero annotation coverage.
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 no wasted words. It front-loads the key information (action, resource, admin restriction), making it easy to parse quickly. Every part of the sentence contributes essential context.
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's complexity as a destructive admin operation with no annotations and no output schema, the description is incomplete. It should cover more behavioral aspects like permanence of deletion, effects on data, or response format. The current description leaves critical gaps for safe and 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?
Schema description coverage is 100%, with the parameter 'collectionIdOrName' fully documented in the schema. The description doesn't add any additional meaning or context beyond what the schema provides, such as examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 ('Delete') and resource ('a collection from PocketBase'), making the purpose unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'delete_record' or 'update_collection', which would require a more specific scope or comparison.
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 includes 'admin only', which implies usage context and prerequisites, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'update_collection' or 'delete_record'. The context is implied rather than fully articulated with clear alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a record
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection name | |
| id | Yes | Record ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete a record' implies a destructive, irreversible mutation, but it doesn't specify consequences (e.g., data loss, audit trails), permissions required, or error handling. This is inadequate for a destructive tool with zero annotation coverage.
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 extremely concise with a single sentence, 'Delete a record', which is front-loaded and wastes no words. It efficiently communicates the core action 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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It fails to address critical aspects like what happens post-deletion, error cases, or return values, leaving significant gaps for an AI agent to understand the tool's 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%, with clear descriptions for 'collection' and 'id' parameters. The description adds no additional meaning beyond the schema, such as format examples or constraints, but the schema itself is well-documented, meeting the baseline for adequate parameter semantics.
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 'Delete a record' states a clear verb ('Delete') and resource ('record'), but it's vague about what type of record is being deleted and doesn't distinguish it from sibling tools like 'delete_collection' or 'update_record'. It provides basic purpose but lacks specificity.
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 offers no guidance on when to use this tool versus alternatives like 'delete_collection' or 'update_record', nor does it mention prerequisites such as authentication or permissions. It's a bare statement with no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collectionIdOrName | Yes | ID or name of the collection to view | |
| fields | No | Comma separated string of the fields to return in the JSON response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets details' without disclosing behavioral traits like permissions needed, rate limits, error handling, or what happens if the collection doesn't exist. It's minimal and lacks critical operational context.
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—'Get details for a collection' is front-loaded and appropriately sized for its purpose, making it highly concise and well-structured.
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 (a read operation with 2 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error cases, or usage nuances, leaving significant gaps for an AI agent to understand the tool fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('collectionIdOrName' and 'fields'). The description adds no meaning beyond this, such as examples of field names or how to format the comma-separated string, resulting in a 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 'Get details for a collection' clearly states the verb ('Get') and resource ('collection'), but it's vague about what 'details' entails and doesn't differentiate from sibling tools like 'list_collections' or 'update_collection'. It's functional but lacks specificity.
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 is provided on when to use this tool versus alternatives such as 'list_collections' for browsing or 'update_collection' for modifications. The description implies usage for viewing a specific collection but offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Impersonate another user (admin only)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the user to impersonate | |
| collectionIdOrName | No | Collection name or id (default: users) | users |
| duration | No | Token expirey time (default: 3600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers limited behavioral insight. It mentions admin-only access but doesn't disclose critical traits like whether this is a read/write operation, security implications, token generation details, or side effects. For a sensitive tool like impersonation, this is a significant gap in 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 extremely concise with a single, front-loaded sentence that states the core purpose and key constraint ('admin only'). There is zero waste or redundancy, making it efficient and easy to parse, though this conciseness comes at the cost of depth in other dimensions.
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's complexity (impersonation is a high-stakes operation), lack of annotations, and no output schema, the description is incomplete. It fails to explain what the tool returns (e.g., a token or session), security considerations, or how it integrates with sibling authentication tools, leaving critical context gaps for safe and 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?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying user impersonation, which aligns with the 'id' parameter. Baseline 3 is appropriate as the schema handles the heavy lifting, but the description doesn't enhance understanding of 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 clearly states the action ('impersonate') and target ('another user'), with the additional constraint 'admin only' indicating permission requirements. However, it doesn't explicitly differentiate this tool from sibling authentication tools like 'authenticate_user' or 'create_user', which would require more specific context about what impersonation entails versus standard authentication.
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 minimal guidance with 'admin only' hinting at when to use (admin contexts), but lacks explicit when-not-to-use scenarios, alternatives (e.g., vs. 'authenticate_user'), or prerequisites. No comparison to sibling tools is made, leaving usage context vague beyond the admin restriction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import data into a collection
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection name | |
| data | Yes | Array of records to import | |
| mode | No | Import mode (default: create) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'import' which implies a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it overwrites existing data, error handling, rate limits, or what happens on partial failures. For a mutation tool with zero annotation coverage, this is inadequate.
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?
Extremely concise with a single sentence that directly states the tool's purpose. No wasted words or redundant information. Perfectly front-loaded with the core action.
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 mutation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't cover important contextual aspects like what the tool returns, error conditions, side effects, or how it differs from similar tools. The agent would struggle to use this effectively without trial and error.
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 parameters are fully documented in the schema. The description adds no additional meaning about parameters beyond the basic action. It doesn't explain the implications of different 'mode' values or provide examples of data format. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Import data into a collection' clearly states the action (import) and target resource (collection), distinguishing it from sibling tools like create_record or update_record which handle individual records. However, it doesn't specify what type of data or format, leaving some ambiguity compared to more specific alternatives.
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 create_record, update_record, or create_collection. The description implies bulk operations but doesn't clarify prerequisites, constraints, or comparative advantages over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available authentication methods
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, what permissions are required, how results are formatted, or if there are rate limits. 'List all' implies completeness but lacks detail on pagination or filtering beyond the schema parameter.
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 wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it highly efficient.
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 no annotations and no output schema, the description is too sparse. It doesn't explain what 'authentication methods' entails, how results are returned, or any behavioral nuances. Given the context of sibling auth tools, more guidance on usage and output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'collection' with its type, description, and default. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high coverage.
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 verb ('List') and resource ('authentication methods'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_collections' or 'list_records' beyond the resource name, 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. There's no mention of prerequisites, context for listing auth methods, or comparison to related tools like 'authenticate_user' or 'get_collection' that might overlap in functionality.
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 PocketBase
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter query for collections | |
| sort | No | Sort order for collections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention potential side effects, authentication requirements, rate limits, pagination, or return format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 wasted words. It's appropriately sized for a simple list operation and front-loads the core purpose immediately, making it easy to parse quickly.
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's low complexity (a list operation with 2 optional parameters) and 100% schema coverage, the description is minimally adequate. However, with no output schema and no annotations, it should ideally mention the return type or format to be more complete, but it's not critically lacking for this simple case.
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 100% description coverage, with both parameters ('filter' and 'sort') documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 ('List all collections') and resource ('in PocketBase'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_collection' or 'create_collection', which would require explicit comparison to achieve a score of 5.
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 like 'get_collection' (for a single collection) or 'create_collection' (for creating new ones). There's no mention of prerequisites, context, or exclusions, leaving usage entirely implied from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List records from a collection with optional filters
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection name | |
| filter | No | Filter query | |
| sort | No | Sort field and direction | |
| page | No | Page number | |
| perPage | No | Items per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a list operation with optional filters, implying read-only behavior, but doesn't disclose critical details like pagination handling (implied by 'page' and 'perPage' parameters), rate limits, authentication requirements, or error conditions. For a tool with 5 parameters and no annotation coverage, this leaves significant behavioral gaps.
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 that front-loads the core purpose ('List records from a collection') and adds key functionality ('with optional filters'). There is no wasted verbiage, and it's appropriately sized for the tool's complexity.
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 5 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format. For a list operation with filtering and pagination, more guidance on results and limitations would improve completeness, but it's not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema by mentioning 'optional filters' (hinting at the 'filter' parameter) but doesn't provide additional context like filter syntax examples or default behaviors. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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 verb ('List') and resource ('records from a collection'), making the purpose understandable. It distinguishes from siblings like 'get_collection' or 'create_record' by focusing on listing records rather than single retrieval or creation. However, it doesn't explicitly differentiate from other list operations like 'list_collections' beyond the resource type.
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 mentions 'optional filters' but doesn't specify scenarios where filtering is needed or when to choose this over other tools like 'get_collection' for metadata or 'search' operations if available. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request email change
| Name | Required | Description | Default |
|---|---|---|---|
| newEmail | Yes | New email address | |
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to describe what the tool does beyond 'request'—such as whether it sends a notification, requires confirmation, affects user state, or has side effects like rate limits. This leaves critical behavioral traits unspecified for a mutation-related tool.
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 extremely concise with just two words, avoiding unnecessary elaboration. It's front-loaded with the core action, though this brevity contributes to underspecification rather than efficiency. Every word earns its place, but the content is minimal.
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 an email change request (likely involving user authentication, confirmation workflows, and side effects), the description is incomplete. With no annotations, no output schema, and minimal behavioral context, it fails to provide enough information for safe and effective use, especially compared to detailed sibling tools like 'confirm_email_change'.
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%, with clear documentation for both parameters ('newEmail' and 'collection'). The description adds no additional meaning beyond the schema, such as email format requirements or collection implications. Baseline 3 is appropriate since the schema adequately covers parameter semantics.
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 'Request email change' is a tautology that restates the tool name without adding meaningful context. It specifies the action ('request') and resource ('email change') but lacks specificity about what the request entails or who initiates it. Compared to sibling tools like 'confirm_email_change', it doesn't distinguish its role in the workflow.
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., authentication), related tools like 'confirm_email_change', or scenarios where it's appropriate. Without this, an agent might misuse it or overlook necessary follow-up steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request password reset
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email | ||
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. It doesn't indicate whether this is a read-only or mutation operation, what side effects occur (email sending, temporary token generation), security implications, rate limits, or response format. For a security-sensitive operation, this lack of transparency is critical.
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 extremely concise at just three words, with no wasted verbiage. However, this conciseness comes at the cost of being under-specified for a security operation. While structurally minimal, it could benefit from slightly more content to be genuinely helpful.
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 password reset tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after the request, what the user experiences, error conditions, or security considerations. Given the sensitive nature of password operations and the lack of structured metadata, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (email and collection) adequately. The description adds no parameter information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide additional context about parameter relationships 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 'Request password reset' is a tautology that restates the tool name without adding specificity. It doesn't explain what resource is being acted upon (user accounts) or what the actual outcome is (sending a reset email/link). While the purpose is somewhat inferable, it lacks the verb+resource clarity needed for higher scoring.
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. With sibling tools like 'confirm_password_reset' available, there's no indication of the workflow relationship or prerequisites. The description doesn't mention authentication state requirements, error conditions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request email verification
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email | ||
| collection | No | Collection name (default: users) | users |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal insight. It implies a mutation (requesting verification likely sends an email), but doesn't specify permissions required, rate limits, whether it's idempotent, what happens on success/failure, or the response format. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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 wasted words. It front-loads the core purpose ('Request email verification') without unnecessary elaboration. Every word earns its place, making it easy to parse quickly.
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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error handling), response expectations, and usage context. While concise, it doesn't compensate for the missing structured data, leaving the agent under-informed about how and when to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters ('email' and 'collection'). The description adds no parameter-specific information beyond what the schema provides—it doesn't explain why 'collection' defaults to 'users' or how these parameters interact. Baseline 3 is appropriate when the schema handles all parameter documentation.
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 ('Request') and resource ('email verification'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'confirm_verification' by focusing on the initiation rather than completion of verification. However, it doesn't specify what type of verification (e.g., initial account verification, re-verification) or the mechanism (e.g., sends verification link/code).
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., unverified email state), exclusions (e.g., already verified emails), or related tools like 'confirm_verification' for completing the process. The agent must infer usage from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing collection in PocketBase (admin only)
| Name | Required | Description | Default |
|---|---|---|---|
| collectionIdOrName | Yes | ID or name of the collection to update | |
| name | No | New unique collection name | |
| type | No | Type of the collection | |
| fields | No | List with the new collection fields. If not empty, the old schema will be replaced with the new one. | |
| createRule | No | API rule for creating records | |
| updateRule | No | API rule for updating records | |
| deleteRule | No | API rule for deleting records | |
| listRule | No | API rule for listing and viewing records | |
| viewRule | No | API rule for viewing a single record | |
| viewQuery | No | SQL query for view collections | |
| passwordAuth | No | Password authentication options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'admin only' (permissions) but fails to describe critical traits: whether this is a destructive operation (e.g., replacing fields schema), what happens to existing data, error conditions, or response format. For a complex mutation tool with 11 parameters, this is inadequate.
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 extremely concise (one sentence) and front-loaded with essential information ('Update an existing collection'). Every word earns its place, with no redundant or verbose phrasing. It efficiently communicates core purpose and a key constraint ('admin only').
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's complexity (11 parameters, mutation operation, no output schema, no annotations), the description is insufficient. It lacks information about behavioral consequences (e.g., schema replacement with 'fields'), error handling, return values, and detailed usage context. The 'admin only' hint is helpful but doesn't compensate for other gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 11 parameters. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't clarify relationships between parameters like 'fields' replacement behavior). Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 verb ('Update') and resource ('an existing collection in PocketBase'), making the purpose unambiguous. It distinguishes from siblings like 'create_collection' (new vs existing) and 'delete_collection' (update vs remove). However, it doesn't specify what aspects can be updated (name, type, fields, rules, etc.), 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 minimal guidance: 'admin only' indicates a permission requirement, but it doesn't explain when to use this tool versus alternatives like 'create_collection' or 'update_record'. No explicit when-not-to-use scenarios or prerequisites beyond admin status are mentioned, leaving significant gaps in usage context.
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
| Name | Required | Description | Default |
|---|---|---|---|
| collection | Yes | Collection name | |
| id | Yes | Record ID | |
| data | Yes | Updated record data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool performs an update operation but doesn't mention permission requirements, whether changes are reversible, potential side effects, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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 no wasted words. It's appropriately sized for a basic tool description and gets straight to the point 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?
For a mutation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens during updates, error conditions, or return values. The agent lacks crucial information about how this tool behaves in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (collection, id, data). The description adds no additional meaning about parameter usage, relationships, or constraints beyond what the schema provides, meeting the baseline for high schema coverage.
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 'Update an existing record' clearly states the action (update) and target (record), but it's vague about what constitutes a 'record' in this context and doesn't distinguish from sibling tools like update_collection. It avoids tautology but lacks specificity about the resource being modified.
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 is provided about when to use this tool versus alternatives like create_record or delete_record, nor about prerequisites such as authentication or existing record requirements. The description offers no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between authentication tools (authenticate_user, authenticate_with_oauth2, authenticate_with_otp) that could cause confusion, though their descriptions clarify the methods. Other tools like create_record and update_record are clearly differentiated by their actions on records.
Tool names follow a consistent verb_noun pattern throughout, such as authenticate_user, create_collection, list_records, and update_record. There are no deviations in naming conventions, making the set predictable and easy to understand.
With 24 tools, the count is on the higher side for a typical MCP server, which might feel heavy and could overwhelm agents. However, given PocketBase's scope covering authentication, collections, records, and admin functions, it is borderline but still within a reasonable range for the domain.
The tool set provides comprehensive coverage for PocketBase operations, including full CRUD for collections and records, authentication methods (user, OAuth2, OTP), user management, and admin functions like backup and impersonation. No obvious gaps are present, ensuring agents can handle complete workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
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…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrwyndham/pocketbase-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
