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

With no annotations supplied, the description carries the full behavioral burden and only partially meets it. It discloses that sign_in reuses configured Web secrets, which is useful auth context, but says nothing about session persistence, whether the browser is headless, side effects of click/fill/upload, download destinations, or what close does to state.

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 text is short and front-loads what the tool is before drilling into per-action parameter notes. The fragmentary sentence style ('For drag use value as target selector; for tab use its index') is dense but each clause maps to a real parameter, so little is wasted.

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?

This is a 13-action browser automation surface with five parameters, 0% schema description coverage, no annotations, and no output schema. A four-sentence blurb covering only a handful of actions and four of five parameters leaves an agent without enough to reliably invoke most of the enum values.

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 and it does for part of the surface: value means a path on navigate and a target selector on drag, tab takes an index, selector is a Playwright locator, and save_as applies to click downloads. However upload_files is never mentioned and several actions (fill, press, select, hover, screenshot) get no parameter mapping, so the compensation is incomplete.

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 identifies the tool as an 'Optional Chromium for browser-local UI' and names a couple of operations (navigate, snapshot), so the general domain is clear. But it never enumerates or characterizes the full action set (click, fill, press, select, hover, upload, close, screenshot, tab), leaving an agent to infer most capabilities from the enum.

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 on when to reach for this browser tool versus siblings like artex_call or artex_find_routes, and no stated preconditions such as needing an initialized session. The only hints are action-specific mechanics (value for navigate/drag, index for tab, save_as for downloads), which are parameter semantics rather than 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?

No annotations exist, so the description carries the full behavioral burden. It never states that this is a mutating call capable of DELETE/PUT, never mentions authentication requirements, error behavior, or what preview_chars and overwrite_local actually do. The ARTEX_TRANSFER_DIR note is the one piece of genuine operational context, which is not enough for a 9-parameter HTTP escape hatch.

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?

Four short sentences, front-loaded with the core action and with the escape hatches grouped afterwards. Dense without padding, though the telegraphic fragments ("for any full response use save_as") read slightly under-specified rather than crisp.

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 generic HTTP passthrough with 9 parameters, no annotations, and no output schema, the description covers the primary invocation path but omits response-shaping behavior (preview_chars truncation, save_as file writing, overwrite_local safety). An agent could call it, but not confidently predict side effects.

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 has to compensate and does so partially: it clarifies the path_params/query/body split, states that repeated query values take arrays, and explains that upload_files and save_as are alternatives to inline payloads. However preview_chars (default 6000) and overwrite_local are entirely unexplained despite being non-obvious knobs. Roughly half the parameter surface is left to guesswork.

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?

"Call an exact registered Web route template" gives a concrete verb and resource, and the follow-up sentences carve out what the call is not (multipart handling, streaming, full-response capture). An agent can distinguish this from artex_find_routes and artex_read_events. It stops short of 5 because the phrase "registered Web route template" is never tied explicitly to route discovery.

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 real routing work: streaming routes go to artex_read_events, multipart goes through upload_files, and full responses go to save_as. What is missing is the precondition that the route must first be located via artex_find_routes, and no guidance on when a non-HTTP sibling would be preferable.

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 full behavioral burden. It usefully hints that the change is non-persistent and that secrets must be updated separately, but omits whether authentication/privilege is required, whether existing sessions are invalidated, whether the change is reversible, and what happens on failure — all critical for a credential mutation.

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 tight sentences, front-loaded with the action, and the trailing clause about persistent secrets earns its place. The first sentence is slightly cryptic in its env-var reference, which keeps it from a 5.

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 credential-changing tool with no annotations, no output schema, and an undocumented confirm parameter, the description does too little — it leaves the source of the new password and the effect of confirmation ambiguous. It is adequate only in the narrow sense of naming the 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% for the single `confirm` boolean, and the description never mentions it. A confirm flag defaulting to false on a destructive credential change is exactly the parameter that needs explanation (does false mean no-op or a dry run?), and the description provides none.

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 gives a specific verb+resource ("Change the ARTEX password"), which is distinguishable from artex_login/artex_logout/artex_configure_basic_auth at a glance. However, it never clarifies what ARTEX_NEW_ADMIN_PASSWORD actually is (an environment variable? a config key?) or how that relates to the sole input parameter, so the mechanism stays murky.

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 clause "Update persistent secrets separately" acts as an implied exclusion — this tool only touches the live password, not stored secrets — which is genuine usage guidance. There is still no explicit statement of when to reach for this versus artex_configure_basic_auth or artex_initialize, and no prerequisites.

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 exist, so the description carries the full burden, and it discloses only that the new password is read from ARTEX_NEW_BASIC_PASSWORD or its _FILE variant. It says nothing about the confirm flag, whether the change is immediate or requires a restart, or the lockout risk of disabling the gate on a live server.

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 with the core action front-loaded and zero filler. Brevity is not the problem here; the missing content is, so a 4 rather than 5.

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?

