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

With no annotations, the description carries the full load, and it does disclose the meaningful behavioral trait that extraction is regex-based rather than model-based, implying pattern-bound recall and possible misses. It does not state whether missing param defaults are applied, how no-match cases behave, or that the operation is a pure read of supplied text. An output schema exists, so return shape need not be covered.

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

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

One sentence, front-loaded with the action and finished with the decisive constraint. No filler, no repetition of the tool name.

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 two-parameter tool with an output schema, the definition covers what is extracted, by what mechanism, and the allowed kinds. The only shortfall is the absence of guidance on the text input's expected scope or size, which is minor 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?

Schema description coverage is 0% and the schema declares no enum for kind, so the description's inline enumeration {emails, urls, phones, numbers} is the only source of valid values — real added meaning. The text parameter is left unexplained, though its purpose is largely self-evident from the name and the required flag.

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 (Extract) and resource (entities) and closes with the four supported kinds, which distinguishes it from siblings like ai_keywords or ai_sentiment. It stops short of stating scope or exclusions (e.g., single text vs. bulk), so it is clear but not fully discriminating.

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: the kind enumeration hints that you call this when you want patterned entities rather than semantic keywords, but the description never says when to prefer it over ai_keywords or when not to use it. No prerequisites or exclusions are given.

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, and it does disclose one meaningful trait: stopwords for Spanish and English are removed, implying language handling. It says nothing about tokenization, case folding, minimum word length, or ranking ties.

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 operation and with zero filler. Its brevity is efficient rather than padded, though it borders on under-specification for a tool with undocumented parameters.

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 and an output schema exists, so return values need not be explained. However, with no annotations and no parameter documentation, an agent still lacks the detail needed to predict the 'top' argument's effect or the stopword language selection behavior.

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

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

Schema description coverage is 0%, so the two parameters are undocumented in structured data, and the description does not compensate. 'Top' (count of keywords, default 10) and 'text' are never explained beyond the loose implication of 'top keywords by frequency'.

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 operation (extract top keywords ranked by frequency) on a specific resource (text), which is clear enough to distinguish it from general frequency counting. It does not explicitly contrast itself with siblings like analysis_frequency or ai_text_stats, 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 guidance on when to use this instead of analysis_frequency, ai_text_stats, or ai_extract, all of which plausibly overlap. The agent must infer the choice from names 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 at all, the description carries the full burden. It does disclose the method (lexicon-based, implying deterministic rather than ML scoring) and the output range/label, which is meaningful context, but says nothing about accuracy limits, language detection failure, text length limits, or determinism guarantees.

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 core capability and method, with the return contract second. 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?

An output schema exists, so return values needn't be re-explained, and the description sensibly summarizes them anyway. However, for a tool with zero annotation coverage and an undocumented parameter, it omits behavioral edge cases (language fallback, empty/very long text) that an agent would need before calling it confidently.

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 is one parameter with 0% schema description coverage, so the schema adds no meaning. The description implies the parameter is the text to score but never states length limits, encoding, or how language is determined, leaving the sole parameter under-specified.

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 operation and resource ('lexicon-based sentiment ... text') and constrains the input domain to Spanish/English. It is clearly distinguishable from siblings like ai_text_stats or ai_keywords, though it never explicitly contrasts itself with 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: an agent can infer this is the tool for sentiment scoring, but there is no statement of when to prefer it, no exclusions, and no mention of what happens with other languages or mixed-language input.

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

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

With no annotations, the description carries the behavioral burden, and it does disclose the key output traits (ASCII-only, hyphen-separated) that go beyond the tool name. It does not say how non-ASCII characters, casing, or punctuation are handled, nor whether stripping can yield an empty slug.

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 that states the action and the output format with no filler. 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?

For a one-parameter utility with an output schema present, the description covers what the tool produces and the slug's format. The only meaningful gap is edge-case behavior on unicode/empty results.

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 only source of parameter meaning is the word 'text' in the description, which merely echoes the parameter name. The single parameter is self-explanatory, so this is adequate but adds no real semantics beyond 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 gives a specific verb ('Convert') and resource ('text'), plus the output form ('URL-friendly slug, ASCII, hyphen-separated'). It is unmistakable against siblings like ai_text_stats or ai_keywords, though it doesn't explicitly name a differentiator.

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, but for a single-purpose transformation utility the applicability is strongly implied by the phrase 'URL-friendly slug'. No alternatives or exclusion conditions are stated.

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

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

