identifAI MCP Server

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

With no annotations, the description carries the full transparency burden. It discloses key behaviors: base64 encoding overhead, async result retrieval ('Returns a classification identifier'), size limitations, and authentication options. It does not detail data retention or credit consumption, but the provided context is substantial for a classification tool.

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

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

The description is concise and well-structured: purpose first, then input format, return behavior, a practical warning, alternative tool, and auth instructions. Every sentence contributes actionable information 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?

Given the tool has 6 parameters, no annotations, and no output schema, the description covers the essential operational context: input encoding, size limits, alternative tool, auth, and async result identifier. A small gap is not explicitly connecting the returned identifier to a retrieval tool like get_audio_classification, but sibling names and existing context largely fill this.

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 structured schema already documents all 6 parameters. The description adds some value by reiterating the 10 MB limit and warning about base64 overhead, but it does not meaningfully elaborate on parameters like refId, noCache, filename, or preventC2paForces beyond their schema descriptions.

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+resource: 'Upload an audio or speech file to detect whether it is human-recorded or AI-synthesized.' It clearly states the tool's function and distinguishes it from sibling tools by focusing on audio and the base64 input mode, explicitly naming classify_audio_url as the alternative for larger files.

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 explicit usage guidance, including when to avoid this tool: 'For audio files larger than 10 MB, use classify_audio_url instead.' It also gives authentication guidance (apiKey parameter vs X-Api-Key header), which helps the agent decide how to invoke the tool.

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 discloses the async nature (returns a classification identifier for later retrieval) and authentication options, but omits details about error handling, rate limits, caching, or the effects of optional parameters like noCache and preventC2paForces.

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 long and front-loaded: the first sentence states the core purpose, the second explains the async return, and the third covers authentication. Every sentence adds value with no filler.

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 explains the return value is a classification identifier for async retrieval, but it doesn't specify the identifier's format or how to retrieve the result (e.g., via get_audio_classification). It is adequate for basic usage but incomplete for a fully autonomous agent.

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 baseline is 3. The tool description adds context only for the apiKey parameter (optional when header configured, with a link to obtain keys), but does not elaborate on other parameters beyond what the schema already 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 it submits a publicly accessible audio URL for AI-generated speech detection, using a specific verb and resource. It also differentiates itself from siblings by focusing on URL-based input and async identifier retrieval, distinguishing it from direct upload tools like classify_audio.

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 when to use this tool: when the audio is available via a public HTTP/HTTPS URL and asynchronous processing is acceptable. It establishes clear context but does not explicitly name alternative tools or state when not to use it, stopping short of a full 5.

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 behavioral disclosure burden. It discloses the base64 ~33% size overhead, the 4 MB payload limit, async execution ('Returns a classification identifier for async result retrieval'), and authentication options — all important operational traits beyond what the schema shows.

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 the core purpose in the first sentence, then moves through input format, return behavior, a clearly labeled WARNING, and authentication. Every sentence carries operational value; the warning is appropriately emphasized with 'WARNING:' and the length is justified for such a parameter-rich 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?

Given the 10 parameters and no output schema, the description covers the primary flow (encode → classify → retrieve via async identifier), size limitations, and authentication. It stops short of naming the specific retrieval function (e.g., get_image_classification), but the 'async result retrieval' phrase is sufficient for a user familiar with the MCP server. The schema covers the remaining boolean flags, so overall completeness is strong.

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. The description adds a warning about base64 overhead and the 4 MB threshold, but that context is also partially in the fileData parameter description. No additional parameter semantics are provided beyond what the schema already documents.

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 action ('Upload an image file') and outcome ('detect whether it is human-made or AI-generated'), clearly distinguishing it from classify_image_url (which accepts a URL) and audio/video siblings. It also notes the async result identifier, so the tool's role is unambiguous.

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

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

