Frenchie
Server Details
OCR, transcription, file extraction, and image generation for AI agents via MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Lab94/frenchie-skill
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 7 of 7 tools scored. Lowest: 3/5.
Each tool targets a distinct operation: extraction, OCR, transcription, image generation, file upload, result retrieval, and job result fetching. No overlap in functionality.
All tool names use snake_case with a consistent verb_to_noun or verb_noun pattern, making them predictable and easy to understand.
With 7 tools, the set is well-scoped for file conversion and image generation, covering necessary steps without bloat.
The pipeline from upload to conversion to result retrieval is fully covered. Minor gaps like job management or deletion are not essential for the core workflow.
Available Tools
7 toolsextract_to_markdownExtract to MarkdownAInspect
Extract structured documents (.docx, .xlsx, .csv, .tsv, .pptx) into Markdown through Frenchie. stdio mode auto-saves the result to .frenchie//result.md; HTTP mode returns inline Markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. | |
| file_path | No | Absolute local file path. Stdio transport only — over HTTP, upload via upload_file first and pass uploaded_file_reference instead. | |
| uploaded_file_reference | No | Object key returned by upload_file. Required for HTTP transport; ignored when file_path is provided in stdio. |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobId | No | |
| result | No | |
| status | Yes | |
| creditsUsed | No | |
| resultExpiresAt | No | |
| estimatedCompletion | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds value by detailing auto-save behavior in stdio mode and inline return in HTTP mode, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence front-loads the core action and supported formats; the second efficiently covers mode-dependent details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 2 transport modes) and the presence of an output schema, the description fully covers purpose, supported inputs, mode-specific behaviors, and output format. No gaps remain for an agent to successfully select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema coverage (100%), but the description adds context about transport-specific usage (file_path for stdio, uploaded_file_reference for HTTP) and fallback behavior for api_key, which enriches the meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Extract structured documents into Markdown'), lists supported file types (.docx, .xlsx, .csv, .tsv, .pptx), and distinguishes it from sibling tools like ocr_to_markdown and transcribe_to_markdown by specifying input format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (stdio and HTTP) with different output behaviors, giving clear context on when to use each. However, it does not explicitly mention when not to use this tool or compare it to alternatives, 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.
fetch_result_fileFetch Result File (HTTP)ARead-onlyIdempotentInspect
Get a temporary download URL for a result file from OCR/transcription output. Use this to download images referenced as frenchie-result: in the result markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. | |
| object_key | Yes | The object key parsed from a frenchie-result:<objectKey> reference in the result markdown. |
Output Schema
| Name | Required | Description |
|---|---|---|
| filename | Yes | Suggested filename derived from the original object key. |
| expires_in | Yes | URL expiry in seconds (typically 900). |
| download_url | Yes | Temporary HTTPS download URL for the result file. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that the URL is temporary and mentions HTTP, which are important behavioral traits. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no redundancy or unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown but indicated), the description does not need to detail return values. It covers purpose and usage well, but could mention the URL's temporary nature more explicitly. Still complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with clear descriptions for both parameters. The description adds minor context like 'parsed from a frenchie-result:<objectKey>' but mostly mirrors the schema. Meets baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool fetches a temporary download URL for result files from OCR/transcription output. It distinguishes from sibling tools like get_job_result or upload_file by specifying this is for downloading files referenced in result markdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly tells when to use this tool: to download images referenced as frenchie-result: in the result markdown. However, it does not mention when not to use or provide alternatives, so a slight deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_imageGenerate ImageAInspect
Generate a single image from a text prompt through Frenchie (gpt-image-2). Required: prompt. Optional: style (free-text style direction), size, quality, format, background. stdio mode auto-saves the image to .frenchie//generated.; HTTP mode returns a presigned imageUrl that the agent should download for the user.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Optional output size. Defaults to model auto. | |
| style | No | Optional style direction (e.g. 'flat vector, neon palette'). Merged into the provider prompt by Frenchie. | |
| format | No | Optional output format. Defaults to png. | |
| prompt | Yes | Required. Plain-language description of the image to generate (e.g. 'poster of a ramen shop at night'). | |
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. | |
| quality | No | Optional output quality. | |
| background | No | Optional background. transparent is rejected when format is jpeg. | |
| output_dir | No | Stdio mode only: absolute directory under which .frenchie/<slug>/generated.<ext> is saved. Defaults to the MCP server's process cwd. Recommended: pass your workspace root so the image lands next to your work instead of $HOME. |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobId | No | |
| result | No | |
| status | Yes | |
| creditsUsed | No | |
| resultExpiresAt | No | |
| estimatedCompletion | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), description reveals auto-saving behavior in stdio mode and presigned URL return in HTTP mode. Also documents a constraint: transparent background is rejected when format is jpeg.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three succinct sentences: purpose, parameter summary, mode behavior. No superfluous information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mode differences, constraints), the description covers key aspects. The presence of an output schema reduces the need to detail return structure. Minor gap: no explicit guidance on parameter combinations or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. Description adds value by explaining mode-specific behavior for output_dir and summarizing optional parameters. It does not repeat schema details verbatim but provides context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates a single image from a text prompt, specifying the underlying model (Frenchie/gpt-image-2). It distinguishes itself from sibling tools (fetch, OCR, transcription, upload) which perform different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists required and optional parameters, and explains mode-specific behavior (stdio vs HTTP). While it doesn't explicitly state when not to use, the sibling tools are sufficiently distinct that misuse is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_resultGet Job ResultBRead-onlyIdempotentInspect
Fetch the latest async Frenchie job result
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job ID returned by ocr_to_markdown, transcribe_to_markdown, or generate_image when status was 'processing'. | |
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobId | No | |
| result | No | |
| status | Yes | |
| creditsUsed | No | |
| resultExpiresAt | No | |
| estimatedCompletion | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover safety and idempotency. The description adds 'async' and 'latest', indicating non-immediate behavior and versioning, but it does not clarify whether the job must be completed or if intermediate statuses are returned. This is adequate but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence—and front-loaded with the core action. However, it could include a brief usage hint without adding much length, so it is not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (though not provided), the description need not detail return values. However, it lacks context about when to expect a result (e.g., after job completion) and how it relates to sibling tools like 'fetch_result_file'. Minimal but functionally sufficient for a simple polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (job_id, api_key). The description adds no additional information about parameters, so with high coverage, a score of 3 is appropriate (baseline).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch the latest async Frenchie job result,' specifying the verb (fetch) and the resource (async job result). The tool name 'get_job_result' aligns well, and sibling tools like 'fetch_result_file' and 'generate_image' are distinct, 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.
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 that it is for polling after job submission, nor does it reference conditions like 'status was processing' (though the schema hint does). A user would not know the appropriate context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ocr_to_markdownOCR to MarkdownBInspect
Convert PDF/image files into Markdown through Frenchie
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. | |
| file_path | No | Absolute local file path. Stdio transport only — over HTTP, upload via upload_file first and pass uploaded_file_reference instead. | |
| uploaded_file_reference | No | Object key returned by upload_file. Required for HTTP transport; ignored when file_path is provided in stdio. |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobId | No | |
| result | No | |
| status | Yes | |
| creditsUsed | No | |
| resultExpiresAt | No | |
| estimatedCompletion | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description hints at external service ('through Frenchie') but does not disclose side effects, rate limits, or whether the operation is asynchronous. Annotations show readOnlyHint false, which implies mutation, but no further behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (7 words) but omits important context about workflow and behavior. While efficient, it sacrifices substance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, an output schema, and sibling tools suggesting an async workflow, the description fails to mention how results are obtained or how it integrates with upload_file and get_job_result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with clear descriptions. The tool description adds no extra information beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Convert PDF/image files into Markdown', specifying verb, resource, and output format. It distinguishes itself from sibling 'transcribe_to_markdown' which handles audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like transcribe_to_markdown or upload_file. No prerequisites or workflow hints are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transcribe_to_markdownTranscribe to MarkdownAInspect
Convert audio/video files into Markdown transcripts through Frenchie. Set language (ISO 639-1 code, e.g. 'th', 'en', 'ja') for better accuracy; omit for auto-detection.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. | |
| language | No | Optional ISO 639-1 language code (e.g. 'th', 'en', 'ja') for better accuracy; omit for auto-detection. | |
| file_path | No | Absolute local file path. Stdio transport only — over HTTP, upload via upload_file first and pass uploaded_file_reference instead. | |
| uploaded_file_reference | No | Object key returned by upload_file. Required for HTTP transport; ignored when file_path is provided in stdio. |
Output Schema
| Name | Required | Description |
|---|---|---|
| jobId | No | |
| result | No | |
| status | Yes | |
| creditsUsed | No | |
| resultExpiresAt | No | |
| estimatedCompletion | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds context about using an API key with fallback to environment variable, but it does not elaborate on network usage, file handling, or potential delays. Overall, it adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. It is concise with no redundant phrases, and the optional language hint is efficiently appended.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters and an output schema, the description is acceptable but could be more complete. It does not mention typical use cases, file format support, or limitations. For a simple conversion tool, it meets the minimum but leaves gaps in contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds slightly extra explanation for the language parameter (e.g., 'for better accuracy'), but it largely repeats schema information for api_key, file_path, and uploaded_file_reference. No essential new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Convert audio/video files into Markdown transcripts through Frenchie' with a specific verb and resource. It distinguishes from siblings like ocr_to_markdown (which handles images) and generate_image (which creates images), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance on setting the language parameter for better accuracy versus omitting for auto-detection, but it does not explicitly tell when to use this tool over alternatives like ocr_to_markdown or fetch_result_file. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_fileUpload File (HTTP)AInspect
Get a presigned upload URL for use with ocr_to_markdown, transcribe_to_markdown, or extract_to_markdown in HTTP mode. After calling this tool, PUT the file to upload_url (with the correct Content-Type header), then pass object_key as uploaded_file_reference to the processing tool.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Frenchie API key (fr_...). Falls back to the FRENCHIE_API_KEY env var when omitted. | |
| filename | Yes | Original filename with extension (e.g. 'report.pdf'). | |
| file_size | Yes | File size in bytes. | |
| mime_type | Yes | MIME type (e.g. 'application/pdf', 'audio/mpeg'). |
Output Schema
| Name | Required | Description |
|---|---|---|
| expires_in | Yes | URL expiry in seconds |
| object_key | Yes | Pass this as uploaded_file_reference to ocr_to_markdown, transcribe_to_markdown, or extract_to_markdown |
| upload_url | Yes | Presigned URL — PUT the file here with the correct Content-Type header |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false). Description adds that it returns a presigned URL and requires PUT, but doesn't detail error cases, rate limits, or auth beyond api_key param.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, efficient stepwise instruction. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for its purpose: explains how to chain with sibling tools, and output schema exists for return values. Given tool simplicity, covers all needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 4 parameters. Description adds no additional semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'get[s] a presigned upload URL' for use with specific tools (ocr_to_markdown or transcribe_to_markdown), distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use (before processing tools), provides step-by-step: PUT file to upload_url with correct Content-Type, then pass object_key as uploaded_file_reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!