How do I use filoo MCP server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@filoo MCP server Shorten https://example.com/very-long-url to slug 'blog'" 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.

filoo MCP server

by jrlprost

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

@filooapp/mcp-server

npm version license

The official MCP server for filoo.app — an AI agent URL shortener with built-in click tracking. Plug this into Claude Desktop, Cursor, or any other Model Context Protocol client and your agent can shorten URLs, manage links, and read scan analytics through 8 first-class tools.

If you are looking for an "MCP server URL shortener", a "Claude URL shortener tool", a "Cursor link shortener", or a way to give an AI agent its own short link namespace, this is it.

What is filoo

filoo is an API-first URL shortener built for both humans and agents. Each link lives under a username (filoo.app/{username}/{slug}), comes with a QR code, and tracks clicks with country, device, referrer, and source breakdowns. The agents tier gives you 50,000 active links, 5,000 new links per day, unlimited usernames, and a 1,000 requests/minute API rate limit — designed so a fleet of agents can hammer the API without throttling.

Docs and pricing: https://filoo.app/api

Related MCP server: DWZ Short URL MCP Server

Installation

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "filoo": {
      "command": "npx",
      "args": ["-y", "@filooapp/mcp-server"],
      "env": {
        "FILOO_API_KEY": "flo_live_xxxxxxxxxxxx"
      }
    }
  }
}

Restart Claude Desktop. Your agent now has the 8 filoo tools.

Cursor

In Cursor settings → MCP, add a new server:

{
  "filoo": {
    "command": "npx",
    "args": ["-y", "@filooapp/mcp-server"],
    "env": { "FILOO_API_KEY": "flo_live_xxxxxxxxxxxx" }
  }
}

Generic MCP client (stdio)

FILOO_API_KEY=flo_live_xxxxxxxxxxxx npx -y @filooapp/mcp-server

The process speaks JSON-RPC over stdio per the MCP spec.

Local install

npm install -g @filooapp/mcp-server
FILOO_API_KEY=flo_live_xxxxxxxxxxxx mcp-server-filoo

Configuration

Env var	Required	Description
`FILOO_API_KEY`	yes	Your filoo API key, starts with `flo_live_`. Get one at https://filoo.app/dashboard/api (pro, agents, or lifetime tier).
`FILOO_API_BASE`	no	Override the API base URL. Defaults to `https://filoo.app/api/v1`.

The 8 tools

Each tool maps 1:1 to a filoo REST endpoint. The descriptions below are what the LLM reads when deciding which tool to call.

`filoo_me`

Get the authenticated user's account: tier, usernames, boost credits, and limits.

Example prompt: "What's my filoo plan and how many links can I still create?"

`filoo_usage`

Today's usage vs. quotas: links created today, API calls today, active link count vs. cap.

Example prompt: "How close am I to my filoo daily limit?"

`filoo_list_usernames`

List every username you own and which one is primary.

Example prompt: "List all my filoo usernames."

`filoo_create_link`

Create a new short link. Args: destination (required), slug?, username?, label?.

Example prompt: "Shorten https://example.com/very-long-launch-page under my 'agency' username with slug 'q4-launch'."

`filoo_list_links`

Cursor-paginated list of your links, newest first. Args: limit? (max 100), cursor?.

Example prompt: "Show me my last 20 filoo links."

`filoo_get_link`

Fetch one link by code. Args: code (form username:slug).

Example prompt: "What does filoo link agency:q4-launch point to?"

`filoo_update_link`

Repoint or rename a link without changing its short URL. Args: code, destination?, label?, active?.

Example prompt: "Point filoo link agency:q4-launch to the new landing page at https://example.com/launched."

`filoo_delete_link`

Permanently delete a short link. Args: code.

Example prompt: "Delete the filoo link agency:old-promo."

`filoo_link_stats`

Click totals, uniques, bots, top countries, and top sources for a link. Args: code.

Example prompt: "How is filoo link agency:q4-launch performing? Show top countries and sources."

