Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full transparency burden. It discloses Vault-backed credential usage and the authorizationKey requirement, but does not explain potential side effects (e.g., data modification/deletion), error behavior, response format, or endpoint restrictions. Some context is added, but significant behavioral traits remain undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, and every sentence earns its place. There is no fluff or repetition, making it appropriately concise for the content it delivers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (7 params, nested objects, no output schema, no annotations), yet the description is minimal. It lacks any guidance on response handling, error behavior, request construction, or examples, and does not compensate for the lack of annotations or schema descriptions. Only the fallback positioning and auth caveat are covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the 7 parameters. It only explains 'authorizationKey' (mutating calls require it) and implicitly 'userId' via 'selected user's Vault-backed credential.' Method, path, body, query, and headers have no added meaning beyond raw types. This is insufficient for a generic API request tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a generic Forcepoint API request using Vault-backed credentials, and contrasts it with dedicated tools by saying 'Use only when no dedicated tool fits.' This distinguishes it from the many sibling tools, showing a specific verb, resource, and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use only when no dedicated tool fits,' which tells the agent this is the fallback option, not the first choice. It also provides a conditional usage requirement for mutating calls when admin auth is enabled, adding practical guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It discloses the read-only nature and Postgres-backed storage, but does not mention permissions, side effects (none expected), or any other behavioral traits. It adds basic transparency but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the purpose. Every word serves a function, and there is no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with a single optional parameter and no output schema. The description explains the core function and read-only nature, but it does not mention what the configuration contains or what the return value looks like, which would be helpful given the lack of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one optional parameter userId, and the description adds 'for one user scope' which gives context that the parameter identifies the user. However, it does not clarify that the parameter is optional or what happens if omitted, so it only partially compensates for the 0% schema coverage in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads Postgres-backed Forcepoint connection configuration for one user scope. The verb 'Read' and resource 'connection configuration' are specific, and the tool is differentiated from sibling tools like forcepoint_connection_config_set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reading configuration but does not explicitly mention when to use this over alternatives like forcepoint_connection_info. The 'Read-only' hint is useful but there is no direct comparison or exclusion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the mutating nature and an auth prerequisite, but does not clarify partial vs. full update semantics, reversibility, or response behavior. This is more than minimal but still lacks key behavioral details 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the main purpose and add a critical mutating/auth caveat. No filler or redundant content; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters, no annotations, and no output schema, the description is too sparse. It omits details on update behavior, success/failure indicators, and role of the three scope parameters. The lack of reference to the get sibling or any usage scenario reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the purpose of baseUrl, timeoutMs, and userApiVersion, and implies authorizationKey's role, but leaves tenant, userId, and account unexplained. This is insufficient for a 7-parameter tool with zero parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Persist') and resource ('Forcepoint base URL, timeout, or preferred user API version') with an explicit scope ('for one user scope'). It clearly distinguishes from the sibling 'forcepoint_connection_config_get' by indicating a mutating/write operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for setting connection configuration, mentioning 'Mutating' and an auth condition ('requires authorizationKey when admin auth is enabled'). However, it does not explicitly contrast with the get counterpart or state when to prefer alternative tools, leaving usage guidance mainly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Explicitly labels itself 'Read-only', which is a key behavioral disclosure. It also enumerates the content areas (runtime defaults, auth model, docs, persistence wiring), providing useful context beyond the tool name. Since no annotations are provided, the description carries the burden and does so reasonably well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with the verb 'Return'. Every word earns its place; no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter info tool with no output schema, the description gives a clear overview of the return content across four categories. It could detail the exact structure or field names, but it is adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is complete and there are no parameter semantics to explain. Baseline 4 applies for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Return' and clearly specifies the resource scope: Forcepoint MCP runtime defaults, authentication model, docs references, and persistence wiring. This distinguishes it from siblings like forcepoint_connection_config_get/set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance or alternatives are mentioned. The description implies it is for retrieving connection info, but it does not compare with forcepoint_connection_config_get, forcepoint_scope_info, or forcepoint_health_check.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explicitly states 'Read-only,' disclosing that the operation is safe and non-mutating. It also clarifies that it returns data. However, it does not disclose return format or any access requirements beyond this, which is modest but adequate given the tool's simple nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two concise sentences that are front-loaded with the action and resource, followed by a behavioral note. No filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no parameters and no output schema, the description is reasonably complete. It states what is returned (endpoint catalog and OpenAPI metadata) and that it is read-only. Given the simplicity, it does not require further detail, although a note on the response format would improve it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it adds some context by indicating the tool returns inventory metadata rather than accepting arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Return' and specifies the resource as 'documented Forcepoint endpoint catalog and generated OpenAPI inventory metadata,' making the purpose clear. It is distinct from sibling tools like forcepoint_api_request or forcepoint_connection_info, though it does not explicitly name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention selection criteria, exclusions, or alternative tools. The only clue is 'Read-only,' which implies inspection use but is not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does disclose that the tool is 'Mutating' and mentions an important condition: 'requires authorizationKey when admin auth is enabled.' However, it does not explain potential failures (e.g., if users do not exist), idempotency, or response behavior. This provides some transparency but leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the primary purpose. It wastes no words and is appropriately sized for a tool of moderate complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no output schema, and no annotations, the description is not complete. It omits parameter details, return value behavior, error conditions, and any prerequisites beyond auth. The provided info covers purpose but not enough of the operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all 4 parameters. The description mentions authorizationKey in passing but does not explain the roles of groupname, companyemail, or userId. The phrase 'Add existing users' implies that companyemail might identify users, but this is not explicit. Overall, little parameter meaning is added beyond the schema's raw fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb and resource: 'Add existing users to a Forcepoint group.' This clearly states the action and distinguishes it from sibling tools like forcepoint_group_remove_members or forcepoint_group_create_or_update. The name itself is also descriptive, but the description adds clarity with the phrase 'existing users'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no guidance on when to use this tool versus alternatives. It does not mention when to choose add_members over remove_members or create_or_update, nor does it state any explicit exclusions or preconditions (beyond the auth note). The 'Mutating' tag is a behavioral hint, not a usage guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool is mutating and requires an authorizationKey under certain admin auth conditions. However, it does not explain the create-or-update semantics (e.g., what happens if the group already exists) or the return behavior. With no annotations provided, some important context is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose and safety traits, and contains no filler. It efficiently communicates the core action and key constraint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should provide more behavioral and parameter context. It omits how the rename/create logic works, fails to mention userId, and does not state what happens on success or failure. The description is too incomplete for a tool with nested object parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no explanation of parameters. It does not clarify that payload requires groupname and optionally newgroupname, nor what userId or authorizationKey are for. The parameter names are somewhat self-explanatory but the description does not compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates or renames a Forcepoint group, which is a specific verb+resource pair. It distinguishes from sibling tools like forcepoint_group_add_members and forcepoint_group_delete by focusing on group creation/rename.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as forcepoint_group_add_members or forcepoint_user_create_or_update. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses the operation is high-risk and mandates an authorizationKey under admin auth, which is valuable. However, it omits side effects (e.g., whether members are removed, whether deletion is permanent) or error conditions, leaving significant behavioral gaps for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and every word adds value. It avoids redundancy and gets straight to the point, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that this is a high-risk mutation with no annotations and no output schema, the description is too sparse. It lacks information on return values, error handling, reversibility, and cascading effects, which are critical for an agent deciding to invoke a destructive operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It clarifies that authorizationKey is conditionally required, adding meaning beyond the schema's bare `minLength`. 'groupname' is implied as the target, but 'userId' is entirely unexplained, leaving a key parameter ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Delete a Forcepoint group' uses a specific verb and resource, making the tool's function unmistakable. It clearly distinguishes this from sibling tools like group_add_members, group_remove_members, or group_create_or_update by stating the delete action explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates the action's intent—deleting a group—which implicitly tells the agent when to use it. It also adds caution with 'High-risk mutation' and notes the conditional authorizationKey requirement, providing useful usage context though it doesn't explicitly name alternatives or when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explicitly states 'Read-only' and mentions 'pagination metadata', which gives some behavioral context. However, it does not explain how the status parameter filters members, what errors might occur, or any authentication requirements, leaving gaps for a read tool with five parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately states the action and key concepts (read, group details, member status slice, pagination metadata). No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having five parameters and no output schema, the description is minimal. It doesn't explain parameter meanings, return value structure beyond pagination metadata, or any prerequisites. For a tool with this complexity, the description is incomplete and would leave an agent uncertain about how to effectively invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It hints at member status and pagination but doesn't explain the relationship between status and 'member status slice' nor does it clarify the role of userId. GroupName is obvious from the tool name, but pageToken and pageSize are only implicitly linked to pagination metadata. This is insufficient for a five-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Read' and identifies the resource as 'Forcepoint group details', clearly distinguishing this from sibling write operations like forcepoint_group_add_members and forcepoint_group_delete. However, it doesn't explicitly differentiate from forcepoint_group_list, which also reads group-related data, so it's not a perfect 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to choose this tool over alternatives such as forcepoint_group_list or forcepoint_user_get. There is no mention of exclusions, prerequisites, or specific use cases, leaving the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations available, the description must fully disclose behavioral traits. It only states 'Read-only', which is a useful safety hint, but omits other important behavior such as whether userId is required, what happens if no groups exist, or any permission requirements. The description carries a heavy burden and fails to provide enough detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences that are front-loaded with the core action and include a useful safety note. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations and output schema, the description is underspecified. It lacks parameter meaning, usage prerequisites, and return behavior, making it insufficient for an agent to fully understand how to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for explaining the parameter. It vaguely refers to 'selected user scope' but does not explicitly clarify that userId identifies the user whose groups are listed. With only one optional parameter, clearer semantics are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (List), a resource (Forcepoint groups), and a scope (selected user scope). This clearly distinguishes it from sibling tools like get, create, or delete for groups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context (list operation for a user scope) and implicitly differentiates from alternatives that modify or fetch a single group. However, it does not explicitly say when not to use this tool or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 states the tool is mutating and explains the authorizationKey requirement, which is useful. However, it does not disclose side effects, reversibility, failure behavior, or whether group existence is required, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the core action, and every word adds value. It is appropriately sized and structured for quick consumption.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of an output schema and 0% parameter coverage, the description should provide more context about expected responses, error handling, and operational side effects. The basic purpose is clear, but an agent would need to infer or guess about return formats and failure modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate by explaining parameters. It only mentions authorizationKey, leaving groupname, companyemail, and userId unexplained. While their names imply meaning, the description adds little semantic value beyond the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation ('Remove users from a Forcepoint group'), specifying the verb and resource. It distinguishes itself from the sibling tool 'forcepoint_group_add_members' by focusing on removal rather than addition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes it is mutating and mentions the authorizationKey requirement when admin auth is enabled, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria (e.g., 'use this only when you need to remove members, not add them').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the tool is 'Read-only,' which is a key behavioral trait, and specifies the endpoint used. However, it does not explain what happens on failure, timeout, or the format of the response, leaving gaps in transparency given no annotations are provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the purpose and read-only nature.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool has a simple interface (one optional parameter, no output schema), the description omits crucial context about the parameter and expected output. It does not clarify what constitutes a successful health check or what the response contains, making it incomplete for an agent to invoke confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not mention the 'userId' parameter at all, and the schema has zero description coverage. Since the parameter is optional and unexplained, the agent cannot infer its role in the health check.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Verify Forcepoint reachability and stored credentials using the documented group-list read endpoint.' The verb 'Verify' and the specific resource (Forcepoint reachability and credentials) make the purpose distinct from sibling tools like forcepoint_group_list or forcepoint_connection_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for health-checking, but does not explicitly state when to use it over alternatives such as forcepoint_connection_info or forcepoint_api_request. It provides context about the endpoint but no exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses 'Read-only' and the Vault storage context, which is useful, but omits details like response format, pagination, or behavior when userId is absent. The read-only note adds value, but more transparency would be expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, well-structured sentence with no redundancy. It is front-loaded with the verb and resource, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks return-value details (no output schema) and does not specify criteria for when to use this tool over other token-related siblings. With zero annotations and no output schema, more context is needed to be complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It says 'user-scoped,' hinting that userId filters by user, but does not explain the parameter meaning, optionality in prose, or behavior when omitted. This is insufficient for an agent to understand how to set the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and identifies the resource 'user-scoped MCP HTTP bearer-token metadata stored in Vault,' clearly distinguishing it from mutation siblings like upsert/revoke. The scope and data source are explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (listing token metadata) but does not explicitly state when to prefer it over forcepoint_user_token_get or other siblings, nor does it mention exclusions or prerequisites. It gives no direct comparison to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses that the operation is mutating and high-risk, which are important behavioral traits. It also flags the conditional auth requirement. However, it does not describe specific effects like token invalidation or return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently conveys the core action and risk level with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple revoke operation, the description covers purpose and risk, but given the absence of annotations and output schema, it leaves gaps such as response format and exact permission details. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It mentions tokenId and provides context for authorizationKey, but does not explain userId. This is partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action: 'Revoke a user-scoped MCP HTTP bearer token by tokenId.' This clearly identifies the resource and scope, and distinguishes from sibling token operations like get and upsert.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides usage context by labeling the operation as 'Mutating and high-risk' and specifies that authorizationKey is required when admin auth is enabled. This gives conditional guidance but does not explicitly mention alternatives or 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the tool is 'Mutating and high-risk' and mentions the authorizationKey requirement, providing some behavioral context. However, it does not explain the side effects of an update, whether the operation is idempotent, or what happens to existing tokens, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences: the first states the purpose, and the second provides important risk and auth context. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, no output schema, no annotations), the description is too sparse. It does not cover parameter semantics, return values, or operational details like whether the token is immediately active or how updates affect existing tokens. For a high-risk mutation tool, this is insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 8 parameters with no descriptions (0% coverage), and the description provides no parameter explanations. It only indirectly mentions authorizationKey as a requirement. None of token, scopes, userId, tokenId, audience, expiresAt, or returnToken are explained, failing to compensate for the schema's lack of detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create or update a user-scoped MCP HTTP bearer token stored in Vault', specifying the verb (create/update), resource (MCP HTTP bearer token), and scope (user-scoped, stored in Vault). This distinguishes it from sibling token tools like forcepoint_user_token_set or forcepoint_mcp_http_token_revoke.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus alternatives, such as forcepoint_user_token_set or forcepoint_mcp_http_token_get. It only mentions a prerequisite ('requires authorizationKey when admin auth is enabled') and a caution about risk, but no explicit when/when-not or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explicitly states 'Read-only,' which is a key safety trait. It also mentions 'safety checks' as part of its suggestions, indicating a consultative role. It doesn't discuss auth, rate limits, or output format, but for a read-only planning tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the main action ('Suggest Forcepoint MCP tool sequences...'), followed by purpose and safety. Every word adds value; there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool's purpose is clear, the description lacks details about the output structure (since there is no output schema) and how parameters like 'path' and 'method' are used. It sufficiently covers the high-level intent but leaves specifics to inference, which is acceptable for a planning tool but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 6 parameters with 0% description coverage. The description only hints at 'workflow intent' (intent) and 'tool schemas' (includeToolSchemas), but omits explanation for 'path,' 'method,' 'operationType,' and 'includeExamples.' The enum for operationType is visible in schema, but its meaning is not elaborated. The description does not compensate for the schema's lack of parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Suggest Forcepoint MCP tool sequences, safety checks, and rich tool schemas for a workflow intent.' This is a specific verb (suggest) and resource (tool sequences/schemas), and it distinguishes itself from sibling tools that perform actual operations by positioning itself as a planning/discovery aid.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context for use: 'use for schema discovery and planning.' The read-only hint implies this is for exploration before executing actions. While it doesn't explicitly name alternative tools or when not to use it, the sibling tool list and the description make it evident that this is a meta-tool for workflow design, not execution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states 'Read-only,' which is a valuable safety disclosure in the absence of annotations. It does not reveal error behavior, return structure, or the meaning of the paths, but the read-only flag covers the main side-effect concern.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that communicates the action and the read-only feature without any fluff. Every phrase adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple info tool with an optional parameter and no output schema, the description gives the essential purpose and safety profile. However, it lacks details about the actual path structure and does not place the tool in context relative to siblings, leaving some gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema documents a single optional `userId` parameter with no description. The description's use of 'user-scoped' implies that this parameter controls the scope, adding meaningful context beyond the schema. It does not explain the parameter's format, optionality, or default behavior, so the baseline is maintained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Return') and identifies a concrete resource ('user-scoped Postgres and Vault paths'), clearly distinguishing it from generic tools. It doesn't explicitly name sibling tools, so it falls short of the highest score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to choose this tool over the many related siblings (e.g., forcepoint_connection_info, forcepoint_user_get). No conditions, exclusions, or alternatives are mentioned, leaving the agent to guess.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states 'Mutating' and the auth requirement, but does not disclose whether updates are partial or full, whether the operation is idempotent, or what happens to existing fields when only a subset is provided. The phrase 'Create or update' suggests upsert behavior but does not detail the merge semantics, which is critical for a write tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with the core purpose stated first and the auth requirement in the second sentence. However, 'Mutating' is redundant with 'Create or update' and 'through the documented Config API' adds little value, so it is slightly less efficient than it could be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a nested payload object with numerous business-specific fields, no output schema, and no annotations. The description provides only a high-level overview and auth condition, leaving users without guidance on required vs optional fields, return values, error behavior, or edge cases like user existence.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only mentions authorizationKey, leaving userId and the entire payload structure unexplained. Critically, it does not clarify how userId interacts with payload to decide between create and update, which is essential for correct tool invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb phrase 'Create or update a Forcepoint user' which clearly identifies the action and resource. It distinguishes this from read/delete sibling tools like forcepoint_user_get and forcepoint_user_delete by implying an upsert operation, though it does not explicitly contrast with those.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description conveys the general use case (creating or updating a user) but does not provide explicit guidance on when to prefer this tool over alternatives such as forcepoint_user_get for reads or forcepoint_user_deactivate for state management. The only additional guidance is the authorizationKey requirement, which is a prerequisite rather than a selection criterion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses mutating and potentially disruptive behavior, and notes an auth dependency. However, it does not specify what deactivation does to user sessions, tokens, or whether it is reversible (though reactivate sibling hints at reversibility). This is a minimal but non-trivial disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core action, and every word earns its place. No fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (no output schema, few params), and the description covers the essential behavioral warning and auth condition. It does not explain the outcome or side effects on the user record, but given the sibling tools and low complexity, it is mostly complete. A bit more detail on deactivation effects would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It only adds context for authorizationKey (conditional requirement), but does not explain userId vs companyemail usage. The required companyemail is clear from the schema, but the optional userId and authorizationKey remain ambiguous. Partial compensation for one parameter only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Deactivate a Forcepoint user') with a specific verb and resource. It distinguishes from sibling tools like forcepoint_user_delete and forcepoint_user_reactivate by using the term 'deactivate' rather than destroy or re-enable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by noting the operation is 'mutating and potentially disruptive' and mentions the conditional requirement for authorizationKey. It does not explicitly name alternatives, but the sibling list and the deactivate action imply when this should be used compared to reactivate or delete. Slight deduction for lack of explicit 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly labels the operation as 'high-risk mutation', which is a strong warning about consequences. It also discloses the conditional requirement for authorizationKey, adding useful context beyond the schema. However, it does not explain permanence, error cases, or side effects, so it is not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short, front-loaded sentences. The first sentence states the core purpose, and the second provides essential risk/requirement info. Every word earns its place; no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