With no annotations supplied, the description carries the full behavioral burden and does meaningful work: it discloses the algorithm family (extractive, word-frequency), the language restriction (ES/EN stopwords — a real limitation for other languages), order preservation, and a hard output cap of 10 sentences. It does not address determinism, performance on long inputs, or failure/empty-result behavior, which keeps it below a 5.

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

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

Two short sentences, zero filler, with the method and output-cap constraint front-loaded so the most decision-relevant information arrives first.

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 (2 params, non-nested, read-only analysis) and an output schema exists, so return values need not be explained. The description covers method, ordering, language support and length bounds, which is close to complete; the remaining gap is explicit sibling routing, which for a summarizer is a minor omission.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the ES/EN language constraint (relevant to the 'text' parameter) and the 'Max 10 sentences' bound, which maps to max_sentences. But the bound is ambiguous: it is unclear whether 10 is a hard cap enforced by the tool or a description of typical output, and the default of 3 and the effect of low values are never mentioned.

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 combination ('Extractive summary') and immediately qualifies it with the algorithm used ('word-frequency scoring') and the output invariant ('keeping original order'). This clearly separates it from siblings such as ai_keywords, ai_extract or ai_sentiment, which operate on the same text input but produce different artifacts.

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 name and the 'Extractive summary' framing, and the ES/EN stopword detail implies the input language constraint. However, there is no explicit 'use this when... instead of ai_extract/ai_keywords' guidance, and no statement of preconditions (minimum text length, language) that would let an agent route confidently.

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 computed metrics, which is the core behavior, and implies a side-effect-free computation. However it says nothing about input size limits, how reading time is derived (e.g. words-per-minute assumption), or language/markup handling.

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 fragment with zero filler; every item in the list conveys a distinct computed metric. It is a sentence fragment rather than a structured statement, but nothing 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?

An output schema exists, so return values need no explanation, and the tool is simple with one required parameter. Still, for a metric-computing tool the description leaves loose ends: reading-time methodology and input-size behavior are unstated, which an agent may need to interpret results.

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 single `text` parameter has no documentation anywhere. The description implies it is the text to analyze, but adds no detail on format, length constraints, or whether plain text versus markup is expected.

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?

"Text metrics" names the resource and the colon-list enumerates exactly what is computed (chars, words, unique words, sentences, paragraphs, reading time), so an agent knows the tool's output surface. It does not explicitly distinguish itself from text-adjacent siblings like analysis_stats or analysis_frequency, which keeps it from 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 mention of alternatives such as analysis_frequency (word frequency) or ai_summarize, and no stated preconditions. Usage is only inferable from the fact that a single text argument 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?

No annotations are provided, so the description carries the full burden. It discloses the output metrics but says nothing about preconditions (equal-length arrays, minimum sample size, numeric-only input), failure behavior on mismatched lengths, or that the operation is a stateless read with no side effects.

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?

It is a single short parenthetical fragment with zero padding and the key term front-loaded, which is good. But the brevity crosses into under-specification rather than efficiency, since nothing about inputs or usage survives the trim.

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 in depth (the parenthetical partly duplicates it anyway). Still, for a two-required-parameter statistical tool with no annotations and 0% parameter coverage, the definition leaves out the constraints and usage context an agent needs to call it correctly.

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

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

Schema description coverage is 0%: both required parameters are bare arrays titled only 'X' and 'Y' with no element semantics. The description does not compensate by explaining that x and y are paired numeric samples that must be the same length and non-constant, leaving real ambiguity for the caller.

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 the specific statistic (Pearson correlation) and lists the returned metrics (r, r², direction, strength), so the resource is identifiable. However it is a noun fragment with no verb, and it does not distinguish itself from siblings such as analysis_linear_regression or analysis_stats, which overlap in scope.

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

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

There is no when-to-use guidance at all: nothing says to pick this over analysis_linear_regression when you want relationship strength rather than a predictive model, nor over analysis_stats for a general summary. The agent must infer the choice from the tool name alone.

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

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

With no annotations, the description carries the full burden. It does disclose the core behavior — tallying items and returning a ranked subset — but says nothing about ordering guarantees, tie-breaking, case sensitivity, or how the result set is truncated. The presence of an output schema relieves it of describing the return shape.

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 eleven-word sentence with the operation front-loaded and no filler. It is efficient, though the terseness leaves '_item_' vague enough that it trades away some precision.

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

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