Explicitly states when not to use this tool: 'For images larger than 4 MB, use classify_image_url instead' — naming the alternative and providing a reason. It also gives authentication guidance (apiKey vs X-Api-Key header), which helps agents decide how to configure the call.

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

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

With no annotations, the description must carry transparency. It discloses the authentication mechanism and the fact that the tool returns only an identifier (not the classification itself) for later retrieval. However, it does not mention whether the operation is asynchronous, what happens to the submitted image/URL, or any rate limits, leaving gaps in expected 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 concise, with the core purpose stated first and no filler. The authentication section is a bit long but provides necessary configuration details. Overall, it is well-structured and 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?

The description covers purpose, return behavior, and auth, but for a tool with 9 parameters and no output schema, it leaves out the follow-up step (e.g., using get_image_classification to fetch the result). It also does not explain that classification may be asynchronous or how results are stored, making it slightly incomplete for an agent to fully invoke and chain calls.

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. The description does not add significant parameter-level detail beyond noting that 'the same analysis options as file-based classification' apply, which is marginal. All parameters are already well-documented in the schema.

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

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

The description states a specific action ('Submit a publicly accessible image URL') with a clear goal ('detect whether it is human-made or AI-generated'). It also clarifies the return type ('classification identifier for result retrieval') and differentiates from file-based classification via 'Supports the same analysis options as file-based classification.' This makes the tool's purpose distinct from siblings like classify_image.

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 implies use for publicly accessible URLs and notes that it shares options with file-based classification, but it does not explicitly name alternatives or state when NOT to use this tool. It does provide authentication guidance (apiKey vs header), which is useful for setup, but lacks a direct comparison to siblings such as classify_image.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses the base64 encoding overhead (~33%), the ~10 MB size constraint, the frame-splitting behavior, and the asynchronous result retrieval via a classification identifier. These go beyond simple tool purpose and aid the agent in understanding operational implications.

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 well-structured and appropriately sized: an opening purpose statement, a note on frame splitting and async retrieval, a clear warning about base64 overhead with a direct pointer to the alternative tool, and a concise authentication note. It front-loads the primary purpose and keeps all sentences relevant.

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 a complex tool with 14 parameters, no output schema, and no annotations, the description covers the key operational context: input format (base64), size limit and fallback, asynchronous behavior, and authentication. It could be more complete by naming the get_video_classification tool for result retrieval, but it is sufficient for an agent to correctly invoke the tool and understand the async flow.

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. The description adds meaningful context for fileData (base64 raw bytes, not a path) and apiKey (header vs parameter), but the schema already documents each parameter well. There is no significant new parameter-level insight 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's function: upload a video file to detect whether it is human-made or AI-generated. It distinguishes this from sibling tools by explicitly noting it handles base64-encoded video content and mentioning classify_video_url for larger files.

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: provide base64 content, split into frames, and retrieve results asynchronously. It explicitly names classify_video_url as the alternative for videos larger than 10 MB. However, it stops short of specifying when to prefer this tool over other classify_* tools beyond the video-vs-audio/image domain distinction.

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

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

With no annotations, the description carries the full burden. It discloses the public URL requirement and authentication mechanism, which is useful. However, it does not describe the output format, error behavior, caching defaults, or side effects — significant gaps for a tool with many options. The reference to file-based classification adds some context but lacks depth.

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

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

Two sentences: the first front-loads the core action, and the second handles authentication. No fluff, redundant information, or restatement of schema fields. 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?

This is a complex tool with 13 parameters, no output schema, and no annotations. The description provides purpose and auth but omits return value expectations, processing behavior, error scenarios, or any guidance on selecting among the many options. For an agent invoking this tool, the description is insufficiently complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides; even the authentication detail is already in the apiKey parameter description. It only mentions 'same options as file-based classification' at a high level, which is not parameter semantics.

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

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

