Florence-2 MCP Server
The Florence-2 MCP Server processes images and PDF files by:
OCR: Extracting text from images or PDFs provided via file path or URL
Caption Generation: Creating descriptive captions for images provided via file path or URL
Hosts the repository for the Florence-2 MCP server, allows installation via git
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Florence-2 MCP Serverextract text from this screenshot of a document"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Florence-2 MCP Server
An MCP server for processing images using Florence-2.
You can process images or PDF files stored on a local or web server to extract text using OCR (Optical Character Recognition) or generate descriptive captions summarizing the content of the images.
Installation
Claude
Download the latest MCP bundle mcp-florence2.mcpb from
the Releases page,
then open the downloaded .mcpb file or drag it into the Claude Desktop's Settings window.
You can also manually configure this server for Claude Desktop.
Edit the claude_desktop_config.json file by adding the following entry under mcpServers:
{
"mcpServers": {
"florence-2": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/jkawamoto/mcp-florence2",
"mcp-florence2"
]
}
}
}After editing, restart the application.
For more information, see: Connect to local MCP servers - Model Context Protocol.
goose
Open this link
goose://extension?cmd=uvx&arg=--from&arg=git%2Bhttps%3A%2F%2Fgithub.com%2Fjkawamoto%2Fmcp-florence2&arg=mcp-florence2&id=florence2&name=Florence-2&description=An%20MCP%20server%20for%20processing%20images%20using%20Florence-2to launch the installer, then click "Yes" to confirm the installation.
You can also directly edit the config file (~/.config/goose/config.yaml) to include the following entry:
extensions:
florence2:
name: Florence-2
cmd: uvx
args: [ --from, git+https://github.com/jkawamoto/mcp-florence2, mcp-florence2 ]
enabled: true
type: stdioFor more details on configuring MCP servers in Goose, refer to the documentation: Using Extensions | goose.
LM Studio
To configure this server for LM Studio, click the button below.
Related MCP server: 🪄 ImageSorcery MCP
Tools
ocr
Process an image file or URL using OCR to extract text.
Arguments:
src: A file path or URL to the image file that needs to be processed.
caption
Processes an image file and generates captions for the image.
Arguments:
src: A file path or URL to the image file that needs to be processed.
process
Processes an image file with a custom prompt using the Florence-2 model.
Arguments:
src: A file path or URL to the image file that needs to be processed.
prompt: A custom prompt for the Florence-2 model.
License
This application is licensed under the MIT License. See the LICENSE file for more details.
Available Tools
2 toolscaptionA
Processes an image file and generates captions for the image.
| Name | Required | Description | Default |
|---|---|---|---|
| src | Yes | A file path or URL to the image file that needs to be processed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses basic behavior (process image, generate caption) but lacks details on performance, file size limits, or output format. With no annotations, it carries full burden and does adequately for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no redundancy. Every word contributes meaning, and it is front-loaded with the core function.
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 simplicity (one parameter, output schema exists), the description is complete enough for an agent to understand purpose. Slightly more context on output format would elevate to 5.
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 covers parameter 'src' with description 'A file path or URL to the image file'. The tool description adds no additional meaning beyond what the schema provides. Schema coverage is 100%, 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 uses a specific verb 'Processes' with a clear resource 'image file' and outcome 'generates captions'. It effectively distinguishes from the sibling tool 'ocr' which likely extracts text.
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 vs alternatives. Usage is implied from context (generating captions vs OCR), but no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ocrB
Process an image file or URL using OCR to extract text.
| Name | Required | Description | Default |
|---|---|---|---|
| src | Yes | A file path or URL to the image file that needs to be processed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, required permissions, rate limits, or any behavioral traits beyond the basic action. It is too minimal for a tool without 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 sentence, front-loaded, with no unnecessary words. It efficiently conveys the core purpose.
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 simplicity and presence of an output schema (not detailed here), the description covers the essential input and action. It could mention output format, but overall adequate for a straightforward OCR 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 description coverage is 100% for the lone parameter, which already describes 'src' as a file path or URL. The tool description adds no extra meaning, 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 (OCR) and the resource (image file or URL) and the output (extract text). It distinguishes from sibling tool 'caption' which likely does a different task.
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 vs alternatives. The description does not mention prerequisites, when not to use, or compare with sibling 'caption'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.3.14- Changed
caption1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "result": { + "items": { + "type": "string" + }, + "title": "Result", + "type": "array" + } + }, + "required": [ + "result" + ], + "title": "captionOutput", + "type": "object" +}
- Changed
ocr1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "result": { + "items": { + "type": "string" + }, + "title": "Result", + "type": "array" + } + }, + "required": [ + "result" + ], + "title": "ocrOutput", + "type": "object" +}
2 tool updates
- First observed
caption - First observed
ocr
TDQS
The caption and ocr tools have clearly distinct purposes: one generates image captions, the other extracts text via OCR. No overlap or ambiguity.
Both tool names are single lowercase verbs (caption, ocr), following a consistent and predictable pattern.
Only 2 tools for a server named after Florence-2, a multimodal model capable of many tasks (e.g., object detection, segmentation). This feels under-scoped and insufficient.
Obvious gaps exist: Florence-2 supports object detection, phrase grounding, region captioning, etc. The server only covers captioning and OCR, missing major capabilities.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation
MCP server for Wan AI video generation
MCP server for Grok Imagine AI video generation
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server for analyzing images using OpenRouter vision models, offering capabilities like automatic image resizing, model configuration, and handling custom queries about images.10MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server providing tools for image processing operations330PythonMIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides image generation capabilities using Google's Gemini 2.5 Flash Image Preview model.22MIT
- FlicenseNot gradedqualityCmaintenanceMCP server for generating and editing images using gpt-image-2. Enables image creation, editing, listing, and retrieval via natural language tools.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jkawamoto/mcp-florence2'
If you have feedback or need assistance with the MCP directory API, please join our Discord server