For a simple two-parameter tool with an output schema, the essentials are mostly covered, but the one non-obvious parameter (top) and questions like case sensitivity go unaddressed in both schema and description. Adequate, not 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 description coverage is 0%, so the description must compensate. 'Each item' loosely maps to the items array, but the top parameter (default 20) is never mentioned or explained — 'the most common ones' only hints at a limit without identifying it or its default.

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: 'Count occurrences of each item' and adds the output framing 'return the most common ones'. That distinguishes it from pure aggregators like analysis_stats. It does not name or contrast any sibling explicitly, which keeps it from 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 alternatives such as analysis_stats or ai_keywords for related text counting tasks. The usage is only implied by the verb 'count'.

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 does disclose the estimation method (least squares) and the named return fields, implying a pure computation with no side effects. It does not state input preconditions (equal-length arrays, minimum sample size) or error behavior on degenerate input, which are the realistic failure modes.

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 no waste, front-loading the model being fitted before the return values. 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?

An output schema exists, so restating return fields is not strictly needed, and the core operation is well conveyed for a simple two-parameter tool. The remaining gap is operational: no array-length or sample-size constraints, which is exactly what an agent needs to avoid a failed call.

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 neither parameter is documented, so the description must compensate. The equation 'y = slope·x + intercept' implies x is the independent variable and y the dependent one, which adds real meaning, but nothing is said about matching lengths or numeric-only contents.

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 an explicit verb and model ('Fit y = slope·x + intercept by least squares') plus the returned quantities, so an agent knows exactly what computation happens. It does not mention the sibling analysis_correlation or state how this differs from it, leaving differentiation 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?

There is no when-to-use guidance, no mention of alternatives such as analysis_correlation for association-only questions, and no prerequisites. The only usage signal is the implicit math, which the agent must infer.

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 deliver on the most important traits: "Safely" plus "No code execution" asserts a sandboxed, side-effect-free evaluation rather than arbitrary code. It does not cover error behavior (malformed expressions, division by zero) or numeric precision/return type, leaving some behavioral gaps.

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 sentences, front-loaded with the core action and the safety guarantee, then a dense grammar list. No filler or redundancy; every clause adds information an agent would otherwise have to guess.

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 description is correctly omitted, and the input grammar is fully enumerated. For a one-parameter evaluator the definition is nearly complete; only failure modes and result type/numeric precision are undocumented.

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% — the single `expression` parameter has no documentation in the schema. The description compensates well by enumerating the exact grammar (operators, parentheses, supported functions, and pi/e/tau constants), which is the semantic detail an agent needs. Minor gaps remain around whitespace handling and error responses.

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 ("evaluate") and resource ("arithmetic expression"), then enumerates the supported operators, functions, and constants. This makes it unmistakable next to siblings like analysis_stats, analysis_linear_regression, or system_run_command.

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: the enumerated grammar tells an agent what this tool accepts, and "No code execution" hints that system_run_command is the wrong choice for arbitrary scripting. There is no explicit when-to-use/when-not statement or named alternative, so the agent must infer the routing.

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 whole burden. It discloses that the tool is purely computational and which metrics are produced, which implicitly signals a non-destructive read, but it never states whether stdev/variance are sample or population, how single-element or empty lists behave, or whether input order matters. For a stateless calculator these are minor but real gaps.

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 resource named first and the output metrics listed after; no filler or redundancy.

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 the description does not need to explain return formatting, and its metric list is a helpful preview rather than a requirement. Combined with a single trivially typed parameter, the definition is nearly sufficient, with only edge-case behavior left unstated.

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 there is one required parameter; the phrase 'a list of numbers' restates the schema's array-of-numbers type rather than adding meaning. No constraints are given on minimum length, numeric range, or whether non-finite values are accepted.

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 operation ('descriptive statistics') and an explicit input domain ('a list of numbers'), then enumerates the exact statistics returned (n, sum, mean, median, min/max, stdev, variance, percentiles). That enumeration separates it clearly from siblings like analysis_correlation, analysis_frequency and analysis_linear_regression, even though no sibling is named.

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 or when-not-to-use guidance and no mention of alternatives such as analysis_frequency or analysis_linear_regression. An agent must infer from the tool name alone that this is the right pick for summary statistics rather than a distribution or relationship test.

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; to its credit it discloses two real behaviors the agent could not otherwise know: private/internal hosts are blocked by default, and response bodies are truncated. It omits error behavior, redirect handling, retry semantics, and whether json_body and body interact, which matters for a network tool with zero annotation coverage.

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 short sentences, front-loaded with the action and methods, then the two most surprising constraints. Nothing is padded, though the terseness leaves known ambiguities unresolved.

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 six-parameter network tool with no annotations and no schema descriptions, the definition leaves the two body parameters indistinguishable and the timeout unexplained — the agent cannot invoke it confidently without guessing.

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 six parameters, so the description must compensate and largely does not. It explains the method set and that the body may be truncated, but says nothing about headers, timeout units/defaults, or the critical distinction between body and json_body.

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 and resource ('Perform an HTTP request') and enumerates the supported methods, which is enough to distinguish it from pure utility siblings such as automation_uuid4 or analysis_math_eval. It does not, however, differentiate itself from automation_send_webhook, which is the closest overlapping sibling.

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?