Getting an API key

Sign up at https://filoo.app
Upgrade to the agents tier (50,000 links, 5,000/day, 1,000 req/min) — it's purpose-built for AI agent workloads. The pro and lifetime tiers also expose the API.
Go to https://filoo.app/dashboard/api and create a key. It starts with flo_live_.
Paste it into your MCP client config under FILOO_API_KEY.

Full API reference: https://filoo.app/api

Development

git clone https://github.com/filooapp/mcp-server
cd mcp-server
npm install
npm run build
FILOO_API_KEY=flo_live_xxx node dist/index.js

License

Available Tools

9 tools

filoo_create_linkA

Create a new short link on filoo. Returns the short_url (filoo.app/{username}/{slug}) and the link code. Use this whenever an agent needs to shorten a URL, hand a clean URL to a user, generate a QR-friendly link, or attach click tracking to an outbound URL. Counts against the daily creation quota and active link cap — call filoo_usage first if unsure.

ParametersJSON Schema

Name	Required	Description
`slug`	No	Optional custom slug like 'spring-sale'. Alphanumeric + hyphens, 1–64 chars. Auto-generated if omitted.
`label`	No	Optional private label shown only in the dashboard.
`username`	No	Username to publish under. Defaults to the user's primary username.
`destination`	Yes	The long URL to shorten (http or https).

TDQS

A4.3/5.0

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 that the operation counts against daily creation quota and active link cap, suggests a precondition check, and states the return format. No destructive actions are implied, and the behavior is adequately transparent.

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 main purpose. Every sentence adds value: purpose, return value, usage context, quota warning. There is no redundancy or fluff.

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 no output schema, the description sufficiently explains the return values (short_url, link code) and the URL format. It covers usage context, quota considerations, and a prerequisite check. The parameter schema is complete, and the description integrates well with the overall tool definition.

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 100%, so the baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides; it only mentions the return value. No extra semantics are contributed.

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 explicitly states 'Create a new short link on filoo' and lists the return values. It clearly distinguishes this creation tool from sibling tools like filoo_get_link, filoo_update_link, etc., which serve different purposes.

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 specifies when to use this tool (e.g., 'shorten a URL', 'generate a QR-friendly link') and advises checking quotas with filoo_usage if unsure. It does not explicitly contrast with alternative tools like filoo_update_link, but the context is clear for typical usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_delete_linkA

Permanently delete a filoo short link. The short_url stops resolving (returns 404). Click history is preserved on the filoo side for analytics. This action cannot be undone — confirm with the user before calling unless they explicitly asked to delete.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Link code in the form 'username:slug'.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavioral traits: the short_url stops resolving (404), click history is preserved, and the action is irreversible. This exceeds the minimum for a destructive tool.

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, front-loaded with the core action and effect, then supplementary guidance. Every sentence adds value with no wasted words.

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 description covers purpose, behavior, and usage guidelines adequately. Although no output schema exists, the tool's simplicity (one parameter, destructive action) means the description is nearly complete. Minor gap: no mention of return value or error conditions.

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 100% for the single 'code' parameter, and the description does not add extra semantic value beyond the schema's format note. Baseline 3 is appropriate as the schema carries the load.

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 'permanently delete' and resource 'filoo short link', clearly identifying the tool's purpose. It distinguishes from sibling tools like filoo_get_link or filoo_update_link by being the only deletion tool.

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 advises to confirm with the user before invoking unless they explicitly asked to delete, providing clear usage guidance. Though it doesn't mention alternatives or when not to use, the destructive nature makes this guidance sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_get_linkA

Get full details for one filoo short link by code. The code format is 'username:slug' (the colon is URL-encoded automatically). Returns destination, label, active flag, created_at, and short_url.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Link code in the form 'username:slug', e.g. 'agency:campaign-1'.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but description explains URL encoding behavior and lists returned fields, making behavior clear for a 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?

