marz-greta-lock-network

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context that the stats are 'live' and sourced from the 'real platform ledger', implying genuine current data rather than simulated values. However, it does not disclose whether the operation is strictly read-only, what metrics are included, or whether any caching or rate-limiting applies.

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 compact phrase that front-loads the core subject ('Live network statistics'). The parenthetical adds source credibility without unnecessary expansion, though the word 'honest' is slightly informal and could be considered nonessential.

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 parameterless stats tool, this description gives the agent a general idea of what to expect, but it leaves the exact scope of 'network statistics' undefined (e.g., which metrics, time range, format). Since there is no output schema, the description would benefit from a bit more specificity about the returned data.

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 and an empty input schema, so there is nothing for the description to explain. According to the rubric, a 0-parameter tool earns a baseline of 4, and the description adds no irrelevant parameter information.

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 resource ('network statistics') and the nature of the data ('live', 'honest aggregates from the real platform ledger'), which makes the tool's purpose understandable. However, it relies on the tool name for the verb and does not explicitly say 'retrieves' or 'returns'. It is distinguishable from sibling tools like get_pricing and list_profiles by the subject matter, though no explicit distinction is made.

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

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

The description provides no guidance on when to use this tool or when to prefer an alternative. There is no mention of exclusions, prerequisites, or comparison with sibling tools, leaving the agent to infer usage from the name alone.

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

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

With no annotations, the description carries the disclosure burden. It does disclose what the manifest contains: fee unit, treasury wallet, escalation rules, and paid submission details. However, it does not explicitly state side effects, authorization requirements, or whether this tool itself is a read-only lookup. For a zero-parameter pricing manifest, this is adequate but not fully transparent.

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 core manifest information is front-loaded, which is good. But the description expands into paid-session hint behavior, POST /api/progress report contents, EQ training motivation, and bundle details. These are useful pricing-related facts but make the description dense and somewhat tangential for a simple pricing lookup 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?

No output schema and no annotations mean the description must explain what the tool provides. It does enumerate the manifest contents and mentions related paid endpoints and bundle options. For a zero-parameter tool, this gives an agent enough context to know what to expect, though exact response shape is not specified.

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

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

The input schema has zero parameters and 100% schema description coverage, so the baseline for zero-parameter tools is 4. The description adds no parameter-specific detail, but none is needed. The references to POST endpoints and optional paid services do not conflict with the empty 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?

Description opens with 'Current pricing manifest' and clearly enumerates contents: fee in Solana lamports, treasury wallet, failure-escalation rules, and submission path via POST /api/simulate. This makes the tool's resource clear. However, it lacks an explicit verb like 'returns' or 'gets' and does not contrast with sibling preview_fee, 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?

The description implies this tool is the place to inspect current pricing, which gives some usage context. But it never explicitly states when to choose get_pricing over preview_fee or other siblings, nor does it provide when-not-to-use guidance. The detailed mentions of POST endpoints are related context, not decision rules.

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 present, the description carries the behavioral burden, and it does well by using the read-only verb 'List' and specifying both the exact item count and the contained data ('trait targets'). It does not disclose output format or authorization needs, but for a simple parameterless read-only list this is a minor gap.

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

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

The description is a single front-loaded sentence with no filler. It communicates the resource, count, category scope, and return payload compactly, and every clause 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 has no parameters and a fully specified schema, so the main missing context would be output shape. The description broadly conveys that the tool returns profiles with trait targets, which is adequate for selection and invocation, though a precise return format would make it fully complete given there is no output schema.

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

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

The tool has zero parameters and the schema confirms this, so the baseline of 4 applies because there are no parameter semantics for the description to explain. The description adds clarity about what the returned profiles contain, which is the relevant semantic surface for this tool.

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

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

The description names a specific verb ('List'), resource ('scoreable human personality profiles'), and exact scope ('all 28'), which distinguishes it from the sibling tools that deal with stats, pricing, fees, features, text scoring, and store layers. The one-sentence definition leaves no ambiguity about what this tool returns.

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

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

