PPT.now MCP Server

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

Adds real context beyond annotations: private-network URLs and embedded URL credentials are rejected, and the tool is open-world (fetches an external URL). The annotations already cover readOnly/idempotent/destructive, so the security constraint is the value-add. It still doesn't say what happens on timeout or whether a partial/failed conversion is retryable.

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 dense sentence that front-loads the action and ends with the security constraint; nothing is redundant. It is slightly overloaded for a single sentence, but no clause is wasted.

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 described, and the security constraint is useful. But for a 9-parameter conversion tool with zero schema documentation, the description leaves too much unexplained — notably the converter slug vocabulary and the optional sizing/quality parameters that materially change output.

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 burden, yet it only touches source_url and converter (and implies wait_for_completion). Width, height, quality, strip_metadata, background_color and timeout_seconds — the image-rendering controls an agent must choose correctly — are completely unexplained, and 'converter slug' is never illustrated or linked to list_converters.

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 gives a specific verb chain (download, submit, optionally wait) and resource (a publicly accessible PowerPoint file / supported input URL submitted to PPT.now via a converter slug). It is clear enough to distinguish from get_conversion_status and list_converters, but the tool name 'convert_image_url' conflicts with the title and body, which are both about PowerPoint files — that mismatch costs a point.

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?

Mentions the optional wait ('optionally wait for the result'), which implicitly tells an agent that wait_for_completion=false leaves a job to be polled later. However, it never names get_conversion_status or list_converters as the follow-up/interrogation tools, and never states when a supported non-PowerPoint input URL is acceptable versus not.

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 names the returned data but adds little beyond that about freshness, authentication, or rate-limit behavior, and no contradiction is present.

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 efficient sentence with the key returned fields front-loaded. Every word contributes to the stated purpose and there is 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?

The tool is a simple no-parameter read operation with an output schema and read-only annotations, so the description is largely complete. It could mention when usage data refreshes, but that is a minor gap given the schema and annotations.

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 introduces no parameter semantics, which is appropriate because there are none.

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: returning the caller's PPT.now API credits, usage, and rate limit. The sibling tools are conversion-related, so this account-usage tool is clearly distinguishable.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives or what conditions call for checking usage. Usage is only implied by the tool name and description.

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 one useful behavioral fact — a completed job returns an absolute, temporary download URL — but says nothing about polling cadence, job state transitions, or URL expiry, which matter for a status-polling 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?

Two short sentences, front-loaded with the action, and the second sentence carries non-obvious information about the success payload. Nothing is wasted.

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

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

For a single-parameter polling tool with annotations and an output schema, the core is covered. The gaps — origin of job_id and what to do while a job is incomplete — are exactly the things the description should have supplied since the output schema can't.

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?

One parameter with 0% schema description coverage; the description never explains what job_id is or where to obtain it. It only implies the id refers to a PPT.now conversion job, which is minimal compensation 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 verb+resource: checking the status of a PPT.now conversion job. The name and phrasing distinguish it from the conversion-triggering sibling convert_image_url and the informational siblings list_converters/get_api_usage, though the description never explicitly names those alternatives.

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

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

No guidance on when to call this versus the conversion tools, and no stated prerequisite that job_id must come from a prior conversion request. The only implied usage is 'after you started a job', which the agent must infer.

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 safety and world-boundedness are covered structurally. The description adds that the catalog is 'live' and that results are guaranteed valid slugs, which is genuinely useful context, but there is a mild tension between 'live' remote catalog and openWorldHint=false that goes unaddressed.

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

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

A single front-loaded sentence with no wasted framing; the slug examples are legitimately useful for recognition. Slightly padded by the four-item example list, but it earns its length.

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 details are rightly omitted, and the tool itself is a simple two-parameter list operation. However, with zero schema coverage, the description leaves pagination limits and search matching behavior unexplained, which an agent needs to call it well.

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 parameter meaning and does not: neither 'limit' (1-100, default 50) nor 'search' (free-text matching behavior) is explained. Only a loose hint at searching exists, leaving both parameters undocumented in prose.

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 ('Search the live PPT.now converter catalog') and clarifies the return type ('valid converter slugs'), with concrete examples like ppt-to-pdf. It implicitly separates discovery from the sibling conversion tools, but never names them 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: an agent can infer this is a discovery/lookup step to obtain slugs before calling convert_image_url or a conversion endpoint. There is no explicit statement of when to use this versus the siblings, nor any prerequisite or exclusion.

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