Gemina FileTag
Server Details
Tag, rename, and enrich PDFs and images. Free tier: 1,500 tags/month, no credit card.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- tommyil/gemina-mcp
- GitHub Stars
- 0
- Server Listing
- Gemina FileTag
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.6/5 across 3 of 3 tools scored.
Each tool targets a distinct action: uploading local files, tagging an uploaded file, or tagging a remote URL. There is no ambiguity in their purposes.
All tool names follow a consistent verb_noun pattern (files_create_upload, tag_file, tag_url) using snake_case, with clear and predictable naming.
Three tools is appropriate for a focused file tagging service, covering the core workflow of uploading and tagging without unnecessary extras.
The server covers the primary use case of uploading and tagging files, but lacks post-tagging management like listing, updating, or deleting tags, which are notable gaps.
Available Tools
3 toolsfiles_create_uploadAInspect
Reserve a pre-signed PUT slot for a forthcoming file upload. Returns the upload URL, an upload.headers dict (the agent MUST echo every header in this dict on the PUT -- today that is just Content-Type), the slot expiry (5 minutes), and a next_tool_call recipe pointing at tag_file -- copy-paste the file_id to run the FileTag pipeline against the uploaded bytes. This is the canonical path for any file the agent holds locally; bytes never traverse the LLM context (they go directly from the agent host to GCS). Allowed types: PDF, PNG, JPEG, GIF, WebP. Max size 50 MB.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | No | Optional lowercase-hex SHA-256 of the file. When provided, the server verifies the uploaded bytes' hash before tagging. | |
| filename | Yes | Original filename including extension (e.g. ``invoice.pdf``). | |
| mime_type | Yes | MIME type of the file. Allowed: application/pdf, image/png, image/jpeg, image/gif, image/webp. | |
| size_bytes | Yes | Exact byte size of the file. Server validates the uploaded blob against this declaration at ``tag_file`` time and rejects mismatches before consuming the slot. |
Output Schema
| Name | Required | Description |
|---|---|---|
| upload | Yes | |
| file_id | Yes | |
| next_tool_call | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns upload URL, headers dict, slot expiry (5 min), next_tool_call recipe, direct-to-GCS transfer, allowed types, max size. Sufficient given no 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?
Concise at 4 sentences, front-loaded with main action, no wasted words. Well-structured for quick parsing.
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 4 parameters with full schema descriptions and output schema existing, the description covers all needed behavioral context for an agent to use the tool effectively.
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 baseline 3. Description adds value by mentioning SHA-256 verification and reinforcing type/size constraints.
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 'Reserve a pre-signed PUT slot for a forthcoming file upload' with a specific verb and resource. Distinct from sibling tools tag_file and tag_url.
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 instructions: echo all headers on PUT, copy-paste file_id to run tag pipeline, canonical path for local files, bytes not via LLM. Clear context but no explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tag_fileAInspect
Run the FileTag pipeline against a previously uploaded slot. The file_id comes from a prior files_create_upload call. The server validates the uploaded blob (size, content-type, optional SHA-256), atomically consumes the slot, runs the FileTag extraction (renaming + metadata embedding), and returns the structured result with the extracted metadata, the suggested filename, the enriched_file_url (short-lived signed URL to the renamed copy with metadata embedded into document properties), and a next_action recipe (http_get_and_save) telling the agent to download that URL and save it as the suggested filename -- act on it unless the user explicitly asked for metadata only. Each slot is single-use; reserve a new slot with files_create_upload to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | The ``file_id`` returned by a prior ``files_create_upload`` call, after the agent has completed the PUT to the signed URL. | |
| end_user_id | No | Optional end-user identifier (the entity the file belongs to). | |
| external_id | No | Optional caller-supplied identifier echoed in the result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| metadata | Yes | |
| document_id | Yes | |
| next_action | Yes | Structured copy-paste recipe for the post-tag follow-up: HTTP GET ``enriched_file_url`` and save as ``suggested_filename``. Mirrors the ``next_tool_call`` pattern from ``files_create_upload`` -- one structured instruction per step keeps multi-step flows reliable across volatile agent scratchpads. |
| enriched_file_url | Yes | Short-lived signed URL to the input file with the extracted metadata embedded directly into the document properties (XMP for PDFs, EXIF/XMP for images). This is the canonical enriched output of the tool -- the file the user actually wants. Agents should download it within ``enriched_file_expires_in_seconds`` and save it under ``suggested_filename`` rather than embedding metadata client-side. Skip the download only if the user explicitly asked for the metadata payload alone. |
| filename_patterns | Yes | |
| suggested_filename | Yes | Recommended filename for the enriched file -- one of the six ``filename_patterns``, picked as the safest default for general use. Pair this with ``enriched_file_url`` when saving the downloaded file. |
| document_extraction_id | Yes | |
| enriched_file_expires_at | Yes | Absolute UTC timestamp when ``enriched_file_url`` stops resolving. |
| enriched_file_expires_in_seconds | Yes | Seconds until ``enriched_file_url`` expires, captured at response time. Easier for agents to reason about than the absolute timestamp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it validates the blob, atomically consumes the slot, runs extraction, and returns a structured result including enriched_file_url and next_action. It also notes the side effect of the slot being single-use.
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 comprehensive but slightly verbose. It is front-loaded with the main action and proceeds with essential details. Every sentence adds value, but could be trimmed slightly without losing clarity.
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 the tool (multiple steps, output schema exists), the description is complete. It covers the entire pipeline, the output fields, and the expected agent action, leaving no ambiguity.
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 baseline is 3. The description adds meaning by explaining where file_id comes from (prior upload) and that it requires the agent completed the PUT. This adds context beyond the schema's type and 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 the tool runs the FileTag pipeline on a previously uploaded slot, specifying it uses a file_id from a prior files_create_upload call. It distinguishes itself from siblings (files_create_upload, tag_url) by detailing the specific workflow and output.
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 explicit usage guidance: it must be used after files_create_upload and the PUT operation, the slot is single-use, and the agent should act on the next_action (download and save) unless the user requests metadata only. It also mentions alternatives for retrying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tag_urlAInspect
Fetch a remote URL server-side and run the FileTag pipeline. The bytes never traverse the LLM context -- the agent supplies the URL, the server fetches under strict SSRF guards (HTTPS only, no private IP ranges, 30-second timeout, 50 MB cap, redirects disabled), and returns the structured tag result with metadata, suggested filename, enriched_file_url (short-lived signed URL to the renamed copy with metadata embedded into document properties), and a next_action recipe (http_get_and_save) telling the agent to download that URL and save it as the suggested filename -- act on it unless the user explicitly asked for metadata only. Use this when the file already lives at a public URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public HTTPS URL pointing at the file. Hostname must NOT resolve to a private/reserved address. Redirects are NOT followed -- agents must resolve them before invoking. | |
| end_user_id | No | Optional end-user identifier. | |
| external_id | No | Optional caller-supplied identifier echoed in the result. |
Output Schema
| Name | Required | Description |
|---|---|---|
| metadata | Yes | |
| document_id | Yes | |
| next_action | Yes | Structured copy-paste recipe for the post-tag follow-up: HTTP GET ``enriched_file_url`` and save as ``suggested_filename``. Mirrors the ``next_tool_call`` pattern from ``files_create_upload`` -- one structured instruction per step keeps multi-step flows reliable across volatile agent scratchpads. |
| enriched_file_url | Yes | Short-lived signed URL to the input file with the extracted metadata embedded directly into the document properties (XMP for PDFs, EXIF/XMP for images). This is the canonical enriched output of the tool -- the file the user actually wants. Agents should download it within ``enriched_file_expires_in_seconds`` and save it under ``suggested_filename`` rather than embedding metadata client-side. Skip the download only if the user explicitly asked for the metadata payload alone. |
| filename_patterns | Yes | |
| suggested_filename | Yes | Recommended filename for the enriched file -- one of the six ``filename_patterns``, picked as the safest default for general use. Pair this with ``enriched_file_url`` when saving the downloaded file. |
| document_extraction_id | Yes | |
| enriched_file_expires_at | Yes | Absolute UTC timestamp when ``enriched_file_url`` stops resolving. |
| enriched_file_expires_in_seconds | Yes | Seconds until ``enriched_file_url`` expires, captured at response time. Easier for agents to reason about than the absolute timestamp. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: server-side fetch, SSRF guards (HTTPS only, no private IP, 30s timeout, 50MB cap, no redirects), and that bytes never traverse LLM context. It also details the return structure and agent action steps.
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 paragraph that is somewhat lengthy, but it front-loads the main action and every sentence adds value. Could be more structured for easier parsing.
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 the tool, the output schema exists, and the description covers what the tool does, its constraints, output fields, and how to use the result. No gaps.
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%, baseline 3. The description adds meaningful context for the url parameter (SSRF constraints) but adds nothing for end_user_id or external_id beyond the schema. This extra context justifies a 4.
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 tool fetches a URL server-side and runs the FileTag pipeline, distinguishing it from siblings like files_create_upload and tag_file which handle local files.
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 states when to use: 'when the file already lives at a public URL.' Also provides post-invocation guidance about acting on next_action. However, it does not explicitly mention when not to use or direct alternatives.
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!
Your Connectors
Sign in to create a connector for this server.