Listing the methods implies this is the general-purpose HTTP escape hatch, and the anti-SSRF note implies an internal-network exclusion. There is no explicit statement of when to prefer this over automation_send_webhook, nor of any prerequisites such as auth or rate limits.

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?

It adds useful behavior absent from the schema: the HTTP method is POST and the secret becomes an X-Webhook-Secret header only when provided. With no annotations, it still leaves operational behavior such as external side effects, errors, timeouts, and retries undisclosed.

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 single sentence is front-loaded with the core operation and contains no filler. The parenthetical efficiently communicates the optional header 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?

For a simple three-parameter tool with an output schema, it covers the essential invocation and compensates well for undocumented parameters. Missing sibling-selection guidance and operational details leave clear gaps, especially because no annotations are supplied.

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?

Despite 0% schema description coverage, the description supplies meaning for all three parameters: the URL is the webhook destination, the payload is JSON, and the optional secret controls the named header. It does not add URL validation, payload constraints, or secret-handling details.

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 action (POST), resource (JSON payload), and destination (webhook URL). It does not explicitly distinguish this specialized tool from the sibling automation_http_request.

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, prerequisite information, or alternative-tool recommendation. In particular, it does not explain when to choose this tool over automation_http_request.

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 disclosure burden; it does convey the output format (epoch + ISO-8601 UTC), which is genuinely useful behavioral information. However, it says nothing about side effects, determinism, or timezone/locale assumptions beyond 'UTC', leaving the safety profile implicit for a tool that is obviously a read.

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 compact sentence that front-loads the returned value and enumerates both formats with no filler. Nothing in it is 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?

For a zero-parameter tool with an output schema present and 100% schema coverage, the description is nearly sufficient — the output schema documents the return shape. The one gap is the unresolved overlap with sibling system_now, which an agent cannot resolve from this text.

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 no parameter semantics to explain and the baseline applies. The description correctly does not fabricate inputs.

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 the resource (current time) and specifies the exact two representations returned (unix epoch and ISO-8601 UTC), so an agent knows precisely what it gets. It does not differentiate itself from the sibling system_now, which appears to serve an overlapping purpose.

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 statement of prerequisites, and no mention of when an agent should prefer this over system_now or why both exist. Usage must be inferred entirely from the name and the noun 'Current time'.

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 burden; it does disclose that output is random (non-deterministic) and conforms to UUID v4, which are the relevant behavioral traits. It does not state that the operation is side-effect-free or local, though for a pure generator this is a minor omission.

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

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

A single front-loaded sentence with no filler; every word (random, UUID, v4, string) contributes meaning.

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?

With no inputs and an output schema covering the return value, the definition supplies nearly everything required to invoke the tool correctly. The only gap is the absence of a hint about typical usage contexts relative to its sibling generators.

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

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

The tool takes zero parameters, so the baseline applies and there is no schema semantics the description needs to supplement. Nothing is missing 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 ('Generate') and a precise resource ('random UUID v4 string'), which unambiguously separates it from siblings like automation_timestamp and system_now. It does not explicitly name a sibling it displaces, but the resource is distinct enough that no confusion arises.

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 tool versus automation_timestamp or system_now — e.g., for generating unique identifiers for records versus time-based values. The agent must infer the use case from the name and description 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 must carry the full behavioral load. It usefully discloses the blocking semantics implied by 'Sleep' and the 0.01–60 second range that the schema does not encode, but it omits what happens on out-of-range values (clamp, error, or silent acceptance) and does not say whether the call blocks the workflow. No return-value detail is needed because an output schema exists.

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 no filler, and the core behavior plus range is front-loaded. Slight density loss from the parenthetical bounds being the only structural element, but nothing 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?

For a one-parameter delay utility with an output schema, the definition covers what it does, valid input bounds, and typical use. The only meaningful gap is out-of-range behavior for the seconds value, which an agent could plausibly hit.

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 schema documents only the name and a default of 1. The description compensates by supplying the accepted range (0.01–60), which is the single most important constraint for this parameter and is absent from 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?

