fansly-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but a few overlap: analizar_rendimiento_posts, obtener_tendencias_hashtag, and analizar_atribucion_links all analyze post performance from slightly different angles. Descriptions help, but some tools could be confused without careful reading.
Naming Consistency5/5
All 13 tools use a consistent verb_noun pattern (verificar_sesion, obtener_metricas_perfil, analizar_rendimiento_posts, etc.). The verbs vary (obtener, analizar, generar, auditar, calcular) but follow a predictable structure, making the set easy to navigate.
Tool Count5/5
With 13 tools, the server is well-scoped for a Fansly analytics suite. Each tool covers a distinct aspect of analytics (profile, posts, fans, churn, PPV, content), and the count falls comfortably within the ideal 3-15 range without feeling excessive.
Completeness4/5
The server provides broad coverage of analytics: session check, profile metrics, growth, post performance, hashtag trends, time heatmap, top fans, churn, tier audit, message flow, PPV pricing, attribution, and content audit. Minor gaps exist, such as no tool to refresh all data at once or to directly set PPV prices, but these are workable around.
Average 3.8/5 across 13 of 13 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the core actions (list and aggregate tips) but does not specify whether this is read-only, what 'recientes' means in terms of time window, or any side effects. It also doesn't disclose potential limitations or auth requirements, which is insufficient for an unannotated 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?
The description is a single concise sentence that front-loads the primary action (list conversations) and then adds the aggregation detail. Every word contributes value, and there is no fluff or redundancy. It is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the main function and what is returned (conversations and aggregated tips), but it lacks important context such as the time period for 'recientes', the output format, and whether any filtering is possible. With no output schema, these details are left ambiguous, making it minimally viable but with clear gaps.
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 trivially complete with 100% coverage. The description does not need to explain parameter semantics because there are none. The baseline of 4 for no parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists conversations (messaging/groups) and aggregates tips from recent messages. It uses specific verbs and identifies the resources involved, making the purpose understandable. However, it does not explicitly distinguish this tool from sibling tools, though the focus on tips is unique.
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?
The description provides no guidance on when to use this tool versus alternatives. It simply describes what the tool does without mentioning any context, exclusions, or prerequisites. There is no mention of when this would be preferred over other tools like obtener_metricas_perfil or analizar_rendimiento_posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions analyzing local SQLite, implying a read-only operation, but does not explicitly state side effects, permission requirements, or the report's return format. This lack of detail fails to inform the agent about important behavioral aspects.
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 a single sentence that immediately states the tool's main function, front-loading the key information. It contains no filler, repetition, or irrelevant details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple parameter set, the description does not explain the output format or the exact contents of the report beyond vague WoW/MoM metrics. Since there is no output schema, the description should have provided more detail on return values, but it remains minimal and leaves substantial ambiguity.
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?
The single parameter 'dias' is fully described in the schema with a clear explanation (retrospective days to analyze), giving 100% schema coverage. The tool description adds no extra parameter semantics, but the baseline of 3 is appropriate because the schema does all the heavy lifting.
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 'Genera' and clearly identifies the resource: a comparative growth report with WoW/MoM metrics, plus the data source 'SQLite local.' This distinguishes it from sibling tools that focus on other aspects like hashtag trends or heatmaps.
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 is provided on when to use this tool versus alternatives. The description only states what the tool does without any exclusions, prerequisites, or comparisons to sibling tools, leaving the agent without explicit usage context.
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?
With no annotations, the description carries the burden. It implies a read-only operation (search and summarize) and discloses the scope of 'publicaciones propias'. However, it lacks details on possible limitations, required permissions, or what 'resume interacción acumulada' entails in terms of output shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and efficiently captures the core function. However, the parenthetical '(contentSearch en timelinenew)' introduces an internal implementation detail that is not necessary for a user and slightly detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no nested objects), the description provides a basis for understanding the tool. But since there is no output schema, the description does not clearly specify what the summarized interaction looks like (e.g., a single metric, a breakdown, or a list). This gap makes it less complete for an AI agent.
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?
The schema description coverage is 100%, with the parameter 'hashtag' well-defined (target hashtag without #). The tool description adds context about how the hashtag is used (to search posts and summarize interaction) but does not provide additional syntactic or format details 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 a specific action: searching own posts containing a hashtag and summarizing accumulated interaction. It distinguishes itself from sibling tools by focusing on hashtag-based aggregation, which no other sibling mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for analyzing own posts by hashtag. However, it does not explicitly state when to use this tool versus alternatives like analizar_rendimiento_posts or obtener_metricas_perfil, nor does it provide any exclusions or conditions.
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 the full burden. It adds context about using daily snapshots from SQLite, which is useful, but it does not disclose the calculation method, output format, or potential limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the purpose. Every word earns its place; there is no unnecessary detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description explains the purpose and data source but does not describe the return value or expected output format, which would be necessary given the absence of an output schema.
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?
The schema covers the single parameter 'dias' fully with a description, so the baseline is 3. The tool description does not add any extra meaning about the parameter beyond what the schema already provides.
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 'Mide' (measures) and clearly identifies the resource: subscriber cancellation/churn. It also specifies the data source (daily snapshots in SQLite), which distinguishes it from sibling analytics tools that focus on other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool measures but provides no explicit guidance on when to use it versus alternatives, nor any exclusions. While it is clearly the only churn-focused tool among siblings, this is implied rather than stated.
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?
With no annotations, the description carries the burden of disclosing behavior. It does mention the side effect of persisting to SQLite, which is useful, but it omits details such as whether data is appended/overwritten, authentication requirements, or rate limits. The transparency is adequate but not rich.
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 a single, well-structured sentence that front-loads the main action and includes essential details (source, data fields, persistence). No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no output schema), but the description does not clarify the return value or the outcome of persistence (e.g., confirmation, count, or data returned). It also lacks context about error cases or prerequisites. These gaps reduce completeness, though the core function is clear.
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?
The schema provides 100% coverage with a clear description for 'limite'. The tool description adds no further parameter context beyond the schema, so the baseline score of 3 applies. It does not clarify how 'limite' affects the extraction or persistence behavior.
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 a specific action ('Extrae') on a well-defined resource ('publicaciones recientes del propio timeline (timelinenew)') and lists the extracted data types (likes, comments, tips). It stands out from sibling tools by mentioning persistence to SQLite and the specific 'timelinenew' source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The functional description implies usage for extracting and storing post performance data, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. Without a 'use when' or comparison to siblings, the guidance remains implicit rather than explicit.
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?
With no annotations, the description carries the behavioral burden. It suggests a read-only inspection ('Inspecciona') and states the output intent ('identificando tipos de contenido'), but it does not disclose return format, limitations, or whether any side effects exist. This is partial but not complete transparency.
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 a single, front-loaded sentence with no redundant fluff. It conveys the verb, resource, and goal efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides a minimally viable action and data source. However, it lacks context about what 'caja fuerte' refers to, what the audit returns, and when it is relevant. This leaves some completeness gaps.
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 input schema has zero parameters, so there is no parameter burden. The description adds context about what is inspected (media types) but no parameter details are needed. Baseline 4 applies.
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 a specific verb ('Inspecciona') and names the exact resource ('media publicado en el muro del perfil (mediaoffers/location)') with a clear objective ('identificando tipos de contenido'). This distinguishes it from sibling tools like auditar_promociones_tiers or analizar_rendimiento_posts.
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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or relationships to sibling tools, so an agent must infer usage solely from the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action and source but does not explicitly confirm that the operation is read-only, whether authentication is required, or any side effects. The word 'audita' suggests inspection but does not guarantee safety.
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 a single sentence, front-loaded with the verb 'Audita' and immediately specifying the target and source. It is concise with zero extraneous content, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, no annotations, and no output schema. The description mentions what is audited (tiers, prices, plans) and the source (account/me), but it does not clarify the return format or any caveats. While adequate for a low-complexity tool, it falls short of fully describing the output.
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 0 parameters, and the input schema is an empty object. Since there are no parameters to explain, the description does not need to compensate. The baseline of 4 applies here, as the description adds no parameter-specific meaning but none 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 specific action (audits) and resource (subscription tiers, prices, plans), and specifies the source (real profile via account/me). This distinguishes it from sibling tools like auditar_caja_fuerte, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the real profile (account/me), suggesting it is for the authenticated user's actual data. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing SQLite data but does not state whether the tool performs read-only operations, what permissions are needed, whether it writes anything, or what the suggested price format looks like. This lack of detail limits transparency.
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 a single, well-structured sentence that clearly conveys the tool's purpose without any redundancy or unnecessary details. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description provides a basic understanding of what it does but leaves gaps. It does not explain when to use the tool, what the output consists of beyond a 'price suggestion,' or any caveats about the analysis. More context would improve completeness.
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 empty. There are no parameter names, defaults, or formats to explain. The description does not need to add parameter semantics, and the baseline score of 4 for no-parameter tools applies.
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 a specific action: 'Analiza patrones históricos de compra desde SQLite y sugiere un precio orientativo para PPV.' It names the resource (historical purchase patterns from SQLite) and the goal (suggest a PPV price), which distinguishes it from sibling analytics tools that focus on metrics, reports, or audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a PPV price suggestion is needed based on purchase history, but it does not explicitly state when to use it vs. alternatives, nor does it provide any exclusions or prerequisites. Context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that data comes from persisted SQLite data (post_metrics), suggesting a read-only analysis, but it does not state whether the tool mutates data, what side effects might occur, or the format of the results. For a no-parameter tool this is a notable gap.
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 a single, front-loaded sentence that communicates the core function and data source without extra words. Every part adds value, and it is appropriately sized for a tool with no parameters.
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?
For a zero-parameter tool with no output schema, the description is reasonably complete: it states the analysis target (post tip income) and the data source. It could mention the output form or clarify that it only covers tipped posts, but given the low complexity, it provides sufficient context for invocation.
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 input schema has zero parameters, so the baseline is 4. The description adds meaningful context by explaining the tool analyzes post-level tip income from a specific data source, which helps the agent understand the tool's domain even though no parameters need explanation.
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 a specific verb ('Analiza') and resource ('publicaciones') while adding the revenue dimension ('ingresos por propinas') and data source ('SQLite (post_metrics)'). It clearly distinguishes itself from sibling tool analizar_rendimiento_posts by focusing on tip income attribution rather than general post performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to know which posts generate most tip income), but it does not explicitly state when not to use it or mention alternatives like analizar_rendimiento_posts. No exclusions or prerequisites are provided, but the intended use case is inferable.
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 the full burden. It discloses the data source and action, but does not clarify what 'top' means (sorting criteria), whether results are paginated, or any potential side effects. For a read-only list, this is adequate but not richly 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?
A single sentence with an immediate action word and no filler. It is front-loaded and every word earns its place, making it highly concise and effective.
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?
For a simple list tool with one optional parameter, the description covers the core behavior (what it lists and from where). It lacks explicit return format details, but since no output schema exists, this is somewhat expected and acceptable for a tool of this complexity.
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?
The schema fully documents the 'limite' parameter with a description, so baseline 3 applies. The description adds no additional parameter semantics beyond what the schema already provides.
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 'Lista' and identifies the resource as 'fans con chats activos' from '/messaging/groups', clearly distinguishing it from sibling analytics tools by focusing on active conversation participants. It states exactly what the tool does and from which source.
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?
It provides context by noting this is the 'real data source for profiles that interact', implying it should be used when identifying engaged fans. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
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?
With no annotations, the description carries the full burden of disclosing behavior. It says the tool extracts timeline posts and generates a matrix, which implies a read-only analysis. However, it does not specify auth needs, data limits, whether it processes all historical posts, or what happens if the timeline is empty. Basic behavior is disclosed, but not rich context.
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 a single, well-structured sentence that front-loads the action and output. Every word earns its place, with no redundancy or extraneous detail.
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?
For a simple tool with no parameters and no output schema, the description is largely complete. It specifies the input source (own timeline) and the output (7x24 matrix). It could optionally mention the time span covered (e.g., all available data) but this is a minor gap, not a critical omission.
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 per the rubric the baseline is 4. The description adds no parameter details because none exist, and the input schema is empty. No additional documentation is needed for parameters.
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 identifies a specific action ('Extrae las publicaciones del propio timeline') and a clear deliverable ('genera una matriz 7x24 con el volumen de publicaciones por hora/día'). This distinguishes it from sibling analytics tools, which focus on metrics, growth, or performance rather than a heatmap of posting activity.
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 clearly implies usage: use when you need a weekly hourly heatmap of your own post volume. It states the scope ('propio timeline') but does not explicitly contrast with alternatives or say when not to use it. Still, the intent is clear enough for an agent to select it appropriately.
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?
With no annotations provided, the description must carry the burden of behavioral disclosure. 'Extrae' implies a read-only operation, and the endpoint suggests a GET-like call, but it does not explicitly state that it has no side effects or mention authentication requirements or return behavior. This is adequate but not fully 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 a single, well-structured sentence that front-loads the verb and immediately communicates the tool's purpose. Every phrase contributes specific information, with no redundancy or filler.
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 the tool has no parameters, no output schema, and no annotations, the description is nearly complete. It clearly states what data is returned and from where. It could potentially mention that it returns current profile stats only, but this is a minor gap.
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 baseline is 4. The description adds value by specifying the exact data to be extracted and the source endpoint, which is more meaningful than the empty schema alone.
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 'Extrae' and clearly specifies the resource ('métricas del perfil activo') and the endpoint ('/account/me'). It enumerates exact data types (followers, published content, subscription tiers, walls), which distinguishes it from sibling analytics tools like post performance or growth reports.
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 clear context: it is for retrieving metrics of the active profile, implying use when profile-level aggregate data is needed. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
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 are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool checks two specific locations (browser_data/ and FANSLY_TOKEN) and reports authentication status, which is relevant behavioral context. It does not mention side effects or network calls, but for a simple verification tool, the core behavior is adequately disclosed.
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 a single, front-loaded sentence that states the verb and the object immediately. Every word contributes to conveying the tool's purpose and behavior, with no redundant or filler content.
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 the tool's simplicity (no parameters, no output schema, sibling tools are all analytics), the description is complete. It explains what is checked, where the token may reside, and that the output is the authentication status, which fully covers the expected functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, giving a baseline of 4. The description adds meaning beyond the empty schema by specifying exactly what is checked (browser_data/ directory or FANSLY_TOKEN environment variable), providing semantic context that would otherwise be completely absent.
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's function with the specific verb 'Comprueba' (checks) and identifies the resource: session token existence in browser_data/ or FANSLY_TOKEN, then reports the authentication status. This distinguishes it from the sibling analytics tools, which focus on metrics and reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives, but the purpose of checking a session token implies it should be used as a prerequisite before performing other operations, such as the analytics tools listed as siblings. Usage is implied rather than directly stated.
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:

[![mcp-fansly MCP server](https://glama.ai/mcp/servers/aronjesusfj-lang/mcp-fansly/badges/card.svg)](https://glama.ai/mcp/servers/aronjesusfj-lang/mcp-fansly)

Score Badge

Copy to your README.md:

[![mcp-fansly MCP server](https://glama.ai/mcp/servers/aronjesusfj-lang/mcp-fansly/badges/score.svg)](https://glama.ai/mcp/servers/aronjesusfj-lang/mcp-fansly)

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/aronjesusfj-lang/mcp-fansly'

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