This is a security-sensitive mutation with no annotations, no output schema, and zero percent parameter coverage, yet the description covers only the password source. An agent could not confidently set confirm, enabled, or username from this text 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%, so all four parameters (confirm, enabled, username, replace_password) are undocumented in the schema. The description explains the password's source but never connects it to replace_password, and leaves confirm, enabled, and username entirely 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?

"Change the built-in HTTP Basic gate" gives a verb and a resource, but "change" is ambiguous for a tool whose parameters cover enable/disable, username, and password replacement. It also fails to distinguish itself from the sibling artex_change_password, leaving the agent to guess which one touches the Basic-auth gate.

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 when-to-use guidance is given: nothing says whether this requires the server to be initialized, whether it takes effect live or after restart, or why one would pick this over artex_change_password or artex_login. The only hint at an alternative is the implicit env-var sourcing of the password.

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 and openWorldHint=false, so the safety profile is covered. The description adds the multi-term matching behavior ('Separate query terms with spaces, e.g. task control'), which is genuinely useful semantics, but says nothing about the result shape or how pagination behaves.

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 action and scope, followed by the one piece of syntax guidance that actually matters. Nothing is wasted or buried.

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 search tool with no output schema and zero schema coverage, the description covers search intent and query phrasing but leaves the method filter and pagination semantics undefined. Adequate to invoke, not adequate to invoke precisely.

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 all four parameters (query, method, limit, offset) rely entirely on the description. The description explains query term syntax and hints at the searched fields, but never mentions method, limit, or offset — an agent must guess that method filters by HTTP verb and that limit/offset paginate.

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 verb (Search) and resource (Web operations/routes) and even lists the searchable fields: path, handler, notes. That is enough for an agent to recognize the tool, though no sibling is named or contrasted (siblings are auth/status/browser tools, so no direct overlap exists).

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?

Use is implied by 'Search Web operations by path, handler or notes' — an agent can infer this is the lookup tool for routes. There is no explicit when-not guidance, no mention of an alternative, and no statement about whether this is the only way to inspect routes.

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 supplied, so the description carries the full behavioral burden. It helpfully discloses that the password comes from configuration (not a parameter) and that the call establishes a signed-in session, plus that confirmation is mandatory. It omits what happens on a system that is already initialized, whether the operation is idempotent or destructive to existing credentials, and what a confirm=false call does.

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 with the primary action front-loaded and the safety requirement second. Every clause carries information; there is no filler or restatement of the title.

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-shot bootstrap operation that creates an admin credential and changes session state, the definition covers the core action and the confirmation requirement. With no output schema and no annotations, it should still address the already-initialized case and the resulting auth state, which it does only partially via 'and sign in'.

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% for the single 'confirm' parameter, so the description must compensate. 'Explicit confirmation required' does point at the confirm flag and signals it is not optional in practice despite defaulting to false, but it never explains what the flag gates or what a rejected confirmation looks like.

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 gives a specific verb+resource: 'Set the first ARTEX administrator password' and adds the side effect 'and sign in'. The word 'first' implicitly separates it from artex_change_password and artex_login, though no sibling is named explicitly. An agent can identify the operation, but the differentiation is inferred rather than stated.

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?

