PNG.now MCP Server

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

Goes beyond annotations by disclosing the external PNG.now dependency, the optional synchronous waiting behavior, and important SSRF/security rejections (private-network URLs, embedded credentials). It does not cover auth, rate limits, or cost implications, but with annotations and an output schema present, this is solid added context.

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 tight sentences: the first front-loads the operational flow and the second front-loads safety constraints. No filler 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?

Covers the core conversion flow and URL safety, but a 9-parameter tool with zero schema descriptions needs more parameter meaning. It also does not explain how the 'don't wait' path connects to get_conversion_status, leaving an agent to infer polling behavior.

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

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

Schema description coverage is 0% across 9 parameters; the description only clarifies source_url (public, no credentials) and hints that converter is a slug. Width, height, quality, strip_metadata, background_color, timeout_seconds, and wait_for_completion are entirely undocumented, so the description fails to compensate for the schema gap.

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 multi-step action: download a remote PNG/usable image URL, submit it to PNG.now with a converter slug, and optionally wait. The conversion-creation scope is distinguishable from siblings like get_conversion_status and list_converters.

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 'optionally wait for the result' phrasing implies you can poll later, and URL restrictions are stated, but the description never explicitly says when to use this tool versus get_conversion_status or list_converters. Usage is implied rather than directed.

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 safety is covered. The description adds the useful detail that results are scoped to 'the caller' (identity-derived, no parameters), but says nothing about freshness, caching, or what a rate-limit value means.

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

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

A single front-loaded sentence with no filler; every clause names a concrete returned field.

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, return-value details are unnecessary, and a zero-parameter read tool has little left to explain. Only minor gaps remain, such as whether the data is live or cached.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed by referring to 'the caller's' data rather than any query argument.

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 ('Return') and resource ('caller's PNG.now API credits, usage, and rate limit'), enumerating exactly what comes back. It is clearly distinct from the conversion-oriented siblings, though it doesn't explicitly contrast itself with them.

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

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

There is no explicit when-to-use statement or exclusion. Usage is only implied — an agent infers it should call this to check quota or rate-limit status — with no guidance on frequency or 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 declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description earns credit for disclosing that a completed job returns an absolute, temporary download URL, which tells the agent the result is unstable and must be consumed promptly. It doesn't describe intermediate states (pending/failed).

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 tight sentences with no filler, front-loading the object of the operation and following with the meaningful return-value caveat. Nothing superfluous, though it is quite terse for a job-status 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?

An output schema exists, so return values needn't be spelled out, and the description still flags the temporary-URL characteristic. What's missing is lifecycle context — what an incomplete or failed job yields and how often to poll — but for a one-parameter read tool this is close to 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 0%, so the single job_id parameter is undocumented in structured data; the description only implies it identifies a 'PNG.now conversion job'. That adds some meaning but no format or provenance detail, so it's minimum viable.

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 ('a PNG.now conversion job'), which cleanly separates it from the sibling convert_image_url that starts conversions. It never names a sibling explicitly, so differentiation relies on inference from 'conversion job'.

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 word 'Check' and by the fact a job_id is required, suggesting this polls an existing job. However, it never says where the job_id comes from (presumably convert_image_url) or when to poll versus give up, leaving the agent to infer the workflow.

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, so safety is covered; the description adds that the catalog is 'live' (results reflect current server state) and that returned values are slugs, which is useful context beyond the annotations. It does not discuss result count behavior relative to limit or the shape of the response. Minor tension: 'live' external catalog versus openWorldHint=false, though this is not a clear 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?

A single front-loaded sentence with concrete examples; nothing wasted. It is arguably slightly too short given the undocumented parameters, but that is a completeness issue rather than 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 an output schema present, return-format explanation is not needed, and the examples of slugs compensate somewhat. However, for a two-parameter search tool with zero schema coverage, the missing description of 'search' matching behavior and 'limit' semantics leaves a real gap.

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

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

Schema description coverage is 0%, so the description should carry the parameter burden, but it only gestures at 'search' and never explains matching semantics, nor mentions 'limit' or its 1-100 range and default. An agent gets no help on how to constrain or paginate results.

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?

Names a specific verb ('Search') and resource ('live PNG.now converter catalog'), plus concrete example outputs (png-to-jpg, compress-png) that make the tool's scope unmistakable. It does not explicitly contrast with convert_image_url, but the listing-versus-converting distinction is inferable from the examples.

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

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

Usage is only implied: an agent can guess this is the discovery step before calling convert_image_url with a slug, but no when-to-use, when-not-to-use, or alternative is stated. The mention of 'valid converter slugs' hints at the downstream purpose without spelling it out.

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