PocketBase MCP Server

by mrwyndham

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
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.
Naming Consistency5/5
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.
Tool Count3/5
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.
Completeness5/5
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.
Average 2.8/5 across 24 of 24 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose2/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pocketbase-mcp MCP server](https://glama.ai/mcp/servers/mrwyndham/pocketbase-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mrwyndham/pocketbase-mcp)

Score Badge

Copy to your README.md:

[![pocketbase-mcp MCP server](https://glama.ai/mcp/servers/mrwyndham/pocketbase-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mrwyndham/pocketbase-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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