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 describes the mapping format but does not explain what happens when a session is created, whether it persists, how naming collisions are handled, or what the response contains. This is a significant transparency gap.

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 with no filler. The essential example for the most complex parameter is front-loaded, making it quick 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?

Given four parameters and no annotations, this description is incomplete. It covers the mappings parameter well but omits semantics for the other required parameters and any context about session creation behavior. An agent would likely need to guess at several 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?

Schema description coverage is 0%, so the description must compensate. It provides a helpful example for 'mappings', but leaves 'name', 'description', and 'case_sensitive' semantically unexplained beyond their schema titles and default value.

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

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

The description states a specific verb and resource: 'Create a new swap session with key-value mappings.' This clearly distinguishes it from sibling tools like phantomswap_list_sessions or phantomswap_mask_text. 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.

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

The verb 'create' implies when to use it, but there is no explicit guidance about when to choose this over alternatives, no preconditions, and no mention of what a 'swap session' is used for afterward. The context is inferable but not stated.

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 behavioral disclosure burden. 'Get' clearly signals a read operation, and 'full details and all key-value mappings' hints at the response scope. However, it does not mention behavior for nonexistent sessions, authentication requirements, or the fact that no state is modified. This is adequate for a simple getter 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.

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

The description is a single, front-loaded sentence with no filler or redundancy. It states the verb, the resource, and the scope of returned data efficiently.

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 low-complexity getter with one self-descriptive parameter and an output schema, the description covers the core operation. The output schema handles return-value details, so not explaining them is acceptable. Minor gaps remain around not-found behavior and explicit relationship to sibling tools, keeping it from a 5.

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 should compensate for the parameter's meaning. It only says 'a specific swap session,' which largely restates what session_name_or_id already conveys. It does not explain accepted formats, whether both name and ID resolve to the same session, or what happens on ambiguous or missing values.

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 clear verb ('Get') and identifies the exact resource ('a specific swap session'). It also states the tool returns 'full details and all key-value mappings,' which distinguishes it from list_sessions and makes the operational scope obvious.

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?

Usage context is only implied: the agent can infer this tool is for retrieving a single session while list_sessions is for enumerating them. The description does not explicitly state when to prefer this tool, when not to use it, or how it relates to create_session or the masking/unmasking siblings.

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 behavioral disclosure burden. It does convey a read-only enumeration behavior and that results are summary-level, which is useful. However, it does not mention potential pagination, ordering, empty results, or any side effects/caveats, leaving some gaps for a no-annotation 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?

A single, front-loaded sentence with no filler. Every phrase earns its place by identifying the action, the resource scope, and the output 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?

For a zero-parameter listing tool with an output schema present, the description is largely sufficient. It would be more complete with explicit guidance on when to use list versus get, but given the low complexity and rich schema context, the gap is minor.

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?

There are zero parameters and schema coverage is effectively complete, so there is nothing for the description to elaborate. The baseline of 4 applies; the description adds no parameter-specific detail because none is 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 uses a specific verb ('List') and resource ('all available PhantomSwap swap sessions') and clarifies the output ('summary details'). This clearly distinguishes it from sibling tools like get_session (one session) and create_session (new session).

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 states what the tool does but gives no explicit guidance on when to choose it over alternatives such as phantomswap_get_session. There is no mention of use cases, exclusions, or routing logic; any usage inference is left to the agent.

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 must disclose behavioral traits, but it does not. It does not mention whether masking modifies files in place, whether it is reversible, what happens to subdirectories, or whether any session state is consumed or changed.

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 one short sentence with no filler and front-loads the main action. It is concise, though it sacrifices useful detail for brevity.

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 3 parameters, 0% schema coverage, and no annotations, the description is far too thin. It omits the role of file_extensions, behavior on nested directories, session requirements, and side effects. The presence of an output schema does not compensate for these missing operational 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?

Schema description coverage is 0%, so the description must compensate for missing parameter meaning. It only indirectly references session_name_or_id and directory_path, and says nothing about file_extensions, which is a meaningful optional parameter with no schema documentation.

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

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

