RAR.now MCP Server

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

Annotations already declare openWorldHint=true, non-read-only, non-idempotent, so the safety profile is partly covered; the description still adds non-obvious context: the service fetches an external URL, private-network URLs and embedded credentials are rejected (an SSRF guard the agent should anticipate failing on), and completion can be deferred. It does not mention auth, rate limits, or what happens to already-submitted jobs if the call times out, which keeps it from a 5.

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

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

A single front-loaded sentence with no filler; the rejection rule is stated as a compact trailing clause. Slightly compressed to the point of ambiguity about the resource, but 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?

An output schema exists, so return values need no explanation, and the annotations cover the mutation profile. What is missing for a 9-parameter, open-world, non-idempotent conversion call is which parameters actually matter for this resource, how to obtain a valid converter slug, and how deferred results are retrieved.

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

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

Schema description coverage is 0% across 9 parameters, so the description must carry the meaning and it only touches two of them: 'converter slug' and the implicit waiting behavior of wait_for_completion. Seven parameters (width, height, quality, strip_metadata, background_color, timeout_seconds) are undocumented anywhere, and their image-oriented semantics conflict with the 'RAR archive' framing, leaving the agent to guess which apply.

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 concrete mechanism (download a URL, submit to RAR.now with a converter slug) but the resource is inconsistent across the definition: the tool name says 'convert_image_url', the title and description say 'RAR archive', and the schema is full of image parameters (width, height, quality, background_color). An agent cannot tell from prose alone whether it is converting images or archives, which is a real ambiguity rather than a stylistic quibble.

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 statement of when to choose this tool over the siblings get_conversion_status, list_converters, or get_api_usage. The phrase 'optionally wait for the result' hints that wait_for_completion=false implies polling elsewhere, but that routing is left entirely to inference, and nothing tells the agent where converter slugs come from (presumably list_converters).

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 and openWorldHint=true, so the safety profile is covered. The description adds that results are scoped to the caller's own account, which is useful context, but says nothing about rate-limit exhaustion behavior or what happens when no usage exists.

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

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

A single front-loaded sentence with no filler; the resource list (credits, usage, rate limit) is compact and informative. Nothing could be removed without losing meaning.

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

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

With an output schema present and zero parameters, the description only needs to establish purpose and scope, which it does. The remaining gap – behavior at rate-limit boundaries – is minor for a read-only status tool.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The description correctly signals that no input is required by describing the call as purely a read of the caller's state.

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 (Return) and a precise resource (caller's RAR.now API credits, usage, and rate limit), so an agent knows exactly what it retrieves. It doesn't explicitly contrast with siblings, but the domain is clearly distinct from the conversion tools, so confusion risk is low.

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

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

Usage is implied by the resource itself – an agent would call it to check quota or rate-limit status. There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives, though the sibling set offers no competing option for this 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 declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real value by disclosing that the returned download URL is absolute and temporary, which hints at expiry. It does not say what pending/failed states look like or how long the URL stays valid.

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

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

Two short sentences, front-loaded with the purpose, and the second sentence adds non-obvious information about the returned URL. 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?

An output schema exists, so return structure needn't be explained, and the temporary-URL caveat is a useful addition. However, for a polling tool the description omits the two things an agent most needs: what job_id refers to and how to behave while a job is not yet complete.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter, and it does not: job_id is never explained, nor is it stated where the ID comes from (presumably the response of a convert call). Only the existence of a job concept is conveyed.

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

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

States a specific verb and resource: checking the status of a RAR.now conversion job, and adds that a completed job yields an absolute temporary download URL. It implicitly contrasts with convert_image_url (which starts a job), though it never names the sibling explicitly.

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

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

Usage is implied — you call this to poll a job you already started — but there is no explicit guidance on when to call it, how often to poll, whether it is safe to call repeatedly, or what to do if the job is still pending. No alternative is named.

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 and openWorldHint=false, so the safety profile is covered. The description adds that the catalog is 'live' (content changes over time), which is useful context, but says nothing about how many results come back, whether results are paginated/truncated by limit, or how matching works. Note the mild tension between 'live catalog' and openWorldHint=false, though 'live' plausibly means fresh data rather than external open-world access.

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 well-formed sentence with the action front-loaded and no filler. The slug examples are justified since they define the output domain, though some of that space could have gone to the undocumented search/limit semantics.

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

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

An output schema exists, so return-value shape needn't be restated. For a read-only, filter-and-list tool the description covers what the tool produces (converter slugs) and that the source is live, which is enough to call it correctly, even if parameter detail is thin.

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 carry the burden for the two parameters and largely does not. It gestures at search behavior ('Search the live ... catalog') but never explains matching semantics (prefix/substring/case), and completely ignores limit with its default of 50 and maximum of 100.

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?

A specific verb-plus-resource statement: search the RAR.now converter catalog and return converter slugs, illustrated with concrete examples (rar-to-zip, rar-to-7z, rar-to-tar). It is clearly a discovery/list tool, not a conversion, so an agent can distinguish it from convert_image_url and get_conversion_status without opening a schema, though no sibling is named explicitly.

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

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

Usage is only implied: returning 'valid converter slugs' hints that this is a prerequisite lookup step before invoking a conversion, but the description never states when to call it, when not to, or which sibling to use instead. With no exclusions or alternatives named, the agent must infer the workflow.

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