Two sentences: first gives purpose, second adds code format and return fields. No fluff, front-loaded.

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?

Simple tool with one parameter; description covers input format and output fields. Could mention error handling but acceptable for its simplicity.

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 100% and baseline is 3. Description adds value by noting URL encoding and listing return fields, exceeding schema detail.

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 it gets full details for one filoo short link by code, clearly distinguishing it from sibling filoo_list_links which lists links.

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?

No guidance on when to use this tool vs alternatives like filoo_list_links or filoo_create_link. The description only explains input format.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_link_statsA

Get click/scan analytics for one filoo short link: total clicks, unique visitors, bot count, top countries, and top traffic sources (including QR-code sources). Use to answer questions like 'how is my campaign link doing?' or to compare performance across links.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Link code in the form 'username:slug'.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It discloses the returned metrics (clicks, visitors, bot count, etc.) and mentions QR-code sources. It does not mention permissions or error cases, but for a read-only analytics tool, the transparency is good.

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 front-loaded with purpose and followed by usage examples. Every word earns its place; no 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 one parameter, no output schema, and no annotations, the description explains the returned metrics and provides usage context. It is sufficient for a simple analytics tool, though could mention data freshness or ownership requirements.

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 coverage is 100% with one parameter 'code' described as 'Link code in the form 'username:slug'.' The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 gets click/scan analytics for one filoo short link, listing specific metrics (total clicks, unique visitors, bot count, top countries, top traffic sources with QR-code sources). It distinguishes from sibling tools like filoo_get_link (likely returns link metadata) and filoo_list_links (lists all links).

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 clear context and example use cases ('how is my campaign link doing?' or compare performance across links). However, it does not explicitly state when not to use it or mention alternatives like filoo_get_link for non-analytics details.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_list_linksA

List the authenticated user's short links, newest first, cursor-paginated. Returns items[] with code, short_url, destination, created_at, plus a cursor to fetch the next page. Use to inventory existing links before creating a new one (avoid duplicates) or to find a link by destination.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Page size, max 100. Default 20.
`cursor`	No	Pagination cursor from a previous call.

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It discloses pagination ('cursor-paginated'), ordering ('newest first'), and return structure. However, it does not explicitly mention auth requirements or rate limits, though 'authenticated user' implies auth. A 4 is appropriate as the description is transparent enough for a read-only list 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 two sentences, front-loaded with the main action, then return format, then use cases. No wasted words; every sentence adds value.

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 no output schema, the description explains the return structure (items with fields and cursor) and ordering. It also provides use case context. For a simple list tool, this is 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 already describes limit and cursor parameters with 100% coverage, so baseline is 3. The description adds the ordering 'newest first' and clarifies cursor usage for pagination, adding moderate value beyond 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 clearly states the tool lists the authenticated user's short links with ordering and pagination. It distinguishes from siblings like filoo_get_link (single link) and filoo_create_link (creation) by focusing on listing and inventory use.

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?

The description explicitly provides use cases: 'Use to inventory existing links before creating a new one (avoid duplicates) or to find a link by destination.' This tells when to use the tool and implicitly when not (e.g., for a single link, use get_link).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_list_usernamesA

List every username the authenticated user owns on filoo, along with which one is primary. Short links live under a username (filoo.app/{username}/{slug}), so this is the canonical way for an agent to discover what namespaces it can publish into.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the purpose and output (list of usernames with primary flag) and adds context about the naming scheme (filoo.app/{username}/{slug}). Since there are no annotations, the description carries the full burden. The tool has no side effects and is a simple read operation, so the description is sufficiently transparent for its simplicity, though it could explicitly mention that it is read-only and requires authentication.

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: the first describes the core functionality concisely, and the second adds valuable context about the naming convention and purpose. Every sentence is meaningful and there is no fluff.

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?