The description clearly states 'Submit a publicly accessible video URL for AI-generated content detection' — a specific verb, resource, and scope. It distinguishes from siblings by explicitly referencing 'file-based classification' and using 'URL' in the tool name.

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 'Supports the same frame extraction and analysis options as file-based classification' gives context for when to use this tool (video URL) versus the file-based sibling. Authentication guidance (apiKey parameter or X-Api-Key header) is a clear usage instruction. No explicit exclusions or alternatives are named, but the context is sufficient for differentiation.

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

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

No annotations are provided, so the description must carry the behavioral transparency burden. It adds useful facts about the batch limit ('up to 100 identifiers') and single-request behavior, but it does not disclose return format, error handling, or ordering behavior. This is minimal but non-trivial disclosure.

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

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

The description is two short sentences, front-loaded with the main purpose and constraint, with no filler or redundant restatement of the tool name.

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

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

The description covers the essential purpose and API limit, and the schema enriches parameter understanding, but with no output schema and no annotations, the agent lacks information about the return shape or failure behavior. A brief note on response format would make it more 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 describes both parameters completely, including the max-100 constraint for 'identifiers' and detailed apiKey guidance. The description adds only the clarifying context that identifiers refer to audio classifications, so it adds marginal 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 ('Retrieve') with a clear resource ('classification results') and scope ('multiple audio files in a single request'). This clearly distinguishes the tool from the singular get_audio_classification and the parallel get_all_image/video_classifications 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 phrase 'multiple audio files in a single request' implies the tool is intended for batch retrieval, which provides useful contextual guidance. However, it does not explicitly state when not to use it or name alternative tools, relying instead on sibling names for differentiation.

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 burden. It discloses the batch behavior and the 100-identifier limit, but it does not mention error handling, authentication nuances, rate limits, or response structure, leaving some behavioral gaps.

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

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

The description is two short sentences with the primary action front-loaded and no unnecessary words. It is highly scannable and efficient.

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 batch retrieval tool with no output schema, the description covers the core capability, input limit, and a typical use case. It could mention response format, but the basic context is sufficient for an agent to select and 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?

Schema description coverage is 100%, with both 'identifiers' and 'apiKey' fully described. The description merely restates the 100-identifier limit already in the schema, adding no new parameter meaning. 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 clearly states the tool retrieves classification results for multiple images in a single request, using a specific verb (retrieve) and resource (classification results for multiple images). This distinguishes it from the singular get_image_classification and other media-type 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 a clear usage context by noting it is 'useful for batch result polling,' implying when to use it instead of single-result tools. It does not explicitly mention exclusions or alternatives, but the batch vs. single distinction is 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?

No annotations are provided, so the description carries the full burden. It only states the basic operation and the max 100 constraint, which is already in the schema. No disclosure of behavior like error handling, pagination, result format, or authentication requirements.

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

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

The description is a single, front-loaded sentence with no redundant information. It is concise and easy to scan, earning every word.

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 batch retrieval tool with no output schema, the description lacks details about the response format (e.g., whether results are mapped by identifier, what fields are returned). However, the simplicity of the tool and the schema's parameter descriptions partially compensate, making it minimally adequate.

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. The description adds no meaning beyond the schema; it only restates the max 100 identifiers limit, already present in the schema.

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

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

The description uses the specific verb 'Retrieve' with the resource 'classification results for multiple videos' and a clear scope ('in a single request', 'up to 100 identifiers'). This distinguishes it from sibling tools like get_video_classification (single result) and classify_video (creation).

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 implies batch usage for multiple videos at once, but does not explicitly mention alternatives or exclusion cases. It gives clear context without stating when not to use it.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does disclose the key polling behavior, which is useful, but it omits details about what happens when the result isn't ready yet (e.g., error vs. empty response), rate limits, or other potential traps. This is a minimum-viable disclosure.

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

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

The description is two short sentences, directly states the primary action, and adds the crucial polling nuance without any filler or redundancy.

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

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

For a simple polling retrieval tool, this is largely complete: it names the prerequisite (previous submission), the identifier source, and the polling loop. It lacks specifics on return format or non-ready handling, but given the lack of an output schema and the tool's low complexity, it's adequate.

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

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

