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

With no annotations provided, the description carries the full disclosure burden and does well: it specifies output contents, the extraction pipeline (instaloader → gallery-dl fallback), supported URL patterns, and the login prerequisite for private/rate-limited cases. It stops short of detailing error handling or exact response structure, but the core behavior is transparent.

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

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

Two concise sentences carry a high information density: purpose, return values, supported URL patterns, implementation strategy, and auth requirement. Every phrase earns its place and the key action is 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?

Given there is no output schema and no annotations, the description covers the essential context: what inputs are accepted, what outputs to expect, and when login is necessary. It does not describe error behavior or response formatting in detail, but for a tool of this complexity the disclosed information is sufficient for an agent 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 description coverage is 100%, so the baseline for parameter semantics is 3. The description adds value beyond the schema by explaining that login is needed for private/rate-limited content, which directly ties to the optional session_user parameter and clarifies when it must be supplied. This extra context justifies a 4.

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

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

The description uses a specific verb ('Extract') and resource ('konten Instagram'), enumerating supported content types (post, reel, carousel) and explicit return values (caption, media URLs per slide, metadata). It clearly distinguishes the tool from siblings like ig_to_screener by framing it as raw content extraction rather than transformation or parsing.

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 context for when the tool works—supporting /p/ and /reel/ URLs and noting login requirements for private/rate-limited content. However, it never explicitly contrasts this tool with alternatives or states when not to use it, leaving the choice between ig_extract and ig_to_screener implicit 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?

With no annotations, the description carries the full transparency burden. It outlines the main processing steps (extract caption/carousel, OCR slides, parse into screener) but does not mention authentication needs, rate limits, side effects, or failure modes.

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

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

The description is compact and flows logically via arrows, capturing the full pipeline in one sentence. It is slightly dense but remains easy to scan and understand.

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 explains what the tool does and its output type ('filter screener terstruktur'), but does not specify the exact output format, error behavior, or limitations (e.g., supported Instagram URL variants). Given no output schema, this is a moderate gap.

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

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

Schema coverage is 100% and each parameter has a clear, if brief, description. The 'hint' parameter lists allowed presets, and 'session_user' explains its optional login purpose, providing useful context beyond bare names.

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 a one-shot workflow that combines extraction, OCR, and parsing into a structured screener. It implies a more convenient alternative to the sibling tools, though it does not explicitly name 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 phrase 'Paling gampang buat user — cukup kasih link IG' suggests this is the go-to when a user provides an Instagram URL, but it lacks explicit guidance on when to prefer this over the individual sibling tools or what prerequisites exist.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the AI reads numbers and criteria from each slide and returns combined JSON, which is useful. However, it does not mention limitations, error cases, or any side effects, so transparency is adequate but not thorough.

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 concise and front-loaded with the core purpose. The three sentences each add useful information: what the tool does, how to send input, and what output to expect. Minor redundancy with the schema's image fields is acceptable and does not significantly bloat the description.

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 explains the main input options and the general output (combined filter JSON), but it lacks detail about the structure of that JSON and does not clarify the role of the optional hint parameter. Given no output schema exists, a bit more detail about the returned filter format would make the tool easier to use 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 schema already documents all three parameters with 100% coverage, which sets the baseline at 3. The description adds some value by explaining that image_url or image_base64 are the two ways to submit an image, but it does not elaborate on the hint parameter beyond what the schema already says.

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 action—OCR an image of a screener into a structured filter—and identifies the input sources (IG carousel screenshots, filter tables, cover reels). However, it does not explicitly differentiate this tool from its siblings like screener_parse or ig_to_screener, so an agent may not immediately know which one to choose.

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 through the description: use this when you have an image of a screener and want structured filter output. It explains how to provide input (URL or base64) but gives no explicit guidance on when NOT to use it or which sibling tool to prefer in alternative scenarios.

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

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

No annotations are present, so the description carries the behavioral disclosure burden. It honestly states that common patterns like PER<15, RSI<30, and foreign net buy are handled, and that output is ready for a screener builder. It does not mention behavior on unrecognized input, output shape beyond 'structured filters', or any limitations, which is a notable gap.

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

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

The description is compact: three sentences covering purpose, supported patterns, and output. It is front-loaded with the main action and avoids filler, making it easy to scan.

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

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

The tool is moderately complex with two parameters and no output schema, but the description does not explain the exact structure of the returned filters or how 'hint' affects the result. It says the output is ready for a screener builder, which is some guidance, but an agent might still be unsure about what format to expect.

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 both 'text' and 'hint'. The description adds a useful example for 'text' but does not explain the role of 'hint' or how it influences parsing. Since the schema does the heavy lifting, a baseline 3 is appropriate.

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

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

The description uses a specific verb ('Parse') and clearly identifies the resource: free-form screener text converted into structured filters. It gives concrete examples of handled patterns, making the purpose understandable. However, it does not explicitly distinguish itself from siblings like screener_from_image or ig_to_screener, though the input types are listed.

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 suitable inputs — IG captions, OCR text, manual descriptions — and shows example patterns. It does not state when to prefer this tool over the sibling tools, nor does it mention any exclusions or alternatives, leaving the routing decision to inference.

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