proton-pass-community-mcp

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools map to distinct resource-action pairs: vaults, items, members, invites, attachments, and utilities are clearly separated. A few boundary cases like create_login_item_from_template versus create_custom_item or list_shares versus list_vaults could cause minor confusion, but the descriptions generally resolve it.
Naming Consistency4/5
The dominant verb_noun snake_case pattern is consistent across the set: list_vaults, create_vault, trash_item, untrash_item, share_vault, and so on. The main deviations are generic single-verb tools like inject and run, plus verbose template-based creation variants, but the overall pattern remains predictable.
Tool Count2/5
47 tools is a very large MCP surface, beyond what is typically comfortable for agent tool selection. Many tools are narrowly scoped variants, such as eight item-creation tools and separate member-management clusters, which could potentially be consolidated without losing clarity.
Completeness4/5
The tool set covers the full password-manager workflow well: vault lifecycle, item lifecycle with trash/restore/permanent delete, sharing and invitations, member management, TOTP, password generation, and session/settings checks. Minor gaps like uploading or updating attachments keep it from being a 5, but agents can complete common workflows without dead ends.
Average 3.2/5 across 47 of 47 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under GPL 3.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'List item members.' implies a read-only operation but does not state authentication needs, return format, pagination, or any side-effect guarantees. This is minimal, though not misleading.
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 extremely short, but brevity here is under-specification rather than successful conciseness. It is a single restatement of the name with no structure or additional detail, so it does not earn its place as helpful 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 tool requires two parameters and is part of a family of member- and sharing-related tools, the description is incomplete. It does not clarify what 'item members' means in this context, what the output contains, or how this listing relates to similar operations like list_vault_members.
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 parameters (shareId, itemId, output) are already documented in the schema. The description adds nothing about parameters, but it also does not need to for the baseline, since the structured schema already explains what each parameter means.
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 'List item members.' is a direct restatement of the tool name (list_item_members) with spaces and punctuation, adding no new semantic information. It does identify a verb and resource, but because it is a tautology it fails the bar for even a clear-but-undifferentiated purpose.
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. Sibling tools like list_vault_members, update_item_member, remove_item_member, and share_item exist, but the description gives no context on how list_item_members fits among them.
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?
The description merely restates the tool name and provides no behavioral details. With no annotations provided, the description carries the full burden, and it fails to disclose output format, default behavior, randomness guarantees, or how the parameters influence the result. It is effectively a tautology.
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 extremely short, but brevity here reflects under-specification rather than purposeful conciseness. A single sentence with no detail about behavior or parameters does not structure information effectively for an agent.
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 that the tool has 4 optional parameters, no annotations, and no output schema, the description is insufficient. It does not state what the tool returns, how the parameters combine, or how it fits into the broader toolset. The schema helps, but the description leaves critical context about invocation and results unaddressed.
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 covers 100% of the parameters with descriptions, including an enum for separator, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema already provides, and a score above 3 would require the description to enrich or clarify parameter semantics.
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 states a clear verb and resource: 'Generate a passphrase.' It does not distinguish itself from the sibling tool generate_random_password, so it lacks the differentiation needed for a 5. It is clear enough for an agent to know the basic action, just without comparing to 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?
There is no guidance about when to use this tool versus generate_random_password or any other sibling. The description provides no context, exclusions, or situational advice, leaving the agent to infer usage solely from the tool name.
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 only says 'Remove an item member' and does not disclose that this is a destructive/write operation, that confirm must be true, whether removal is reversible, or what permissions are needed. The confirm requirement appears only in the schema, not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and contains no wasted words, so it is concise. However, it is so under-specified that it adds little value beyond the tool name, bordering on a tautology rather than a genuinely informative description.
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?
This is a destructive mutation tool with no annotations and no output schema, yet the description omits critical context such as the confirm flag behavior, effects of removing a member, and any permission or safety caveats. The schema explains the parameters, but the description fails to provide the operational context an agent needs to invoke it confidently.
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 each parameter (shareId, memberShareId, confirm) already having a meaningful description. The tool description itself adds no parameter-level meaning, so the baseline of 3 applies: 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 names a specific verb ('Remove') and a clear resource ('item member'), which distinguishes it from related tools like remove_vault_member and update_item_member. It is slightly terse and essentially restates the tool name, but the meaning is unambiguous enough for an agent to select it for removing a member from an item's sharing list.
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?
There is no guidance on when to use this tool versus alternatives such as list_item_members, update_item_member, or remove_vault_member. The description provides no context about prerequisites, ownership requirements, or situations where removal would be inappropriate.
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 responsibility for behavioral disclosure, but it only restates the basic operation. It fails to mention that confirm must be true, that agentReason is validated after mutation, or what happens to the item when trashed. The operation's side effects and response behavior are left unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified for a tool with a write guard and multiple selector parameters. It is brief, yet brevity comes at the cost of omitting essential usage 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 six parameters, a required confirm flag, and no output schema, the description is not complete enough. It does not explain how to construct a valid request, whether selectors are alternatives or additive, or what the tool returns. The agent must infer critical details from parameter names and schema hints.
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 each parameter already has meaningful documentation. The description adds the concept of 'selectors', implying itemId, shareId, itemTitle, and vaultName are alternative ways to identify the item, but it does not clarify how they should be combined or which are sufficient.
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 states a specific action ('Move an item to trash') and resource ('item'), which clearly distinguishes it from reverse operations like untrash_item and from permanent deletion like delete_item. The phrase 'by selectors' hints at flexible identification but remains somewhat vague about what selectors are.
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 gives no guidance on when to use this tool versus alternatives such as delete_item, untrash_item, or move_item. It does not mention prerequisites like confirm being true or when selector-based identification should be preferred over itemId-based identification.
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 it only says the action is to accept an invite. It does not reveal potential side effects, whether the action is reversible, or that the confirm parameter must be true for the write to execute—info left entirely to the schema.
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 concise sentence with zero fluff. It is not front-loaded in a structured way, but it is appropriately short for a tool this straightforward, earning a strong score without reaching the higher bar of explicitly scoping or routing behavior.
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?
There are no annotations and no output schema, so the description must supply more context than just the action. It fails to mention the confirmation requirement, expected outcome, or relationship to list_invites/reject_invite, leaving an agent without enough behavioral context beyond the schema's parameter notes.
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 both parameters (inviteToken and confirm) already have meaningful descriptions, including that confirm must be true for the write operation. The tool description adds no additional parameter meaning, so the schema carries the full load and the baseline of 3 applies.
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 uses a specific verb ('Accept') and a clear resource ('invitation token'), which states the core function in a complete sentence. It is not a tautology and is distinguishable from the sibling reject_invite by its opposite action, though it does not explicitly name that sibling.
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 such as reject_invite or list_invites. It does not mention any prerequisites, such as needing to first obtain a token via list_invites, nor does it explain the confirm flag's role in executing the action.
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 identifies the operation as a create, but it does not mention the confirm flag required to execute the write, the agentReason requirement, whether existing data is affected, or what the operation returns.
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, front-loaded sentence with no filler. It communicates the core action, source, and target efficiently, though it omits useful behavioral context that could be included without much extra length.
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 has five parameters, a large nested template object, no output schema, and no annotations, the one-line description is materially incomplete. An agent is left without guidance on the required confirm behavior, how to choose between vaultName and shareId, or whether agentReason is needed in agent contexts.
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 the five top-level parameters, including the template payload and target vault/share. The description adds the context that the item is created 'from template payload in a vault or share', but it does not explain the relationship between vaultName and shareId or the confirm requirement beyond what the schema already states.
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 states a specific verb ('Create') and resource ('identity item') and clarifies it uses a 'template payload' with a target of 'vault or share'. This clearly distinguishes it from sibling tools like create_note_item or create_wifi_item, although it does not explicitly name any sibling it is not.
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 given on when to choose this tool over alternatives such as create_custom_item or create_login_item_from_template. The description implies it is for identity items, but it does not state when this is the appropriate choice or mention any 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 present, the description carries the full behavioral burden, but it merely restates the operation and does not disclose critical traits: that confirm must be true to execute the write, that agentReason is required for agent sessions, or how vaultName versus shareId resolves. The schema documents the confirm parameter, but the description itself contributes no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 9-word sentence with the verb front-loaded and zero filler makes for an efficient, well-structured description. It is terse but not padded; additional behavioral content could be added without sacrificing this structural quality.
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 10-parameter mutation tool with no annotations and no output schema, a one-sentence description is under-specified. Critical invocation context is missing: the confirm=true execution requirement, whether vaultName or shareId is preferred or what happens when neither is given, the agentReason requirement, and routing to the similar create_login_item_from_template sibling.
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 baseline of 3 applies even though the description adds no parameter-level detail. The phrase 'in a vault or share' loosely aligns with shareId and vaultName but does not explain their relationship or fallback behavior. The schema already documents every parameter, so no significant compensation is needed.
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 states a specific verb and resource ('Create a login item') plus a target context ('in a vault or share'), making the core purpose clear and distinguishing it from item-type siblings like create_note_item or create_credit_card_item. It falls short only in not differentiating from the closely named sibling create_login_item_from_template, which also creates login items.
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 its many alternatives. There is no mention of conditions that would favor create_login_item_from_template, generate_random_password, or the other create_*_item tools, and no exclusions, prerequisites, or context signals are given.
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 disclosing behavior. It only says 'Create a new vault,' which implies a write operation, but it omits that confirm=true is required to execute, what happens on success, and any side effects such as becoming the default vault. The schema reveals the confirm guard, but the description itself adds no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and efficiently communicates the core purpose, though it trades away useful behavioral detail.
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 write operation with no annotations and no output schema, the description is too thin. It does not mention the confirmation requirement, expected return value, or any constraints around vault creation. The schema covers parameter names but not the overall call 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 the schema already documents the 'name' parameter and the confirm guard. The description adds no parameter-level meaning, which is acceptable under the baseline for high schema 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?
States a specific verb and resource: 'Create a new vault.' It clearly identifies the operation and object, distinguishing it from sibling tools like list_vaults, update_vault, and delete_vault. However, it does not add scope context or further differentiate itself from other create-type tools.
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 given on when to use this tool versus alternatives such as update_vault or set_default_vault. The description implies usage only through the verb 'Create,' but does not provide exclusions, prerequisites, or specific conditions.
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 only states that a vault will be deleted, with no mention of whether deletion is permanent, what happens to contained items, members, shares, or whether confirmation is required. The schema mentions the confirm flag, but the description itself adds no behavioral context beyond the action itself.
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 sentence that front-loads the primary action and target. Every word earns its place, and there is no redundant or filler 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?
For a destructive tool with no annotations and no output schema, the description is too thin. It does not explain the consequences of deleting a vault, require or clarify confirmation behavior, or note any effects on shared vaults or members. An agent would not know from this description whether the operation is reversible or whether additional safeguards are expected.
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. The description adds only the relation that a vault can be identified by 'share ID or vault name', which is consistent with the schema. It does not clarify whether exactly one identifier is required, what happens if both are provided, or the role of confirm beyond what the schema already states.
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 identifies the action ('Delete a vault') and the resource, and specifies the two acceptable identifiers ('by share ID or vault name'). It is not a tautology and is distinguishable from sibling vault tools like create_vault or update_vault, though it does not explicitly name a competing alternative.
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 does not indicate when to use delete_vault versus other tools, such as trash_item or delete_item, nor does it clarify whether this is a permanent, irreversible operation compared to soft-delete alternatives. There is no guidance about prerequisites, ownership requirements, or when shareId should be preferred over vaultName.
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, and it discloses almost nothing. For a security-sensitive generation tool, there is no mention of whether the password is cryptographically random, what the default character set is, what happens if no options are specified, or whether ambiguous characters are avoided. The return format is also undisclosed and there is no output schema to compensate.
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 single sentence is maximally efficient with zero filler words and states the core purpose immediately. It loses a point only because such brevity veers toward under-specification rather than deliberate conciseness, though the schema picks up the slack for parameter documentation.
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?
The tool has four optional parameters, no output schema, and no annotations, yet the description explains none of the surrounding behavior: default output, interaction of the boolean flags, or the form of the returned password. For a security-related tool especially, an agent lacks enough information to invoke it with confidence without making assumptions.
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 baseline of 3 applies. The description itself adds no parameter-level meaning beyond the schema, but the schema already documents each parameter's purpose. Missing context like defaults and interaction between toggles (e.g., behavior when all flags are false) would be valuable but is not required at this coverage level.
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 states a clear verb and resource ('Generate a random password') with no ambiguity about the operation. However, it does not differentiate from the sibling tool 'generate_passphrase', which serves a closely related purpose, so an agent could not tell which to choose from the description alone.
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. The description does not mention the configurable options (length, numbers, symbols, uppercase), when to prefer this over generate_passphrase, or any constraints for safe use. The agent is left to infer everything from the schema.
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 behavioral burden, but it only says 'inject', implying a write without disclosing whether the input is overwritten, whether confirmation is required, or whether force can replace an existing output. It also omits that confirm must be true for the write to execute and that fileMode and force affect file-system 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?
A single sentence with no filler, front-loaded with the action and target. It earns its place without repeating parameter names or schema details.
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 six-parameter file-writing operation with no annotations and no output schema, the description omits essential context: output-file behavior, confirmation semantics, overwrite safety, and template reference format. The schema covers parameter mechanics but not the operational context an agent needs to invoke the tool safely.
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 baseline is 3; the description adds only the high-level notion that inFile is a template and that secrets come from Proton Pass references. It does not explain the reference syntax or the relationship between inFile and outFile beyond what the schema already states.
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 names a specific action ('inject'), a data source ('Proton Pass references'), and a target ('a template file'), making the core purpose clear and broadly distinguishing it from item-management and vault tools. It does not clarify whether the template is modified in place or written to a separate outFile, so it falls just short of full clarity.
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?
There is no guidance about when to choose this tool over siblings such as run or create_login_item_from_template, and no mention of prerequisites or exclusions. The intended use is only implied by the one-line description, so an agent must rely on inference.
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 does not mention that confirm must be true, that the item is removed from the source vault, that permissions may be required, or any side effects. 'Move' only weakly suggests a write 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 short sentence with no filler, and the core action is front-loaded. It is concise, though it sacrifices important behavioral and usage detail.
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?
With eight parameters, no required fields, no annotations, and no output schema, this sparse description is insufficient for correct invocation. It leaves the agent to infer how to identify the item, how to specify source and destination via vault names versus share IDs, and what confirm and agentReason are for.
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 baseline is 3 and the individual parameter descriptions already convey basic meaning. However, the tool description adds no guidance about parameter relationships, such as whether itemId and itemTitle are alternatives, or how fromVaultName/fromShareId should be combined.
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 states a specific action ('Move') on a resource ('an item') with a destination context ('from one vault to another'). This distinguishes it from item-level operations like update_item, trash_item, and delete_item, and from vault-level transfer_vault, though it does not explicitly contrast with those siblings.
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 transfer_vault or share_item. There is no mention of prerequisites, conditions, or exclusion criteria; the only usage context is implied by the name and the word 'move.'
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?
Annotations are absent, so the description carries the full burden. It does not mention that this is a destructive write, that the confirm parameter must be true, or any consequences; the confirmation requirement appears only in the schema, not the description.
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 single sentence is very brief and front-loaded with no filler. However, it is so terse that it leaves important operational context to the schema, so it is not a model of helpful concision.
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 destructive mutation with no annotations and no output schema, the description should at least mention the confirmation requirement and how the vault/member are identified. It does neither, leaving the agent to infer operational details from the schema and sibling names.
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 coverage is 100%, so the baseline is 3. The description itself adds no parameter-level detail beyond the schema, though the schema already documents memberShareId, shareId, vaultName, and confirm adequately.
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 uses a specific verb and resource ('Remove a member from a vault') that clearly names the operation. It is distinguishable from the sibling update_vault_member by the remove/update contrast, though it does not explicitly differentiate itself.
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 given on when to use this tool versus alternatives, such as update_vault_member for membership changes or list_vault_members for finding memberShareId. The context is only implied by the verb 'remove'.
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 only says a command is run with secrets resolved, but it does not disclose that this may execute arbitrary, potentially destructive code, nor that confirmation may be required or that masking is enabled by default.
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, front-loaded sentence with no wasted words. It loses a point only because it is terse to the point of omitting important safety and usage 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?
This is a potentially dangerous arbitrary-command tool with no annotations and no output schema. The description does not mention confirmation semantics, masking behavior, env-file handling, or agent-session requirements, so an agent cannot fully assess the implications of invoking it.
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 parameters are already documented with meaningful detail. The description adds little beyond the overall concept of secret resolution in the environment, so the baseline of 3 is appropriate.
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 and resource: it runs a command and resolves Proton Pass secret references in the environment. However, it does not distinguish this tool from its sibling 'inject', which may perform a similar secret-injection role.
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?
There is no guidance about when to use 'run' instead of sibling tools such as 'inject' or other read-only utilities. The description also does not mention the confirm requirement or that this is intended for agent-driven commands rather than for general interactive use.
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, but it only states the basic action. It does not disclose what the score represents, whether the password is transmitted or processed locally, or what side effects, if any, exist.
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 sentence with no filler and is immediately understandable. It errs on the side of too little structure rather than excess, which keeps it from being a model of front-loaded organization.
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?
The tool has no output schema, and the description does not explain the return value or the difference between 'json' and 'human' output beyond the schema's enum. An agent knows it should pass a password, but not how to interpret the result or handle edge cases.
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%: both 'password' and 'output' are documented with descriptions, and the output parameter includes an enum and default. The tool description adds no parameter meaning beyond the schema, so the baseline of 3 applies.
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 states a specific verb ('score') and resource ('password strength'), making the tool's function clear. It is not a pure tautology because 'strength' adds meaning beyond the tool name, though it does not elaborate on the scoring scale or criteria.
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?
There is no guidance on when to use this tool or when to prefer an alternative. While the sibling list contains password generation tools, the description does not explain that this tool is for analysis rather than creation, leaving usage context to inference.
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 only says 'Set', which implies mutation, but it does not mention that confirmation is required, that an existing default may be overwritten, or any other side effects.
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, front-loaded sentence with no filler or redundant phrasing. It efficiently communicates the core action and the two accepted inputs.
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 mutating tool with no annotations and no output schema, the description is incomplete. It does not explain the `confirm` requirement, which parameter to prefer, what happens to the existing default, or how this relates to `unset_default_vault`.
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%, and the schema already explains `confirm`, `shareId`, and `vaultName`. The description adds little beyond restating the two addressing modes, so the baseline score of 3 is appropriate.
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 identifies the operation ('Set default vault') and the addressing methods ('by share ID or vault name'). It is unambiguous and distinguishable from the sibling `unset_default_vault`, though it does not explicitly call out that distinction.
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 given about when to use this tool versus alternatives such as `unset_default_vault` or `view_settings`. It also does not state prerequisites, exclusions, or whether `shareId` and `vaultName` are mutually exclusive alternatives.
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, but it only states the action without mentioning the write operation gate, the need for confirm=true, or side effects like invite delivery. This is a significant transparency gap for a mutating 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, concise sentence with no filler. However, it is so terse that it omits the important confirmation behavior, so it sacrifices completeness for brevity.
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?
The description is not complete enough for a write tool with a confirmation gate and no annotations. It fails to mention that confirm must be true to execute, what happens after sharing, or how this relates to invites and shares. The schema fills some gaps, but the behavioral context remains missing.
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%, and each parameter already has a meaningful description, including the confirm requirement and role enum. The tool description adds no parameter-level meaning, but the schema sufficiently documents the 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 states a clear verb and resource: 'Share an item with a user.' It is specific enough to distinguish this from share_vault, but it does not explicitly differentiate from related sharing tools or mention the required confirmation flag.
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 such as share_vault, list_shares, accept_invite, or update_item_member. The description gives no context about prerequisites, typical scenarios, 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, the description carries the full burden of behavioral disclosure, but it merely states the action without explaining side effects, whether an invitation is sent, how existing members are affected, or that the write operation requires confirmation. The 'confirm' parameter exists in the schema but is not echoed in the description.
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, front-loaded sentence with no filler. It is appropriately concise for a simple tool, though it may be too terse to fully serve the agent's selection and invocation needs.
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?
This is a mutation tool with no annotations and no output schema, yet the description does not explain how parameters relate (e.g., whether shareId and vaultName are alternatives), why confirm is required, or what happens as a result of sharing. An agent would have to rely entirely on the schema to understand the operation, which is insufficient for correct invocation.
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 each parameter. The description adds no additional semantic meaning beyond the schema, which is appropriate given the baseline of 3 for high schema 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 'Share a vault with a user' clearly identifies a specific verb, resource, and recipient. It is distinct enough from siblings like transfer_vault and share_item, but it does not explicitly differentiate from them by name or mention that it creates an invitation or grants access.
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 such as transfer_vault, accept_invite, or share_item. The description only states what the tool does, leaving the agent to infer the context from the tool name.
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 for disclosing behavioral traits. It only says 'Unset default vault setting' and does not mention side effects, reversibility, permissions, or whether the action is idempotent. The confirm parameter hints at a write operation, but that information lives in the schema, not the description.
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 short sentence with no filler, and the action is front-loaded. It is structurally clean, though slightly too terse to fully earn a top score.
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?
For a simple one-parameter write operation, the description is minimally viable. However, it omits useful context such as that this only clears the default-vault preference and does not delete the vault, and it does not connect to the paired set_default_vault tool.
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%, and the confirm parameter is already described as 'Must be true to execute the write operation.' The tool description adds no additional parameter meaning, so the baseline of 3 applies.
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 uses a specific verb ('Unset') and a clear resource ('default vault setting'), so an agent can understand the core action. It is implicitly differentiated from the sibling set_default_vault by the opposite direction of the operation, though it does not explicitly state that distinction.
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 gives no guidance on when to use this tool versus set_default_vault or view_settings. The intended usage context must be inferred from the tool name and sibling list, which is not sufficient for reliable 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, the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but the description does not mention the confirm gate, the required agentReason, potential destructive consequences, or whether changes are reversible.
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, front-loaded sentence with no filler. It is concise, but the phrasing 'selectors and field assignments' is compact enough to border on jargon, slightly reducing clarity without wasting space.
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?
The tool has 7 parameters including a mutation-confirmation flag and a required agentReason, but the description does not explain how selectors work, when confirmation is needed, or what happens after the update. The schema covers parameter semantics, but the overall behavioral context is incomplete for safe invocation.
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 baseline is 3. The description adds the concept of 'selectors' which loosely maps to itemId, shareId, itemTitle, and vaultName, but does not meaningfully clarify the field assignment format beyond what the schema already provides.
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 names a specific action ('Update') and resource ('an item'), and adds the mechanism of 'selectors and field assignments.' This is enough to distinguish it from creation, deletion, and viewing siblings, though the term 'selectors' is somewhat vague without elaboration.
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 given about when to use this tool versus alternatives like move_item, trash_item, or update_vault. The operation is implied by the name but not contextualized, and no exclusions or alternative references are provided.
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 behavioral disclosure burden. It discloses that an update occurs but does not mention that confirm must be true to execute, that agentReason is required, or that the operation is a write with potentially irreversible effects. The 'agentReason' schema note also hints at unusual post-mutation validation, which is not surfaced in the description.
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, concise sentence with no filler. It front-loads the action and resource, then immediately states the identification modes, making it easy to scan.
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?
The tool involves five parameters, required confirm-like semantics, multiple identifier options, and no output schema or annotations. The description does not convey the write-confirmation requirement, the required agentReason, or any safety concerns, leaving an agent under-informed for correct invocation.
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 baseline is 3. The description adds meaning by explaining that shareId or vaultName are the identification alternatives, which helps disambiguate identifier parameters. However, it does not explain the roles of confirm or agentReason, though those are documented in the schema.
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 states a clear verb ('Update') and resource ('a vault'), and further specifies two identification methods: share ID or vault name. It does not explicitly contrast with sibling vault tools, but the name and scope make its purpose reasonably distinct.
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 such as create_vault, share_vault, transfer_vault, delete_vault, or unset_default_vault. The description only implies use for updating a vault, leaving context and exclusions unstated.
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 exist, so the description carries full responsibility for revealing behavioral traits. It only says 'Update a vault member role' – it does not disclose that the operation is a write, requires confirm=true, or what happens when confirm is false. It also does not mention any side effects or validation behavior, so an agent has little warning about the mutating nature beyond the word 'Update'.
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 concise sentence with no wasted words, and the verb is front-loaded. It could include more context, but as far as wording economy goes it is 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?
With 5 parameters (including a confirm flag that must be true), no output schema, and no annotations, the tool needs situational context. The description offers none: it does not explain how to identify the vault (shareId vs vaultName), that confirm is required for a write, or when to use this versus related member tools. An agent can call it technically from schema but cannot decide confidently when it is appropriate.
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 including the confirm flag and the role enum. The description adds no parameter-level detail, so it earns the baseline 3 for relying on the schema.
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 states a specific verb ('Update'), resource ('vault member'), and the attribute being changed ('role'), which distinguishes it from siblings like update_vault, remove_ault_member, and update_item_member. However, it does not explicitly name alternatives or scope conditions, so it is clear but not as rich as a 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?
No usage guidance is provided. The description never says when to use this tool vs update_item_member, remove_vault_member, or share_vault. There are no exclusions, no prerequisites, and no mention of the confirm flag, so agents get no direction for choosing among related member/vault 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?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It indicates a write operation but does not mention the required confirm flag, permission needs, side effects, or any additional execution requirements. This is a meaningful gap for a mutation tool.
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 sentence with no filler or redundancy. It front-loads the primary action and object. However, it is concise to the point of omitting important behavioral context, so it earns a 4 rather than a 5.
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?
The tool has a complex nested template schema, five parameters, and no output schema or annotations. A one-sentence description is not enough to guide correct invocation. It does not explain the confirm requirement, the distinction between vaultName and shareId, or the agentReason field, leaving too much for the agent to infer.
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 parameters in detail. The description adds only the idea of 'template payload' and 'vault or share,' which loosely maps to template, vaultName, and shareId. It does not add meaningful semantics beyond the schema.
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 a specific verb and resource: 'Create a custom item from template payload in a vault or share.' It identifies the action and the main target. It distinguishes from specialized create tools somewhat by emphasizing 'custom item' and 'template payload,' though it does not explicitly differentiate from create_login_item_from_template.
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?
Usage is implied: use this when creating a custom item from a template payload. However, there is no explicit when-to-use or when-not-to-use guidance versus sibling tools such as create_login_item_from_template or create_note_item. No alternatives 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Create an email alias item.' This implies a write operation yet does not mention that the write requires confirm=true, where the item will be created (shareId/vaultName), or any side effects. The schema supplies some detail, but the tool description itself is nearly empty of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, and the core purpose is front-loaded. However, it is arguably under-specified for a tool with five parameters and no annotations, so it earns a high but not perfect score.
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, no output schema, and several parameters that control destination and confirmation, the description is too sparse. While the schema provides parameter-level details, the overall tool description fails to explain required confirmation behavior, destination semantics, or expected outcomes, leaving significant gaps for an agent deciding to call it.
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 input schema already documents all five parameters and their meanings. The tool description adds no additional parameter semantics beyond the schema, which is exactly the baseline scenario for a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create') and a specific resource ('email alias item'), which clearly identifies what the tool does. This distinguishes it from sibling create_*_item tools (login, note, credit card, wifi, custom, identity) by item type. The purpose is immediately understandable.
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 does not mention conditions, prerequisites, or why an agent should choose this over create_custom_item or other create_*_item tools. Usage is only implied by the name and item type, not explicitly stated.
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 must carry the full burden of behavioral disclosure. It only says 'Create' and does not mention the critical confirm flag required to execute the write, the agentReason requirement for agent sessions, or any side effects. These are critical behavioral traits missing from the description, though they appear in the schema parameter descriptions.
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, front-loaded sentence with no filler: 'Create a note item in a vault or share.' Every word contributes meaning, including the location qualifier. It is concise without being underspecified at the syntactic level.
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?
The schema covers all parameter semantics, including confirm and agentReason descriptions, so the structured data fills some gaps. However, the description alone lacks behavioral context (e.g., confirmation required, agent reason required) and there is no output schema to explain return values. This makes the definition adequate but not fully complete for a mutation tool with no annotations.
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%, meaning every parameter is already documented in the input schema. The description itself adds no parameter-level detail, but baseline 3 applies because the schema is doing the heavy lifting. The description's mention of 'vault or share' loosely maps to the vaultName/shareId parameters without adding new semantics.
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 states a specific verb and resource: 'Create a note item in a vault or share.' This clearly identifies the operation and its target location, distinguishing it from other item creation tools like create_login_item or create_credit_card_item. However, it does not explicitly name any sibling alternative, which would make the differentiation stronger.
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 gives no guidance on when to use this tool versus the many other create_*_item tools or when to prefer an alternative. It only implies the basic purpose—creating a note item—but does not state prerequisites, exclusions, or conditions like needing a vault/share context or confirmation.
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 burden of disclosing side effects, but it only says 'Create.' It does not mention the confirm flag needed to execute the write, agent-session requirements, or any destructive/irreversible behavior. That key behavior is left to the input schema rather than the tool description.
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?
A single sentence with no filler; the core action and destination are front-loaded. This is appropriately concise for a simple create operation.
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?
Although the schema is richly documented, the description omits important invocation context: selecting between vaultName and shareId, the confirmation requirement, and the agentReason obligation. For a write tool affecting sensitive credit card data, this is too incomplete.
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 baseline is 3. The phrase 'in a vault or share' minimally maps to vaultName/shareId, but the description adds no meaning beyond what the schema already states for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Create'), a specific resource type ('credit card item'), and a target ('vault or share'). The resource type immediately distinguishes it from sibling item-creation tools such as create_login_item or create_note_item.
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 gives no guidance on when to prefer this tool over alternatives, no exclusions, and no conditions such as whether a vaultName or shareId is required or how a default vault applies. It only restates the obvious context of creating such an item.
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 alone must disclose behavioral traits, but it only says 'create' and says nothing about the confirm guard, write side effects, shareId/vaultName behavior, or agentReason requirements. The schema mentions confirm, but the description itself adds no behavioral context beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no repetition of schema details and no filler. It communicates the essential purpose immediately and earns its place.
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?
Despite strong per-parameter schema coverage, the tool has no annotations and no output schema, and the description does not mention the confirm-to-execute guard, the required agentReason context, or how this differs from the direct create_login_item path. An agent could infer most details from the schema, but the description alone leaves important invocation and usage context unstated.
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%, and the schema already explains template, confirm, shareId, vaultName, and agentReason. The description adds only the notion that the operation consumes template JSON, which is already reflected in the template parameter's schema description, so there is meaningful but limited added 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 states a specific verb ('Create'), a resource ('login item'), and the source format ('template JSON'), making its core function clear. It does not explicitly name the sibling alternative create_login_item, so it does not fully distinguish itself, but the 'from template' phrasing provides a meaningful contrast.
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 phrase 'from template JSON' implicitly suggests this tool should be used when a template payload is available, likely versus the direct-field create_login_item sibling. However, it does not explicitly state when to prefer it, when not to use it, or name the alternative.
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 only names the action and gives no indication of irreversibility, required permissions, side effects, or the need for confirmation, aside from what is buried in the parameter schema.
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 front-loaded sentence with no unnecessary words. It is appropriately concise for a simple tool, though it misses the opportunity to state the confirmation requirement in prose.
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?
For a simple two-parameter tool with fully documented schemas, the description plus schema is mostly sufficient for invocation. However, with no output schema and no annotations, the agent gets little sense of what a successful rejection returns or whether the action is reversible.
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%, and the parameter descriptions are meaningful: inviteToken is tied to list_invites, and confirm must be true for the write operation. The tool description itself adds no parameter details, so the baseline of 3 applies.
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 states a specific action ('Reject') on a specific resource ('an invitation token'), making the tool's intent clear. It also naturally contrasts with the sibling accept_invite, though it does not explicitly describe what rejecting the invitation accomplishes.
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?
No explicit when-to-use or when-not-to-use guidance is provided, and alternatives are not named. However, the tool name and sibling set make the intended context reasonably clear: use this to decline an invitation rather than accept it.
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 it only states 'update' without revealing the write-confirmation requirement, permission needs, or side effects. The confirm parameter in the schema hints at the write nature, but the description itself adds no behavioral context beyond the verb.
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 one-sentence description is tightly worded with no filler, front-loading the core action. It earns high marks for conciseness, even though brevity sacrifices behavioral details.
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 with a mandatory confirmation flag and several related sibling tools, a bare one-liner is not complete: it omits the confirm requirement, the relationship between shareId and memberShareId, and when to choose this over update_vault_member. The schema compensates for parameters, but the description lacks enough context for reliable tool selection.
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 every parameter already has a description in the schema. The description itself adds no parameter-level meaning beyond the schema, such as the confirm flag semantics or the role enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an item member role' uses a specific verb (update), a precise resource (item member), and target attribute (role), clearly distinguishing it from siblings like update_vault_member and remove_item_member. No ambiguity remains about the tool's core function.
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 such as update_vault_member or share_item. It also fails to mention that confirm must be true for the write operation to execute, which is critical 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It signals an ownership mutation but omits important behavior such as the confirm flag being required to execute, the irreversibility of the transfer, and the effect on the current owner's access.
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 concise, front-loaded sentence with no filler. It is efficient for stating the core purpose, although it is so terse that behavioral and usage details are left to the schema and sibling 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?
For a mutating tool with no annotations and no output schema, the description is incomplete. It does not clarify how the vault is identified, that confirm must be true, or what consequences the transfer has for the current owner and the recipient.
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 baseline is 3; each parameter is already documented in the schema. The description adds no parameter-level meaning beyond conceptually mapping 'vault' to shareId/vaultName and 'member' to memberShareId, and it does not clarify how shareId and vaultName relate or which one is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('transfer'), a specific resource ('vault ownership'), and the recipient ('a member'). This clearly distinguishes it from sibling tools like share_vault or update_vault_member, which involve granting access or modifying membership rather than changing ownership.
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 intended use case is implied: use this when vault ownership should be passed to a member. However, it does not explicitly explain when to choose this over share_vault or update_vault_member, nor does it mention prerequisites such as the target member already having a share in the vault.
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 exist, so the descrption must carry the behavioral burden. 'Generate' implies a non-mutating operation, but the descrption does not state whether access to the item's TOTP secret is required, what happens if the item has no TOTP field, or what kind of result is returned. Those are meaningful unknowns for a tool with no output schema.
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?
One concise, front-loaded sentence with no filler. It communicates the operation, resource, addressing mechanism, and optional field targeting efficiently.
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?
With eight params, zero required fields, multiple addressing strategies, and no output schema, this is a non-trivial tool call. The description gives only the high-level purpose and leaves unclear the URI-versus-selector relationship, ambiguity behavior, and output shape, so an agent lacks sufficient context for confident invocation.
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 descrption coverage is 100%, so the parameters are already well documented. The description adds the useful grouping of several lookup params as 'selectors' and 'targeting a specific field,' but it does not explain how the selector params relate or which combinations are valid, so the semantic value added over the schema is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific operation and resource: 'Generate TOTP code(s) for an item...' and the phrase 'by URI or selectors' evokes the item-addressing mechanisms. This clearly distinguishes it from sibling generate_totp, which sounds generic rather than item-based.
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 implies use this when you need a TOTP code for an existing item, and it names URI or selector-based addressing. However, it never explicitly contrasts with generate_totp, nor says when not to use this tool, so the when/when-not guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does disclose pagination support and JSON output, which is useful. However, it does not explicitly state that the operation is read-only, describe the response shape or cursor mechanics, or clarify default filtering behavior for trashed items.
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 action-first sentence with no filler. It is appropriately concise, though it could have used a second sentence to route the agent toward search_items or view_item for other item operations.
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?
With eight parameters, no output schema, and no annotations, a bit more high-level context would help. The schema documents the parameters well, but the description does not mention the exactly-one-of shareId/vaultName requirement, what happens with no scope, or the shape of the returned paginated response. It is adequate but has clear 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 baseline is 3. All eight parameters have descriptions covering defaults, allowed enums, formats, and the shareId/vaultName mutual exclusion. The tool description itself adds no parameter meaning beyond what the schema already provides.
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?
States a specific verb ('List'), resource ('items'), and scope ('a vault or share'), with a mention of pagination and JSON output. It does not explicitly contrast with sibling search_items or view_item, so it is clear but not sharply differentiated.
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?
Only general context is given: list items for a vault or share. There is no explicit guidance about when to choose list_items over search_items or view_item, nor are any exclusions stated. The intended usage has to be inferred from the tool name and basic description.
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. 'Restore' implies a write operation, but the description does not mention that confirm=true is required, that permissions may be needed, or what side effects the restoration has. This is a meaningful gap for a mutation 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 one short sentence with no filler and the core action is front-loaded. Every word contributes to the stated 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 6-parameter tool with no annotations and no output schema, the description is underspecified. It does not explain the selector concept, the confirm requirement, or the necessary conditions for a successful restore, leaving the agent to infer important operational details.
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 baseline is 3. The description's 'selectors' phrasing hints at the multiple identification parameters (itemId, shareId, itemTitle, vaultName), but it does not clarify how they combine or whether at least one is required beyond agentReason. The schema handles most parameter meaning on its own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Restore an item from trash by selectors.' This clearly distinguishes the tool from siblings like trash_item and delete_item. The action is unambiguous despite the slightly vague 'by selectors' qualifier.
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 phrase 'from trash' implies the tool should be used on items that are currently trashed, which gives some usage context. However, it does not explicitly state when not to use it, nor does it mention alternatives such as view_item or search_items for locating the trashed item first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does communicate a read-only listing operation and authenticated-user scoping, which is useful. However, it does not explicitly state non-mutation, pagination, or output behavior, leaving meaningful transparency 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?
One sentence, no filler, and the core verb and resource are front-loaded. Every word carries meaning.
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 simple listing nature, no required parameters, and full schema coverage, the description is mostly sufficient. Yet it offers no usage guidance, no clarification of what constitutes a 'share,' and no indication of how output behaves, so an agent may still be uncertain when selecting among listing siblings.
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 already fully documents all three parameters, including the output enum/default and the onlyItems/onlyVaults booleans. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('shares'), and further scopes it to shares accessible to the current authenticated user. This clearly distinguishes it from sibling tools like list_vaults, list_items, and share_item.
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?
There is no guidance about when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The only context is the user scope; no sibling alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'View' implies a read-only operation, and 'optionally returning a specific field' describes output behavior. However, it does not address edge cases like selector precedence, behavior when no matching item exists, or any permission requirements, leaving some behavioral ambiguity.
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 sentence that front-loads the core purpose and omits all unnecessary detail. Every phrase earns its place, making it easy to scan and understand instantly.
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?
The tool has 8 optional parameters and no output schema, and the description leaves unclear how selectors should be combined to target an item. It also does not describe what the response looks like beyond a possibly specific field. The schema compensates for parameter details, but the selector interaction and return behavior remain under-specified.
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 baseline is 3. The description adds a useful conceptual grouping ('URI or selectors') and explains the 'field' parameter's purpose, but it does not add semantics about how multiple selectors combine or which ones are sufficient. It does not go beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('View'), a clear resource ('item'), and the singular scope ('a specific item') that distinguishes it from sibling tools like list_items or search_items. Naming 'by URI or selectors' further clarifies the access mechanism. It is immediately clear what this tool does.
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 gives no guidance on when to use this tool versus alternatives such as list_items or search_items, and does not mention prerequisites or exclusion cases. An agent is not told how to identify an item before calling, or which selector combinations are valid. This is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly indicates a read-only 'View' operation and identifies the underlying command source, but it does not disclose output format, authentication requirements, or any potential side effects. It is adequate but not rich.
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?
A single, tightly worded sentence that front-loads the action and resource. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only info tool, the description is largely complete: it states the purpose, the source, and the nature of the output ('summary'). It could add more detail about return fields, but the low complexity means nothing essential is missing for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds helpful context about what the tool returns and where it comes from, which is sufficient given there is nothing to document in the schema.
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 names a specific verb ('View'), a specific resource ('current Proton Pass session/account summary'), and a source ('pass-cli info'). It is clear and unambiguous, though it does not explicitly differentiate itself from siblings like view_user_info or check_status.
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 given about when to use this tool versus alternatives such as check_status or view_user_info. There are no exclusions, prerequisites, or conditions stated, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the burden, and 'View' does convey a read-only behavior with no mutation semantics. It adds no detail about output format, whether settings are local/global, or any side effects, but the verb itself is a meaningful behavioral signal for a settings inspection 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 a single, front-loaded sentence with no filler words. Every word earns its place, and the structure is optimal for an agent scanning sibling definitions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the essentials: what it acts on and what action it performs. It omits the return format and any environmental context, but these are less critical for a simple settings view with no required arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so there is no parameter documentation gap. The baseline of 4 applies because no parameter descriptions are needed; the description adds no parameter info but none is required.
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 states a clear verb ('View') and a specific resource ('current Proton Pass CLI settings'), which distinguishes it from sibling tools like view_session_info and view_user_info by the resource being settings. However, it does not explicitly contrast itself with those siblings, relying on the distinct noun rather than naming them.
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 any alternative. The description only restates the tool's purpose, leaving the agent to infer usage from the name and resource. There are no exclusions, prerequisites, or context signals.
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?
There are no annotations, so the description bears the full burden of disclosing behavioral traits. It only says 'Create', omitting the confirm=true write gate, the agentReason requirement, and any side effects or return behavior. This is thin for a mutation tool with no safety annotations.
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?
One concise, front-loaded sentence with no filler. Every word contributes to identifying the operation's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the one-line description, the schema is rich and fully documents parameters, required fields, allowed enums, and the confirmation flag. Combined with the clear purpose statement, this is nearly complete for invoking the tool correctly, though there is no explicit mention of return values in the absence of an output schema.
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 nine parameters and their constraints. The description only adds the high-level 'vault or share' destination notion, which is marginal beyond the existing vaultName and shareId descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Create a WiFi item') and adds scope ('in a vault or share'), making the tool's role immediately clear. This distinguishes it from sibling item-creation tools such as create_login_item and create_note_item.
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 gives useful context — WiFi items are created in a vault or share — but it offers no explicit when-to-use or when-not-to-use guidance relative to the many sibling create_*_item tools. The intended usage is implied by the WiFi resource rather than stated.
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 behavioral burden. It accurately says the tool generates a token, but it does not disclose time-dependence, invalid-input behavior, or the fact that this is a stateless computation with no vault side effects.
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 the action and source front-loaded. Every word contributes; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter stateless tool with full schema coverage, the description covers the core action and input. The output format is partially handled by the schema's enum. It could be improved by explicitly routing to generate_item_totp for vault-based TOTP generation, but the missing context is minor.
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, including the secretOrUri format and output enum/default. The description essentially restates the schema's parameter descriptions without adding extra meaning such as validation rules or edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('generate'), a concrete artifact ('TOTP token'), and the accepted sources ('secret or otpauth URI'). This source phrase distinguishes it from the sibling generate_item_totp, which operates on a stored vault item.
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 implies when to use it: when you have a raw secret or otpauth URI rather than a vault item. However, it does not explicitly name the alternative (generate_item_totp) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses MCP pagination support and JSON output, which is useful context beyond the schema. However, it does not explicitly state that the operation is read-only or describe any side effects, though 'search' reasonably implies a non-mutating query.
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, front-loaded sentence that communicates the core purpose and pagination behavior without waste. The phrase 'for JSON output' is slightly redundant in an MCP context, but overall the description is appropriately concise.
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?
For an 11-parameter tool with no output schema and no annotations, the description is minimal but not inadequate. The schema covers parameter semantics richly, and the description provides pagination context, yet it omits guidance about the default vault behavior and return shape beyond pagination hints.
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%, and every parameter, including default values and enums, is documented in the input schema. The description adds no new parameter-level meaning beyond noting title-based search and pagination, so the schema-driven baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Search items by title'. This distinguishes the tool from siblings like list_items and view_item by making the title-search scope explicit.
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 implies usage for title-based searching and paginated access, but it does not explicitly state when to use this tool instead of list_items or other search-like alternatives. There is no when-not-to-use guidance or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'View' signals a read-only operation, and 'from pass-cli user info' adds source context. However, it does not disclose authentication requirements, potential side effects, or error/return behavior; for a simple read-only tool this is adequate but not comprehensive.
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, front-loaded sentence that states the action, target, and source with no filler or redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional enum parameter and no required inputs, the description plus schema cover most calling needs. It lacks explicit usage guidance and return-structure detail, but the simplicity of the operation makes the definition largely complete.
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%, and the single 'output' parameter is already fully documented with enum values, a default, and a description. The tool description adds no additional parameter-level meaning beyond what the schema provides.
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 uses a specific verb, 'View', and identifies the resource as 'Proton user profile/account details'. The source 'from pass-cli user info' helps distinguish it from siblings like view_settings and view_session_info, though it does not explicitly name them.
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 intended usage is implied by the subject matter: use this tool to view Proton user profile/account details. However, there is no explicit guidance about when to choose this over view_settings or view_session_info, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses scope ('pending', 'accessible to the current authenticated user') and implies read-only behavior, but does not mention pagination behavior, response shape, or that it does not mutate state. These are useful but not critical for a simple list 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?
A single, front-loaded sentence with no filler. Every word contributes to the meaning, and the most important scoping information ('pending', 'accessible to current user') appears immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list operation with fully documented pagination parameters, the description is adequate. It would benefit from mentioning that the response is a paginated list with a nextCursor, since no output schema exists, but the schema's cursor and pageSize descriptions largely compensate.
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 cursor and pageSize with defaults and constraints. The description adds no parameter-specific meaning beyond what the schema provides, which yields the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('pending invitations'), and a clear scope ('accessible to the current authenticated user'). This distinguishes it from sibling tools like accept_invite/reject_invite (which act on invites) and list_shares (which list shares, not invites).
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 implies usage: it is for viewing pending invites available to the authenticated user, which naturally precedes accept/reject actions. However, it does not explicitly name alternatives or state when not to use it, leaving the agent to infer the workflow from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does disclose an important behavioral trait—only vaults 'accessible to the current authenticated user' are returned—and 'List' implies a read-only operation. It does not mention result shape, pagination, or whether shared/archived vaults are included, but for a simple list tool the inherent semantics cover much of the burden.
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. The key verb and resource appear immediately, and the scoping phrase 'accessible to the current authenticated user' is relevant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list operation with no output schema, the description is nearly complete. The input schema covers the only parameter, and the verb 'List' implies an array of vaults is returned. It could add detail about what vault metadata is included, but nothing essential is missing for correct invocation.
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%; the only parameter, output, has an enum ('json'/'human') and its own description ('Output format'). The tool description itself adds no extra parameter detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource—'List vaults'—and scopes them to 'the current authenticated user.' This clearly separates it from sibling tools like create_vault, delete_vault, or list_items, and the meaning is unambiguous without needing to inspect the schema.
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 implies the obvious use case: enumerate vaults the current user can access. However, it offers no explicit guidance about when to prefer this tool over alternatives such as list_items, list_shares, or list_invites, and it gives no exclusions. This is adequate but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It conveys that the tool performs checks rather than modifying state, but it does not explicitly state that it is read-only, whether it requires authentication, or what happens if checks fail. This is adequate but not rich.
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?
A single clear sentence that front-loads the action and lists the key checks. There is no redundant wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description is mostly complete: it names the three areas checked. The main gap is that with no output schema, the description does not mention what the tool returns or whether it uses exit codes, but the tool's simplicity makes this a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully describes the input surface. The description does not need to explain parameters, and the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Run preflight checks' and the resources involved: connectivity, authentication, and CLI version compatibility. This distinguishes it from sibling tools like view_session_info or view_user_info, which focus on viewing session/user details rather than environment readiness.
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 word 'preflight' implies this should be used before running operations that depend on connectivity, authentication, or CLI compatibility, but there is no explicit guidance on when to use it versus alternatives. The usage context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List' clearly indicates a read-only operation on members, which is the core behavioral trait. However, it does not disclose any assumptions about identifier requirements, pagination behavior, or response shape beyond what the schema already provides.
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?
A single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and selector options.
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?
The definition is adequate for a simple list operation, but it leaves ambiguity around required inputs: no parameters are marked required, yet the description implies at least one of shareId or vaultName should be provided. It also does not clarify behavior if both are supplied or neither is supplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented individually. The description adds meaningful relational semantics by stating that shareId and vaultName are alternative ways to identify the vault ('or'), which is not encoded in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb and resource: 'List members for a vault', with the identification mechanism ('by share ID or vault name'). This is distinct from sibling tools like list_vaults, list_shares, and update_vault_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of use is clear: call this when you need the member list for a vault, identified by either share ID or vault name. It does not explicitly name alternatives or exclusions, but the intended usage is apparent and no misleading alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states that deletion is permanent and bypasses trash, which conveys irreversibility and destructive intent. It does not detail side effects like cascading deletion or permission requirements, but the central behavioral risk is clearly disclosed.
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?
A single, tightly worded sentence that front-loads the most important facts: permanent deletion, the identifying fields, and the bypassing-trash behavior. Every word earns its place, with no repetition of schema details or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description covers the essential context: what is deleted, the required identifiers, and the irreversible nature of the operation. The confirm parameter is already documented in the schema, so its absence from the description is not a gap. Minor details like side effects on attachments are not covered, but the core invocation context is complete enough.
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%: all four parameters have descriptions in the schema. The tool description merely echoes 'share ID' and 'item ID' without adding new semantic detail, so it does not go beyond the structured information. Baseline 3 is appropriate given the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('delete'), a concrete resource ('item'), and the mechanism ('by share ID and item ID'). The phrase 'bypassing trash' clearly distinguishes this from sibling tools like trash_item and untrash_item. An agent can tell exactly what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: this is the permanent, irreversible deletion path rather than a soft delete to trash. It does not explicitly name alternatives or exclusion conditions, but 'permanently' and 'bypassing trash' give enough contextual signal to route the agent toward or away from this tool alongside sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 reveals the destructive potential ('potentially overwriting it') and the confirmation requirement, which are critical behavioral traits absent from the schema alone.
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?
Two short sentences with no filler. The primary action is stated first, followed by the critical caveats (overwrite, permission, confirmation). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description covers purpose, side effects, and prerequisites. It does not describe the return value, but for a download-to-path operation that is not essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by clarifying that outputPath may be overwritten and that confirm must be true for the write operation to execute. This enriches two parameter semantics without duplicating schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download an item attachment'), the destination ('to a local path'), and the potential side-effect ('overwriting it'). This makes the tool's purpose distinct from sibling tools like view_item or move_item, which operate differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No direct alternatives are named, but the description gives important usage context: it requires write permission and confirmation. This tells an agent when it is appropriate to use the tool and the precondition that must be satisfied before invoking it.
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:

[![proton-pass-community-mcp MCP server](https://glama.ai/mcp/servers/hesreallyhim/proton-pass-community-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hesreallyhim/proton-pass-community-mcp)

Score Badge

Copy to your README.md:

[![proton-pass-community-mcp MCP server](https://glama.ai/mcp/servers/hesreallyhim/proton-pass-community-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hesreallyhim/proton-pass-community-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/hesreallyhim/proton-pass-community-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server