States a specific verb ('Sleep') plus the unit and hard bounds ('N seconds (0.01–60)'), so the agent knows exactly what the tool does. It does not name or contrast with any sibling, but no sibling in the list overlaps with a pure delay operation, so the differentiation is implicit 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?

'Useful for polling and retries' gives concrete use contexts, which is enough to select it over automation_http_request or system_now. It stops short of stating when not to use it or what alternative to choose instead of waiting (e.g., an explicit retry helper).

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 does not say how arrays are indexed in the flattened keys, what happens on key collisions, whether the input is mutated or copied, or how non-object input is handled. It also leaves the configurable separator behavior implied by 'dotted keys' rather than stated.

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 transformation and followed by the input-passing hint. Efficient with no filler, though the second sentence could have carried the separator detail instead of stopping at the input format.

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-shape explanation is not needed, and the tool is conceptually simple. Still, key-generation rules for arrays, collision handling, and separator usage are absent, leaving real behavioral gaps for a transformation whose output is the whole point.

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 'data' property has no type at all, so 'Pass data as a JSON value' genuinely adds meaning the schema lacks. However, 'separator' is never mentioned despite controlling the produced key syntax, so only half the parameters are covered.

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 plus the transformation contract: 'Flatten nested JSON objects/arrays into a single-level dict with dotted keys.' That is clearly distinct from data_to_json and data_read_json in the sibling list, though it never names an alternative explicitly.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as data_read_json or data_to_json. The agent must infer from the name alone that this is the tool for flattening an already-parsed or inline JSON value.

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 still implies read-only behavior and states that it returns columns, sample rows, and totals. However, it omits important behavioral context such as how limiting works, whether delimiter parsing is robust, error behavior, or sandbox access constraints.

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

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

The description is two short sentences, front-loads the main action, and contains no filler. Every clause contributes directly to identifying the tool and its output.

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 less explanation, but the description is still incomplete for a three-parameter tool with 0% schema description coverage. It provides no practical guidance on limit or delimiter semantics, leaving an agent to infer behavior from parameter names 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 coverage is 0%, so the description should explain path, limit, and delimiter. It only hints that 'sample rows' relate to limit and that CSV implies a delimiter, but gives no explicit meaning for any parameter, leaving the schema titles to carry the burden.

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: 'Read a CSV file from the sandbox.' This clearly distinguishes it from siblings like data_read_json and files_read_file, although it does not explicitly name alternatives. The added return summary reinforces the operation.

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

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

There is no guidance on when to use this tool versus data_read_json or files_read_file. The sandbox context implies a constrained environment, but the description gives no conditions, prerequisites, or exclusions.

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 does carry real weight and it does disclose two useful traits: reads occur inside the sandbox and files over 10 MB are not accepted. It remains silent on what happens on invalid JSON, whether the path is relative to a sandbox root, and whether errors are thrown or returned, which matters for a parsing tool with zero annotation coverage.

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

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

One sentence, front-loaded with the action and resource, with the size limit appended as a parenthetical constraint. Nothing is wasted and nothing is 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?

An output schema exists, so explaining return values is unnecessary, and the size cap plus sandbox mention cover the main runtime caveats. However, for a parsing tool the handling of malformed JSON and the exact path resolution are still unexplained, leaving meaningful 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 coverage is 0% for the single required 'path' parameter, so the description should compensate and only partially does: 'from the sandbox' hints at a sandbox-relative path but gives no format, extension rules, or absolute-path behavior. The 10 MB bound is a useful constraint but is not tied to any parameter.

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

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

States a specific verb and resource ('Read and parse a JSON file from the sandbox') plus a size bound, which cleanly separates it from a generic binary read. It does not explicitly distinguish itself from sibling files_read_file or data_read_csv, leaving that differentiation to inference.

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

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

No guidance on when to choose this over files_read_file (raw read) or data_read_csv, and no prerequisites or exclusions stated. The agent must infer that this tool both reads and parses, unlike the generic file reader.

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 disclosure burden and does well on the most important trait: it is explicitly read-only and states that writes and DDL are blocked. It says nothing about permissions, query timeouts, error behavior, or how results are returned, so the disclosure is partial.

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 read-only constraint front-loaded. Nothing is wasted and the critical restriction appears before the caveat.

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 safety profile is covered. However, for a tool that takes an arbitrary filesystem path and an arbitrary SQL string, the absence of any path-resolution or limit guidance leaves real gaps for an agent composing a call.

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 three parameters, so the description must compensate and largely does not. 'SELECT/WITH' and 'SQLite file' give indirect meaning to sql and path, but path resolution (sandbox-relative? absolute?) and the purpose of limit (default 100) are entirely 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 ('Run') and resource ('SQL query against a SQLite file in the sandbox') and constrains it to SELECT/WITH. The SQLite-file resource implicitly separates it from data_read_csv and data_read_json, though no sibling is named explicitly.

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

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

