GhostKey

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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior. The description adds a useful behavioral nuance by saying staged families should not be treated as callable, but it does not describe output shape, catalog contents, or any auth/discovery constraints.

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. It covers the core action and the key caveat about staged families without unnecessary detail.

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 parameterless, read-only catalog with rich annotations and no output schema, the description is largely complete: it says the tool lists exposed capabilities and identifies staged families. The main gap is that 'staged families' and the exact catalog output are not defined, but the tool's low complexity keeps this from being a major omission.

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 there is no parameter semantics for the description to compensate for. The baseline for a parameterless tool is 4, and the description appropriately avoids inventing parameter guidance.

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 clear verb and resource: list the capabilities exposed by this GhostKey MCP server. It also distinguishes callable capabilities from staged families, though it does not explicitly name sibling tools or say how it relates to 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?

Usage is implied by the discovery-oriented wording: use it to see what the server exposes and which families are staged. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the sibling tools.

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?

Annotations already declare readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds substantive context beyond them: storage prerequisite, one-time enrollment, browser-generated non-exportable P-256 key, and only public-key upload, though it omits expiration/error and return 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?

Three compact sentences front-load the create action, then state the prerequisite and key-handling behavior. Every sentence contributes useful context with 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 one-parameter tool with no output schema and annotations covering safety traits, the description supplies the critical prerequisite and cryptographic behavior. It still leaves the label parameter and caller-facing result undefined, so it is strong 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 sole optional parameter, label, has 0% schema description coverage and is not mentioned in the description at all. The schema gives type and length limits, but neither source explains what the label means or how it is used, so the description does not compensate for the coverage gap.

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?

States a specific verb, "Create," and a specific resource, "one-time trusted-device enrollment capability," so the agent can distinguish it from the pairing status sibling. "Capability" is slightly abstract, but the pairing/enrollment intent is clear.

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?

Adds a prerequisite that GhostKey persistent trusted-device storage must be configured and implies one-time enrollment use. It does not name alternatives such as ghostkey_device_pairing_status or say when not to use this tool, so usage guidance remains 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral constraints, namely one-time use, original credentials, and an expiry window, but it does not clarify what resolution returns or how invalid/expired credentials are handled.

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 scope, and contains no filler. The expiry constraint follows immediately and 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 simple two-parameter read tool, the description covers invocation prerequisites and validity period. However, with no output schema, it omits what the status resolution actually returns, which is a meaningful gap for a status-oriented tool.

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 names both required parameters and adds that they are the original pairing ID and pairing code, but it does not explain format, validation, or error behavior beyond what the bare schema provides.

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 names a specific resource (one-time trusted-device pairing) and context (after browser enrollment), but the verb 'Resolve' is ambiguous for a tool named 'status' and does not explicitly say it retrieves or checks pairing status. It also does not name or differentiate the sibling pairing_create tool.

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 gives clear timing guidance: use after the browser has enrolled and before the pairing capability expires. It also states the required original pairing ID and code, though it does not name alternatives or explicitly describe failure when expired.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real value beyond that by scoping the content: operating, payment, upstream-rights, browser-session and trusted-device policy, telling the agent what it will actually get back. It stops short of describing format, length, or whether the policy is versioned/cached.

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 sentence with the verb front-loaded and no filler; every clause names a distinct policy area that adds 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 zero-param, no-output-schema tool, the description adequately conveys what the call returns via the enumerated policy domains. A brief note on the shape of the response (e.g., a structured policy document) would close the remaining gap.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and no schema gap to compensate for.

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?