The description states a specific action ('Mask all files in a directory') and the mechanism ('using a swap session'). It clearly differentiates from siblings like phantomswap_mask_text and phantomswap_unmask_directory by specifying directory-level masking.

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 when to use this tool: when masking all files in a directory rather than a single text value. However, it provides no explicit guidance about prerequisites such as needing an existing swap session, nor exclusions versus alternative tools like mask_text or unmask_directory.

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 explains that values are swapped with fake placeholders, but does not disclose whether the session stores the mapping, whether masking is reversible, what side effects occur, or what the output represents. This is minimal transparency for a stateful-looking operation.

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

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

The description is a single concise sentence with no filler, which is positive. However, it is under-specified for a tool with two required parameters and a session-based workflow, so the conciseness is not fully 'appropriate' to the tool's needs.

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 definition lacks key context about sessions, session lifecycle, availability of an inverse operation, and any constraints around masking text. An output schema exists but cannot compensate for missing usage semantics. Overall, the description is too sparse for an agent to confidently select and 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 only implicitly explains 'text' while leaving 'session_name_or_id' completely unexplained. The agent cannot infer how to choose or specify a session, what the session is used for, or what format the identifiers take.

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 ('Mask sensitive information in text') and a clear resource ('text'), with the method 'swapping real values with fake placeholders'. It implies differentiation from siblings like phantomswap_mask_directory by targeting text, but does not explicitly name alternatives or distinguish them.

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 phantomswap_unmask_text, phantomswap_mask_directory, or session-related tools. The description does not mention prerequisites like having a session, which seems important given the required session_name_or_id parameter.

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 not explain the effects of unmasking files, whether files are modified in place, whether a valid swap session is required or consumed, or what side effects may occur. 'Unmask' implies mutation, but the consequences and prerequisites are unstated.

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 filler or redundant phrasing. It is efficient, though it sacrifices necessary detail for brevity.

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 three parameters and no annotations, but the description only covers a generic action. It omits the optional file_extensions behavior, session requirements, and any operational context. The presence of an output schema reduces the need to explain return values, but the behavioral and prerequisite gaps remain significant.

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 by explaining parameters. It indirectly covers 'directory_path' and 'session_name_or_id' through the phrase 'directory using a swap session,' but it completely ignores 'file_extensions' and gives no format, behavior, or filtering details for any 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 clearly states the operation ('Unmask all files'), the target resource ('in a directory'), and the mechanism ('using a swap session'). This distinguishes it from siblings like phantomswap_unmask_text and phantomswap_mask_directory through verb 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?

No explicit guidance is given on when to use this tool versus alternatives such as phantomswap_unmask_text or phantomswap_mask_directory. The wording implies directory-level unmasking, but it never states when this is the right choice or when another sibling should be used.

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 present, so the description carries the full burden of behavioral disclosure. It explains the core transformation but omits any context about session dependence, side effects, permissions, or error behavior, which is significant for a tool requiring a session_name_or_id.

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

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

The description is a single clear, front-loaded sentence with no filler or redundancy. While it is too terse to fully inform the agent, its structure efficiently communicates the primary action and resource.

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 an output schema, the description lacks essential context about session usage, placeholder semantics, and its relationship to sibling mask tools. With two required parameters and no annotations, an agent cannot confidently determine prerequisites or expected behavior.

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

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

Schema description coverage is 0%, and the description does not compensate. The 'text' parameter is only implied by the verb, and 'session_name_or_id' is completely unexplained, leaving the agent without a clear understanding of how the session relates to unmasking.

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 'Unmask' applied to the resource 'text', with the mechanism 'restoring fake placeholders back to original real values'. It distinguishes itself from siblings such as unmask_directory by the explicit 'text' resource and from mask_text by the inversion of the 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?

There is no guidance about when to use this tool versus alternatives like mask_text or unmask_directory. No conditions, exclusions, or related-tool routing are provided, so the agent must infer usage from the tool name alone.

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