Create and manage TinyURL short links: aliases, destinations, tags, archive, click analytics.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 8 tools
Each tool maps to a distinct resource+action: create, read (get/list), update, change destination, archive toggle, analytics, count. Descriptions explicitly cross-reference each other (e.g. update_link pointing to change_destination for URLs), eliminating the main potential confusion between update and destination change.
All eight tools follow a uniform tinyurl_<verb>_<noun> snake_case pattern (tinyurl_change_destination, tinyurl_list_links, tinyurl_get_analytics, etc.). No mixed conventions or vague verbs.
Eight tools is well-scoped for a URL shortener: create/read/update mutations plus archive, analytics, and count. Each tool earns its place with no redundancy.
Core lifecycle is covered: create, get, list, update, retarget, archive/restore, analytics, and count. There is no explicit delete tool despite get_link surfacing a 'deleted' flag, a minor gap users can work around via archiving.
WRITE: point an existing short link at a new destination. DESTRUCTIVE: everyone who opens the short link is sent to the new URL from now on and the old destination is overwritten. The new URL must be http(s). PATCH /change.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The new destination URL (absolute, http:// or https://). | |
| alias | Yes | The link's alias. | |
| domain | No | The short link's domain: tinyurl.com (default) or one of the account's branded domains. | tinyurl.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description goes further and explains exactly what is destroyed: "everyone who opens the short link is sent to the new URL from now on and the old destination is overwritten." This is precisely the added context annotations cannot convey.
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?
Three short, front-loaded fragments lead with WRITE and DESTRUCTIVE flags, then the concrete consequence, then the constraint and endpoint. Zero wasted words.
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 mutation tool with no output schema, the description covers the write semantics, the destructive effect, the URL constraint, and the underlying endpoint. Only the lack of sibling differentiation keeps it from being 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 description coverage is 100%, so alias, url, and domain are already documented in the schema. The description restates the http(s) constraint on url but adds nothing about alias or domain selection, 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?
States a specific verb and resource: "point an existing short link at a new destination." The scope is narrower than a generic update, but the description never contrasts itself with the sibling tinyurl_update_link, which is the main risk of mis-selection.
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 implies usage (an existing link must be repointed) and states a prerequisite that the new URL be http(s). However, it gives no when-not guidance and does not route the agent away from tinyurl_update_link or tinyurl_create_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many short links the account has (active or archived), optionally within a creation date range or filtered by alias or tag. GET /urls/{type}/count.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only links created before this ISO 8601 date or date-time. | |
| from | No | Only links created after this ISO 8601 date or date-time. | |
| type | No | available = active links, archived = archived links. | available |
| search | No | Filter: alias:<text> or tag:<text>. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description reinforces scope (active vs archived, date-range and alias/tag filtering) but adds little beyond what the schema's type enum and filter params already say; the endpoint path is the only genuinely new context.
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?
A single front-loaded sentence captures the core purpose plus filter scope, followed by the endpoint for reference. Nothing is wasted, though the trailing GET path is marginally redundant for an agent that already has the name and params.
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 zero-required, four-parameter counting tool with a 100%-covered schema and safety covered by annotations, the definition is sufficient. The only mild gap is that with no output schema it doesn't explicitly state the return is a scalar count, though that is inferable from the name.
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 four parameters (from, to, type, search) are already fully documented in the schema. The description restates the filtering capabilities but adds no syntax or format detail beyond it, 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?
States a specific verb (count/how many) and resource (short links) with explicit scope (active, archived, all account links). An agent can distinguish this from sibling tinyurl_list_links purely by intent — this returns a number, not records.
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 says the count can be 'optionally within a creation date range or filtered by alias or tag,' which implies when the filters apply, but it never names an alternative (e.g., use list_links to retrieve the links themselves) or a when-not condition. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: create ONE new short link for an http(s) destination URL. Optional custom alias (5-30 characters on tinyurl.com), domain (tinyurl.com or a branded domain), tags, expiry and description. Not idempotent: calling it again without an alias creates another link. Returns the new tiny_url. POST /create.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The long destination URL (absolute, http:// or https://). | |
| tags | No | Tags to group the link (each up to 45 characters). | |
| alias | No | Custom alias (5-30 characters on tinyurl.com, 1+ on a branded domain). A random one is generated when omitted. | |
| domain | No | Domain for the new link: tinyurl.com (default) or one of the account's branded domains. | |
| expires_at | No | ISO 8601 expiry; omit or null for a link that never expires. | |
| description | No | Internal description of the link (3-1000 characters). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-idempotency and write semantics, but the description adds the mechanism behind idempotentHint=false (a second alias-less call creates a duplicate link) and notes the return value ('the new tiny_url') plus the HTTP surface (POST /create). It does not mention auth/rate-limit behavior or what happens on alias collision.
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?
Four compact sentences, front-loaded with the operation type and the single required target, followed by optional fields and the critical non-idempotency caveat. No filler.
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?
With no output schema, the description correctly compensates by naming the returned field (tiny_url); with full schema coverage and annotations covering safety, nothing an agent needs to invoke this correctly is missing.
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 six parameters are already documented in the schema, and the description's field summary (alias, domain, tags, expiry, description) largely echoes it. Baseline 3 applies since the schema carries the parameter detail.
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 ('create ONE new short link for an http(s) destination URL') and the WRITE prefix signals mutation immediately, distinguishing it from read siblings like tinyurl_get_link. An agent can tell it creates a brand-new link rather than modifying one, which separates it from tinyurl_update_link and tinyurl_change_destination.
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 an explicit behavioral rule for repeated invocation ('not idempotent: calling it again without an alias creates another link'), which is genuine usage guidance. However, it never names the alternative tools for modifying an existing link, so the when-not-to-use-this routing is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregated click analytics for the account, or for one link (alias) or one tag, from a start date. report: timeline (clicks over time; interval minute/hour/day/week/month), general (browsers, operating systems, devices), weekday and hour (popularity), top_sources (referrers), top_languages, location (countries, or the regions of one country via region = ISO 3166 alpha-2 code). Which reports are available depends on the account's TinyURL plan. Visitor-level raw logs are not exposed. GET /analytics/*.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | End of the report (default: now). | |
| tag | No | Only links with this tag. | |
| from | Yes | Start of the report, ISO 8601 date or date-time (required). | |
| alias | No | Only this short link, written domain/alias, e.g. tinyurl.com/myalias. | |
| region | No | location report only: world (default, lists countries) or a country code such as US (lists its regions). | |
| report | Yes | Which analytics report. | |
| interval | No | Bucket size, timeline report only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm readOnlyHint=true. The description adds valuable behavior beyond that: plan-dependent report availability and the explicit negative that visitor-level raw logs are not exposed. Doesn't cover pagination or output format, but read-only analytics needs little more.
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 scope, then enumerates report types in a dense run-on sentence. All information is relevant but the middle sentence is packed and harder to parse than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with full schema coverage and no output schema, the description adequately covers scope, report types, and access limitations. Missing details about response shape are acceptable since output schema is absent but not expected here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enriches the report enum (describing each report's content) and explains interval semantics and region usage beyond the schema's terse descriptions, adding real value.
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+resource ('Aggregated click analytics') and clarifies the scope (account, one link, or one tag). Clearly distinguishable from all siblings, which are link CRUD/counting operations.
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?
Explains scoping (account, alias, or tag) and that report availability depends on plan, which is useful context for selecting the tool. However, it doesn't explicitly say when to use this vs. other analytics-adjacent queries, though no sibling overlaps directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Details of one short link: destination URL, tiny_url, tags, created/expires dates, archived/deleted flags, analytics settings, total hits and owner. GET /alias/{domain}/{alias}.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | The alias, the part after the domain: https://tinyurl.com/<alias>. | |
| domain | No | The short link's domain: tinyurl.com (default) or one of the account's branded domains. | tinyurl.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine context beyond that: the concrete endpoint mapping (GET /alias/{domain}/{alias}) and a full enumeration of returned fields, which is valuable given there is no output schema. It stops short of noting auth requirements or error behavior.
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 tight sentences: purpose and returned contents first, endpoint second. Nothing is redundant and the most decision-relevant information is front-loaded.
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?
With no output schema, the description usefully compensates by listing the returned fields, and the readOnly annotation covers safety. The main remaining gap is the absence of routing guidance against siblings like tinyurl_list_links and tinyurl_get_analytics.
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 the schema already documents both alias and domain (including the branded-domain alternative and default). The description's endpoint path echoes the parameters but adds no format, alias-syntax, or domain-resolution detail beyond what the schema provides. 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 description names a specific resource (one short link) and enumerates exactly what is retrieved: destination URL, tiny_url, tags, dates, flags, analytics settings, hits and owner. The word 'one' implicitly separates it from the sibling tinyurl_list_links, so an agent can tell single-retrieval apart from list operations without opening the 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?
Usage is only implied by 'Details of one short link' – the agent can infer this is the fetch-a-single-record tool, but there is no explicit when-to-use, no mention of tinyurl_list_links as the alternative, and no note on how it differs from tinyurl_get_analytics despite overlapping analytics fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's short links (type available = active, archived = archived), optionally created within a date range or filtered by alias or tag. The TinyURL API does not page this list: at most limit items (default 50, max 200) are returned together with the total, so narrow with from/to/search when truncated is true. GET /urls/{type}.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only links created before this ISO 8601 date or date-time. | |
| from | No | Only links created after this ISO 8601 date or date-time. | |
| type | No | available = active links, archived = archived links. | available |
| limit | No | Maximum links to return (default 50). | |
| search | No | Filter: alias:<text> or tag:<text>. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint annotation by disclosing a non-obvious trait: the API does not page, at most `limit` items come back with the total, and a truncated flag signals when to narrow the query. This is exactly the operational detail an agent needs to avoid silently missing links.
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?
Three tightly packed sentences, front-loaded with the core action, then the filtering constraint, then the route. No filler and each sentence carries unique 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?
With no output schema, the description helpfully sketches the return shape (items plus total plus a truncated flag) and covers all filter parameters. It stops short of describing item fields, but for a list endpoint the operational picture is largely 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 description coverage is 100%, so the schema already documents to, from, type, limit and search. The description restates the type semantics and limit defaults rather than adding new 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?
States a concrete verb (List) and resource (the account's short links), specifies the type split between active and archived, and adds the underlying route GET /urls/{type}. An agent can distinguish this from tinyurl_get_link (single link) and tinyurl_get_analytics without opening a 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?
Gives clear usage context: date-range and alias/tag filters are optional, and the agent should narrow with from/to/search when the result is truncated. It does not explicitly contrast this tool with siblings like tinyurl_count_links, which is the only gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: archive an active short link (archived = true) or restore an archived one (archived = false). Archiving moves the link to the archived list; nothing is deleted and it can be restored. The API's archive endpoint is a toggle, so the link's current state is read first and nothing is changed when it already matches, and the state afterwards is checked. Do not run two archive calls for the same link at once. GET /alias/{domain}/{alias}, then PATCH /archive.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | The alias, the part after the domain: https://tinyurl.com/<alias>. | |
| domain | No | The short link's domain: tinyurl.com (default) or one of the account's branded domains. | tinyurl.com |
| archived | Yes | true = archive the link, false = unarchive it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: it discloses the toggle mechanic, the read-first/compare/no-op behavior that explains why idempotentHint holds, the post-write state check, the non-destructive nature (nothing deleted, restorable), and a concurrency warning. This is unusually rich behavioral disclosure for a mutation tool.
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 WRITE marker and a one-line purpose, then behavior, then constraints. Compact and mostly waste-free, though the trailing GET/PATCH implementation note is arguably redundant for the agent's decision-making.
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 is needed for this mutation, and the annotations plus full schema coverage leave little for the description to carry. The description still closes the gaps by explaining idempotency, reversal, and concurrency, so an agent has everything it needs.
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 alias, domain, and archived. The description reinforces the archived=true/false meaning but adds no syntax or value beyond what the schema provides, so the 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?
States a specific verb pairing (archive/restore) and the exact resource (short link), front-loaded with a WRITE marker. An agent can distinguish it from siblings like tinyurl_update_link or tinyurl_change_destination because the archived=true/false semantics define the operation precisely.
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?
Explains the two use conditions clearly (archive an active link, restore an archived one) and adds a concurrency exclusion (do not run two archive calls for the same link at once). It stops short of naming sibling alternatives such as update_link, so it is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: change an existing short link's alias, tags, expiry, description or click-analytics switch. At least one new_* field is required. DESTRUCTIVE for what it replaces: new_tags REPLACES all existing tags, and renaming the alias (new_alias) makes the old short URL stop working. The destination URL is changed with tinyurl_change_destination. PATCH /update.
| Name | Required | Description | Default |
|---|---|---|---|
| alias | Yes | The link's current alias. | |
| domain | No | The short link's domain: tinyurl.com (default) or one of the account's branded domains. | tinyurl.com |
| new_tags | No | The complete new tag list; replaces the existing tags (an empty list removes them). | |
| new_alias | No | New alias (5-30 characters on tinyurl.com). The old short URL stops working. | |
| new_stats | No | true/false = turn click-analytics collection on/off. | |
| new_expires_at | No | New ISO 8601 expiry; null = never expires. | |
| new_description | No | New description (null clears it). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint/idempotentHint/readOnlyHint booleans; the description goes further and spells out the concrete consequences: new_tags REPLACES the entire existing tag list, and a new alias makes the old short URL stop working. That is exactly the impact detail an agent needs before a destructive update, plus the underlying PATCH /update semantics.
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?
Three short sentences, front-loaded with the WRITE label and the destructive warnings, followed by the alternative tool and endpoint. No filler, no repetition of the title.
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 7-parameter mutation tool with a fully documented schema, rich annotations and no output schema, the description covers operation type, minimum required input, destructive effects and the sibling boundary — nothing an agent needs to invoke it correctly is missing.
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 the schema already documents each parameter's format and constraints (lengths, ISO 8601 pattern, null semantics). The description restates the field list and the new_* requirement but adds no per-parameter meaning beyond the schema, which is the baseline-3 case.
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?
Opens with an explicit 'WRITE: change an existing short link' verb+resource and enumerates the mutable fields (alias, tags, expiry, description, click-analytics switch). It names the sibling that handles the one adjacent operation (tinyurl_change_destination), so an agent can separate it from the other tools without reading schemas.
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?
States the precondition 'At least one new_* field is required' and routes destination-URL changes to tinyurl_change_destination, which is a genuine when-not rule. It does not address the other adjacent siblings (e.g. tinyurl_set_link_archived, tinyurl_create_link), so it stops short of full alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Short links with QR, custom domains and bot-free click analytics. Create, edit, delete, analyze.
Create and manage short links, track clicks, and automate URL management
Short links, QR codes, link and website analytics: create and edit links, read clicks and visitors.
Create and manage short links, go links, QR codes, and link-in-bio pages, with click analytics.
Add one secure layer between your agents and this server.
