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

The description explicitly says the agent can do ANY Evomi operation, which inherently signals broad and potentially destructive behavior. Combined with annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true), the safety and side-effect profile is clear. The description adds context about it being conversational and capable of both action-oriented and informational tasks beyond what the schema alone conveys.

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 compact and front-loaded with the core purpose, followed by a single illustrative list of example requests. Every sentence earns its place, and the examples are varied without being padded. This is appropriately sized for a tool with one parameter and a broad scope.

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 powerful agent tool covering every Evomi operation, the description conveys sufficient context: natural language interaction, broad capability, and representative examples. The absence of an output schema is mitigated by the assistant's conversational nature, though a note about confirmation or credit consumption could have made it even stronger. Annotations fill the safety-related gaps, so the definition is reasonably complete.

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

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

The schema already covers the single parameter with 100% coverage, so the baseline is 3. The description adds meaningful value by providing diverse example prompts that illustrate the expected format and breadth of the message parameter, helping an agent craft valid natural language requests. It does not overburden with redundant schema repetition.

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 identifies this tool as an AI-powered conversational assistant covering ALL Evomi operations, and provides concrete examples that illustrate its scope. It distinguishes itself from the many specific sibling tools by positioning itself as the general-purpose natural language entry point, so an agent can readily tell it apart from direct operation tools.

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

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

The description gives clear usage context by stating the tool accepts any Evomi operation request and lists representative examples like creating configs, running scrapes, discovering URLs, scheduling jobs, and checking account info. It does not explicitly state when NOT to use it or point to alternative direct tools, but the 'ANY Evomi operation' framing makes the usage context strong enough for an agent.

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

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

Annotations only declare readOnlyHint=true, so the description must carry the behavioral burden, and it does: it discloses that the tool 'Fetches the account's own credentials' so the output 'CONTAINS THE PROXY PASSWORD', that it validates targeting and explains unsupported combinations rather than returning a broken string, and it establishes a secret-handling protocol (use the credential for the task, don't repeat it, show only on explicit request). This goes well beyond what annotations 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?

The description is front-loaded with purpose, followed by usage triggers, then behavioral and secret-handling notes. At roughly 150 words it is on the longer side, but the SECRET HANDLING paragraph earns its length given the credential-exposure risk, and there is no filler or repetition of schema content.

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 28-parameter tool with no output schema, the description covers the critical gaps: what the output contains (connection strings plus a verification curl command), what happens on invalid combinations, and the live-secret hazard. The detailed schema descriptions compensate for most remaining gaps, though the exact return object shape (e.g., reported session ids) is only hinted at via the session_id parameter description.

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 100%, so the baseline is 3 and the description isn't required to document parameters. It adds a modest conceptual framing — 'geo targeting, sticky sessions and expert filters encoded into the password' — which explains how the many parameters materialize in the output, but it provides no per-parameter detail beyond the already-thorough 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 opens with a specific verb and resource: 'Build ready-to-use Evomi proxy connection strings' with a clear deliverable ('plus a curl command to verify them'). It distinguishes itself from siblings by stating exactly which user requests route here ('a US residential proxy', 'proxies for Berlin', 'a sticky session'), separating it from generate_proxy_list and get_proxy_credentials without ambiguity.

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

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

Gives clear, concrete usage context with quoted example user requests ('how to configure a proxy in code') that an agent can match against. However, it names no explicit exclusions or sibling alternatives — generate_proxy_list is a plausible alternative for bulk proxy generation, and the description never explains when to pick that instead.

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

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

The description adds behavioral context beyond the annotations: it explains that the tool follows links up to a specified depth and that scraper_config can reference saved settings or inline options. This is useful because it reveals how the crawl operates, while readOnlyHint and openWorldHint already cover the safety profile.

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

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

The description is three sentences with no filler. It front-loads the core purpose, then adds the key behavior around depth and scraper_config. Every sentence earns its place.

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

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

The core crawl behavior, depth, and scraper_config usage are covered, but the tool has a nested object, six parameters, and no output schema. The description does not explain return format, async behavior, or how max_urls affects the crawl. This is adequate but has clear gaps for a tool of this complexity.

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 about 50%, and the description partially compensates by clarifying that depth controls how far links are followed and that scraper_config accepts config_id or full options. However, max_urls and async_mode receive no semantic explanation in either the schema or the description.

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

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

The description clearly states a specific verb and resource: 'Crawl a website to discover and scrape multiple pages.' This distinguishes the tool from siblings like scrape_url, which targets a single page, and map_website, which is about mapping links rather than scraping content.

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

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

The description implies this tool is for multi-page crawling and scraping via 'discover and scrape multiple pages' and 'follows links up to specified depth,' but it never gives explicit when-to-use or when-not-to-use guidance, nor does it name alternative tools like scrape_url or map_website.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description's 'Create ... new' is consistent with a non-destructive write operation. However, the description adds no extra behavioral context such as duplicate-name behavior, validation requirements, or response behavior.

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

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

The description is a single, tightly written sentence beginning with the action and resource. It contains no filler and is appropriately minimal for the tool's simple surface.

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

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

This is a creation tool with a required nested config object, no output schema, and no explanation of how to construct a valid config. The one-sentence description is not enough for an agent to know what values to provide or what to expect after creation.

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 only 50%: the 'name' parameter has no description, and 'config' is only described as 'Scraping configuration'. The tool description repeats the phrase 'scrape configuration' but does not explain what the config object should contain or how name is used.

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 identifies the verb 'Create' and the resource 'scrape configuration', and adds the purpose 'for reuse'. It does not explicitly distinguish create_config from the sibling generate_config, which could sound similar, so it falls short of full differentiation.

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

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

There is no guidance on when to use create_config versus update_config or generate_config, even though those siblings exist. An agent must infer that create is for new configurations and update is for existing ones; the description does not state this.

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 annotations all false and no output schema, the description carries the full burden and only states that a job is created. It doesn't disclose whether the job starts immediately, whether it validates the config, what the response contains, or how duplicates are handled.

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

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