The description implies usage through the SELECT/WITH constraint and the note that writes and DDL are blocked, giving the agent a clear picture of the allowed operation class. It never says when to prefer this over data_read_csv or data_read_json, nor what to do when a query is rejected.

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 discloses the output shape ('pretty JSON string') and implicitly flags failure on non-serializable input via the qualifier 'JSON-serializable', but says nothing about error behavior, key ordering, or whether it is a pure/side-effect-free 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 front-loaded sentence with no filler; the essential purpose and output form arrive immediately.

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 explanation is unnecessary, and the tool is simple with only two parameters. The main remaining gap is the unstated semantics of 'indent' and any error behavior for non-serializable input.

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 'data' parameter has no type at all in the schema; the description partially compensates by clarifying it accepts 'any JSON-serializable data'. However, the 'indent' parameter is never mentioned in either the schema or the description, so its formatting effects must be inferred from the default of 2 and the word 'pretty'.

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 ('Serialize') and both the input class ('any JSON-serializable data') and output form ('pretty JSON string'). It is distinguishable from siblings like data_read_json or data_flatten_json, though it does not explicitly name how it differs from them.

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

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

No guidance on when to use this versus data_flatten_json or data_read_json, and no prerequisites or exclusions. The agent must infer applicability purely from the one-line purpose statement.

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 supplied, the description carries the full behavioral burden for a destructive operation. It correctly discloses the non-recursive scope, but says nothing about permanence/irreversibility, behavior when the path does not exist, sandbox-root confinement, or permission requirements.

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, front-loaded with the verb and immediately qualified by the key constraint. No filler or redundant restatement of the tool name.

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, and the tool is a simple one-parameter operation. However, for an irreversible file removal with no annotations, the missing details on permanence, error cases, and path resolution leave a real 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% for the single parameter, and the description adds nothing about what "path" means — whether it is absolute, sandbox-relative, whether subdirectories are allowed inside it, or what conventions the sibling file tools use. The one parameter it has is essentially undocumented everywhere.

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?

"Delete a file ... from the sandbox" gives a specific verb plus resource, and "(never a directory)" bounds the scope in a way the name alone does not. It does not name any sibling or alternative, so it falls short of full differentiation, but the operation is unmistakable.

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 parenthetical clarifies one exclusion (directories are out of scope), which is meaningful when-guidedance. It gives no positive context about when to prefer this over, say, overwriting via files_write_file, and no prerequisites or state expectations.

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 does disclose two useful traits — the operation is confined to a sandbox and paths must be relative — but says nothing about whether listing is recursive or single-level, whether hidden/empty entries are included, whether output is truncated, or how a bad path fails. For a read tool with zero annotation coverage, that leaves significant behavior undisclosed.

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 the scope constraint in parentheses — nothing is wasted. The terseness brushes against under-specification, but as a structural matter it is clean 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?

An output schema exists, so the description is not obligated to describe return values. However, for a filesystem listing tool the missing details that matter most — recursion depth, ordering, hidden files, and what happens on a nonexistent path — are not covered by the schema either, leaving the agent to discover them by trial.

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 path parameter has 0% schema description coverage, so the only semantic input is the schema's default of ".". The description compensates partially by stating "relative paths only", which tells the agent the accepted path form, but it does not explain what "." means, whether subdirectory paths are supported, or how trailing separators are handled.

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 ("List") and resource ("files/folders") plus the operational scope ("sandboxed workspace"), which lets an agent distinguish it from files_read_file, files_delete_file, and files_search_files. It stops short of explicitly naming how it differs from files_search_files, so it is clear but not fully sibling-differentiated.

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: the agent can infer this is the tool to reach for when it needs an inventory of the sandbox, but there is no explicit when-to-use statement, no mention of when files_search_files would be preferred, and no prerequisites or error conditions (e.g., nonexistent path).

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 real behavior: only UTF-8 text is supported, access is limited to the sandbox, and max_bytes caps the output. It omits what happens on truncation, missing files, or non-UTF-8 content, and does not confirm the operation is side-effect free.

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 resource and scope stated first and the output-limiting parameter explained inline. Nothing is wasted, though the parenthetical could be integrated more smoothly.

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, has only two parameters, and an output schema exists so return values need not be explained. Still, for a filesystem read with zero annotation coverage, one more sentence on truncation and error behavior would close the remaining 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 adds meaning for max_bytes (it caps output size), but says nothing about path — whether it is relative to the sandbox root, absolute, or how traversal is handled — leaving the required parameter's semantics thin.

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 (read) and resource (a UTF-8 text file in the sandbox), which clearly separates it from files_write_file and files_delete_file in the sibling list. It does not explicitly name a sibling it contrasts with, so it falls just short of 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 or when-not-to-use guidance, and no routing to alternatives such as files_search_files or files_list_files for locating a file first. The purpose implies usage, but the description never says it.

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 implies read-only intent and discloses the return shape (matching paths with line numbers), but says nothing about case sensitivity, binary/large file handling, .gitignore or hidden-file behavior, or whether results are truncated by max_results. For a search tool with zero annotation coverage, that is a substantial 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?

