crepe-mcp

by mariolpantunes

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool has a distinct target resource and action, from presentation lifecycle operations (create, get, set, delete, compile) to separate search sources (academic, web, Wikipedia, fetch URL). The only overlapping area is set_slide handling add/replace/insert, but its description clearly parameterizes the behavior.
Naming Consistency3/5
Presentation tools consistently use verb_noun names (list_presentations, create_presentation, delete_slide, compile_presentation), but search tools shift to noun_verb order (academic_search, web_search, wikipedia_read). All names are snake_case and verbs are clear, so the inconsistency is moderate rather than chaotic.
Tool Count3/5
17 tools sits in the borderline heavy range. The count is justified if the server intentionally combines presentation creation with research utilities, but the two distinct domains could feel bloated. Each subdomain alone would be well-scoped.
Completeness4/5
The presentation workflow covers the full lifecycle: create, read, update, delete, import/export, compile, and visual validation. The research tools handle web, academic, Wikipedia, and URL fetching. Minor gaps exist (e.g., no direct slide reordering, no academic PDF full-text fetch), but agents can achieve these with existing tools or workarounds.
Average 4.1/5 across 17 of 17 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 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
This repository is licensed under MIT License.
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

Behavior3/5
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 explicitly states that the tool deletes in-memory state and on-disk scratch dir, which clearly communicates the destructive scope and implies non-destruction of the presentation itself. However, it does not mention idempotency, error behavior, or whether the presentation becomes unusable after cleanup, leaving some uncertainty.
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, front-loaded sentence with no wasted words. It efficiently conveys the operation and its targets, making it both brief and clear.
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 that an output schema exists, return values are likely covered. The description provides the core operation but lacks usage guidance, edge-case behavior, and prerequisites. For a one-parameter cleanup tool, this is minimally viable but not comprehensive, especially considering the lack of annotations.
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?
The schema has no descriptions for presentation_id (0% coverage). The description references 'a presentation' but does not explicitly explain the parameter's meaning beyond the parameter name itself. It does not clarify the format, required context, or relationship to other objects. The description adds minimal value in compensating for the missing schema descriptions.
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 identifies a specific verb ('Delete') and a precise resource ('presentation's in-memory state and on-disk scratch dir'). This clearly distinguishes it from sibling tools like create_presentation, get_presentation, or delete_slide, which operate on the presentation or slides themselves. The scope of deletion is explicit, leaving no ambiguity about what this tool does.
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 versus alternatives. It does not mention typical workflow positions (e.g., after render_slides_as_pngs or export_presentation_source), nor does it note any exclusions or sibling tools that might be more appropriate for similar tasks. The intended usage is only implicit in the name 'cleanup'.
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 transparency burden. It explicitly discloses the optional side effect of writing files when output_dir is provided, and clarifies the default behavior is returning source. However, it leaves the effect of theme/highlight_style on the output unclear, which slightly reduces transparency.
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: a clear purpose statement, output_dir behavior, and a parameter cross-reference. It is front-loaded, with no fluff or redundant information.
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 core purpose and one side effect, and an output schema exists to explain return values. However, it omits the required presentation_id parameter and provides vague parameter semantics, making it only partially complete for a 4-parameter tool.
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. It explains output_dir's write behavior well, but theme/highlight_style are only cross-referenced to compile_presentation, and presentation_id is not mentioned at all. The required parameter and theme semantics are left ambiguous.
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 returns the pandoc source (slides Markdown + config.yml) for a presentation. The verb 'Return' and resource specification distinguish it from siblings like compile_presentation and import_presentation_source.
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 use when the raw source is needed, but it doesn't provide explicit when-to-use/when-not-to-use guidance or name alternatives. The phrase 'this presentation compiles from' hints at the relationship, but no exclusions or explicit alternatives are given.
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 full burden. It adds the 'zero-based' indexing detail and implies a read-only operation via 'Return', but it does not disclose error behavior, return format, or any other edge-case behavior. The description is minimal but sufficient for a simple read 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, front-loaded sentence with no wasted words. Every element earn its place: the verb, the object, and the crucial indexing detail.
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, the presence of an output schema, and the two parameters, the description covers the essential usage. It lacks only explicit guidance on when to use it versus get_presentation, and does not mention potential out-of-bounds behavior, but these are minor gaps for this straightforward read 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. It clarifies that slide_index is zero-based, adding meaningful semantics beyond the schema's type declaration. presentation_id is not described, but its purpose is obvious from the parameter name and sibling context.
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 a specific verb ('Return'), resource ('full content of a single slide'), and the indexing convention ('zero-based index'). This distinguishes it from siblings like get_presentation (whole presentation) and set_slide (mutation).
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 when needing a single slide's content, but does not explicitly compare to alternatives such as get_presentation, nor does it state when not to use it. No exclusions or alternative recommendations are provided.
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 must itself convey behavioral traits. It discloses the output type (PNG sequence) and a dependency (compiled artifact), which is useful. However, it does not explicitly state whether the operation is read-only or if any side effects occur, leaving some ambiguity that annotations would normally cover.
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 extremely concise—two short sentences—with the core purpose front-loaded. Every word earns its place, and there is no redundancy or 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 essential purpose and a key prerequisite, and an output schema exists to document return values. However, it could be more complete by explicitly mentioning that the presentation must be compiled first or by clarifying the optional parameters (dpi, output_dir). The current text is adequate but leaves room for an agent to misunderstand the workflow.
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. It only adds meaning for the 'format' parameter (must match a previously compiled artifact), but does not explain presentation_id, dpi, or output_dir. The schema's defaults and types provide some information, but the description adds little beyond the format constraint.
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 converts a compiled artifact into a numbered PNG sequence for visual validation. It uses a specific verb ('Convert') and resource ('compiled artifact'), and the mention of 'numbered PNG sequence' distinguishes it from sibling tools like compile_presentation or get_slide.
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?
The description gives a clear use case ('for visual validation') and a prerequisite ('format must match a previously compiled artifact'), implying this tool is used after compilation. It does not explicitly name alternatives or state when not to use it, but the context suffices for a well-informed agent.
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 an important behavior: requires CREPE_TAVILY_API_KEY, and that a missing key returns an empty result with a warning field rather than an error. This adds meaningful context beyond the schema, though it does not mention rate limits or result structure.
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: the first states the core purpose, the second adds essential context about the API key requirement. Every sentence earns its place, with no redundant content.
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 (two parameters) and has an output schema, so the description need not detail return values. However, it lacks parameter guidance and does not differentiate usage from sibling tools, leaving some contextual gaps but not severely incomplete.
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%: the description provides no information about the 'query' or 'max_results' parameters. While the names are reasonably self-explanatory, the description does not explain semantics, format, or how max_results behaves, which is a significant gap given the low schema coverage.
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: 'Search the web via the Tavily API.' This is a specific verb ('Search') and resource ('the web'), and it distinguishes from sibling tools like academic_search, wikipedia_search, and fetch_webpage by explicitly covering general web search.
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 does not explicitly state when to use this tool versus alternatives. It implies general web search, but lacks exclusions or guidance such as 'use academic_search for scholarly articles.' The existence of siblings provides context, but the description itself does not offer usage direction.
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 the return type (titles, URLs, excerpts) and the workflow with wikipedia_read, but does not describe any limitations, error conditions, or side effects. For a simple read-only search, this is acceptable 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?
Two sentences, no unrelated content. The first sentence states the core function, the second provides an actionable next step. Very efficient.
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 is simple and the description covers the main purpose and a follow-up action. The output schema presumably handles return value details. It could mention the limit parameter, but overall it's sufficiently complete for an agent to select and use it correctly.
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. It does not explicitly describe the 'query' or 'limit' parameters. The name 'query' is intuitive from context, but 'limit' is not mentioned at all, and its default value is only in the schema.
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 'Search Wikipedia and return matching article titles, URLs, and excerpts.' This clearly identifies the verb (search), resource (Wikipedia), and output, distinguishing it from siblings like web_search and wikipedia_read.
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 clearly sets the context for searching Wikipedia and explicitly directs to use wikipedia_read for full articles. However, it does not explicitly contrast with other search tools like web_search or academic_search, so it lacks explicit exclusions.
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 the shifting behavior and the optional expected_slide_count guard, but does not detail consequences like irreversibility or index out-of-bounds handling. This is partial disclosure.
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 with no fluff, front-loading the primary action and adding the guard parameter note. Very efficient.
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 delete tool, the description covers the main purpose, a behavioral effect, and an optional parameter. It doesn't cover edge cases or return values, but the output schema exists. Overall, it's fairly complete.
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?
With 0% schema description coverage, the description explains the 'index' parameter by reference and the 'expected_slide_count' as a stale-state guard, but does not elaborate on 'presentation_id'. This partial compensation warrants 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 'Remove a slide by index' which is a specific verb and resource, and the effect on subsequent slides distinguishes it from sibling tools like get_slide or set_slide. No ambiguity.
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?
The description implies usage by describing the destructive action, but does not explicitly state when to use it versus alternatives like cleanup_presentation. It provides clear context for the expected_slide_count guard, but lacks explicit when-to-use or exclusion 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 provided, the description carries the full burden. It discloses key behavioral traits: the use of a headless browser if a specific path is set, the fallback to urllib with a warning, and the http/https restriction. This adds useful context beyond the schema, though it doesn't mention error handling or max_chars behavior.
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-loads the primary action, and every clause adds value. It is concise without being under-specified, achieving high information density in minimal text.
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 output schema exists (so return values are documented) and the tool is simple, the description covers the main purpose, protocol restriction, and implementation fallback. However, it could mention the max_chars parameter's effect or potential failure modes, but overall it is fairly 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.
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 explain the parameters. It does not mention max_chars at all, and even the url parameter's format is only implied by the http/https restriction. The tool has 2 parameters, and the description adds no semantic value over the bare schema, leaving a significant gap.
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 extracts readable plain text from a URL, specifies the http/https restriction, and distinguishes it from sibling search tools by focusing on raw URL fetching. The verb 'extract' is specific and the resource (URL) is clear.
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?
The context of when to use this tool is implicit: when you need to retrieve plain text from a specific URL. It doesn't explicitly exclude alternatives or mention sibling tools, but the purpose is clear enough that an agent would know not to use it for search or presentations. Lacks explicit when-not guidance, but clear context earns a 4.
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 full transparency burden. It discloses the partial-update behavior ('Only fields given a value are changed'), which is valuable, but it leaves ambiguity about null handling (e.g., whether null clears a field) and does not mention permissions, errors, or reversibility.
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 verb and resource, with no wasted words. Every piece of information (scope, fields, partial update) earns its place.
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 metadata-update tool, the description is adequate but has gaps: it doesn't clarify how to clear a field (since null is allowed), nor does it mention prerequisites or failure modes. The existence of an output schema may cover return values, but the description alone is not fully complete.
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?
Schema coverage is 0%, so the description must compensate. It names the updatable fields and explains the update semantics, which is critical given the schema only lists types and defaults. Presentation_id is implied as the target identifier, though not explicitly described.
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 updates title-slide metadata on an existing presentation and enumerates the specific fields (title/subtitle/author/institute/date). This distinguishes it from siblings like create_presentation and set_slide, which handle creation and slide content respectively.
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?
The description provides clear context: it operates on an existing presentation and only changes fields given a value. It does not explicitly name alternative tools or state when not to use it, but the scope is clear enough to infer appropriate usage.
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 full burden. It discloses that the tool writes directly to an absolute output_path, compiles the in-memory presentation, and distinguishes PDF vs PPTX behavior. However, it doesn't mention whether existing files are overwritten, permission requirements, potential errors (e.g., missing lualatex), or side effects beyond file creation.
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 well-structured, with the main action and follow-up step in two sentences, followed by a tight parameter list. No wasted words; every line adds value.
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 tool with 6 parameters and no annotations, the description covers the core workflow, output formats, and parameter constraints. The presence of an output schema reduces the need to explain return values. However, the missing presentation_id explanation and lack of error/overwrite behavior keep it from being fully complete.
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?
Schema description coverage is 0%, so the description must explain parameters. It does explain output_path (absolute), format ('pdf' or 'pptx'), theme (Beamer theme, PDF only, default 'moloch'), highlight_style (default 'tango'), and reference_doc (pptx template, optional). The required presentation_id is omitted, but all other parameters receive meaningful context beyond their raw schema types.
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 ('Compile') and resource ('the in-memory presentation') while specifying the output formats (PDF or PPTX) and destination. It clearly distinguishes itself from sibling tools like export_presentation_source (source export) and render_slides_as_pngs (image rendering).
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 advises calling render_slides_as_pngs afterwards for visual validation, and gives format-specific constraints (theme for PDF only, reference_doc for PPTX only). However, it doesn't explicitly state when to choose this tool over alternatives like export_presentation_source, leaving some room for ambiguity.
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 must disclose behavior on its own. It clarifies that this is a read operation (via 'Return') and provides specific details about the returned data, including slide previews and artifact existence. This goes beyond a generic description.
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 that front-loads the core action ('Return') and packs specific, useful details without wasted words. Every component earns its place.
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 read-only tool with one parameter, the description adequately covers the essential aspects of the response (metadata, slide list, artifacts). It does not mention error handling or pagination, but these are not critical for this straightforward 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?
The single parameter 'presentation_id' is not described in the schema and the description does not explicitly reference it. However, the parameter's purpose is self-evident from the tool name and context, so the description adds minimal but sufficient meaning for this trivial case.
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 'Return' and clearly identifies the resource: a presentation's metadata, ordered slide list, and compiled artifacts. This distinguishes it from sibling tools like get_slide (single slide) and list_presentations (list of presentations).
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?
The description provides clear context by detailing exactly what the tool returns, allowing an agent to infer when to use it (e.g., when a full presentation overview is needed). However, it does not explicitly mention alternatives or exclusions such as 'use get_slide for a single slide'.
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 key behaviors: returns up to `limit` results, includes title/link (open-access PDF preferred), and truncates abstracts to 400 chars. It also states 'No API key required.' This goes beyond a simple 'search' statement and provides useful operational detail, though it omits rate limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. It is concise without sacrificing necessary detail, such as result fields and truncation limits.
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?
For a simple search tool with an output schema, the description fully covers the essential context: the source (Semantic Scholar), authentication ('No API key required'), result count behavior, and what each result contains. It provides enough for an agent to select and invoke the tool correctly, even without seeing the output schema.
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?
Schema description coverage is 0%, so the description must compensate. It explains `limit` directly: 'Returns up to `limit` results' — clarifying its effect on result count. The `query` parameter is implied by the tool's purpose ('Search... for academic papers'), making it self-explanatory. No syntax or examples are given, but for two simple params this is sufficient.
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+resource: 'Search Semantic Scholar for academic papers.' This clearly distinguishes it from sibling tools like web_search or wikipedia_search, which are more general or target different content. The purpose is unambiguous.
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 academic paper searches but does not explicitly mention when to use it instead of alternatives like web_search or wikipedia_search. 'No API key required' is a usage prerequisite, but no exclusion or alternative guidance is provided. The context is clear, but not explicit.
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 tool lists every presentation currently held in memory, which indicates a read-only operation and limits scope to in-memory objects. While it doesn't mention edge cases or side effects, the operation is simple and the phrase 'currently held in memory' adds useful behavioral context beyond a generic 'list presentations'.
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 that front-loads the purpose. Every word contributes value, with no unnecessary 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?
The tool is simple (no parameters) and an output schema exists, so the description does not need to explain return values. The description fully covers the tool's purpose and scope, making it complete for an agent to select and invoke it correctly.
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 has zero parameters, so the baseline is 4. The description's phrase 'every presentation' confirms there is no filtering or parameters, aligning with the schema. There is no additional parameter meaning needed.
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 every presentation currently held in memory, using a specific verb ('List') and resource ('presentations'). This distinguishes it from sibling tools like get_presentation (which retrieves a single presentation) and create_presentation (which creates one). The scope is explicit and unambiguous.
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 enumerating all in-memory presentations, but it does not explicitly state when to use this tool versus alternatives like get_presentation. No exclusions or alternative tool mentions are provided, so the guidance is only implicit.
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 transparency burden. It clearly indicates this is a creation operation (write behavior) and discloses that an empty presentation is created, returning an ID. It also notes that metadata is set here. It lacks explicit side-effect details (e.g., persistence, error conditions) but adequately conveys the core behavior.
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-loading the primary purpose in the first clause. Every sentence adds value: the first states the action and return value, the second frames the parameters as title-slide metadata. No redundant or filler content.
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, so return value details are not needed, but the description adds the key integration fact that the returned ID is required by other tools. For a simple create operation, it covers the essential context: the resource, the metadata parameters, and the prerequisite role. Minor gaps around error handling and edge cases keep it from a perfect score.
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?
Schema description coverage is 0%, so the description must compensate. It enumerates all five parameters (title, optional subtitle, author, institute, date) and labels them as 'title-slide metadata', adding semantic meaning beyond the parameter names. It could provide more detail on formats or interactions, but this is sufficient for self-explanatory parameters.
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 'Create' with the resource 'presentation' and specifies it creates an 'empty' presentation, clearly distinguishing it from siblings like list_presentations or update_presentation_metadata. It also mentions the return value and that it's required by other tools, uniquely identifying its role.
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?
The description explicitly states the returned presentation_id is 'required by every other Group-A tool', signaling that this tool should be used first as the creation entry point. It also says 'All title-slide metadata is set here', providing guidance on when to use it for initial setup. It doesn't mention alternatives but none are obvious for creation.
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?
Since there are no annotations, the description carries the burden of disclosing behavior. It explicitly states that content is truncated to max_chars characters, with a default of 15,000, which is a key behavioral trait beyond what the schema shows. It does not cover error cases, but for a simple fetch operation this is adequate.
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 concise sentences, front-loaded with the main purpose. Every sentence adds value: the first states the core action, the second clarifies the title requirement, and the third explains the truncation behavior. No filler or 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 (2 parameters, no annotations), the description covers the essential aspects: what it does, how to supply parameters, and key output behavior. The output schema exists to explain return values, so that is not the description's job. It could mention error handling for invalid titles, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for its parameters, so the description must compensate. It does so effectively by explaining that 'title' should be the exact article title from wikipedia_search and that 'max_chars' controls truncation with a default. Both parameters receive meaningful semantic context beyond their raw schema definitions.
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 begins with 'Fetch the full plain-text body of a Wikipedia article,' which clearly states the verb (fetch), resource (Wikipedia article body), and scope. This distinguishes it from sibling tools like wikipedia_search (which searches titles) and fetch_webpage (which is not Wikipedia-specific).
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?
The instruction that 'title should be the exact article title from wikipedia_search' provides clear workflow context: first search, then read. While it does not explicitly mention when not to use it or compare with alternatives, the guidance is sufficient for a typical usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly states the destructive nature ('Every slide it currently has is replaced'), clarifies that metadata is untouched, and details the parsing rules (splits on headings, ignores code blocks). This is exactly the kind of context an agent needs before using a replacement 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 concise and front-loaded with the primary action. It uses three focused sentences to cover the main behavior, parsing details, and constraints without any filler. Every sentence adds value, and the structure is easy to parse.
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's complexity (destructive import with parsing rules), the description covers the essential behaviors: replacement of slides, untouched metadata, prerequisite existence, and the required input format. Since an output schema exists, explaining return values is unnecessary. The description is complete enough for an agent to correctly select and invoke this tool.
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 schema description coverage is 0%, so the description must compensate. It does so by explaining that 'exactly one of markdown (inline content) or source_path (absolute path to a .md file) must be given,' thereby clarifying the two optional parameters. It also notes that presentation_id must already exist. This adds meaningful interpretation beyond the raw schema, though it could offer more detail on the id parameter itself.
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 and resource: 'Replace a presentation's slides by parsing pandoc slide Markdown.' This clearly distinguishes it from sibling tools like create_presentation or set_slide, and the inclusion of parsing mechanics further clarifies its unique 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?
The description provides clear context for when to use this tool: to replace all slides of an existing presentation with content derived from markdown. It states the prerequisite that presentation_id must already exist and the constraint that exactly one input source must be provided. However, it does not explicitly name alternative tools for different scenarios (e.g., set_slide for single-slide edits), so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: default append/replace logic, shift semantics for insert, and the concurrency failure behavior when expected_slide_count mismatches. It also details content format constraints for Pandoc Markdown and Beamer-specific syntax, which is critical for correct invocation.
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 dense but every sentence adds value—no filler. It is well-structured with clear sections for operational modes, content format, and concurrency guidance, making it easy to parse without sacrificing important details.
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?
For a tool of this complexity, the description covers all essential aspects: operation semantics, content format specifics, concurrency handling, and related tools. The presence of an output schema means return values don't need to be explained, and the description is otherwise complete for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It thoroughly explains insert, content (with examples), expected_slide_count, and index behavior relative to slide count. Presentation_id and title are self-evident from their names, so the description sufficiently compensates for the lack of schema descriptions.
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 'Add, replace, or insert a slide,' which clearly states the tool's function with a specific verb and resource. It further distinguishes itself from siblings like delete_slide and get_slide by detailing the different insertion/replacement modes, making the purpose unambiguous.
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?
It explicitly explains when to use insert=True vs insert=False, including edge cases like index >= slide count. It also recommends combining with delete_slide to move slides and suggests using expected_slide_count for concurrent calls, providing clear when-to-use guidance and pointing to get_presentation as an alternative for refreshing state.
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

Copy to your README.md:

[![crepe-mcp MCP server](https://glama.ai/mcp/servers/mariolpantunes/crepe-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mariolpantunes/crepe-mcp)

Score Badge

Copy to your README.md:

[![crepe-mcp MCP server](https://glama.ai/mcp/servers/mariolpantunes/crepe-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mariolpantunes/crepe-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/mariolpantunes/crepe-mcp'

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