One short sentence with clear front-loaded action. The phrase 'runs at regular intervals' is slightly redundant with 'scheduled,' but there is no waste.

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 mutating 5-parameter tool with no annotations and no output schema, the description is too thin. It omits prerequisites, return behavior, and default/edge-case behavior, leaving the agent to infer critical call details.

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 description adds no parameter-level meaning beyond saying 'regular intervals,' and the schema already documents interval_minutes. It doesn't help with the undocumented name or stop_on_error parameters, and with 60% schema coverage the description should compensate but doesn't.

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

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

The description identifies a specific action ('Create') and resource ('scheduled scrape job'), and the word 'scheduled' separates it from one-off scraping tools like scrape_url. It doesn't explicitly name sibling tools, but the resource is distinct enough for an agent to choose it over update/delete/config tools.

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

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

There is no guidance on when to choose this tool over its siblings, such as 'use update_schedule to modify an existing job.' The create semantics are implied by the verb, but no context about prerequisites (e.g., an existing config_id) is 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?

Annotations indicate readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the description needed to add behavioral context such as side effects, required permissions, or what 'create' implies. It only says 'Create a new extraction schema' and adds nothing beyond the annotations. No contradiction exists, but no value is added.

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

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

The description is a single sentence with no filler or redundant phrases. It is as concise as possible while conveying the basic purpose.

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

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

The tool has 5 parameters, a nested config object, no output schema, and no usage guidance. The description is far too sparse to give an agent enough context to invoke the tool correctly, especially for parameters like fix, test, and extract_prompt.

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?

With only 20% schema description coverage, the description needed to compensate by explaining parameters like name, config, extract_prompt, fix, and test. It provides no parameter-level meaning whatsoever, leaving agents to guess the roles of most fields.

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

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

The description states a clear action and resource: 'Create a new extraction schema for structured data extraction.' It is specific enough to distinguish from update/delete/list operations on schemas, though it does not explicitly differentiate it from create_config or other sibling tools.

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

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

The description gives no guidance on when to use this tool versus alternatives like create_config, update_schema, or list_schemas. There is no mention of prerequisites, exclusions, or context that would help an agent choose this tool over siblings.

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

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

The annotations are all false, providing only that the operation is mutating, non-idempotent, and non-destructive — a weak signal set. The description adds 'create a new' (implying state mutation) but discloses no side effects: no mention of duplicate-name behavior, whether set_as_default unsets other configs, or per-storage-type credential handling. With annotations this thin, the description carries the burden of behavioral disclosure and does not meet it.

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 ten-word sentence, front-loaded with verb and resource, with zero wasted words. It is efficient in structure, even though its brevity contributes to underspecification in other dimensions.

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 4 parameters, a nested config object whose structure is completely unspecified, no output schema, and all-false annotations, one sentence cannot adequately equip an agent. The description omits return-value expectations, per-storage-type credential shapes, set_as_default semantics, and duplicate/error 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 only 25% (just 'config: Storage credentials'), and the description adds nothing about any parameter — no naming conventions, no explanation of storage_type options, no structure for the nested config object across the three storage types, and no meaning for set_as_default. The description entirely fails to compensate for the schema's near-total silence on parameters.

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 ('Create'), a clear resource ('storage configuration'), and adds purpose context ('for saving scraped data'), which ties it to the scraper domain. It is distinguishable from update/delete/list storage configs by the create verb, though it does not explicitly differentiate from the similarly named create_config 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?

'for saving scraped data' implies when an agent would use this tool — when configuring where scraped output is persisted. However, it provides no explicit when-not-to-use guidance, no mention that create_config covers non-storage configurations, and no pointer to update_storage_config for modifying existing ones. The guidance is implied rather than 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?

The description adds no behavioral context beyond what the annotations already provide. The annotations indicate destructiveHint=true and idempotentHint=true, so the agent knows the operation is destructive and idempotent. The description merely restates the action without mentioning permanence, impact on active tasks, or failure behavior.

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

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

The description is a single short sentence with no wasted words. It is front-loaded with the action and resource, making it easy to parse. For a simple delete tool with one parameter, this length is appropriate.

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

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

Given the tool's simplicity and the annotations covering destructive and idempotent behavior, the description is minimally adequate. However, there is no output schema and no mention of return values, side effects, or prerequisites. A sentence about permanent deletion or behavior for non-existent config IDs would improve completeness.

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 the undocumented config_id parameter. It does not; it simply says 'delete a scrape configuration' without explaining what config_id refers to, how to obtain it, or any constraints. The parameter name is self-explanatory but the description adds no value 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 'Delete a scrape configuration' clearly identifies the verb (delete) and the resource (scrape configuration), distinguishing it from sibling delete tools for schemas, storage configs, and schedules. This is a specific and unambiguous action statement.

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: when you need to delete a scrape configuration, this is the tool. However, it does not explicitly state when not to use it or point to alternatives like delete_schema or delete_storage_config. The resource type is clear, so usage is implied rather than absent.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, which covers the core behavioral profile. The description adds no extra context beyond naming the resource, but it does not contradict the annotations.

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

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

The description is a single sentence with no filler and the key verb is front-loaded. It is concise, though somewhat terse and missing potentially useful context.

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 one-parameter delete operation, the description plus annotations provide an adequate baseline. However, it lacks contextual cues such as where schedule_id comes from, whether associated runs are also deleted, or how this differs from toggle_schedule.

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 schema has 0% description coverage and the description does not explain schedule_id's format, provenance, or constraints. The parameter's meaning is inferable only from its name and the tool name, so the description adds minimal value 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 states a specific verb ('Delete') and resource ('a scheduled job'), making the operation clear. It distinguishes itself from schedule read/update/toggle tools and from delete_config/delete_schema, though it does not explicitly name a 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?

No guidance is given about when to use this tool versus alternatives. It does not mention that list_schedules can provide the schedule_id, or that toggle_schedule is the non-destructive way to pause a schedule. An agent must rely entirely on the tool name.

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

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

Annotations already declare destructiveHint and idempotentHint, so 'Delete' adds no new behavioral information. The description does not disclose permanence, cascading effects, failure behavior, or any other operational trait beyond what annotations already 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?