Schema coverage is 100%, so the description doesn't need to add parameter semantics, and it doesn't. Both apiKey and identifier have thorough schema descriptions; the tool description just reinforces that 'identifier' refers to the submission endpoint, adding no new meaning.

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 ('Retrieve the classification result') on a specific resource ('previously submitted audio file') and clearly distinguishes from sibling tools like get_image_classification or classify_audio by focusing on audio classification retrieval after submission.

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 provides clear context: the tool is for polling a previously submitted audio classification result. The phrase 'Poll until the result is ready' implies repeated calls after submission, but it doesn't explicitly name alternatives or exclusions, so it stops short of a 5.

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 burden. It discloses the read-only nature and the required condition, but lacks details on return format, behavior when the condition is not met, or error handling.

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

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

The description is a two-sentence, front-loaded statement with no redundancy. It efficiently conveys purpose and the key prerequisite.

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

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

No output schema or annotations exist, so the description must cover return semantics. It gives the purpose and prerequisite but omits the return format (e.g., image URL, base64) and error cases, leaving some ambiguity for an agent.

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 fully documents apiKey and identifier. The description adds no extra parameter context, but the baseline of 3 is appropriate when schema covers all params.

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 retrieves a visual heatmap highlighting AI-generated regions, with a specific verb 'Retrieve' and a concrete object. It distinguishes itself from sibling classification tools by focusing on heatmap retrieval.

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 the prerequisite that classification must have been submitted with withHeatmap enabled, giving clear context on when the tool is usable. It does not mention alternatives or when not to use it, but the precondition is valuable.

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 must carry the full burden. It discloses the key behavioral trait of asynchronous availability ('Poll this endpoint until the result is available'), which is useful. However, it does not describe return format, error behavior, rate limits, or any side effects. Given that this is a simple retrieval endpoint, the described behavior 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 two sentences, front-loaded with the verb and resource. Every sentence earns its place: the first explains the purpose, the second provides essential usage guidance. No fluff or repetition.

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 retrieval tool with two params and no output schema, the description covers the essential aspects: what to retrieve, how to get the identifier, and the polling behavior. It doesn't describe the response structure, but that might be a known format or less critical here. It also doesn't mention error cases, but the guidance is sufficient for a straightforward 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 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining that the 'identifier' is specifically 'returned by classify_image or classify_image_url', linking the parameter to its source. This enhances understanding beyond the schema's generic 'Classification identifier returned by the submission endpoint.' The apiKey param is not elaborated in the description, but the schema already covers it well.

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 purpose: 'Retrieve the classification result for a previously submitted image.' It uses a specific verb ('retrieve') and resource ('classification result for an image'), and distinguishes it from audio/video siblings by explicitly mentioning 'image' and the image-related submission tools ('classify_image or classify_image_url').

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

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

The description provides clear usage context: use the identifier returned from classify_image or classify_image_url, and poll until the result is available. This implies when to use (after submission) and gives polling guidance. It doesn't explicitly state 'do not use for audio/video', but the image-specific language makes the scope clear. Minor gap: no mention of alternative list retrieval tools like get_all_image_classifications.

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 burden of disclosing behavior. It clearly explains the polling requirement and what each result contains (verdicts and per-heuristic verdicts). It doesn't mention auth or error handling, but the core behavior is well covered.

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

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

The description is three sentences, each adding value: purpose, polling instruction, and result content. It is front-loaded and concise without fluff.

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 no output schema, the description adequately explains the result structure. It omits potential error cases or timeout handling, but the core functionality is fully covered for a simple polling 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 100% as both apiKey and batchId have descriptions. The tool description adds no extra parameter context beyond what the schema already 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 clearly states the tool's function: retrieving tampering detection results for a previously submitted batch of tickets. It uses a specific verb ('retrieve') and resource ('batch results'), and distinguishes itself from sibling tools focused on individual classification by mentioning 'batch' and 'tampering detection results'.

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 provides explicit guidance to poll until the 'done' field is true, establishing when to use this tool (after submitting a batch). However, it doesn't mention alternatives or when not to use it, though no direct alternative exists among 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?