With zero parameters, no output schema, and a simple list operation, the description is complete. It tells what is returned (usernames + primary flag) and why an agent would use it (to discover namespaces for publishing). No additional information is needed.

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 tool has zero parameters, so the input schema is fully covered (100%). The description does not need to explain parameters. The baseline for 0 parameters is 4, and the description adds no extra parameter info, which is acceptable.

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 'List every username the authenticated user owns on filoo, along with which one is primary.' It explains the broader context of short links living under a username (filoo.app/{username}/{slug}) and that this is the canonical way to discover namespaces for publishing. This distinguishes it from sibling tools like filoo_list_links which list links, not usernames.

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 says 'this is the canonical way for an agent to discover what namespaces it can publish into,' which indicates when to use the tool (before creating a link). It doesn't specify when not to use it or provide explicit alternatives, but the context is clear enough for an AI agent to infer its appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_meA

Get the authenticated filoo user's account: tier (free/solo/pro/agents/lifetime), owned usernames, boost credits, and tier limits (active links cap, links-per-day quota, API rate limit). Call this first when an agent needs to know what username to publish under or how much headroom is left.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It discloses the returned fields (tier, usernames, credits, limits) and implies read-only behavior ('Get'). Doesn't mention authentication requirements explicitly, but 'authenticated' in the description implies it.

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 wasted words. First lists returned data, second provides use case context. Front-loaded and 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?

Despite no output schema, the description enumerates the main fields returned. It also explains when to use it. Could mention output format or error cases, but considering the tool's simplicity, it's adequate.

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?

No parameters, so baseline is 4. The description correctly indicates no input is 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 retrieves the authenticated user's account info, listing specific contents (tier, usernames, credits, limits). It distinguishes from sibling tools by focusing on account-level details and recommending it as the first call for user context.

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?

Explicitly advises when to call this tool: 'when an agent needs to know what username to publish under or how much headroom is left.' Doesn't explicitly list alternatives but implies it's for account info, distinct from sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_update_linkA

Update a filoo short link in place: change its destination (the previous destination is kept in the audit history so the short URL is safe to repoint), edit its label, or disable/re-enable it with active. The short_url itself never changes. Useful for keeping a stable short URL while migrating the target.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	Link code in the form 'username:slug'.
`label`	No	New private label.
`active`	No	Set false to disable the link, true to re-enable.
`destination`	No	New long URL to redirect to.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the old destination is kept in audit history and the short URL never changes, which is useful. However, it does not detail authentication requirements, rate limits, or error handling for invalid codes. The transparency is adequate but not comprehensive.

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, each adding value: first states action, second adds behavioral safety note, third gives use case. No filler words, front-loaded, and 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?

Given no output schema and no annotations, the description covers core behavior, safety, and use case. It could mention what happens if the code does not exist or error responses, but overall it is sufficiently complete for a relatively simple update tool.

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 coverage is 100% with clear descriptions. The tool description adds context about the implications of changing destination (safe due to audit) and groups actions, but most parameter meaning is already in the schema. Thus it meets the baseline for high 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 resource (filoo short link) and the actions (change destination, edit label, disable/re-enable). It distinguishes from siblings by mentioning the short URL never changes and audit history keeps previous destination, implying it's for updates not creation or deletion.

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 a use case ('keeping a stable short URL while migrating the target') which guides when to use. It lacks explicit exclusions like 'do not use for new links; use create_link instead', but the context of siblings and the description itself imply the scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

filoo_usageA

Get today's filoo usage versus quotas: links created today, daily creation cap, API calls today, active link count, active link cap, remaining boost credits. Use before bulk-creating links to avoid hitting limits.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but description details the returned values and implies a read-only operation. No hidden destructive effects or authentication requirements mentioned, acceptable for a simple usage query.

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 with no filler; first states purpose, second gives usage guidance. Concise and well-structured.

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?

Tool has no parameters, no output schema, no annotations. Description fully covers what the tool returns and when to use it, making it complete for a simple usage check.

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?