Specific verb 'Return' plus a named resource ('GhostKey's ... policy') and an enumeration of the five policy domains covered. This clearly separates it from action-oriented siblings like ghostkey_session_create or ghostkey_quote, though it doesn't explicitly contrast itself with ghostkey_catalog or ghostkey_status, which also sound informational.

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?

'For autonomous agents' implies the intended consumer and hints the policy should be consulted as operating rules, but there is no explicit statement of when to call this versus ghostkey_status or ghostkey_catalog, and no prerequisites or ordering 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: pricing and settlement destination come from a live HTTP 402 challenge, not a copied wallet or stale price, which reinforces the open-world, read-only nature and clarifies data freshness.

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: the first states the purpose and the second provides a key behavioral constraint. It is front-loaded and free of fluff, though the opening verb 'Explain' is slightly indirect for a quote tool.

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 simple schema (one parameter, no output schema) and rich annotations, the description covers the source of pricing and freshness requirement. However, it does not clarify what the tool returns (e.g., a challenge, a quote object, or explanatory text) or how to supply the 'capability' parameter, leaving gaps 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 description coverage is 0% and the single parameter 'capability' has no description in the schema. The tool description mentions 'paid capability' but does not explain what value to pass (e.g., identifier format, where to find it), leaving the parameter semantics largely undocumented.

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

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

The description states the tool explains how to obtain pricing for a GhostKey/SML paid capability, but does not clearly say it returns a quote or challenge. The verb 'explain' is less direct than 'get' or 'fetch', and there is no explicit differentiation from sibling tools like ghostkey_catalog or ghostkey_policy.

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 implies the tool should be used to obtain authoritative pricing from a fresh HTTP 402 challenge and warns against copied wallets or stale fixed prices, but it does not explicitly state when to choose this tool over alternatives or provide exclusions beyond the freshness caveat.

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?

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotent, but the description adds real behavioral detail beyond them: password and hidden fields are denied, and off-allowlist navigation is denied. It stops short of explaining what happens on denial, whether actions are reversible, or per-action side effects, which keeps it from 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?

Three compact sentences with the core behavior and the security constraints front-loaded, followed by a documentation pointer. The README URL is useful but the line is somewhat load-bearing in place of inline detail, which slightly weakens the structure.

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 8 undocumented parameters, no output schema, and destructive/open-world semantics, the description defers heavily to an external README. It never states what read or inspect return, nor what a successful versus denied response looks like, so an agent cannot fully predict behavior from the definition alone.

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% across 8 parameters, and the description only echoes the action enum values. It does not explain which parameters each action needs (url for navigate, selector/text for input, attribute for read, timeout_ms bounds), nor the roles of session_id and agent_token, leaving most of the schema uninterpreted.

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?

States a specific verb and resource ('Relay one authorized browser action into the user's already-authenticated browser') and enumerates the seven supported actions. This is clearly distinguishable from siblings like ghostkey_session_create, ghostkey_session_status, and ghostkey_session_revoke, which manage the session rather than perform actions within it.

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 phrase 'one authorized browser action' plus the denial rules implies this is the tool to call once a session exists, but usage is only implied. No sibling is named as an alternative, and there is no explicit when-not guidance (e.g., 'do not call before ghostkey_session_create succeeds').

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?

Annotations already cover the safety profile (not read-only, open-world, non-idempotent, non-destructive), and the description adds substantial beyond-schema behavior: exact price and network, the x402 PAYMENT-SIGNATURE header requirement, the 402 challenge with amount 100000, the fact that in-session actions are unmetered, and that login/CAPTCHA and new origin permissions remain the user's responsibility. This is unusually rich disclosure for a paid 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?

Sentences are dense with no filler, and the cost/payment condition is front-loaded where an agent needs it before deciding. It is on the long side for a three-parameter tool, but every clause carries distinct operative 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 paid, non-idempotent mutation tool with no output schema, the description covers cost, payment mechanics, session semantics, and user responsibilities. The main gap is the return payload: it never says what a successful session object contains (session ID/token, expiry), which the agent needs to chain into session_action.

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 carry parameter meaning. It explains trusted_device_id well ('private 256-bit routing capability' so the extension can auto-claim), and 'origin-scoped' implicitly frames allowed_origins, but ttl_seconds is only gestured at with 'short-lived' and no parameter names or bounds are given. Partial compensation for a low-coverage schema.

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?

States a specific verb and resource with scope: 'Create a short-lived, origin-scoped browser delegation session.' That is far more precise than the sibling names alone (session_action, session_status) and implies the lifecycle position. It doesn't explicitly contrast with device_pairing_create or session_action, so it stops short of full sibling differentiation.

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 implied rather than stated: the agent learns payment is required and that a session can optionally be routed to an enrolled device, but there is no explicit 'use this instead of X when Y' routing against sibling tools like session_action or device_pairing_create. The prerequisites (payment header, user handling login/CAPTCHA) are present, which lifts it above bare minimum.

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?

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered structurally. The description adds genuinely useful context beyond that: revocation is immediate and queued work is cancelled, telling the agent the blast radius is broader than the session itself. It omits confirmation requirements, what happens to in-flight versus queued work, and any error/retry behavior for a non-idempotent destructive call.

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 and the destructive effect delivered up front. Brevity here shades into under-specification, but structurally it is tight and readable.

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 destructive, non-idempotent, open-world mutation with two required parameters at 0% schema coverage and no output schema, the description does too little. It never explains the agent_token auth requirement, what a successful revoke does to the caller's own session, or what failure looks like — the agent would have to guess.

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 and does not: neither session_id nor agent_token is mentioned. 'A ... session' weakly implies a session identifier, but the required agent_token credential and its role in authorizing the revocation are completely undocumented.

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?

States a specific verb (revoke) and resource (GhostKey browser delegation session) plus the side effect of cancelling queued work, which distinguishes it from session_create/session_status. It does not, however, differentiate itself from the sibling ghostkey_session_action, which plausibly could also revoke a 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?

There is no explicit when-to-use guidance, no prerequisites, and no naming of alternatives such as ghostkey_session_action or ghostkey_session_status. The word 'Immediately' hints at an urgent path but never says under what conditions this tool rather than another should be chosen.

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?

Annotations already declare readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds genuine context in the 'user-controlled browser bridge' heartbeat concept, but says nothing about what a stale heartbeat means operationally, what failure modes exist, or what the result looks like.

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?

One sentence, no filler, verb and scope front-loaded. It is dense and readable, though it packs two distinct checks (session liveness, bridge heartbeat) without separating them.

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?

There is no output schema, so the description should hint at what is returned (alive/not-alive plus heartbeat freshness), and it only partially does so. Combined with zero parameter documentation in either schema or description, an agent has enough to know the intent but not the full calling contract.

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 both required parameters (session_id, agent_token) are undocumented in the schema. The description never mentions either parameter, so it fails to compensate for the coverage gap on a tool that requires authentication and a session identifier.

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?

States a specific verb ('Check whether') and a precise resource: a scoped GhostKey browser session's liveness plus bridge heartbeat freshness. 'Scoped session' separates it from the sibling ghostkey_status (global) and from ghostkey_session_create/revoke/action, though no sibling is named 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?

Usage is implied by 'check whether ... is alive', but the description never states when to call this versus ghostkey_status or ghostkey_device_pairing_status, nor any prerequisite such as holding a valid agent_token.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing that unreachable or indeterminate authorities yield 'unknown' rather than a fabricated healthy result — an important interpretation rule for an open-world probe.

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 short sentences, front-loaded with the primary purpose and followed by the one non-obvious behavioral caveat. No filler and nothing restated from the annotations.

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, read-only status probe, the inputs side is fully covered, but there is no output schema and the description never sketches what a status report contains (overall state, per-authority reachability, unknown states). Since no output schema exists, the description should carry that burden and only partially does.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly frames the call as configuration-driven ('configured ScriptMasterLabs authorities') rather than parameter-driven.

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?

States a specific verb and resource: 'Report GhostKey server status' plus 'check whether configured ScriptMasterLabs authorities are reachable'. This differentiates it from siblings like ghostkey_session_status and ghostkey_device_pairing_status by scoping to server-level health rather than a specific session or pairing, though it never names those siblings 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 phrasing implies usage as a health/diagnostic probe, and the scope statement ('server status', 'authorities reachable') hints it is a starting point before session or pairing calls. However, it gives no explicit when-to-use or when-not-to-use guidance and does not route the agent to any alternative tool.

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