filoo MCP server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
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.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![filoo-mcp MCP server](https://glama.ai/mcp/servers/jrlprost/filoo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jrlprost/filoo-mcp)

Score Badge

Copy to your README.md:

[![filoo-mcp MCP server](https://glama.ai/mcp/servers/jrlprost/filoo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jrlprost/filoo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/jrlprost/filoo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server