With no annotations provided, the description carries the full burden. It uses 'Retrieve' which implies a read-only operation, and 'current available and used' hints at the response contents. However, it does not explicitly state that it does not consume credits, describe error conditions, or detail the return format. It is minimally 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 two sentences, front-loaded with the primary action and followed by a clear usage tip. Every word earns its place with no fluff or repetition.

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

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

For a simple tool with one optional parameter and no output schema, the description provides the essential purpose and a concrete use case. It does not describe the exact response fields, but the phrase 'available and used' gives a good hint. Given the tool's low complexity, the information is largely 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 only parameter (apiKey) has a 100% schema description that fully explains its purpose, when it's required, and how to obtain it. The tool description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the tool retrieves current available and used classification credits for the authenticated Identifai account. The verb 'Retrieve' plus the specific resource (credits) makes the purpose unambiguous and distinguishes it from all sibling classification and retrieval 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 provides explicit context: 'Use this to check quota status before submitting large batches.' This tells the agent when to invoke the tool, though it does not mention alternatives or exclusions. Since no sibling tool performs quota checks, the guidance is sufficient.

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 and explicitly discloses the asynchronous nature and the need to poll. This is critical behavioral context. It doesn't address error handling or output format, but the async/polling disclosure is valuable and beyond what the schema provides.

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

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

Two short, front-loaded sentences. The first sentence states purpose, the second explains the async/polling behavior. Zero 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?

Given the simple two-parameter schema and no output schema, the description covers the essential workflow: submit, get identifier, then poll here. It doesn't explain the return format or what 'ready' looks like, but the name and context make this minimally sufficient. Slightly more detail on the result would improve it.

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%, with both parameters clearly documented in the schema itself (identifier and apiKey). The tool description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states a specific verb ('Retrieve') and resource ('classification result for a previously submitted video'). It distinguishes itself from siblings like classify_video (submission) and get_all_video_classifications (listing) by targeting a single, previously submitted item.

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 'previously submitted video' and 'Poll until the result is ready' establish the intended use case after submission. It doesn't explicitly name alternatives, but the context implies when to use this tool versus submission or listing tools, so clear without being fully explicit.

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

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

No annotations are provided, so the description carries the burden. It discloses the mutation (override, sets result) but does not detail side effects, reversibility, permissions, or error behavior. It adds some context beyond the schema by specifying 'previously classified', but it leaves ambiguity about what happens if the identifier does not exist or if the override is permanent.

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 sentences with no wasted words. It is front-loaded with the action ('Manually override') and concise in explaining the result. Every sentence adds 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?

For a simple mutation tool with well-documented parameters in the schema, the description covers the core purpose and expected outcome. It lacks information about return values or error handling, but the absence of an output schema and the simplicity of the operation make this acceptable. It is nearly complete for the tool's 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 description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning; it does not elaborate on 'identifier' or 'classification' beyond what the schema already provides. It satisfies the minimum but provides no extra semantic value.

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 purpose: manually override the classification verdict for a previously classified audio file, with a specific outcome ('human' or 'artificial'). It distinguishes itself from sibling tools by explicitly scoping to audio, as opposed to override_image_classification or override_video_classification.

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 appropriate usage by mentioning 'previously classified audio file', suggesting it should be used after a classification exists. It does not explicitly name alternatives, but the audio-specific scope and context make the intended use clear without excluding edge cases. Missing explicit 'when not to use' but otherwise adequate.

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

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