Three short sentences, front-loaded with purpose, then capability, then return shape. No filler or redundant restatement of the name.

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 did not need describing, and the description is adequate for a simple read-only search. However, with 5 undocumented parameters at 0% coverage and no annotations, the definition leaves path scoping, glob filtering, and result limits unexplained.

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 5 parameters, so the description must compensate. It only clarifies that queries may be literal or regex (the regex flag) and vaguely implies sandbox-wide scoping; path, glob_pattern, and max_results semantics are left entirely to bare parameter names with defaults.

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?

"Grep-like text search across sandbox files" names a specific verb (search), the resource (files), and the search modality (grep-like, content-based), and the second sentence adds that it can be literal or regex. This is enough for an agent to distinguish it from siblings like files_list_files, though it never names that alternative explicitly to sharpen the contrast.

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 when-to-use or when-not-to-use guidance and never references the obvious sibling alternatives (files_list_files for enumeration, files_read_file for reading a known file). Usage must be inferred from the word "grep-like", and there is no mention of prerequisites, scope limits, or large-tree behavior.

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 at all, the description carries the full behavioral burden. It does disclose two useful traits: encoding (UTF-8) and side effect of creating missing parent folders. It does not disclose that the default path truncates an existing file, nor any permission or failure behavior, which are significant omissions for a destructive-capable write.

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, the core action front-loaded and the secondary side effect second. Nothing is padded or 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 sandbox/encoding/parent-folder facts are covered. However, for a write tool that can destroy existing file content, the missing overwrite-versus-append semantics leave a real gap an agent needs closed before calling it confidently.

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

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

Schema description coverage is 0%, so the description must compensate for all three bare parameters. It only loosely covers them: "in the sandbox" hints at path scope, "UTF-8 text" hints at content encoding, and "write/append" gestures at the append flag — but the critical default (append=false meaning overwrite/truncate) is never stated.

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?

"Write/append UTF-8 text to a file" gives a specific verb and resource, and "in the sandbox" scopes it so an agent can tell it apart from files_read_file or files_delete_file. It does not explicitly name a sibling it is not, but the name plus verb make the intent 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?

There is no when-to-use guidance, no prerequisite conditions, and no mention of the alternative modes implied by the append flag. An agent must infer from the single word "append" that the same tool overwrites by default, and nothing tells it when overwriting is the right choice versus reading and rewriting.

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 burden. It implies a read-only measurement but never says whether the path must exist, whether it recurses into subdirectories, how permission errors are handled, or whether the call is side-effect free.

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

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

A single front-loaded sentence with no filler, and the returned metrics are stated up front. It is efficient, though extremely terse for a tool with an undocumented parameter.

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 needn't be explained, and the tool is inherently simple. However, the ambiguous path semantics and the absence of any read-only/mutation statement leave meaningful gaps for an unannotated 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?

One parameter with 0% schema description coverage, so the description must compensate. It only says 'for a path' and never clarifies relative-vs-absolute resolution, the '.' default, or whether files are accepted in addition to directories.

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 resource (disk usage statistics) and enumerates the returned metrics (total/used/free bytes and percent) scoped to a path. It is distinguishable from siblings like system_info and system_env_vars, though it doesn't explicitly name the contrast.

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, no mention of when to prefer system_info or other system tools, and no prerequisites stated. The agent must infer that this is the disk-space tool from the title 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 supplied, the description carries the full behavioral burden. It usefully discloses that secret-looking values are masked, but says nothing about whether this reads the server process environment or something else, whether output is capped, or that the operation is non-destructive — all left to inference.

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 followed by the two behaviors that matter. Nothing is padded or restated from 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?

