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

With no annotations, the description carries the burden and does disclose a genuinely non-obvious behavior: the conditional return of 'pin_required' and the handoff to submit_pin. It omits auth/permission requirements, credential handling, and failure behavior, so it is strong but not exhaustive.

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 tight sentences with the core purpose front-loaded, followed by the prerequisite and the pin-flow contingency. No filler; each sentence adds an actionable fact.

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?

An output schema exists, so return-value detail is not strictly required, yet the description still flags the important 'pin_required' branch. Purpose, prerequisite, and follow-up are covered; the undocumented 'lang' parameter is the main 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?

Schema description coverage is 0%, so the description should compensate. It adds real meaning for 'login' ('login starts with 4'), but says nothing about 'password' or the 'lang' parameter, leaving two of three parameters undocumented in both schema and 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?

States a specific verb (Create) and resource (personal webQUIK session) scoped to this MCP connection. It is easily distinguished from siblings like logout and session_status, and the phrase 'personal... for this MCP connection' signals per-connection session semantics.

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?

'Required before any trading or market-data tools' gives an explicit prerequisite and effectively tells the agent when this tool must be called versus skipped. It also names the follow-up alternative ('then call submit_pin'), routing the agent through the SMS flow.

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 behavioral burden. It does disclose the meaningful consequence that this connection's session is removed, implying subsequent authenticated calls will fail, but it omits whether re-authentication is required afterward and what happens to any server-side state or open orders.

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 tight sentence with no waste, front-loading the action and following with the session-removal consequence. Nothing could be cut without losing 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-parameter tool with an output schema (so return values need no explanation), the description covers the essential action and its session-destroying effect. The only real gap is the lack of guidance on prerequisites or post-logout state, which is minor at this complexity level.

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; the baseline for a parameterless tool 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+resource ("Logout from webQUIK") plus a concrete scope detail ("remove this MCP connection's session"). It is clearly distinguishable from siblings like login, submit_pin, and session_status, though it does not explicitly name any of 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 only implied by the verb and the mention of removing the session; there is no explicit when-to-use statement, no note about prerequisites (must be logged in), and no references to alternative siblings such as session_status for checking state before logging 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 disclosure burden. The verb "Return" implies a non-mutating read, which is useful, but nothing is said about whether authentication is required, what session states are possible, or side effects. An output schema exists, which absorbs the return-value burden and keeps this at a middle score rather than lower.

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 short sentence that leads with the action and the scoped resource. Every word earns its place and there is no filler or repetition of the tool 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 zero-parameter, output-schema-backed status tool the description covers what is needed to call it correctly; the return shape is already defined elsewhere. Its only shortfall is the absence of usage context, which is a minor gap given the tool's simplicity.

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 per the baseline there is nothing for the description to clarify beyond the schema. No meaningful gap exists on this dimension.

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 (Return) and resource (this MCP connection's webQUIK session state), which is unambiguous about what comes back. It does not explicitly distinguish itself from session-oriented siblings like login, logout, or submit_pin, but the resource it names is distinct enough that an agent can place it without opening the schema.

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

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

The description offers no when-to-use guidance whatsoever — no mention of checking state before/after login, no conditions, no prerequisites, and no alternative tools named. An agent must infer from the name alone that this is a diagnostic/health-check call.

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, so the description carries the behavioral burden. It discloses the two-step auth context (SMS code issued by login), which is useful. However, it says nothing about failure behavior, attempt limits/lockout, or whether the session becomes authenticated — meaningful gaps for an auth-credential submission 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 zero waste; the trigger condition follows immediately. Nothing redundant.

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?

An output schema exists, so return values need not be explained, and the trigger is clear. Still, for an auth-credential tool with no annotations, the description omits failure/lockout behavior and any post-submit state change.

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?

One parameter with 0% schema description coverage, so the schema adds no meaning. The description compensates partially by clarifying the value is an SMS-delivered PIN code, but gives no format, length, or digit constraints.

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+resource ('Submit SMS/PIN code') and ties it to the login handshake, making it clearly distinct from siblings like login/logout/session_status. It doesn't explicitly name an alternative tool, but the purpose is 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?

Gives an explicit trigger condition: use it only after login has returned pin_required. That is real when-to-use guidance for a second-factor step. It stops short of stating what to do if the PIN fails or how many attempts are allowed.

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 behavioral burden. It mentions 'active order', implying only active orders can be cancelled, but it omits critical traits for a destructive mutation: authentication requirements, irreversibility, failure behavior, and confirmation needs.

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 definition is a single, front-loaded sentence with zero redundant words. Every part of the sentence contributes directly to the purpose.

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?

An output schema exists, so return values need not be described. However, given the mutation nature and lack of annotations, the description is too sparse: it does not cover prerequisites, safety, or how 'active' is determined, leaving significant operational gaps.

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 ('order number' and 'class code') but provides no format, validation, or meaning beyond the parameter names already in the 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?

The description states a specific verb and resource: cancel an active order. It is clearly distinct from sibling tools like send_order and get_orders, but it does not explicitly name or differentiate siblings in the text.

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 purpose: call this tool when you need to cancel an active order. However, no explicit when-to-use, when-not-to-use, or alternative tool guidance is provided.

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, and it supplies almost none: no mention of auth/session requirements, no indication of whether values are real-time or cached, and no clarification of what "depo" limits represent. The presence of an output schema covers return shape but not these traits.

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 short sentence with the resource front-loaded and no filler. It is efficient, though its terseness leaves useful context out rather than being padded.

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 zero-parameter read with an output schema documenting the return values, the description is minimally sufficient. However, with no annotations and no auth or freshness context, an agent lacks information needed to invoke it confidently in a trading session.

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 for a parameterless tool applies. No parameter semantics are needed or missing.

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 clear verb ("Return") and names the specific resource ("cash and depo limits"), which distinguishes it from sibling reads like webquik_get_portfolio or webquik_get_orders. It stops short of explicitly contrasting itself with those siblings, and "depo" is unexplained jargon.

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 call this versus webquik_get_portfolio or other account-state reads, and no prerequisites (e.g., that a session/login is required) are stated. The agent must infer usage entirely.

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. The phrase 'Subscribe to' implies a streaming/long-poll behavior, but the description doesn't explain what that means operationally—whether a connection stays open, how to unsubscribe, or what happens to the returned orders. This is a significant gap for a tool with unclear I/O semantics.

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 short sentence with no wasted words, but it is under-specified rather than concise. It front-loads a compound action without clarifying which behavior actually occurs, so brevity here trades off against clarity.

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?

An output schema exists, so return-value structure need not be described. However, with no annotations, one undocumented parameter, and an ambiguous 'subscribe' semantic, the description is too thin. It omits authentication context and the streaming vs. snapshot distinction, which are critical 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% for the single boolean parameter include_stop_orders, which has a default of true. The description does not mention stop orders at all, so it fails to compensate for the schema's lack of a description. However, with only one optional parameter, the baseline is partial; a 3 reflects that the schema title at least hints at the parameter's purpose.

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 says 'Subscribe to and return active orders,' which is a partial tautology of the tool name and mixes two distinct behaviors (subscribing to a stream vs. returning a snapshot) without explaining which the tool actually does. It doesn't clarify how this differs from sibling order tools like webquik_cancel_order or webquik_send_order, or whether it returns trades vs. orders.

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 use this tool versus alternatives like webquik_get_trades or webquik_get_portfolio, nor any mention of prerequisites such as authentication state after login. The agent is left to infer the context entirely.

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 behavioral burden. The word 'subscribe' hints at a streaming/ongoing-update semantic rather than a one-shot read, but the description never explains whether the subscription persists, how updates are delivered, or what (if any) permissions are required. That ambiguity is significant for an agent deciding whether to call this repeatedly.

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 efficient sentence with the action front-loaded and zero filler. It is appropriately sized for a zero-parameter call, though it is arguably too terse given the unexplained subscription behavior.

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?

An output schema exists, so return values need not be described. However, because the description introduces a non-obvious 'subscribe' behavior without explaining it, and gives no usage context relative to five closely related account-data siblings, it is only minimally complete for the agent's decision-making needs.

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 for a parameterless tool is 4. The description correctly implies no input 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?

States a specific verb pair (subscribe to and return) and a specific resource (client portfolio positions), so the agent knows exactly what it retrieves. It does not, however, distinguish itself from neighbors like webquik_get_orders, webquik_get_trades, or webquik_get_limits, which all return client-scoped data.

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 when-to-use guidance, no indication of how this differs from the other account-data tools in the sibling list, and no stated prerequisites (e.g., must be logged in, session must be active). The only routing signal is the word 'portfolio' in the name itself.

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 behavioral burden. 'Get' implies a read-only operation, but there is no disclosure of auth requirements, rate limits, snapshot-vs-streaming semantics, or what happens when depth exceeds available levels.

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 efficient sentence with the core action front-loaded and the example placed inline where it is most useful. Nothing is wasted, though the brevity leaves gaps elsewhere.

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?

An output schema exists, so return values need not be described, but for a tool with zero annotation coverage and zero schema description coverage the description leaves 'depth' entirely undocumented and says nothing about read-only safety or error conditions.

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 illustrates class_code and sec_code with concrete example values, which adds some meaning, but the 'depth' parameter is never mentioned and no units, limits, or defaults are explained.

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+resource: 'Get order book quotes for an instrument', and the parenthetical example with class_code=TQBR, sec_code=SBER makes the target unambiguous. It does not differentiate from nearby siblings like webquik_get_security_info or webquik_get_trades, so it stops short of a 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?

There is no when-to-use guidance, no exclusions, and no mention of alternative tools (e.g. get_security_info) that an agent might confuse with this one. The example clarifies input format but not tool selection.

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 disclosure burden, and it delivers almost nothing: it never states that this is a read-only lookup, whether it hits the network, or how 'static' parameters differ from live quote data. The only hint is the word 'static', which is not explained.

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 short sentence, front-loaded with the verb and resource, with no filler. It is efficient, though its brevity is partly the cause of the missing parameter and usage 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?

An output schema exists, so return values need not be described, but the definition still omits parameter meaning, read-only behavior, and any routing versus sibling tools. For a two-required-parameter tool with zero schema coverage, this leaves the agent under-equipped.

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 mentions no parameters at all, leaving class_code and sec_code completely undocumented in both places. For a tool that cannot be invoked without a class/security pair, that is a real gap rather than a schema-does-the-work situation.

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 ('Get') and resource ('static parameters for a security') and gives concrete examples (lot size, price step), so the agent knows exactly what data comes back. It does not, however, distinguish itself from the sibling webquik_search_securities, which an agent might reach for instead.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as webquik_search_securities or webquik_get_quotes. The agent must infer the retrieval workflow entirely from the name.

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, and it discloses almost nothing: the word "subscribe" hints at persistent server-side state but never explains whether a subscription is created, how it is torn down, its lifetime, or whether it pushes updates. For a tool whose name suggests streaming, this ambiguity is material.

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 short sentence with no filler, and the resource is front-loaded. It is arguably too terse for the behavioral ambiguity it leaves unresolved, but there is no wasted text.

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?

An output schema exists, so return values need not be described. However, the core behavioral question raised by "subscribe" — is this a stream, a snapshot, or a stateful registration — is left unanswered with no annotations to fall back on, leaving the definition 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 takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to add or omit on this dimension.

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?

"Subscribe to and return recent trades" names a resource (trades) but the verb is ambiguous: it is unclear whether this is a one-shot fetch of recent trades or a persistent streaming subscription. It does not distinguish itself from siblings like webquik_get_orders or webquik_get_quotes beyond the noun.

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 use this versus webquik_get_orders, webquik_get_portfolio, or webquik_get_quotes, all of which live in the same data-retrieval family. An agent gets no trigger condition or exclusion criteria.

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 authentication prerequisite ('after login'), which is useful behavioral context, but says nothing about read-only nature, rate limits, or side effects. The output schema covers return values, so that omission is acceptable, but the disclosure is thin overall.

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 no wasted words, front-loading the action and including a helpful example inline. It is appropriately sized for a simple list operation.

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 list tool with an output schema, the description supplies the essential auth prerequisite and an example. It does not mention pagination or result ordering, but the output schema presumably covers return structure, so the description is nearly 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 tool has zero parameters, so there is no parameter semantics to convey. Per the rubric, zero parameters yields a baseline of 4.

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 ('List') and resource ('instrument classes'), with a concrete example ('TQBR for MOEX equities') that clarifies scope. It does not explicitly name or distinguish itself from sibling tools, but the resource is unique among them, so an agent can tell it apart.

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 'available after login' implies a prerequisite and therefore some usage context, but it does not state when to choose this tool over alternatives or when not to use it. Usage is only implied, 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, the description carries the full burden, and it does disclose one real behavioral constraint: the search only covers already-loaded class lists. That is genuine added context, but it omits read-only nature, whether limit caps results, and any pagination 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?

A single front-loaded sentence with zero filler, which is efficient. It is arguably under-specified rather than over-long, so it earns credit for structure while falling short on completeness.

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?

An output schema exists, so return values need not be explained, and the tool is conceptually simple. Still, with no annotations and 0% parameter description coverage, the definition leaves the class-list dependency and the role of class_code/limit unclear 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%, so the description must compensate. It clarifies that 'query' matches ticker or name, but says nothing about 'class_code' (apparently scoping to a class) or 'limit' (default 30, presumably a result cap), leaving two of three parameters undocumented anywhere.

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 (search) and resource (securities) plus the search key (ticker or name), which lets an agent distinguish it from webquik_get_security_info (single-security detail) and webquik_list_classes (class enumeration). It does not explicitly name those siblings, so differentiation is implied 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?

There is no explicit when-to-use or when-not-to-use guidance and no alternative named. The phrase 'within loaded class lists' hints at a precondition, but the agent is left to infer that webquik_list_classes may need to run first and that webquik_get_security_info is the follow-up for details.

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 behavioral burden for a real-money exchange mutation. It never states that this executes a live MOEX trade, that it is irreversible, that a session/authentication is required, or what happens when price is left at its default of 0 with order_type=market.

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 action is stated first, followed by a compact field legend with no filler. It is terse rather than bloated, though the legend reads more like schema documentation than guidance.

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?

An output schema exists, so return values need not be explained. But for a 5-required-parameter trading mutation with no annotations, the description omits authentication prerequisites, order lifecycle context, and four parameters' semantics, leaving an agent without enough context to call it safely.

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, so the description must compensate; it defines side (buy|sell), order_type (limit|market), account format, and client_code, which is genuinely useful since the schema declares no enums. However, it omits sec_code, class_code, quantity, and the price/order_type interaction (price defaults to 0), leaving half the parameters 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 and resource ('Place a new order on MOEX via webQUIK'), which is clearly distinct from sibling read tools like webquik_get_orders and from webquik_cancel_order. It does not explicitly name the alternative to use for modifying or cancelling, but the action itself is 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 gives no conditions for when to use this tool versus alternatives, no prerequisites (login/submit_pin/session_status siblings suggest a session is required), and no note that it is the only way to open a position versus cancelling an existing one. Usage is only implied by the verb 'Place'.

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