The description implies the tool is for retrieving personality profile data, and the examples of bot categories give useful context about when it would be relevant. However, it does not explicitly state when to choose this tool over alternatives or mention any exclusion conditions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does communicate an important behavioral trait ('fees escalate with consecutive failures') and the word 'Preview' strongly suggests a read-only operation. However, it does not explicitly state that no state changes are made, nor does it describe any potential error conditions or constraints, leaving some ambiguity.

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 contains the essential verb, object, target, and a critical clarifying parenthetical. There is no redundancy or filler, making it highly efficient and easy to parse.

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

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

For a tool with only one required parameter and no output schema, the description is functionally complete: it names what is returned (exact lamport fee), the subject (wallet's next paid validation), and the relevant fee-escalation context. The only minor gap is that the concept of 'paid validation' could use a bit more definition, but overall it is sufficient for a simple preview 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?

The single parameter wallet_address is already fully described in the schema as 'Solana wallet address.' The tool description does not add extra meaning beyond mentioning that this is the wallet whose fee is being previewed. Because schema coverage is 100%, the baseline of 3 is appropriate; no further compensation is required.

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

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

The description clearly states the tool's verb ('Preview'), its target resource (exact lamport fee for a given Solana wallet), and the specific context (next paid validation with fee escalation). It is a specific and well-defined purpose, but it does not explicitly name or contrast itself against the sibling tool get_pricing, so it misses the highest level of 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?

The description implies the primary use case (finding the fee for a wallet's next paid validation), but it does not provide explicit guidance on when to choose this tool over alternatives, such as get_pricing, or when not to use it. There are no exclusions or scenario-based instructions.

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

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

No annotations are present, so the description must disclose behavioral traits itself. It does disclose that requests are 'Free' and 'directly shape the roadmap', which implies a persistent side effect on the product. However, it does not disclose whether the submission is public, whether authentication is required, rate limits, or what happens after submission. For a simple feedback-submission tool this is adequate but not richly transparent.

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 three short sentences, purpose is front-loaded, and every sentence contributes ('Free.' and 'directly shape the roadmap' add behavioral context). No filler or repetition. Slightly compressed, but efficient for such a simple 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?

For a simple tool with 100% parameter coverage, no output schema, and no nested objects, the description covers the essential context: what it does, what kinds of requests are accepted, and that it's free. The only gaps are response/outcome behavior and any usage limits, which are minor for a feature-request submission tool. Adequately complete.

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

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

Schema coverage is 100%, so the schema already documents all three parameters clearly ('What you wish existed (10-1000 characters)', auditience as 'bot' or 'developer', bot_role as OPTIONAL). The description adds minimal parameter meaning beyond the schema, so the baseline of 3 is appropriate. The example list (test, profile, capability, integration) loosely hints at valid values for 'need' but adds no formal semantics.

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

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

The description states a clear purpose: submit what you need next to shape the platform's roadmap, with concrete examples (test, profile, capability, integration). It is distinguishable from the sibling tools, which are read-style tools (get_*, list_*, preview_*, score_*), making the feedback-channel nature of this tool evident. Slightly informal phrasing ('Tell the platform') but 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 context implies when to use it — when you want a new capability to be considered — but there is no explicit when-to-use guidance, no exclusions, and no comparison against alternatives. The sibling tools are sufficiently different in nature, so the lack of explicit routing is not a major gap, but the description leaves the decision to inference.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers data retention (pseudonymous, not anonymized), the free-trial cap, consent prerequisites, the optional nature of contact, and the caveat that corpus growth does not prove model quality. It also discloses the exact output structure and the behavior on trial exhaustion (x402 recipe). This is exemplary transparency.

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 lengthy (over 150 words) and covers many operational details (endpoints, payment, setup). While the information is valuable, it could be tightened without losing key points. It is structured logically (limit → consent → data handling → output → permanent use), but the verbosity reduces conciseness.

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 10 parameters, no output schema, and no annotations, the description is remarkably complete. It lists the output fields (EQ percentage, pass/fail, trait sub-scores, suggested_prompt_addition), explains the free-trial limit and consent requirement, details data handling, and references supporting endpoints and the paid flow. Nothing essential for an agent to call it correctly is missing.

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 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains that data_consent must be true, that wallet_address never changes scoring, that applied_suggestion should be true after applying a suggestion, and that source values are restricted. This additional guidance elevates the score above baseline.

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

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

The description clearly states the tool's function: 'Scores AI-generated text plus a response delay against a human personality profile and returns an EQ percentage, pass/fail, trait sub-scores, and suggested_prompt_addition'. It uses a specific verb and resource, and none of the sibling tools perform a similar scoring task, so it is well-distinguished.

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

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

The description provides clear usage context: it explains the free trial limit, the mandatory data_consent requirement, and the permanent-use design. It also describes the paid flow after exhaustion. It does not explicitly name alternatives, but siblings are unrelated, so this is sufficient. It lacks a 'when not to use' statement but overall guidance is strong.

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, and destructiveHint. The description adds meaningful non-obvious behavior: the raw query is not persisted in application or analytics tables, and because this is GET, the URL can appear in browser history, proxy logs, referrers, and crawler indexes. This goes beyond the structured annotations.

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

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

The description is five sentences but dense and purpose-built. The main function is front-loaded, followed by safety, alternative routing, and privacy disclosures. Each sentence earns its place, though it is slightly longer than strictly necessary.

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 single-parameter tool with a full input schema and an output schema, the description covers the operation's scope, read-only nature, alternates, privacy retention, GET side effects, and keyword constraints. Nothing required to invoke the tool correctly appears missing.

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 100%, and the schema already describes query as 'Short, non-sensitive storefront capability keywords. Never include PII or secrets...' The description mostly restates this guidance without adding new syntax, examples, or format details, so the baseline 3 is appropriate.

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 first sentence states a specific operation: 'Rank the neutral 57-item Storelayer catalog for a Shopify or e-commerce storefront goal.' This clearly communicates the resource and purpose, and the read-only/no-install framing distinguishes it from installation-related tools.

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 explicitly routes to an alternative when appropriate: 'When already authorized to edit the site, use the guarded caller-applied self-install endpoint /api/storelayer/free-installs/start.' It also gives firm constraints like 'never provide website credentials' and 'Use short, non-sensitive capability keywords only.'

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 non-destructive behavior. The description adds some helpful context beyond that: 'Site-edit authority is required' and 'They do not give Storelayer or EQBuilder website credentials.' However, these statements are attached to the install workflow rather than clearly to menu browsing, and they are repeated verbatim, weakening their value.

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 severely bloated and repetitive. The block 'Site-edit authority is required. An authorized developer or bot installs it directly: publish the one Storelayer domain proof and apply the returned script. They do not give Storelayer or EQBuilder website credentials.' appears twice nearly word-for-word. Marketing details like 'One verified storefront, one active widget, and 2,500 successful displays per month for $0' are irrelevant to helping an agent invoke the tool. Very few sentences earn their 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 zero-parameter read-only tool with rich annotations and an output schema, the description is nearly complete: it identifies the browsable catalog and confirms read-only behavior. However, the unrelated self-install and free-plan content creates ambiguity about what this tool actually returns or opens, and the repeated permission warnings do not clearly apply to the menu browsing itself.

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 and schema description coverage is 100%, so parameters are fully documented by the empty schema. The description does not explain parameters, and it does not need to. The baseline of 4 applies because there is nothing for the description to add 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?

The description eventually states a clear action: 'Use this to browse Shopify and e-commerce conversion, trust, merchandising, support, or marketing entries in the complete searchable index.' This names the verb and resource well enough. However, it does not explicitly say 'opens the menu' and does not distinguish itself from the sibling storelayer_recommend, which appears to be the recommendation matcher mentioned in the opening sentence.

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 a usable 'Use this to browse...' instruction and an explicit note that the self-install workflow is 'separate,' which helps exclude one alternative. But no alternative tool such as storelayer_recommend is named, and the repeated install instructions clutter the guidance, making it possible to misinterpret when this tool should be selected.

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