An output schema exists, so return format need not be explained, and the masking note covers the main surprise an agent would hit. The remaining gap is provenance — whose environment variables are read — which is relevant for a low-risk but ambiguous tool.

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

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

Schema coverage is 0%, so the description must compensate, and it does: 'optionally by prefix' tells the agent the single parameter acts as a prefix filter and can be omitted. It does not give examples or say whether matching is case-sensitive, keeping it from a 5.

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 and resource ('List environment variables') plus two scoping details (prefix filtering, secret masking), which separates it from siblings like system_info or files_read_file. It does not explicitly name an alternative tool, so it falls 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?

'Optionally by prefix' implies how to narrow results but never states when an agent should call this versus system_info or system_run_command for environment inspection. Usage is inferable rather than explicit.

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

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

No annotations are supplied, so the description carries the full behavioral burden. 'Get' implies a pure read with no side effects, which is adequate for a zero-parameter introspection tool, but the description never states that it is read-only, side-effect free, or that the values (hostname, cwd) may be environment-sensitive.

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 filler, front-loading the action and then the concrete payload. Nothing could be removed 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?

With zero parameters and an output schema present, the description only needs to frame what the tool returns, and the field enumeration does that. It stops short of noting that the snapshot reflects the server host rather than the caller's machine, which matters for a system-info 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 tool takes no parameters at all, so there is nothing for the description to disambiguate beyond the returned fields, which it does list. Baseline 4 applies for a zero-parameter 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 uses a specific verb ('Get') plus a specific resource ('host system information') and enumerates the exact fields returned (OS, python, CPUs, hostname, cwd). That enumeration is what separates it from siblings like system_disk_usage, system_env_vars, and system_now, though it never names an alternative explicitly.

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

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

When-to-use is only implied by the field list: an agent infers it should call this when it needs OS/Python/CPU/hostname/cwd facts. There is no explicit statement of when not to use it or which sibling to prefer for narrower queries such as disk usage or environment variables.

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, but the description makes clear this is a pure lookup of the current instant in a named zone, so the read-only character is self-evident. It does not explicitly state that the call has no side effects, nor that the tz argument defaults to UTC when omitted, leaving the behavioral burden largely on the schema.

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 core noun phrase first and the format hint in parentheses. Nothing is wasted and nothing is 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 one-optional-parameter read tool with an output schema, the description covers what the tool returns and how to format the argument. The only omission is stating that omitting tz yields UTC, which the schema's default already implies.

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% - the schema only names the parameter 'tz' as a string with a default. The description compensates by specifying the IANA identifier format and giving two valid examples, which is exactly the meaning an agent needs to fill the field correctly.

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 resource precisely: the current date/time resolved for a given IANA timezone, with concrete examples. It does not differentiate itself from the sibling automation_timestamp, so an agent must infer which clock tool to pick.

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 sibling (notably automation_timestamp) is named as an alternative. The only implied guidance is that the caller may pick a timezone.

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 two important behavioral facts: the tool is disabled unless MCP_ENABLE_SHELL=true, and it is dangerous to use. Missing are the working directory, the shell interpreter, whether execution is blocking, what the timeout applies to, and whether output is captured or streamed. The precondition disclosure is real value that annotations do not provide.

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 short sentences with the core action front-loaded and the availability gate placed before the warning. "Use with extreme caution" is generic and could have been made concrete, but nothing is wasteful.

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 gating condition is covered. However, for an arbitrary-code-execution tool with a completely undocumented parameter set, the description leaves too much for an agent to infer before calling 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%, so the description must compensate for both parameters and does not. `command` is only implied by the verb, and `timeout` is entirely unexplained — its unit, default of 10, and whether it kills the process or just the wait are 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?

States a specific verb and resource: 'Execute a shell command on the host.' No sibling tool does this, so it is distinguishable from the analysis/files/system-info tools by resource alone, though the description never explicitly contrasts with them. The gating sentence reinforces that this is a raw execution primitive.

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 with extreme caution" signals risk but gives no when-to-use, when-not-to-use, or alternative guidance. The only concrete routing signal is a hard availability gate (MCP_ENABLE_SHELL), not a choice between tools. An agent knows the tool exists but not when it should be preferred over, say, files_read_file or analysis_math_eval.

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