The description is a single, front-loaded sentence with no filler words. It is concise, though its brevity comes at the cost of useful contextual information.

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

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

For a one-parameter delete operation, the description plus annotations and schema provide a minimally viable picture. However, the lack of parameter semantics and usage guidance means the description is still thin for an agent that needs to select and invoke 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%, so the description needed to clarify the meaning of scheme_id. It does not mention the parameter at all, leaving the agent with only the property name and type from the schema, which is insufficient for a low-coverage case.

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 action ('Delete') and a specific resource ('an extraction schema'), making the tool's purpose clear. It distinguishes from sibling tools like create_schema, get_schema, and update_schema, though it does not add detail beyond the tool name itself.

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 about when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent must infer from the tool name and sibling list that this is for removing schemas, but the description provides no explicit usage context.

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

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

The annotations already convey that the operation is destructive and not read-only, so the description adds no behavioral information beyond what is already structured. It does not disclose consequences such as whether deleting a storage configuration cascades to dependent resources or whether the operation is reversible in any way.

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 one sentence with no filler, and it front-loads the core action and resource. For a simple single-parameter delete operation, this level of conciseness is appropriate.

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 description is minimally viable when combined with the schema and annotations: the schema defines storage_id as required, and the annotations indicate destructiveness and idempotency. However, it leaves out any indication of side effects, return behavior, or how this delete differs from the many sibling delete/config/storage tools.

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?

With 0% schema description coverage, the description must compensate for the lack of parameter documentation, but it does not explicitly mention storage_id or explain how to determine its value. The phrase 'storage configuration' loosely maps to storage_id, but this is minimal semantic help beyond the schema's own property name.

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 ('Delete') and a specific resource ('storage configuration'), making the tool's purpose immediately clear. It distinguishes itself from sibling tools like delete_config or delete_schedule by naming the storage-specific resource, though it does not explicitly differentiate itself from those siblings.

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

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

The description provides no guidance on when to use this tool versus alternatives such as delete_config, delete_schedule, or update_storage_config. There is no stated context, prerequisite, or 'use instead' hint, leaving the agent to infer usage solely from the tool name.

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

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

Annotations declare readOnlyHint=false, meaning this is a state-changing operation, but the description never discloses what 'generate' does beyond producing a result — whether it persists the config, validates the prompt, or consumes credits. The 'using AI' phrasing aligns with openWorldHint=true and hints at non-determinism, but that is the only behavioral disclosure beyond the annotations, leaving persistence and side effects unexplained.

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 wasted words; every component contributes (verb, resource, source, method). It scores highly on compactness, though the brevity comes at the cost of operational detail that other dimensions penalize.

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 output schema and a sibling named create_config, the description leaves essential operational questions unanswered: what the tool returns, whether the generated config is persisted, and how this step fits into the config lifecycle. An agent cannot determine whether calling generate_config alone achieves the goal or whether a follow-up call to create_config is required.

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 only 50%: the `name` parameter has no description, and the tool description does not explain it either. The phrase 'natural language prompt' marginally confirms that `prompt` takes free-form scraping instructions, but it adds no meaning beyond the schema's own 'Describe what to scrape' and fails to compensate for the undocumented `name` parameter or clarify how name and prompt relate.

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 (generate), a resource (scrape config), and the method (from a natural language prompt using AI). It is clear about what the tool does. However, it does not differentiate it from the sibling create_config, which plausibly produces the same end state, so the agent cannot tell from the description alone how the two relate.

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 or when-not-to-use guidance is provided. With create_config as a sibling, the description never clarifies whether generate_config persists the result, whether create_config should be used for structured input, or whether the generated output feeds into create_config. The only implied context is 'you have a natural language prompt,' which is insufficient to disambiguate the config lifecycle.

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

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

