Short links with QR, custom domains and bot-free click analytics. Create, edit, delete, analyze.
Scored across 7 tools
Each tool maps to a distinct action: link CRUD (create/get/list/update/delete), account-level click analytics, and tag-based comparison. The only mild overlap is between compare_tags, list_links (tag filtering) and get_analytics, but the descriptions clearly differentiate per-tag comparison from per-link or account-wide reporting.
All seven tools follow a strict verb_noun snake_case convention (create_link, get_link, list_links, update_link, delete_link, get_analytics, compare_tags), with the verb matching the action taken.
Seven tools is well-scoped for a link-shortening service: full link lifecycle plus analytics and tag comparison, with no redundant tools.
Full create/read/list/update/delete coverage for links, plus analytics and tag comparison, covers core workflows. However, tags appear central (used in list_links and compare_tags) yet no tool assigns or edits tags on a link, and there is no account/plan introspection tool.
Compare the links that carry some tags (e.g. one QR per table, shop window or flyer): for each link, people, QR scans, bots apart and its top countries and devices, over the same period so the rows add up to the total. Without tags it only returns the tags the account uses (etiquetasDisponibles), to choose from. Pro plan (also during the 14-day trial).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days to look back. Default 30. | |
| tags | No | Tags to compare, e.g. ["table-1","table-2"]. Omit to list the available tags. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, the description discloses the paywall (Pro plan or 14-day trial), the aggregation contract ('rows add up to the total' because all rows share the same period), and the no-tags fallback return shape. These are real behavioral facts an agent cannot infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the primary action, then the fallback mode, then the plan constraint — a sensible priority order with little waste. The single long sentence with nested parentheticals is dense and slightly harder to parse than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description names the per-row metrics (people, QR scans, bots separated, top countries/devices) and the degenerate no-tag return, plus the access prerequisite. An agent has enough to decide, call, and anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains both parameters, including the omit-to-list-tags behavior. The description adds a real-world framing for tags and implies the period applies uniformly to all rows, but adds no syntax, limits, or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (compare) plus resource (links carrying tags) and a concrete enumeration of what is reported per row: people, QR scans, bots apart, top countries and devices. It clearly is an analytics/comparison tool, but it never names get_analytics, the sibling an agent would most plausibly confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear usage context (one QR per table, shop window or flyer) and an explicit fallback mode: omitting tags returns only the account's available tags, so the tool can be used to discover valid tag values. It also states the prerequisite (paid plan, including trial). It stops short of explicit exclusions versus get_analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a short link that redirects to a URL. Returns shortUrl, which is what you share.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Destination URL. https:// is added if missing. | |
| name | No | Optional label to recognise the link in the dashboard. | |
| tags | No | Optional tags to group links, e.g. ["table-1","instagram"] (max 10, up to 30 characters each; letters, numbers, - and _; stored lowercase). Adding tags is Pro (also during the 14-day trial). | |
| alias | No | Optional custom alias (letters, numbers, - and _; max 20 characters, never truncated: a longer one is rejected). Pro plan only (also during the 14-day trial): on Free, omit it and the link gets a random code. | |
| domain | No | Optional domain the user owns and has connected to L1NK (Pro plan only), to put the link on, e.g. go.mybrand.com. It must be active. | |
| domain_id | No | Optional id of a verified custom domain (use domain instead). | |
| time_zone | No | Optional IANA time zone (e.g. America/Lima) used to write the activation date to visitors. Default UTC. | |
| max_clicks | No | Optional. Pro plan. The link stops working after this many people (bots are not counted). Approximate at the boundary under simultaneous clicks. | |
| active_from | No | Optional. Pro plan. ISO 8601 date-time (e.g. 2026-11-03T09:00:00-05:00): before it the link does not redirect and shows "this link becomes active on …". | |
| expires_in_days | No | Optional expiry. Pro plan only. | |
| unavailable_page | No | Optional. Pro plan. What visitors see when the link is expired, past max_clicks or not active yet. {"modo":"neutra"} = the neutral L1NK page (default); {"modo":"url","url":"https://..."} = redirect to that fallback URL; {"modo":"mensaje","mensaje":"..."} = a short message of yours (max 200 characters). Shown on the same host, custom domains included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the safety profile is structured. The description adds the return contract ('Returns shortUrl, which is what you share'), which is genuinely useful, but it never spells out the practical consequence of non-idempotency — that repeat calls mint additional links — nor plan gating at the top level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the most agent-relevant fact (you share shortUrl, not the input URL) is front-loaded rather than buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter creation tool this is thin prose, but the schema is exceptionally detailed (100% coverage, nested object documented, plan limits inline) and annotations cover the mutation profile. The one meaningful omission is that duplicate invocations create separate links, which an agent should know before retrying.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters, including the nested unavailable_page object and the Pro-only constraints, are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The definition pairs the specific verb 'Create' with the concrete resource 'short link' and adds its effect ('redirects to a URL'), so it is unmistakable against siblings like get_link, update_link and delete_link. It does not explicitly name a sibling or contrast with one, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this versus update_link (for changing an existing link) or list_links/get_link (for finding one), and no prerequisites such as plan requirements are surfaced in the description. The only usage-shaped content is a hint about sharing shortUrl, which is about the result rather than the decision to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a link permanently. Anyone opening it afterwards gets "not found". Confirm with the user first.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The short code or custom alias of the link (the part after the slash). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral detail: the deletion is permanent and results in a 'not found' response for subsequent accesses. It also instructs to confirm with the user, which is a meaningful operational trait. It does not contradict the idempotentHint=true annotation, though it does not elaborate on idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the action, the consequence, and a user-confirmation requirement with no filler. The key information is front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with annotations covering safety (destructiveHint, readOnlyHint) and an idempotentHint, the description covers the essential semantics. It could mention what happens when the link doesn't exist, but that is not critical given the idempotentHint. The confirmation instruction is an important operational detail not in annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'code' parameter with a pattern and description, giving 100% coverage. The tool description does not add any additional parameter meaning, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Delete a link permanently') and the consequence ('Anyone opening it afterwards gets 'not found'') with a specific verb and resource. It clearly distinguishes from siblings like update_link or get_link, as it is the only destruction tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context (deleting a link) and adds a specific guideline: 'Confirm with the user first.' It does not explicitly mention alternatives or exclusions, but the tool's unique purpose among siblings makes the usage obvious. A 5 would require naming a sibling or an explicit 'use X instead' clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Click analytics by people (bots reported apart): totals, daily series, countries, devices, browsers, referrers and top links. On Pro (and the trial) also aiTraffic (visits from AI assistants such as ChatGPT or Perplexity, with their share and breakdown), cities (top 10 with their country) and QR scans; on Free those fields are null. For the whole account, or for one link with code. The plan caps how far back you can look (Free 30 days, Pro 365).
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | Optional: only this link (its short code or alias). | |
| days | No | Days to look back. Default 30. | |
| tags | No | Optional: only the links that carry at least one of these tags (e.g. ["table-1","table-2"]). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint/openWorldHint in annotations, the description carries real behavioral weight: it discloses that individual entries exclude bots, that aiTraffic/cities/QR scans are Pro-and-trial-only and come back null on Free, and that plan caps bound the lookback window. Those are exactly the caveats an agent needs to interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the returned metrics, then the plan-gated exceptions. Every clause carries information; parentheses are used to pack qualifiers rather than pad.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must convey return shape, and it does by enumerating the metric groups and the fields that may be null. Combined with the plan-cap rules, an agent has enough to call it and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains that omitting code means whole-account scope and that the maximum value of days is plan-dependent rather than a flat 365. It does not mention the tags filter at all, leaving that parameter to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (click analytics) and enumerates exactly what comes back: totals, daily series, countries, devices, browsers, referrers, top links. It also scopes to account-wide vs single-link and flags bot separation. It does not explicitly contrast with the analytics-adjacent sibling compare_tags, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage context: omit code for the whole account, pass code for one link, and the plan determines how far back days can reach (Free 30, Pro 365). It never names alternatives or exclusion conditions (e.g., when to prefer compare_tags), so no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one link: destination, destination rules (reglas) if any, clicks by people, bots apart (link previews and crawlers, not counted in clicks), creation and expiry dates, last click and recent click history. For countries, devices and referrers use get_analytics with the same code.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The short code or custom alias of the link (the part after the slash). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context: clicks exclude previews and crawlers, and bot traffic is reported separately. It does not mention error behavior for unknown codes, but that is a minor gap given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, and the two sentences carry no obvious repetition. The parenthetical about link previews and crawlers is slightly dense but earns its place by clarifying the click count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must carry the return-value burden, and it does: destination, destination rules, click breakdown, creation/expiry dates, last click and recent history. It is complete enough for an agent to know what to expect, with only minor gaps around edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already explains that 'code' is the short code or custom alias. The description only refers to 'the same code' in the get_analytics sentence and adds no syntax or format detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Details of one link') and enumerates the fields returned. It also explicitly distinguishes itself from get_analytics, so an agent can tell the two apart without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names get_analytics as the alternative for country, device and referrer breakdowns, with the condition 'use get_analytics with the same code'. It does not explicitly cover when to use list_links instead, but the single-link scope makes that largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the active (not expired) links of the account with their click counts and tags. Optionally only the links that carry any of the given tags.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional: only links with at least one of these tags (e.g. ["mesa-1","mesa-2"]). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds a genuine constraint not in the annotations: results exclude expired links, and each item carries click counts and tags. However, nothing is said about result volume, pagination, or ordering, which matters for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the scope restriction (active, not expired) is front-loaded and the optional filter follows. Every sentence carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter read tool with no output schema, the description says enough: what is listed, what is excluded, and what fields come back. The only gap is enumeration limits or ordering, which an agent might reasonably want to know before calling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the OR semantics ("at least one of these tags") and constraints. The description's "any of the given tags" restates the schema rather than adding meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (List) plus resource (links) with explicit scope: active, non-expired links of the account. It also states what is returned (click counts, tags), which separates it from get_link (single link) and get_analytics in practice, though it never names those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explains the optional tag filter, but that is parameter behavior, not when-to-use guidance. There is no statement about when to prefer this over get_link for a single item or get_analytics for metrics, so usage must be inferred from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change where a link points, set a new expiry (Pro) or remove its expiry, or set destination rules (Pro): rotate clicks among several URLs (e.g. a WhatsApp rotator between salespeople) or send by country or device. Also (Pro) an activation date, a click limit, and what visitors see when the link is not available. The short code stays the same.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | New destination URL. | |
| code | Yes | The short code or custom alias of the link (the part after the slash). | |
| tags | No | The COMPLETE list of tags the link keeps (it replaces the current one); [] removes them all. Adding a tag the link did not have is Pro (also during the trial); removing is always allowed. | |
| rules | No | Destination rules, Pro plan. Shape: {"version":1, "condiciones":[{"si":{"pais":["PE"],"dispositivo":["ios"]},"destino":"https://..."}], "rotacion":{"destinos":[{"url":"https://wa.me/51...","peso":1}]}}. Conditions are checked in order (pais = ISO country codes; dispositivo = movil, tablet, escritorio, ios, android); the first match wins. Otherwise rotacion takes turns among 2-10 URLs by weight (peso 1-100, default 1). Otherwise the link URL. Bots always get the link URL. Replaces any previous rules. | |
| time_zone | No | Optional IANA time zone (e.g. America/Lima) used to write the activation date to visitors. Default UTC. | |
| max_clicks | No | Optional. Pro plan. The link stops working after this many people (bots are not counted). Approximate at the boundary under simultaneous clicks. | |
| active_from | No | Optional. Pro plan. ISO 8601 date-time (e.g. 2026-11-03T09:00:00-05:00): before it the link does not redirect and shows "this link becomes active on …". | |
| remove_rules | No | true to remove the destination rules (the link goes back to a single URL). | |
| expires_in_days | No | New expiry, counted from today. Not together with remove_expiration. | |
| unavailable_page | No | Optional. Pro plan. What visitors see when the link is expired, past max_clicks or not active yet. {"modo":"neutra"} = the neutral L1NK page (default); {"modo":"url","url":"https://..."} = redirect to that fallback URL; {"modo":"mensaje","mensaje":"..."} = a short message of yours (max 200 characters). Shown on the same host, custom domains included. | |
| remove_expiration | No | true to make the link permanent. | |
| remove_max_clicks | No | true to remove the click limit. | |
| remove_active_from | No | true to remove the activation date (the link works right away). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-destructive, idempotent behavior, so the description adds value beyond that: Pro-plan gating, that rules/tags replacements overwrite prior state, that bots always get the base URL and are not counted, and that the short code is preserved. It doesn't state permission/auth requirements or reversibility explicitly, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main capability is front-loaded in the first sentence, with the Pro-only features grouped afterward. The parenthetical WhatsApp example is illustrative but slightly decorative, and the sentence is dense; still, every clause maps to a real capability, so waste is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter mutation tool with nested objects and no output schema, the description covers all the major intents (redirect, expiry, rules, scheduling, fallback) and notes the key invariant that the code is unchanged. It leaves auth/permission context and the exact non-Pro vs Pro boundary for tags unaddressed, so it is strong but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents every parameter including the nested rules and unavailable_page shapes. The description mostly restates those capabilities (destination rules, activation date, click limit) at a higher level without adding syntax or format detail beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Change where a link points') and then enumerates exactly what can be updated: destination, expiry, destination rules, activation date, click limit, and unavailable page. This is clearly distinct from create_link, delete_link, and get_link without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong context on what kinds of edits this tool handles and flags which capabilities require the Pro plan, plus the useful reassurance that the short code stays the same. It stops short of explicitly naming alternatives (e.g. use delete_link to remove a link entirely) or stating when-not to use it, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_tagscreate_link2 fields changedInput schema / properties / alias / descriptionPrevious value: -"Optional custom alias (letters, numbers, - and _; max 20). Pro plan only (also during the 14-day trial): on Free, omit it and the link gets a random code."New value: +"Optional custom alias (letters, numbers, - and _; max 20 characters, never truncated: a longer one is rejected). Pro plan only (also during the 14-day trial): on Free, omit it and the link gets a random code."Input schema / properties / alias / maxLengthAdded value: +20get_analytics1 field changedInput schema / properties / tagsAdded value: +{
+ "description": "Optional: only the links that carry at least one of these tags (e.g. [\"table-1\",\"table-2\"]).",
+ "items": {
+ "maxLength": 30,
+ "pattern": "^[^,]{1,30}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}update_link1 field changedInput schema / properties / tagsAdded value: +{
+ "description": "The COMPLETE list of tags the link keeps (it replaces the current one); [] removes them all. Adding a tag the link did not have is Pro (also during the trial); removing is always allowed.",
+ "items": {
+ "maxLength": 30,
+ "pattern": "^[^,]{1,30}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}create_link6 fields changedInput schema / properties / active_fromAdded value: +{
+ "description": "Optional. Pro plan. ISO 8601 date-time (e.g. 2026-11-03T09:00:00-05:00): before it the link does not redirect and shows \"this link becomes active on …\".",
+ "maxLength": 40,
+ "type": "string"
+}Input schema / properties / alias / descriptionPrevious value: -"Optional custom alias (letters, numbers, - and _; max 20)."New value: +"Optional custom alias (letters, numbers, - and _; max 20). Pro plan only (also during the 14-day trial): on Free, omit it and the link gets a random code."Input schema / properties / max_clicksAdded value: +{
+ "description": "Optional. Pro plan. The link stops working after this many people (bots are not counted). Approximate at the boundary under simultaneous clicks.",
+ "maximum": 1000000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / tagsAdded value: +{
+ "description": "Optional tags to group links, e.g. [\"table-1\",\"instagram\"] (max 10, up to 30 characters each; letters, numbers, - and _; stored lowercase). Adding tags is Pro (also during the 14-day trial).",
+ "items": {
+ "maxLength": 30,
+ "pattern": "^[^,]{1,30}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}Input schema / properties / time_zoneAdded value: +{
+ "description": "Optional IANA time zone (e.g. America/Lima) used to write the activation date to visitors. Default UTC.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / unavailable_pageAdded value: +{
+ "description": "Optional. Pro plan. What visitors see when the link is expired, past max_clicks or not active yet. {\"modo\":\"neutra\"} = the neutral L1NK page (default); {\"modo\":\"url\",\"url\":\"https://...\"} = redirect to that fallback URL; {\"modo\":\"mensaje\",\"mensaje\":\"...\"} = a short message of yours (max 200 characters). Shown on the same host, custom domains included.",
+ "type": "object"
+}list_links1 field changedInput schema / properties / tagsAdded value: +{
+ "description": "Optional: only links with at least one of these tags (e.g. [\"mesa-1\",\"mesa-2\"]).",
+ "items": {
+ "maxLength": 30,
+ "pattern": "^[^,]{1,30}$",
+ "type": "string"
+ },
+ "maxItems": 10,
+ "type": "array"
+}update_link6 fields changedInput schema / properties / active_fromAdded value: +{
+ "description": "Optional. Pro plan. ISO 8601 date-time (e.g. 2026-11-03T09:00:00-05:00): before it the link does not redirect and shows \"this link becomes active on …\".",
+ "maxLength": 40,
+ "type": "string"
+}Input schema / properties / max_clicksAdded value: +{
+ "description": "Optional. Pro plan. The link stops working after this many people (bots are not counted). Approximate at the boundary under simultaneous clicks.",
+ "maximum": 1000000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / remove_active_fromAdded value: +{
+ "description": "true to remove the activation date (the link works right away).",
+ "type": "boolean"
+}Input schema / properties / remove_max_clicksAdded value: +{
+ "description": "true to remove the click limit.",
+ "type": "boolean"
+}Input schema / properties / time_zoneAdded value: +{
+ "description": "Optional IANA time zone (e.g. America/Lima) used to write the activation date to visitors. Default UTC.",
+ "maxLength": 64,
+ "type": "string"
+}Input schema / properties / unavailable_pageAdded value: +{
+ "description": "Optional. Pro plan. What visitors see when the link is expired, past max_clicks or not active yet. {\"modo\":\"neutra\"} = the neutral L1NK page (default); {\"modo\":\"url\",\"url\":\"https://...\"} = redirect to that fallback URL; {\"modo\":\"mensaje\",\"mensaje\":\"...\"} = a short message of yours (max 200 characters). Shown on the same host, custom domains included.",
+ "type": "object"
+}create_link1 field changedInput schema / properties / domain / descriptionPrevious value: -"Optional custom domain of the account to put the link on, e.g. go.mybrand.com. It must be active."New value: +"Optional domain the user owns and has connected to L1NK (Pro plan only), to put the link on, e.g. go.mybrand.com. It must be active."update_link2 fields changedInput schema / properties / remove_rulesAdded value: +{
+ "description": "true to remove the destination rules (the link goes back to a single URL).",
+ "type": "boolean"
+}Input schema / properties / rulesAdded value: +{
+ "description": "Destination rules, Pro plan. Shape: {\"version\":1, \"condiciones\":[{\"si\":{\"pais\":[\"PE\"],\"dispositivo\":[\"ios\"]},\"destino\":\"https://...\"}], \"rotacion\":{\"destinos\":[{\"url\":\"https://wa.me/51...\",\"peso\":1}]}}. Conditions are checked in order (pais = ISO country codes; dispositivo = movil, tablet, escritorio, ios, android); the first match wins. Otherwise rotacion takes turns among 2-10 URLs by weight (peso 1-100, default 1). Otherwise the link URL. Bots always get the link URL. Replaces any previous rules.",
+ "type": "object"
+}create_link2 fields changedInput schema / properties / domainAdded value: +{
+ "description": "Optional custom domain of the account to put the link on, e.g. go.mybrand.com. It must be active.",
+ "maxLength": 253,
+ "pattern": "^[a-zA-Z0-9.-]+$",
+ "type": "string"
+}Input schema / properties / domain_id / descriptionPrevious value: -"Optional id of a verified custom domain of the account."New value: +"Optional id of a verified custom domain (use domain instead)."get_analytics1 field changedInput schema / properties / codeAdded value: +{
+ "description": "Optional: only this link (its short code or alias).",
+ "pattern": "^[a-zA-Z0-9_-]{1,64}$",
+ "type": "string"
+}create_linkdelete_linkget_analyticsget_linklist_linksupdate_linkShort links, QR codes, link and website analytics: create and edit links, read clicks and visitors.
Create branded short links and QR codes, and pull click analytics by country, device and referrer.
Create and manage short links, go links, QR codes, and link-in-bio pages, with click analytics.
Create and manage short links and QR codes, and read click analytics, on your own domain.
Add one secure layer between your agents and this server.