No annotations are present, so the description must convey behavior. It states that the tool 'Sets the result' to one of two values, which implies a mutation of the existing classification. It does not disclose consequences such as whether the original is overwritten irreversibly, authentication requirements beyond the schema's apiKey description, or side effects on related records. The description is truthful but lacks depth.

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 sentences that are compact and front-loaded with the core action. Every clause adds value: 'Manually override', 'previously classified image', 'Sets the result to human or artificial', and 'Used for corrections and feedback'.

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, the description covers the essential aspects: what it does, how it works (sets to specific values), and when to use it. It omits return value or error behavior, but with no output schema and straightforward operation, the current level is adequate. However, a note on the response (e.g., confirms the override) or validation failure could make it fuller.

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%: each parameter is well-documented with types and descriptions, including the enum for classification. The description aligns with the schema by naming the two classification values but adds no extra semantic detail beyond the schema's own descriptions. Therefore, it meets the baseline but does not elevate it.

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 action: 'Manually override the classification verdict for a previously classified image.' It specifies the verb (override) and the resource (image classification), and lists the two possible result values ('human' or 'artificial'). The inclusion of 'image' distinguishes it from sibling override tools for audio and video.

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 'Used for corrections and feedback' provides explicit usage context, indicating this tool is for fixing misclassified images. It also implies that the image must already be classified ('previously classified'), setting the boundary versus classification tools like classify_image. However, it does not name alternative tools or state when not to use, so it stops short of full 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?

With no annotations provided, the description carries the disclosure burden. It clearly states the tool mutates state by setting a result to one of two values, which is the primary behavioral trait. However, it does not mention whether the override is reversible or what the response contains, though the simple setter nature makes these less critical.

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

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

Two sentences, no filler, front-loaded with the actionable verb 'override'. Every word earns its place, and the core information (what it does, what values it sets) is delivered immediately.

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

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

The tool is a simple setter with a fully documented schema and no output schema. The description covers the essential state-changing behavior and target values. It lacks details about return values or post-conditions, but the simplicity and schema completeness make it sufficiently usable for an agent.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context beyond the schema by explaining that the identifier refers to a prior classification and that the classification parameter determines the new verdict ('sets the result to either human or artificial'). This reinforces the meaning of both parameters without redundancy.

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 ('override') with a clear resource ('classification verdict for a previously classified video') and indicates the allowed outcomes ('human' or 'artificial'). It directly distinguishes this from sibling tools like classify_video or get_video_classification by focusing on manual correction.

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 'previously classified video' implies the tool should be used after an initial classification, but it never explicitly says 'use when the verdict is incorrect' or contrasts with alternatives like reclassifying. No when-not guidance is provided.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: independent analysis per ticket, async retrieval, PDF pages becoming separate entries, max batch size, and authentication options. It does not mention error handling, rate limits, or data retention, but the covered aspects are substantial.

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 four sentences long, front-loaded with the primary purpose, and every sentence adds value: submission purpose, async workflow, PDF handling, batch limit, and authentication. There is no redundancy or filler.

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 moderate complexity and lack of output schema, the description adequately covers the operational essentials: what to submit, how to retrieve results (batch_id via sibling tool), batch limits, PDF behavior, and authentication. It does not detail polling intervals or error scenarios, but those are reasonably deferred to get_tampering_batch_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 100%, so the baseline is 3. The description adds context like each PDF page becoming a separate entry and the async batch_id return, but these are more behavioral than parameter-specific. The schema already thoroughly explains apiKey, tickets, models, refIds, and filenames, so the description doesn't significantly enhance parameter understanding.

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 ('Submit') and resource ('ticket images... to the Identifai v2 API for batch tampering detection'), clearly distinguishing this tool from sibling classification tools. It also names the asynchronous retrieval tool (get_tampering_batch_results), reinforcing its unique role.

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 states that results are retrieved asynchronously via get_tampering_batch_results, providing a clear follow-up workflow. It also notes PDF support and the 10-ticket batch limit, giving practical usage context. However, it does not contrast with alternative submission tools (e.g., classify_image) or state when not to use it.

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