Annotations only declare readOnly/destructive hints; the description adds materially valuable behavior beyond them: the output 'CONTAINS PROXY PASSWORDS', each password is 'a live credential', there is explicit secret-handling guidance (use it, don't repeat it unless asked), and a documented failure mode (no data balance). The explicit 'Read-only' statement is consistent with readOnlyHint=true; no contradiction.

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?

Every sentence earns its place: purpose, scope limit, output-safety warning, targeting restrictions, failure mode, and secret-handling policy. The secret-handling section runs three sentences and could be tightened slightly, but it is high-stakes guidance that justifies the length. Key facts (bulk generation, password-bearing output, sibling alternative) are front-loaded.

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 12 parameters, no output schema, and a security-sensitive return value, the description covers the critical decision surface: what the output is (proxy strings with live passwords), scope limits, targeting exclusions, failure condition, and secret handling. It does not describe the exact response envelope or error format, but the schema's format enum plus this description give an agent enough to invoke 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 coverage is only 50%, so the description must compensate, and it does: it groups the supported parameters ('country/city/region/ISP targeting, sessions and ad blocking'), identifies exclusions (zip, ASN, pool, expert filters), and explains the amount cap in security terms ('because every line embeds a live proxy password'). It doesn't enumerate every parameter, but it tells the agent which parameter families are relevant and why.

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'), a specific resource ('bulk list of Evomi proxy strings server-side via the Public API'), a hard limit (up to 50 per call), and the intended use case (pasting into tools that take a proxy list file). It also differentiates from the sibling build_proxy_connection_string by naming that tool directly, so an agent can disambiguate without opening schemas.

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?

Explicitly gives the exclusion condition ('for zip, ASN, pool mode or expert filters use build_proxy_connection_string instead'), names the alternative tool, and adds a second routing rule for larger lists ('use the Evomi dashboard's generator rather than a conversation'). Also flags a precondition ('Fails if the product has no data balance'). Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description's safety profile is covered. The description adds useful context about the returned contents (credit balance and user details), but it does not mention authentication, data freshness, or error behavior, which would further enrich transparency.

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

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

A single, front-loaded sentence states the action and the key return contents with no filler or repetition. It is appropriately sized for a simple zero-parameter tool.

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

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

For a simple read-only tool with no parameters and no output schema, the description covers the resource and the main return values. It could specify exactly what 'user details' entails, but the description is sufficient for basic invocation and expected response.

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

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

The input schema has zero parameters, so there is nothing the description needs to clarify about parameters. This meets the baseline for a parameterless tool.

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

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

The description uses the specific verb 'Get' and names the resource 'account information', then adds concrete content ('credit balance and user details'). This distinguishes it clearly from sibling tools that target configurations, proxies, or scraping, so an agent can select it without ambiguity.

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 it should be used whenever account information is needed, but it does not explicitly state when to use it, when not to use it, or how it compares to any alternative. Since no sibling tool covers account info, usage is inferable but not directly 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?

Goes beyond the read-only/idempotent annotations by revealing that API keys are masked by default and that setting include_api_key returns a live credential. The detailed secret-handling protocol (use the key, avoid repeating it, show only on request) is exactly the kind of behavioral disclosure that prevents misuse.

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?

Front-loaded with the tool's main purpose and return fields, followed by masking behavior, usage triggers, and secret handling. Slightly redundant by stating 'Read-only' when annotations already carry readOnlyHint, but every remaining sentence serves a distinct function.

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

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

For a tool with no output schema, the description enumerates the key response fields (enabled, remaining credits, concurrency limit, max session length, endpoint URL) and the credential behavior. Combined with annotations and schema defaults, an agent has everything needed to invoke it correctly and handle the result 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?

The description clarifies the effect of include_api_key ('MASKED unless...') and implicitly maps the service options to the two API products, compensating for the schema's 50% description coverage. The service enum values are self-explanatory, so no further elaboration is required.

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

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

States a specific verb ('Check') and resource (this account's access to Evomi's Scraper API and Scraping Browser) followed by concrete data fields. The specificity separates it from sibling tools like get_account_info or get_proxy_credentials, 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?

Gives explicit trigger scenarios: diagnosing a scrape failure due to credits and retrieving the key for EVOMI_SCRAPER_API_KEY. It does not name alternatives or exclusion conditions, but the context is unmistakable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds no behavioral context beyond 'Get', such as not-found behavior, response format, or side effects, so it contributes nothing beyond what annotations already 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?

The description is a single sentence with no filler, stating the operation and the key qualifying detail. It is front-loaded and easy to parse.

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

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

For a one-parameter read-only getter with strong annotations, the description is largely sufficient. It does not mention error behavior when the ID does not exist or the exact return shape, but 'Get a saved scrape configuration by ID' adequately conveys the expected result for a simple retrieval 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?

There is a single required config_id parameter with 0% schema description coverage, so the description must compensate. The phrase 'by ID' explicitly ties the parameter to the saved scrape configuration, which is helpful, but it adds no format, source, or validation detail beyond what the parameter name config_id already implies.

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 (Get), a clear resource (saved scrape configuration), and the selection criterion (by ID). This distinguishes it from list_configs, which lists multiple configurations, and from create_config, update_config, and delete_config.

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

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

The phrase 'by ID' implies the tool should be used when a specific config_id is known, but there is no explicit guidance about when to use this tool versus alternatives. It does not mention that list_configs can be used to discover configuration IDs or that update_config is for modifications, so usage guidance is only implicit.

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

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

The description adds substantial context beyond the annotations: it explicitly states the tool does not rotate or change the password, that the password is a live credential granting paid access, and provides detailed secret-handling guidance. This goes beyond the readOnlyHint and idempotentHint annotations without contradicting them.

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?

Every sentence earns its place: purpose, primary alternative, read-only behavior, and secret handling are each clearly separated. The secret-handling guidance is essential and front-loaded, and the overall structure is 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?

The description covers what the tool returns, the key alternative, the security implications, and how the agent should handle the credential. Although there is no output schema, the description names all relevant output components, so an agent has enough context to invoke the tool 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?

The input schema already provides 100% coverage, including the full enum with human-readable mappings for each product value. The description adds no parameter-specific semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Get'), a clear resource ('proxy username and PLAINTEXT PASSWORD ... along with gateway hostname, ports and remaining balance'), and explicitly differentiates itself from the sibling build_proxy_connection_string. An agent can immediately understand what this tool returns and how it differs from related proxy tools.

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

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

The description gives an explicit usage rule: prefer build_proxy_connection_string when the user just wants something to paste into a client. It also implies when get_proxy_credentials is appropriate — when a live credential is needed for config, command, or code — making tool selection unambiguous.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive, so the description doesn't need to cover those. It adds useful behavioral context beyond annotations: it returns no credentials and mirrors the dashboard usage chart, which helps an agent set expectations about data source and security posture.

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 tightly written: it leads with the core function, then provides use cases and a routing note, and ends with security-relevant clarifications. Every sentence adds value and none restate the tool name or padding.

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 output schema, the description does a good job clarifying what the agent will get: a period total, per-bucket figures, and values equivalent to the dashboard chart. It covers intended usage and the key distinction from sibling tools. Minor missing details like units or exact response formatting are not critical because the schema documents parameters well and the dashboard reference grounds expectations.

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

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

The input schema covers all four parameters with descriptions, so the description doesn't need to repeat parameter details. The phrase about period totals and per-bucket figures aligns with the period and include_buckets parameters, but the main description adds no new parameter-level guidance 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 clearly identifies the action (get bandwidth used), the resource (one Evomi proxy product), the time ranges (24h/3d/7d), and the result shape (period total plus per-bucket figures). It also differentiates itself from list_proxy_products by explicitly stating it is for usage, not remaining balance, and stresses that it returns no credentials.

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 states concrete use cases: 'how much traffic have I used', spend checks, and usage trends. It gives an explicit alternative, list_proxy_products, for a different question (balance left), and clarifies that credentials are not provided — which routes an agent away from using this tool for credential retrieval.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is well covered. The description adds minimal behavior context beyond this, and does not mention return format or error behavior, but it does not contradict the annotations.

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

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

One short sentence contains all the core information with no filler or repetition. The resource and lookup key are front-loaded, making it easy for an agent to parse quickly.

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

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

For a single-required-parameter, read-only getter with a strong annotation profile, the description is nearly sufficient. It implies the return value is the scheduled job, though it does not explicitly describe the response shape or how to discover a schedule_id.

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 schema has 0% description coverage for schedule_id, so the description's 'by ID' partially compensates by confirming that the parameter is the identifier. It does not specify the ID's format or how to obtain it, though the parameter name is self-explanatory.

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') and resource ('a scheduled job'), and qualifies it with 'by ID'. This clearly distinguishes it from sibling list, create, update, delete, and toggle schedule tools.

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

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

The phrase 'by ID' tells an agent this is the point-lookup path rather than a list or mutation operation. It does not explicitly name alternatives like list_schedules or state when not to use it, but the usage context is clear.

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

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

The description adds no behavioral detail beyond what the annotations already state: readOnlyHint is true, idempotentHint is true, and destructiveHint is false. It does not disclose return format, error behavior, or the handling of nonexistent or invalid schema IDs.

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

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

The description is a single, front-loaded sentence with no wasted words. Every part contributes to the core meaning: get, saved extraction schema, by ID.

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 read-only tool with one parameter, the description is minimally workable, but it omits useful context such as the return payload, how to acquire a valid ID via list_schemas, and behavior for missing schemas. The annotations cover safety, so the remaining gaps are not critical but still noticeable.

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?

With 0% schema description coverage, the description must compensate for the single parameter. The phrase 'by ID' gives the agent some meaning for scheme_id, but it does not explain where the ID comes from, its format, or the typo mismatch between 'scheme_id' and the schema resource.

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') and a specific resource ('saved extraction schema') and identifies the selection mechanism ('by ID'). This clearly distinguishes the tool from siblings like list_schemas and get_schema_status, even without naming 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?

The usage is implied: use this tool when you need an existing saved extraction schema by its ID. However, there is no explicit guidance about when to prefer this over get_schema_status, list_schemas, or any alternative, and no mention of how to obtain a valid scheme_id.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that this reports 'test status,' with no detail on what a status value looks like or whether it reflects validation/test execution state.

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

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

The description is a single focused sentence with no filler, and the key resource is stated up front. It is concise, though slightly terse for a tool with no parameter documentation.

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 read-only, idempotent one-parameter tool with rich annotations, the description is minimally adequate. However, with no output schema and no usage guidance, the agent must infer what the returned 'test status' contains and when this call is relevant.

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% and the description does not explain the sole parameter 'scheme_id' beyond its name. The mismatch between 'schema' in the description and 'scheme_id' in the schema could confuse an agent, and no format or meaning is provided.

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 ('Get') and resource ('test status of an extraction schema'), making the tool's core function clear. It does not explicitly distinguish it from sibling tools like list_schemas or get_config, though the 'test status' qualifier narrows the meaning.

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 is provided on when to call this tool instead of get_task_status, get_config, or list_schemas. The only usage signal is inferred from the tool name and brief description, leaving the agent to guess the appropriate context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool targets async tasks and lists some task types, but it does not disclose response format, error behavior, or whether statuses persist. Given the strong annotation coverage, this is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no filler words or repetition. It earns its place, but the parenthetical task-type list is incomplete relative to the schema, which costs a point for 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 status-check tool with no output schema, the agent still lacks information about the returned status values, failure states, and polling behavior. The task_type parameter is only partially described, and the description does not address the config_generate and schema enum values. More context is needed for reliable invocation and interpretation.

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 carries the burden for explaining parameters. It mentions three of the five enum values for task_type but never explains task_id semantics, the default value, or why task_type is optional. The additional meaning over the schema is minimal.

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 specific action ('check the status') and the resource ('async task'), with concrete examples (scrape, crawl, map). However, it omits the other task types present in the schema (config_generate, schema) and does not explicitly differentiate this from the sibling get_schema_status tool, which creates slight ambiguity.

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 is given about when to use this tool versus alternatives such as get_schema_status or agent_request. There is no discussion of when task_type should be supplied, how status results should be interpreted, or when polling would be appropriate. The usage context is only implied by 'async task'.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds value by disclosing that the tool does not return the fingerprint payload or credentials, which is non-obvious behavioral context. It also reinforces the read-only nature of the call.

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

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

Three concise sentences with no filler. The output fields are front-loaded, followed by the use case, then the key limitations. Every sentence 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?

Despite having no output schema, the description names the returned fields and explicitly states exclusions (no fingerprint payload, no credentials). For a zero-parameter, read-only list operation with rich annotations and clear sibling context, nothing essential is missing.

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

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

The tool has zero parameters, so there is no parameter documentation burden on the description. The description focuses on output content instead, which is appropriate for a no-input listing operation.

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

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

The description states a specific verb ('List') and a precise resource ('saved browser fingerprint profiles on this account'), and enumerates the returned fields (id, OS, browser, version, creation date). This clearly differentiates it from sibling list tools like list_configs, list_schemas, and list_proxy_products.

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

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

The description explicitly says when to use the tool: 'Use to find a profile id before launching a browser session.' It also states what the tool does not return, which helps avoid misuse. However, it does not explicitly name an alternative tool for scenarios where the fingerprint payload or credentials are needed.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description adds no new behavioral context beyond that. It does not disclose that the result is paginated, what fields are returned, or that 'all' actually means a page of results given the page and per_page parameters.

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

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

The description is a single clear sentence with no fluff and leads with the action. It is appropriately short for a simple list tool, though it could have added a brief note about pagination or return shape without becoming verbose.

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, all parameters are optional, and annotations cover the safety profile. However, there is no output schema and no mention of pagination, sorting defaults, or what a 'configuration' result looks like, leaving minor but real gaps for an agent deciding how to inspect 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 description is the only prose source of parameter meaning, but it says nothing about page, sort_by, per_page, or sort_order. The schema provides types and enums but no semantic explanation, and the description does not compensate.

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 action ('List') and a clear resource ('saved scrape configurations'). It distinguishes from single-config tools like get_config by using 'all', though it does not explicitly mention any sibling tool or filtering difference.

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

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

There is no guidance on when to use this tool versus alternatives such as get_config, create_config, or list_schemas. The description implies a browse/enumerate use case but never states conditions, exclusions, or preferred alternatives.

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

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

The description adds useful behavioral context beyond the readOnly/idempotent annotations by explicitly stating the tool returns NO proxy passwords and pointing to the tools that do. It also discloses the scope ('on this account') and output fields. It does not mention pagination or response shape, but the tool has no parameters and the listing nature is clear.

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 compact and information-dense: it names the action, defines the output fields, decodes product codes, warns about missing passwords, and gives ordering guidance. Every sentence contributes meaningful content without 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?

For a simple, parameterless read-only list operation, the description is complete. It tells the agent what the tool returns, what it does not return, how to interpret product codes, and when to call it. No output schema exists, but the description covers the return shape adequately by listing the fields.

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

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

The input schema is empty with 100% coverage, so there are no parameter semantics to clarify. Per the baseline for zero-parameter tools, the description does not need to add parameter-level detail; it already explains what the returned data will include.

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

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

The description clearly states the tool's verb and resource: list the Evomi proxy products on the account. It enumerates the exact returned fields (gateway hostname, HTTP/SOCKS5 ports, remaining data balance, proxy username) and product codes, making the tool's purpose unambiguous and distinct from adjacent proxy tools.

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

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

The description explicitly instructs when to call it first ('Call this first to see what the account actually has balance on') and provides specific alternatives for proxy passwords ('use get_proxy_credentials or build_proxy_connection_string for those'). This gives an agent clear routing guidance.

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

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive, and the description is consistent with these. It adds useful behavioral context beyond the annotations: the catalogue is large, results are filtered and capped, entries expose an 'id' and 'name', and no credentials are returned. This is exactly the kind of extra context an agent needs.

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

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

Every sentence earns its place: purpose, usage condition, id/name semantics, cap behavior, and credential safety. The most important information is front-loaded, and the description is compact despite covering several distinct points.

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 output schema, the description compensates by describing the shape of entries ('id' and 'name'), the cap behavior, the filtering mechanism, and what is not returned. It also tells the agent when to use the tool in a larger workflow. Nothing critical is missing for a read-only lookup 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 75% and the schema already documents product, limit, and search. The description adds meaning by explaining that returned 'id' values are what the gateway accepts and should be passed back, while 'name' is only a display form. This helps the agent correctly use results even though the schema does not describe the response.

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 opens with a specific verb and resource: 'Look up which countries, regions, cities, ISPs or continents can be targeted on a given Evomi proxy product.' It clearly distinguishes this lookup tool from sibling tools like list_proxy_products and build_proxy_connection_string by naming the exact purpose and the related tool it feeds into.

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 an explicit usage rule: 'Call this before build_proxy_connection_string whenever a city, region or ISP is involved.' This tells the agent when the tool is needed and which sibling it is a prerequisite for, leaving little to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this retrieves execution history, but does not disclose pagination behavior, result ordering, or error behavior.

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

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

A single sentence that is front-loaded with the core action and resource. No filler or redundant wording.

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

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

For a simple list operation, the description is minimally adequate, but there is no output schema and no parameter descriptions. It does not explain what the execution history contains, how pagination works, or what happens if schedule_id is invalid. Given the annotation coverage, this is acceptable but not rich.

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 the missing parameter documentation. It only indirectly identifies schedule_id through 'scheduled job' and says nothing about page or per_page semantics. The parameter names are self-explanatory, but the description adds minimal value 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 uses a specific verb ('Get') and resource ('execution history for a scheduled job'), clearly distinguishing it from siblings like list_schedules, which lists the jobs themselves. An agent can understand what this tool does without opening the schema.

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

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

The description implies usage: call this when you need execution history for a specific scheduled job, identified by schedule_id. However, it does not explicitly mention when to use it over alternatives, nor does it state exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the resource scope and the 'all' qualifier. It does not describe pagination behavior or the meaning of active_only, but it does not contradict the annotations.

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

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

The description is a single, front-loaded sentence with no filler. It is appropriately concise for a simple list operation, though it sacrifices explanatory value for brevity.

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

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

There is no output schema, yet the description does not clarify what the returned schedule objects contain or whether this returns schedule definitions versus scheduled run history. It also omits pagination and filtering semantics. For a tool with optional parameters and no output schema, more context is needed.

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 needs to compensate by explaining page, per_page, and active_only. It does not. The parameter names and defaults carry some self-evident meaning, and 'all' hints at inclusiveness, but no explicit semantics are provided 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 states a specific verb and resource: 'List all scheduled scrape jobs.' It clearly indicates a listing operation. It does not explicitly differentiate from sibling tools like list_schedule_runs or get_schedule, but the resource and intent are reasonably clear.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_schedule for a single schedule, list_schedule_runs for runs, or create_schedule/update_schedule/delete_schedule for management. The description implies a simple list operation but offers no exclusions or selection criteria.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description does not add behavioral context such as whether results are paginated despite the pagination parameters, what 'all' means given a default per_page of 20, or what the response shape contains.

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 highly concise and front-loaded with the action word, with no wasted words. However, it is slightly too terse to be fully self-sufficient because it omits parameter and pagination context.

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

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

Given four optional parameters, no output schema, and no parameter descriptions, the description leaves an agent uncertain about pagination behavior, valid sort values, and response contents. The annotations cover safety but not invocation details, so the tool definition is not complete enough for correct advanced usage.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining parameters. While 'page' and 'per_page' are somewhat self-explanatory, valid values for 'sort_by' and 'sort_order' are undocumented, and the interaction between 'all' and pagination is not clarified.

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 ('List') and a specific resource ('saved extraction schemas'), making the operation unambiguous. It clearly distinguishes itself from sibling tools like get_schema, create_schema, update_schema, and delete_schema.

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

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

No guidance is provided about when to use this tool versus alternatives such as get_schema or list_configs. There is no mention of prerequisites, typical use cases, or exclusions, so an agent must infer usage purely from the tool name and the word 'List'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it lists all configurations rather than a filtered subset, but it does not describe return format, ordering, or pagination. There is no contradiction with the annotations.

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

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

The description is one concise sentence with the verb, resource, and provider scope front-loaded. There is no filler or redundant information.

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

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

For a zero-parameter, read-only list operation, the description plus annotations are largely sufficient for an agent to call it correctly. It lacks an explicit output format or pagination note, but this is a minor gap given the tool's low complexity.

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

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

The tool has zero parameters and schema description coverage is 100%, so the description carries no parameter documentation burden. For a zero-parameter tool, the baseline is satisfied, and the description appropriately focuses on the resource scope.

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

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

The description names a specific verb (List) and resource (storage configurations), and clarifies scope with provider examples (S3, GCS, Azure Blob). This makes it immediately distinguishable from generic tools like list_configs, though it does not explicitly contrast 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?

The description clearly indicates when to use this tool: when the agent needs to list storage configurations. It does not spell out exclusions or alternatives, but the storage-specific scope plus zero-parameter design makes the usage context clear.

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

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

The annotations already declare readOnlyHint, openWorldHint, and non-destructive behavior; the description does not contradict them. It adds context that the tool may contact external sources (sitemaps, CommonCrawl) or crawl the site itself, but it does not disclose rate limits, latency, pagination, or result-size behavior.

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

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

The description is a single front-loaded sentence with no filler. It communicates the core purpose immediately and every word contributes to the meaning, even though the brevity leaves parameter-level detail to other parts of the definition.

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 description is minimally viable for basic use: it says the tool returns discovered URLs and names the available sources. But for a 6-parameter tool with no output schema, it lacks guidance on source selection, filtering, liveness checking, and asynchronous behavior, leaving meaningful gaps for correct invocation.

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

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

With schema description coverage at 0%, the description carries a heavy burden to explain parameters, but it only restates the sources enum in plain language. It adds no meaning for domain, max_urls, async_mode, url_pattern, or check_if_live, leaving most parameters semantically undocumented.

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

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

The description states a clear action ('Discover URLs'), a specific resource ('a website'), and the data sources involved. It does not explicitly differentiate map_website from the sibling crawl_website, and the mention of 'in-site crawling' creates some overlap, so it stops short of full sibling differentiation.

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

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

The description implies the intended use case: discovering URLs from a website via sitemaps, CommonCrawl, or crawling. However, it gives no explicit guidance on when to prefer map_website over crawl_website, scrape_url, or search_domains, and it offers no exclusions or alternative-selection criteria.

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

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

The annotations already mark destructiveHint=true and readOnlyHint=false, but the description adds crucial detail: the current connection is dropped immediately, the old IP is released, the session ID and credentials remain stable, and no credentials are returned. This significantly exceeds annotation-only information.

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 compact and front-loaded with the MUTATING signal, then covers behavior, conditions, and return behavior in four tight sentences. Every sentence carries operational value.

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 description fully covers action, timing, side effects, and the absence of credentials in the response. However, since there is no output schema, it leaves unspecified what the success response actually contains (e.g., a status, the new IP, or a result object).

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

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

Schema coverage is 100% and both parameters (product and session_id) already have clear descriptions, so the baseline of 3 applies. The description references session identity but adds no parameter-specific formatting or selection guidance 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 opens with 'MUTATING: force an existing Evomi sticky session onto a new exit IP,' giving a specific action, resource, and scope. It clearly distinguishes this from read-style proxy tools by emphasizing the mutation and IP change.

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

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

It explicitly states when to use the tool ('Use when a session's IP has been blocked') and when not to call it ('Only call when the user asks to rotate or change IP — it disrupts anything currently using that session'). This is strong conditional guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about modes and output types, but does not disclose other traits such as async behavior, return structure, or interactions between parameters like pdf boolean and output 'pdf'.

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 compact and front-loaded with the core purpose, followed by mode selection, output choices, and AI extraction guidance. Every sentence earns its place, and there is no filler or repetition of schema details.

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

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

This is a 30-parameter tool with no output schema, yet the description is only three sentences. It covers the basics but omits important runtime context like return value shape, async mode, storage integration, and dependencies between flags such as pdf, screenshot, and output, which an agent may need to invoke advanced features 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 70%, so the schema carries most of the parameter documentation burden. The description adds useful meaning for the mode and output enums (e.g., 'browser (JS)' and 'auto (detect)') and explains the ai_enhance/ai_prompt relationship, but it does not compensate for undocumented or ambiguous parameters such as screenshot versus output screenshot.

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: 'Scrape a single URL.' The word 'single' distinguishes it from sibling tools like crawl_website and map_website, and the listed modes and output formats further clarify its 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?

It gives clear context for using the tool on a single URL rather than crawling or mapping, and provides mode-selection guidance ('request (fast), browser (JS), auto (detect)'). It does not explicitly name alternatives or give when-not-to-use exclusions, but the single-vs-crawl distinction is clear enough.

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

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

Annotations already cover read-only and open-world behavior, and the description adds that the tool performs an actual web search and returns domains with URLs and titles. This is useful context beyond the structured annotation fields.

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 concise sentences with no filler. It front-loads the core action and then provides use-case context and return value 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?

The tool has a simple schema, all parameters are documented, annotations cover safety and open-world behavior, and the description states the return format. It is complete enough for an agent to use it correctly, though it could briefly mention that queries can be arrays.

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 100%, so the schema already documents query, region, and max_urls thoroughly. The description does not add parameter-specific guidance beyond what the schema provides.

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

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

The description clearly states the tool finds domains via web search and is for discovering websites when specific domains are unknown. This distinguishes it from sibling URL-targeted tools like scrape_url and crawl_website.

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

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

It gives clear context for when to use the tool: when you don't know specific domains. It implies a contrast with URL-specific tools but does not explicitly name alternatives.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive action. The description adds meaningful behavioral context by stating the exact state transition performed. It does not contradict the annotations and discloses the primary behavioral effect beyond what the annotations express.

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

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

A single sentence conveys the action, resource, and target state with no filler or redundancy. It is front-loaded and efficient, exactly as concise as it needs to be.

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 toggle operation with no output schema, the description is nearly complete. It covers the action and its object. Minor omissions like return value expectations or permission requirements are not critical given the simplicity, but the absence of any such detail keeps it from a perfect score.

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 only parameter is schedule_id, which the schema leaves entirely undocumented. The description refers to a 'scheduled job' and thereby implies schedule_id references that job, but it does not explicitly define the parameter or describe format/constraints. With 0% schema coverage, the description only partially compensates.

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 identifies the verb ('Toggle') and resource ('a scheduled job') along with the state change ('active/inactive'). It is distinct enough from siblings like update_schedule by specifying this is a state toggle, though it does not explicitly name or contrast with a sibling tool.

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

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

The usage context is implied: an agent would call this to flip a schedule between active and inactive. However, there is no explicit guidance on when to use this instead of update_schedule, create_schedule, or delete_schedule, and no exclusions or alternatives are mentioned.

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

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

Annotations already indicate destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the mutation behavior is communicated structurally. The description adds no additional behavioral context, such as what happens to the existing config or whether unspecified fields are preserved. It does not contradict the annotations.

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

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

The description is a single efficient sentence with no filler. However, its brevity sacrifices meaningful content, leaving parameter semantics and behavior unexplained. It is concise but not appropriately informative for an update tool with an undocumented nested object 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?

This is a destructive update tool with three parameters, no output schema, and no parameter descriptions, yet the description offers only one generic sentence. It does not explain update semantics, required fields beyond what the schema implies, or what the nested config object expects. The description is not sufficient for an agent to reliably invoke the tool.

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

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

Schema description coverage is 0%, and the description does not explain any of the three parameters. It does not clarify that config_id identifies the existing configuration, what name updates, or what the config object should contain. With zero schema descriptions, the tool description needed to compensate and did not.

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 clear verb-resource pair: 'Update an existing scrape configuration.' It distinguishes the operation from create/get/delete siblings by saying 'existing,' which implies the configuration must already exist. It does not explicitly name sibling tools or scope limits, 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?

The description provides no guidance on when to choose this tool over create_config, delete_config, generate_config, or other siblings. There is no mention of prerequisites, partial vs. full updates, or situations where another tool would be appropriate. Usage context is only weakly implied by the word 'update.'

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

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

Annotations already declare this is destructive, idempotent, and not read-only, so the safety profile is known. But the description adds no behavioral context beyond that: it does not say whether fields are partially updated or fully replaced, whether changes take effect immediately, or what happens to pending runs. For a destructive tool, this silence is a meaningful gap.

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

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

The single sentence 'Update an existing scheduled job' contains no wasted words and is front-loaded with the verb. However, the brevity stems from under-specification rather than efficient editing — there is no detail to structure, so it reads as minimal rather than well-crafted for a 5-parameter tool.

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

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

For a destructive tool with five undocumented parameters, no output schema, and a sibling toggle_schedule that overlaps in function, this description is grossly inadequate. An agent has no way to know the effect of each parameter, the update semantics, or how this tool differs from toggle_schedule. Nearly all necessary context is missing.

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

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

Schema description coverage is 0% and the description mentions none of the five parameters (name, config_id, schedule_id, stop_on_error, interval_minutes). Neither the schema nor the description explains what these fields mean, how config_id relates to configs, or what interval_minutes controls. The description fails entirely to compensate for the uncovered schema.

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

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

The description states a specific verb ('Update') and resource ('an existing scheduled job'), making it clear this modifies an existing schedule rather than creating, deleting, or toggling one. The word 'existing' disambiguates from create_schedule among the siblings. However, it does not enumerate what aspects of the job can be updated (name, interval, config, stop_on_error), so the operational scope is only partially clear.

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

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

No usage guidance is provided. The description does not state when to prefer update_schedule over toggle_schedule (enable/disable) or create_schedule, nor does it mention prerequisites such as needing a valid schedule_id. An agent must infer the usage context entirely from the tool name and sibling list.

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

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

Annotations already mark this as non-read-only, destructive, idempotent, and open-world. The description adds no behavioral context beyond the word 'Update'—for example, it does not clarify what gets overwritten, what happens to missing fields, or whether the operation is reversible.

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 extremely terse and contains no filler; every word adds meaning. It is front-loaded with the key action and subject, though it lacks any structural breakdown of behavior or 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?

This is a six-parameter mutation tool with no output schema and no description of return values, error conditions, config structure, or side effects. A single sentence is far too little context for an agent to safely invoke it, especially given the required nested config object.

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

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

Schema description coverage is 0%, and the description provides no explanation of any of the six parameters. The required fields scheme_id, name, and config are entirely unexplained, and the boolean flags fix and test are also left to the agent to infer.

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 ('Update'), a specific resource ('extraction schema'), and the scope ('existing'). This distinguishes it from create_schema and get_schema at a basic level, though it doesn't mention which fields are modifiable.

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 is given on when to use this tool versus create_schema, delete_schema, or get_schema. There is no mention of prerequisites, such as the schema needing to exist or how this differs from updating other resources like configs.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds no extra behavioral context such as potential overwriting, required existence of the storage_id, or consequences of setting as default. With annotations present, the bar is lower, but the description still fails to add any unique behavioral insight.

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

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

The description is a single, front-loaded sentence with no redundant wording. It is concise and grammatically clear, though it omits important detail. It earns its place but is at the edge of being too terse.

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

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

This tool has 4 params including a nested object, a destructive hint, no output schema, and many sibling config tools. The description provides almost no context about what a storage configuration update entails, what fields are updatable, how it relates to the 'config' object, or what happens when set_as_default is used. The agent is left without enough information to call it correctly or distinguish it from update_config.

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 by explaining parameter meaning but does not. It never mentions storage_id (required), config, name, or set_as_default. An agent would have to infer all parameter semantics from the schema alone, which is insufficient given the nested config object and boolean 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 clearly states the verb 'Update' and the specific resource 'storage configuration', which distinguishes it from create/delete storage configs. However, it does not explicitly differentiate it from the sibling update_config tool, so the resource type alone carries the distinction.

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 is provided on when to use this tool versus alternatives like update_config, create_storage_config, or delete_storage_config. The description implies it is for modifying existing storage configurations, but there is no explicit when-to-use or when-not-to-use context.

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