ppt-mcp

by ZiChuanLan

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but ppt_list_route_models and ppt_list_ai_models overlap conceptually, and ppt_check_route vs ppt_create_job may be confused as both initiate workflows. However, descriptions clearly differentiate high-level guided flow from low-level escape hatch, reducing real ambiguity.
Naming Consistency5/5
All tools share a consistent 'ppt_verb_noun' snake_case pattern, with clear action-object pairs. Verbs are consistent (list, get, set, create, download, check) and objects are specific, making the naming predictable and readable.
Tool Count4/5
16 tools is slightly above the ideal 3-15 range, but each tool maps to a distinct step in either the high-level guided workflow or low-level job management. The two parallel flows justify the count, making it reasonable.
Completeness5/5
The tool surface covers the full lifecycle: route selection, workflow state management, job creation, status tracking, cancellation, and result/artifact download. Both high-level and low-level paths are represented, leaving no critical gaps for the PDF-to-PPT conversion domain.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention side effects, whether a job is created, whether the workflow is locked or irreversible, or what the response contains. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and relies on undefined jargon. Brevity is not valuable when it sacrifices clarity and actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema, two parameters, and a pipeline of sibling tools, the description is severely incomplete. It does not explain the tool's role in the conversion workflow, prerequisites beyond a vague 'target and options ready', or the meaning of 'locked'. The agent is left to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate by explaining parameters. It does not mention route_workflow_id or retain_process_artifacts, nor does 'locked high-level workflow' clearly map to either parameter. The agent receives no meaningful parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the vague phrase 'locked high-level workflow' without stating that this tool converts PPT to PDF or triggers a conversion job. The verb 'Submit' is present, but the resource is undefined and does not distinguish it from sibling tools like create_job or submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'after target and options are ready' provides a sequencing hint, implying this tool should be used after set_conversion_target and set_route_options. However, it does not explicitly name alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'probes' something but does not reveal whether it performs network requests, what side effects exist, what it returns, or any authentication requirements. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, which is concise. However, it is under-specified rather than efficiently complete, leaving out crucial context that would make it a high-quality tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters and no annotations, the description is wholly insufficient for an agent to understand the tool's behavior, inputs, or expected output. Even though an output schema exists, the description does not explain what the probe actually checks or how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, and the description mentions none of the six parameters (api_key, model, options, base_url, provider, ocr_ai_chain_mode). The description adds no meaning beyond the bare parameter names, so it fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Probe') and a target resource ('the current AI OCR chain'), which suggests a validation/testing purpose. However, 'whether a model can work' is vague and does not define what success or failure looks like, nor does it clearly differentiate from sibling tools like ppt_health_check or ppt_check_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or context. It only states what it does at a high level, leaving the agent to guess when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It only states 'download to a local output path' without disclosing side effects like file creation, overwrite behavior, or the handling of the optional output_path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded with the verb and object, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and three parameters at 0% schema coverage, the description is too thin. It omits the relationship between job_id and artifact_path and does not explain what happens when output_path is null, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides minimal parameter context. It hints at output_path ('local output path') but does not explain job_id's role or clarify artifact_path. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Download' and resource 'retained artifact file', clearly indicating the action. It implicitly distinguishes from siblings like ppt_download_result and ppt_get_job_artifacts, though not explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states the action without mentioning prerequisites, exclusions, or relationships to other tools like ppt_get_job_artifacts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It only says 'download', not mentioning what happens when output_path is null, whether files are overwritten, or any potential errors. This is a significant gap for an operation that writes to the local filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no extraneous words. It is appropriately concise for the simple operation it describes, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, an output schema, and a simple parameter set, but the description lacks essential context: it does not clarify the relationship to a job, the optional output_path behavior, or any prerequisites. It is not complete enough for an agent to use reliably without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate. It implicitly refers to 'output path' but never mentions the required job_id parameter or explains the optional/nullable behavior of output_path. Parameters are effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Download') with a specific resource ('completed PPTX result') and destination ('local output path'). This distinguishes it from sibling tools like ppt_download_artifact, which is generic, and relates to the conversion workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, such as after job completion, or how it differs from alternatives like ppt_download_artifact. The word 'completed' implies a precondition, but it is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the core function. It does not mention that the operation is read-only, nor does it explain ordering (e.g., 'recent' by time), pagination, or the effect of the optional limit parameter. The description adds minimal behavior beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is front-loaded and appropriately sized for the minimal information it contains, making every word purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple interface (one optional parameter) and presence of an output schema, the description should at least clarify the behavior of the limit parameter and the meaning of 'recent'. Without these details, the description is incomplete for an agent to predict the tool's full behavior, even though the output schema may cover return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'limit' with no description, and schema description coverage is 0%. The description fails to explain the meaning or effect of 'limit', nor does it mention any parameter at all, leaving the agent to infer semantics solely from the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('List') and the resource ('recent conversion jobs') with a specific source ('wrapped local ppt API'). This clearly distinguishes it from sibling tools like ppt_get_job_status, which target individual jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage as a listing operation but provides no explicit guidance on when to choose it over alternatives, nor does it mention any exclusions or related tools. The name and action make the primary use clear, but no comparative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states only the action without disclosing side effects, error conditions, or what happens to the job after cancellation. This is a significant gap for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no fluff. It front-loads the verb and object, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cancel tool with one parameter and an output schema, the description gives the core purpose. However, it omits behavioral context like error handling or prerequisites, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention job_id at all. The schema only provides name and type, so the description fails to explain how to identify the job or any constraints on the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Cancel' and identifies the resource as 'conversion job', with a scope qualifier ('pending or running'). It clearly distinguishes from sibling tools like ppt_get_job_status and ppt_create_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cancelling jobs that are pending or running, but provides no explicit when-to-use or alternatives. It does not state what to do for completed jobs or mention other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly indicates a read-only metadata retrieval operation, but it does not disclose additional behavioral traits such as whether it returns empty results, requires specific permissions, or has rate limits. It adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant or irrelevant content. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description covers the basic action. However, it lacks usage guidance and parameter semantics, making it minimally viable but with clear gaps. The output schema mitigates return-format ambiguity, but the description alone is sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not compensate. The only parameter, job_id, is not described beyond the schema's title 'Job Id'. The phrase 'for a job' adds minimal context, but no format, constraints, or examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') with a clear resource ('debug/process artifact metadata for a job'). It distinguishes from sibling tools like ppt_get_job_status (status) and ppt_download_artifact (artifact download) by focusing on metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention typical workflow context (e.g., 'use to list artifacts before downloading') or exclude cases. The usage context is left entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what it checks, but doesn't disclose what occurs if the API is unreachable, timeouts, or expected response format. This is insufficient for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded, containing no waste. It states the core functionality immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple health check with no parameters and has an output schema (per context signals), so the description doesn't need to explain return values. The minimal description is sufficient for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the schema coverage is trivially 100%. No additional parameter context is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check') and the resource ('wrapped local ppt API'), and specifies the purpose (reachability). It is distinct from sibling tools like ppt_check_route, which checks a specific route, though it doesn't explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it implies a pre-flight connectivity check, it doesn't state any context or mention that other tools depend on this check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It adds useful behavioral guidance (repeat exact model IDs, don't invent categories/recommendations), but doesn't disclose return format, pagination, or any side effects/auth requirements beyond what's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a clear purpose: defining the tool, pointing to the alternative, and imposing output fidelity rules. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but with 0% parameter documentation and no parameter info in the description, the agent is left guessing on required fields. The usage guidance and purpose are clear, but the parameter gap makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the four parameters (api_key, base_url, provider, capability). The description fails to compensate for the missing schema explanations, leaving the agent without clues about how to fill these fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('low-level raw model discovery') and explicitly distinguishes from sibling `ppt_list_route_models` by recommending it for normal OCR flows. This makes the tool's purpose clear and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to prefer `ppt_list_route_models` in normal OCR flows, implying this tool is for raw/low-level discovery. However, it doesn't state specific scenarios where this tool should be used over the alternative, only the negative condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool returns status, stage, progress, and errors, providing useful behavioral context. However, it does not mention idempotency, safety, or behavior for invalid/unknown job IDs, which is a gap for a tool likely used in polling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the action and lists the key return fields efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description is nearly complete. It specifies what will be returned. It could mention polling behavior or that it is read-only, but the tool name and sibling context imply this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'job_id' parameter beyond the schema's field name and type. Since the description adds no meaning about how to obtain or format the job ID, it fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the current status, stage, progress, and errors for a job.' This clearly defines the tool's function and distinguishes it from siblings like ppt_cancel_job, ppt_list_jobs, and ppt_get_job_artifacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking job status but does not explicitly state when to use this tool versus alternatives or mention exclusions. For example, it does not contrast with ppt_list_jobs or explain that it is for a single job's detailed status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context about the workflow being 'locked' and the precondition, but doesn't mention whether the operation is read-only, what the output represents beyond 'candidate models', or any side effects. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every word earns its place. The precondition is stated succinctly without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema present, no annotations), the description is largely complete: it explains what the tool does and the required context. It doesn't detail return values (covered by output schema) or elaborate on 'candidate models', but that's acceptable for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The only parameter (route_workflow_id) is indirectly explained in the usage note ('same route_workflow_id'), making it clear it identifies the workflow, but no format, source, or additional semantics are provided. This meets the minimum threshold but doesn't fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists candidate models for a specific workflow ('currently locked high-level route workflow'), using a specific verb ('List') and resource. This distinguishes it from sibling tools like ppt_list_ai_models, which likely serve a different purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit precondition: only use after pdf_path and page range are confirmed on the same route_workflow_id. This gives clear context for when to use, though it doesn't name alternative tools or explicitly 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.
Behavior3/5
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 discloses a sequencing precondition (step 3) and a prerequisite (pdf_path/page range confirmation), but does not describe side effects such as whether prior options are overwritten, whether the operation is idempotent, or what happens on failure. This is partially transparent but lacks mutation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, front-loaded with the core purpose (Write decisions into workflow) followed by usage context and a clear warning. Every sentence adds value with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, 0% schema coverage, and no annotations, the description provides helpful guided-flow context (step 3) and a key precondition, but does not fully equip the agent to correctly set all parameters. The output schema exists but only specifies types/enums, not semantic relationships. It is adequate for a step in a flow but could elaborate on parameter decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and no parameter descriptions exist in the schema. The description maps high-level concepts ('scanned-page', 'footer', 'AI model') to parameter groups, which helps infer meaning for scanned_page_mode, remove_footer_notebooklm, and the OCR model fields. However, it does not explain individual parameters like route_workflow_id, ocr_ai_model_decision, or ocr_ai_model_choice_index, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Write' and identifies the resource (scanned-page, footer, and AI model decisions) and the destination (the workflow). It also distinguishes itself from the sibling tool ppt_list_route_models by referencing it as an alternative, clarifying its role as a setter rather than a lister.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ppt_list_route_models first (when user wants a non-default AI OCR model) and when NOT to use this tool (before pdf_path and page range are confirmed). This gives clear sequencing and alternative selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It discloses that the tool only locks the route, returns a route_workflow_id, and requires explicit user confirmation via route_confirmed. It could add more detail about side effects or reversible actions, but the 'only locks' phrasing limits ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose. Every sentence earns its place: the first states the action, the second explains the workflow position and output, the third lists follow-up tools. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the workflow position and return value, and an output schema exists, so the return is partially documented. However, the 'route' parameter remains unclear, and the tool's prerequisite (e.g., that the route comes from ppt_list_routes) is only implicit via siblings. Overall it is adequate but has clear gaps in parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameter meaning. It only vaguely hints at route_confirmed through 'after the user explicitly confirms it' and does not explain what the 'route' parameter should contain (e.g., a route name or ID from ppt_list_routes). The description fails to provide useful details about either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lock a high-level route workflow after the user explicitly confirms it,' which uses a specific verb (lock) and resource (route workflow). It clearly distinguishes itself as step 1 of a guided flow, differentiating it from sibling tools like ppt_convert_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is 'step 1 of the high-level guided flow' and lists the exact sequence of subsequent tools to call (ppt_set_conversion_target, ppt_list_route_models if needed, ppt_set_route_options, ppt_convert_pdf). It also says 'It only locks the route,' clarifying what the tool does NOT do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses persistence into a locked workflow, requires explicit user-provided pdf_path, and warns that page scope is not complete until page_range_confirmed=true is written. It does not discuss lock semantics or overwrite behavior, but the critical behavioral constraints are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with the primary purpose, then context, then two critical operational warnings. Every sentence earns its place; there is no fluff or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 an output schema (not shown), the description provides good context: its place in the flow, persistence rationale, and confirmation semantics. It could further explain page_start/page_end vs page_range_decision relationships, but it suffices for an agent to select and invoke the tool correctly in most guided-flow scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. It adds meaning for pdf_path (must be real local PDF path) and page_range_confirmed (must be explicitly true before scope is complete), and mentions 'page range decisions' for page_range_decision. However, page_start/page_end interaction and route_workflow_id semantics are left implicit, so compensation is only partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement: 'Write pdf_path and page range decisions into a locked route workflow.' It clearly identifies the tool's purpose as persisting conversion target state and explicitly labels it as 'step 2' of a guided flow, distinguishing it from sibling tools like ppt_set_route_options and ppt_convert_pdf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance: it is step 2 of a guided flow, used to persist state so weaker models don't need to remember page ranges. It also sets a firm prerequisite that pdf_path must be a real local PDF path explicitly provided by the user. It does not name alternatives or state when not to use it, but the sequential flow context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the PDF is read from local disk by this MCP server and uploaded to the running PPT API. It also highlights the safety requirement (explicit user override). However, it does not cover side effects, job persistence, or error behavior, so it is not fully transparent. Still, it adds meaningful behavioral context beyond basic mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-line purpose, a concise process explanation, a clear recommendation for alternatives, and a strong safety warning. Every sentence earns its place, and the most critical info (when to use) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (which presumably explains return values) and is a low-level job creation operation. The description covers the process, prerequisites, and safety constraint. However, it doesn't mention what a 'job' is or describe any lifecycle behaviors. Given the output schema, the description is mostly complete but could add a bit more context about job semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description compensates for pdf_path (must be a real existing local PDF path) and low_level_override_confirmed (must be confirmed), but it does not explain the 'options' parameter at all. With three parameters and no schema descriptions, partial coverage merits a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a PDF-to-PPT conversion job from a local pdf_path.' It also distinguishes itself from sibling tools by labeling itself as a 'low-level escape hatch' and contrasting with the normal guided workflow (ppt_convert_pdf). This is a specific verb+resource with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it says to prefer the guided route workflow (listing exact steps) and explicitly states 'Never use this tool unless the user explicitly asks to bypass the guided route workflow and confirms low_level_override_confirmed=true.' This is a clear when/when-not with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 behavioral constraints: the tool only lists routes and must not infer or recommend one. It also states the expected next step, which clarifies the tool's limited role. However, it does not describe data source, latency, or any potential errors, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose, followed by critical usage constraints. Every sentence earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description need not explain return values. It provides complete context for the agent: list routes, ask the user, then call `ppt_check_route`. This is sufficient for correct invocation within the sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to explain. Per rubric, this yields a baseline of 4. The description adds no parameter details because none exist, and that is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states the tool's purpose: 'List human-friendly routes for the user to choose from.' It uses a specific verb ('List') and resource ('routes'), and clearly differentiates its role from the sibling `ppt_check_route` by framing listing as a pre-step to checking a chosen route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Do not choose, infer, or recommend a route on the user's behalf' and explicitly directs the next action: 'call `ppt_check_route` with that route and `route_confirmed=true`.' This tells the agent exactly when and how to use the tool within the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

ppt-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![ppt-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ZiChuanLan/ppt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ZiChuanLan/ppt-mcp)

Score Badge

Copy to your README.md:

[![ppt-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ZiChuanLan/ppt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ZiChuanLan/ppt-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ZiChuanLan/ppt-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server