As a destructive mutation with no annotations and no output schema, the description is too sparse. It fails to explain whether deletion is permanent, what happens if the user is active, or what the response looks like. It provides a warning but lacks critical operational details that an agent needs for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not compensate for the lack of parameter explanations. It mentions authorizationKey only as a conditional requirement, but does not clarify the roles of userId vs companyemail (which is required), or how they relate. This leaves significant ambiguity for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Delete') on a specific resource ('deactivated Forcepoint user'), which distinguishes it from sibling tools like user_deactivate or user_get. The 'deactivated' qualifier adds a precise scope, making the intent unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that deletion is intended for deactivated users, but it does not explicitly state when to use this tool instead of alternatives (e.g., user_deactivate for deactivation or user_reactivate for reactivation). There is no 'use this when' or 'use X instead' guidance, only a contextual hint.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states 'Read-only', which conveys the safe, non-mutating nature of the operation. However, no annotations are present, and the description does not disclose behaviors such as error handling, permissions, or output format, leaving those aspects unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that immediately states the action and resource. Every word adds value, with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description is too sparse. It does not mention what the returned user details contain, how to choose between userId and username, or any constraints (e.g., username email format), leaving significant gaps for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not mention any of the three parameters (userId, username, apiVersion). It does not explain the distinction between userId and username, nor how apiVersion affects the request or response, leaving the agent to infer from parameter names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads Forcepoint user details, specifying the API versions (v2 or v2.1). This distinguishes it from sibling tools that create, update, or delete users, as well as token-related operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description does not mention any exclusions or alternative tools for related operations like token retrieval, even though sibling tools exist for those purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 does disclose that the operation is mutating and mentions a conditional authentication requirement, which is useful. However, it lacks details on side effects, reversibility, or expected behavior after reactivation, leaving significant gaps given no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise: two sentences that state the purpose and the key prerequisite. It is front-loaded with the core action, includes no filler, and every clause adds value. This is an ideal example of brevity without losing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple with 3 parameters and no output schema, yet the description omits guidance on differentiating userId from companyemail and does not clarify the operational effect of 'reactivate'. Given the absence of annotations and output schema, the description is only minimally complete, leaving the agent to infer important details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It only adds meaning to one parameter (authorizationKey) via the conditional requirement statement. The required parameter companyemail and optional userId are not explained at all, leaving the agent without guidance on how to choose the correct identity parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Reactivate a Forcepoint user' clearly states a specific verb and resource, making the tool's purpose immediately obvious. It inherently distinguishes from sibling tools like forcepoint_user_deactivate and forcepoint_user_delete by the action verb. The additional 'Mutating' note reinforces its state-changing nature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage context by stating the operation is mutating and requiring authorizationKey under certain conditions. However, it does not explicitly say when to use this tool versus alternatives, nor does it mention exclusions or alternative tools. The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explicitly states the mutating and high-risk nature, which warns of destructive impact, and mentions the authorizationKey requirement. This goes beyond a simple 'delete' statement, providing useful safety and authentication context, though it doesn't detail irreversibility or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the action, and contains no filler. Every word earns its place, efficiently conveying purpose, risk, and a prerequisite.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a simple delete operation with two parameters and no output schema. The description covers the core purpose, risk level, and an important authentication condition. It lacks details on return values or behavior with non-existent users, but these are less critical for a delete tool, making it reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no descriptions for either parameter, so the description must compensate. It explains the authorizationKey parameter's purpose (required when admin auth is enabled), but does not explicitly describe the userId parameter, though 'one user scope' implies its role. This partial explanation warrants a mid-range score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes a Vault-backed Forcepoint credential for one user scope, using the specific verb 'Delete' and a clear resource. It distinguishes from sibling tools like forcepoint_user_token_get and forcepoint_user_token_set, which handle retrieval and creation/updating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by labeling the operation as 'Mutating and high-risk' and noting the conditional requirement for authorizationKey. While it doesn't explicitly name alternatives or exclusions, the context is sufficient to understand when this tool should be used (i.e., when needing to remove a user credential).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explicitly states 'Read-only' and that 'secret values remain redacted,' which are important behavioral disclosures. However, it does not mention error behavior or what metadata is included, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and resource, and contains no filler. Every word adds value, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool, the description conveys the core purpose and safety profile. However, with no output schema, it does not clarify what the returned metadata looks like, and it lacks explicit usage guidance in the context of sibling tools. This makes it adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero description coverage for the only parameter (userId), and the description does not explain what userId represents, its format, or its requirement status. The phrase 'for one user scope' hints at its purpose but does not compensate for the lack of parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Read', the resource ('metadata about the Vault-backed Forcepoint credential'), and the scope ('for one user scope'). It also distinguishes from siblings by noting it is read-only and secret values are redacted, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving credential metadata without modification, but it does not explicitly name alternative tools (e.g., forcepoint_user_token_set, forcepoint_user_token_delete) or state when not to use this tool. The context is clear, but explicit guidance is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does disclose 'Mutating and high-risk' and the authorizationKey condition, which are valuable behavioral signals. Yet it omits side effects like overwriting existing credentials, revocation behavior, or idempotency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two efficient sentences, front-loading the purpose and immediately adding critical risk and authorization context. Every word earns its place; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, mutating tool with no output schema and no annotations, the description is too thin. It covers purpose and high-level risk, but fails to explain parameter semantics, return behavior, error conditions, or overwrite semantics, leaving substantial ambiguity for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It clarifies bearer vs basic auth modes and the authorizationKey condition, but leaves userId, tokenLabel, notes, oauthApplicationName, and the exact relationships between authMode and credential fields unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Store') and resource ('user-scoped Forcepoint bearer token or basic-auth credential in Vault'), clearly distinguishing it from sibling tools like forcepoint_user_token_get and forcepoint_user_token_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly identifies the operation as mutating and high-risk, and notes the conditional requirement for authorizationKey when admin auth is enabled. However, it does not explicitly mention alternative tools or exclusions, so it stops short of full usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.