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 3.9/5 across 7 of 7 tools scored. Lowest: 3.2/5.
Each tool targets a distinct operation: document extraction, OCR, transcription, image generation, async job status, file download, and file upload. There is no overlap between conversion tools as they handle different file types.
Most tools follow a verb_noun pattern with underscores (e.g., upload_file, generate_image). However, some use 'to_markdown' suffix inconsistently (extract_to_markdown, ocr_to_markdown) and one uses an abbreviation (ocr), which slightly deviates from a strict pattern.
With 7 tools, the server covers upload, three distinct conversion types, image generation, async job polling, and result retrieval. This is well-scoped for a media processing assistant, neither over- nor under-provisioned.
The tool surface provides the core workflow (upload, convert, retrieve results) for multiple media types. Minor gaps include lack of result deletion or listing past jobs, but agents can still function effectively without those.
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. 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 automatic selection. | |
| style | No | Optional style direction (e.g. 'flat vector, neon palette'). Merged into the generation 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?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds that the tool auto-saves files (side effect) and returns a URL in HTTP mode. It also mentions the background rejection rule with jpeg. This exceeds annotation information, though it could mention more about idempotency or error cases.
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 three sentences: first states purpose, second lists parameter categories, third explains mode-specific behavior. Every sentence earns its place, and the information is front-loaded. 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?
Given the complexity of 8 parameters, the presence of an output schema, and the annotations, the description covers purpose, parameter summary, mode behavior, and a constraint. It is complete enough for an agent to select and invoke the tool correctly.
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%, so the schema already describes each parameter well. The tool description summarizes them but adds little new meaning beyond restating schema information. The description does clarify that output_dir is stdio-only, but that is also present in the schema description.
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 'Generate a single image from a text prompt through Frenchie.' This is a specific verb+resource combination, and it distinguishes the tool from siblings (extract, fetch, OCR, etc.) which handle different media operations.
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 lists required and optional parameters, and explains how to handle output in different modes (auto-save in stdio vs download URL in HTTP). This provides clear context for usage, though it does not explicitly state when not to use this tool or list alternatives.
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, idempotentHint, and destructiveHint. The description adds that it fetches an async result, but does not disclose error conditions (e.g., job not ready, invalid id) or specify the return format beyond what the output schema provides.
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 sentence with no wasted words. Minor improvement could be removing the potentially misleading 'latest'. Overall efficient and front-loaded.
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 presence of an output schema and generous annotations, the description is minimally adequate. However, it lacks guidance on handling 'processing' status vs. final result, and does not mention that the result may be fetched multiple times idempotently.
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% description coverage; both parameters (job_id and api_key) are well-documented. The tool description adds nothing 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?
The description clearly states the action ('Fetch') and the resource ('async Frenchie job result'). However, the word 'latest' is misleading because the tool requires a specific job_id, not the most recent one. It distinguishes itself from siblings which initiate jobs.
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 implies usage after obtaining a job_id from ocr_to_markdown, transcribe_to_markdown, or generate_image, but does not explicitly state when or when not to use it, nor does it mention alternatives or prerequisites.
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?
Annotations already indicate write behavior (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds the fallback behavior for the API key but does not elaborate on other behavioral traits like rate limits or side effects.
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 sentence with no unnecessary words. It is front-loaded with the core purpose, but it could be slightly expanded to include usage context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and full parameter coverage, the description is adequate but minimal. It mentions the output format (Markdown) and service (Frenchie), but does not clarify what 'Frenchie' is or how to obtain credentials beyond the API key fallback.
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 input schema already documents each parameter thoroughly. The tool description does not add additional meaning beyond the schema's descriptions.
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 'Convert PDF/image files into Markdown through Frenchie' clearly identifies the tool's action (convert) and resource (PDF/image to Markdown). However, it does not distinguish from sibling tools like 'extract_to_markdown' or 'transcribe_to_markdown', which have overlapping purposes.
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 mentions transport-specific details (file_path vs uploaded_file_reference) but does not clarify scenarios for using ocr_to_markdown over siblings.
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 non-read-only, non-destructive, non-idempotent behavior. The description adds the 'through Frenchie' detail, implying an external service call, but does not disclose auth requirements, rate limits, or processing constraints.
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, no wasted words, front-loaded with the core function. The key parameter hint is placed right after the main statement.
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 full schema coverage and annotations, the description covers the primary use case and a key parameter. However, it omits the transport distinction (file_path vs uploaded_file_reference) and does not mention the need for file upload (upload_file sibling) for HTTP transport, which is relevant 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?
Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the language parameter but adds no new meaning beyond the schema. 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?
The description uses a specific verb ('Convert') and resource ('audio/video files into Markdown transcripts'), clearly distinguishing it from sibling tools like ocr_to_markdown (images) and extract_to_markdown (text). The mention of language codes adds precision.
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 explicit guidance on when to use this tool versus alternatives. Sibling tools exist (ocr_to_markdown, extract_to_markdown) but the description does not mention when to choose this one over them or provide exclusions.
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?
Describes the intended workflow but does not discuss error handling, rate limits, or authentication specifics beyond the optional api_key. Annotations indicate non-read-only and open-world, but description adds context about subsequent PUT step. No contradictions.
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, followed by step-by-step instructions. No redundant or extra 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?
Explanation covers the full workflow from obtaining the URL to using it with processing tools. Mentions the correct Content-Type header requirement. Output schema likely documents return fields, so no need to repeat that.
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 adequate schema descriptions. Description does not add significant extra meaning beyond the schema, but the usage context is implied. 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?
Clearly states it gets a presigned upload URL and specifies the downstream tools (ocr_to_markdown, transcribe_to_markdown, extract_to_markdown). Distinguishes from sibling tools which are processing tools.
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?
Provides explicit when-to-use instructions: before using the listed processing tools. Gives step-by-step workflow: tool returns upload_url and object_key, then PUT file to upload_url and pass object_key as 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!