Tool has zero parameters, so schema coverage is 100%. Description adds value by explaining the output metrics, which is more than baseline 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 it retrieves today's usage versus quotas, listing specific metrics. It distinguishes from sibling tools which focus on individual links or user info.

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?

Explicitly says 'Use before bulk-creating links to avoid hitting limits,' providing clear context and when to use. Lacks explicit exclusions but sufficient for the tool's simplicity.

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.

9 tool updatesv0.2.0Jul 29, 2026
- First observedfiloo_create_link
- First observedfiloo_delete_link
- First observedfiloo_get_link
- First observedfiloo_link_stats
- First observedfiloo_list_links
- First observedfiloo_list_usernames
- First observedfiloo_me
- First observedfiloo_update_link
- First observedfiloo_usage

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored 2026-07-29 11:40 across 9 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: account info, usage, username listing, link CRUD, and analytics. No overlap in functionality, making tool selection unambiguous.

Naming Consistency5/5

All tool names follow a consistent 'filoo_verb_noun' pattern (e.g., filoo_get_link, filoo_list_links). The naming is predictable and uniform.

Tool Count5/5

9 tools are well-scoped for a URL shortener service, covering user management, link lifecycle, and analytics without being too many or too few.

Completeness4/5

The tool set covers CRUD for links, account info, usage quotas, username listing, and analytics. A minor gap is the lack of a direct filter/search on list_links, requiring pagination to find by destination, but overall it's complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

linkly B
com.linklyhq
Create and manage short links, track clicks, and automate URL management
Marketing Developer Tools
2521
toui.io URL ShortenerOAuth
io.toui
Short-link service embedded in your AI workflow — shorten links, track campaigns, read stats.
Developer Tools
2
whooshly-mcpOAuth
co.whooshly
Create short links, QR codes, UTM templates, vCards, and landing pages from your AI assistant.
Marketing
2
Sinkto.Link
link.sinkto
Free URL shortener: manage short links, QR codes and click analytics from AI clients.
Marketing
1

Related MCP Servers

Dub.co MCP Server
App Automation Web Scraping Browser Automation
Gitmaxd
A
license
B
quality
D
maintenance
Enables AI agents to create, update, and manage short links through your Dub.co account, allowing for creation, modification, and deletion of custom shortened URLs.
Updated a year ago (2025-04-15 18:23 UTC)
4
18
MIT
DWZ Short URL MCP Server
Developer Tools App Automation
muleiwu
A
license
A
quality
D
maintenance
Enables AI assistants to create, manage, and analyze short URLs through complete URL shortening functionality. Supports batch operations, custom domains, click statistics, and comprehensive link management.
Updated 7 months ago (2026-01-28 08:26 UTC)
6
7
1
MIT
Clypt MCP Server
Marketing App Automation
Bonsai-Tech-LLC
A
license
Not graded
quality
C
maintenance
Connects AI assistants to the Clypt Link Intelligence platform to shorten URLs, manage tags, and generate QR codes. It enables users to view link analytics and perform bulk link operations through natural language commands.
Updated 4 months ago (2026-05-23 04:20 UTC)
55
MIT
lnkifyofficial
Developer Tools App Automation
lnkify
A
license
Not graded
quality
C
maintenance
MCP server that enables AI agents to manage Lnkify links, domains, API keys, and analytics. Allows creation and resolution of short links through natural language.
Updated 2 months ago (2026-06-29 15:56 UTC)
MIT

@filooapp/mcp-server

What is filoo

Installation

Claude Desktop

Cursor

Generic MCP client (stdio)

Local install

Configuration

The 8 tools

filoo_me

filoo_usage

filoo_list_usernames

filoo_create_link

filoo_list_links

filoo_get_link

filoo_update_link

filoo_delete_link

filoo_link_stats

Getting an API key

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

lnkifyofficial

`filoo_me`

`filoo_usage`

`filoo_list_usernames`

`filoo_create_link`

`filoo_list_links`

`filoo_get_link`

`filoo_update_link`

`filoo_delete_link`

`filoo_link_stats`