'First ... password' implies a one-time bootstrap context, which is useful, but the description never states the condition for use versus artex_login or artex_change_password. It also does not say what to do if the system is already initialized. Usage is implied, not specified.

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 adds meaningful behavior by noting that credentials come from server-side configuration and the JWT stays inside the MCP process. However, it omits token lifetime, overwrite behavior, and failure outcomes, leaving gaps for an authentication 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?

A single sentence conveys the core action and two key behavioral points with no wasted wording. The credential source and token handling are front-loaded and easy to scan.

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 login tool without annotations or an output schema, the description explains where secrets come from and how the JWT is stored. It still leaves the agent without explicit invocation context, success signaling, or token-expiry details, so it is 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 tool has zero parameters, so there is no parameter semantics burden beyond the schema. The description correctly avoids restating an empty input schema and focuses on the authentication behavior instead.

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, 'Sign in', and clarifies the authentication resource, making the tool's action clear. It distinguishes itself from mutation siblings like artex_change_password and artex_logout, but does not explicitly contrast with artex_initialize or artex_configure_basic_auth.

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 this tool is used for authentication, but it does not explicitly state when to call it versus alternatives or whether it should be invoked before other tools. Usage is inferable from the login context rather than spelled out.

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 does add one genuinely useful fact — the scope is this MCP process only, not a global or server-side revocation — but it omits whether the server session is invalidated, whether the call is idempotent, and what happens if no session is active.

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 the scope qualifier in the right place and no filler. 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?

The tool is simple (no params, no output schema), so the description is roughly proportionate. However, with zero annotations the description is the only source of behavioral information, and it does not cover failure modes or what clearing entails on the server side.

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 beyond the schema's empty object. Baseline applies.

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 ('clear ... Web session and cookies') and scopes it to 'this MCP process', which differentiates it from a server-wide logout. It stops short of naming artex_login as the counterpart operation, so sibling differentiation is only implicit.

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 inferable from the name and the login sibling in the tool list, but the description never states when to call it, when not to, or that artex_login is the way back in. No explicit guidance on calling it when no session exists.

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 and openWorldHint=true, so the safety profile is covered. The description adds that it returns event IDs and a log since a cursor when available, but it does not explain blocking behavior, SSE streaming semantics, or how the bounded window behaves.

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 compact sentences with the core purpose front-loaded and no filler. However, the terseness leaves no structure for the complex seven-parameter surface.

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 high complexity: seven parameters, no schema descriptions, and no output schema. The description states a minimal purpose and return hint but omits essential details about route construction, cursor semantics, window sizing, and preview limits, making it inadequate for reliable 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?

There are seven parameters with 0% schema description coverage, so the description must carry the burden of explaining them. It only hints at a cursor and a bounded window, without naming required 'route', 'query', 'path_params', 'seconds', 'max_events', 'last_event_id', or 'event_preview_chars' or explaining their formats.

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 gives a specific verb, 'Read', and a bounded resource, 'ARTEX SSE', so the agent can identify this as an event-reading tool. It does not explicitly distinguish itself from siblings such as artex_call or artex_status, but the purpose 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?

The description says it reads a bounded window of SSE and mentions cursor availability, but it does not say when to use this instead of related tools like artex_call. There are no exclusions, prerequisites, or alternative-selection 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is partially covered. The description adds useful behavioral context beyond that: it says the tool uses configured Basic credentials if challenged, which is relevant for an open-world status check.

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 with the primary purpose front-loaded. The second sentence adds relevant authentication behavior without unnecessary wording.

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 no-parameter status tool, the description is largely complete: it states what is checked and how authentication is handled. It does not define what 'setup state' includes or what the response looks like, but no output schema is supplied and the core calling information is present.

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 to explain. The baseline for no-parameter tools is 4, and the description does not need to compensate for schema gaps.

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 and object: 'Check Web access and setup state.' This is clear enough for an agent to understand the tool as a status/diagnostic probe, but it does not explicitly distinguish it from sibling tools such as artex_login or artex_initialize.

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 a diagnostic use case for checking connectivity and setup state, but it does not state when to prefer artex_status over alternatives like artex_login, artex_initialize, or artex_configure_basic_auth. The usage is inferable rather than explicitly guided.

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