Generate ready-to-paste LinkForty SDK initialization code for Android apps, enabling deep linking and analytics.
Generate ready-to-paste LinkForty SDK initialization code for Expo apps, enabling deep linking and analytics.
Generate ready-to-paste LinkForty SDK initialization code for Flutter apps, enabling deep linking and analytics.
Generate ready-to-paste LinkForty SDK initialization code for iOS apps, enabling deep linking and analytics.
Generate ready-to-paste LinkForty SDK initialization code for React Native apps, enabling deep linking and analytics.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LinkForty MCP Server Create a deep link for Spring sale on Instagram with UTM parameters"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect Claude, Cursor, Claude Code, and any MCP-compatible AI tool to your LinkForty deep links and analytics.
Quick start · Available tools · Configuration · LinkForty
The official Model Context Protocol server for LinkForty. It exposes 20 tools that let an AI assistant manage your deep links, query analytics, configure workspaces, and even generate ready-to-paste SDK integration code for your mobile apps — all using natural language.
The server supports two transport modes:
HTTP (recommended) — connect via URL, no local installation needed
stdio — runs locally as a subprocess of your AI client
Once connected, you can ask things like:
"Create a LinkForty deep link for my Spring sale on Instagram with UTM source=instagram, medium=social, campaign=spring-sale"
"Which links drove the most installs last week?"
"Show me click trends for my top 5 links over the last 30 days"
"Why is link xyz123 getting clicks but no installs?"
"Help me add the LinkForty SDK to my React Native app"
"Create 50 deep links from this CSV"
The AI calls the appropriate LinkForty API behind the scenes and returns structured results.
Related MCP server: Sealmetrics MCP Server
Sign in to your LinkForty dashboard
Go to Workspace Settings → API Keys
Click Create API key, copy the value (starts with dl_)
Note: API keys are scoped to a single workspace. If you manage multiple workspaces, you can run multiple instances of the MCP server with different keys.
No local installation required — just a URL and your API key.
Claude Desktop — edit your claude_desktop_config.json:
{
"mcpServers": {
"linkforty": {
"type": "http",
"url": "https://mcp.linkforty.com/mcp",
"headers": {
"Authorization": "Bearer dl_your_api_key_here"
}
}
}
}Cursor — add to Cursor → Settings → MCP Servers:
{
"linkforty": {
"type": "http",
"url": "https://mcp.linkforty.com/mcp",
"headers": {
"Authorization": "Bearer dl_your_api_key_here"
}
}
}Claude Code:
claude mcp add linkforty --transport http --url https://mcp.linkforty.com/mcp --header "Authorization: Bearer dl_your_api_key_here"Runs the MCP server as a local subprocess. Requires Node.js 18+.
Claude Desktop — edit your claude_desktop_config.json:
{
"mcpServers": {
"linkforty": {
"command": "npx",
"args": ["-y", "@linkforty/mcp-server"],
"env": {
"LINKFORTY_API_KEY": "dl_your_api_key_here"
}
}
}
}Cursor — add to Cursor → Settings → MCP Servers:
{
"linkforty": {
"command": "npx",
"args": ["-y", "@linkforty/mcp-server"],
"env": {
"LINKFORTY_API_KEY": "dl_your_api_key_here"
}
}
}Claude Code:
claude mcp add linkforty -e LINKFORTY_API_KEY=dl_your_api_key_here -- npx -y @linkforty/mcp-serverIf you're running LinkForty Core on your own infrastructure, point the server at your instance.
HTTP transport — host the MCP HTTP server yourself and set LINKFORTY_BASE_URL:
LINKFORTY_BASE_URL=https://your-instance.com/api PORT=3001 npx -y @linkforty/mcp-server-httpstdio transport — set the base URL in the env block:
"env": {
"LINKFORTY_API_KEY": "dl_your_api_key_here",
"LINKFORTY_BASE_URL": "https://your-instance.com/api"
}Tool | Description |
| Create a new deep link with iOS/Android/web URLs, UTM, targeting, and more |
| List/filter links by status, source, project, search query, or date range |
| Get a single link by ID or short code |
| Update any field on an existing link |
| Permanently delete a link |
| Create up to 100 links in one call |
Tool | Description |
| Per-link analytics: clicks, geo, devices, time series |
| Workspace-wide analytics across all links |
| Top performing links ranked by clicks |
| Install attribution data with fingerprint matching |
| Click → install → event conversion funnel |
Tool | Description |
| List all link templates |
| Create a new template with default destinations and UTM |
| Mark a template as the workspace default |
Tool | Description |
| List all projects in the workspace |
| Create a new project for grouping links |
Tool | Description |
| List workspaces accessible by the API key |
| Get details about the current workspace |
| Get iOS/Android bundle IDs, schemes, link domains |
Tool | Description |
| Generate ready-to-paste SDK init code for any platform (react-native, expo, ios, android, flutter) |
Environment variable | Required | Default | Description |
| Yes | — | Your LinkForty workspace API key (starts with |
| No |
| Override for self-hosted LinkForty Core instances |
Environment variable | Required | Default | Description |
| No |
| HTTP server port |
| No |
| Override for self-hosted LinkForty Core instances |
The API key is provided per-request via the Authorization: Bearer header, not as an environment variable. This allows a single HTTP server deployment to serve multiple users and workspaces.
No data is stored or logged by the MCP server. It is a stateless translator between MCP requests and LinkForty's REST API. Every tool call is a fresh HTTP request.
API keys inherit your workspace permissions. The MCP server can only do what your API key has permission to do — there's no privilege escalation.
API keys are scoped to a single workspace. A key for Workspace A cannot access Workspace B's data.
stdio mode: The MCP server runs locally as a subprocess. Your API key is stored in your local MCP client config and only sent to the LinkForty API.
HTTP mode: Your API key is sent in the Authorization header to the hosted MCP endpoint (mcp.linkforty.com), which forwards it to the LinkForty API. The MCP server does not store, log, or cache API keys.
# Install
git clone https://github.com/linkforty/mcp-server
cd mcp-server
npm install
# Build
npm run build
# Watch mode
npm run dev
# Test stdio transport
LINKFORTY_API_KEY=dl_... node dist/index.js
# Test HTTP transport
node dist/http.js # starts on port 3001
PORT=8080 node dist/http.js # custom port
curl http://localhost:3001/health # health checkMIT © LinkForty
Create up to 100 deep links in a single request. Each link in the array uses the same shape as create_link. If no templateId or templateSlug is provided on a link, the workspace default template is used automatically. Returns the count and the array of created links. Useful for importing campaigns or generating links in bulk.
| Name | Required | Description | Default |
|---|---|---|---|
| links | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the 100-link limit, the default template behavior, and return structure (count and array). However, it does not discuss error handling, idempotency, or partial failures, leaving gaps in behavioral transparency.
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 description is three sentences with no wasted words. It front-loads the key action and limit, then provides relevant details about template defaults and return value. Structure is optimal for quick comprehension.
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?
The tool is moderately complex with many nested fields, and there is no output schema. The description covers the primary behavior but omits details like atomicity, error handling per link, and whether the returned array order matches input. It is adequate 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?
The input schema has 0% description coverage, so the description must compensate. It adds meaning by explaining that each link uses the same shape as create_link and that missing templateId/templateSlug defaults to the workspace default. This adds value beyond the bare schema, though many nested fields remain unexplained.
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 clearly states it creates up to 100 deep links in a single request, each with the same shape as create_link, and identifies the use case: importing campaigns or generating links in bulk. This distinguishes it from create_link and other sibling tools like list_links or delete_link.
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 explicitly says 'useful for importing campaigns or generating links in bulk,' implying when to use it. It does not explicitly state when not to use it or mention alternatives, but the sibling tool create_link is the clear alternative for single links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new deep link in LinkForty. Supports device-specific URLs (iOS App Store, Google Play, web fallback), UTM parameters, targeting rules, custom short codes, deep link parameters, attribution window, and expiration. If no templateId or templateSlug is provided, the workspace default template is used automatically. Returns the created link with its short URL.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| description | No | ||
| iosUrl | No | ||
| androidUrl | No | ||
| webFallbackUrl | No | ||
| customSchemeUrl | No | ||
| customCode | No | ||
| projectId | No | ||
| templateId | No | ||
| templateSlug | No | ||
| utmParameters | No | ||
| targetingRules | No | ||
| deepLinkParameters | No | ||
| attributionWindowHours | No | ||
| expiresAt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It describes creation, notes automatic default template selection, and specifies the return value (short URL). It does not cover authorization or potential issues like custom code conflicts, but provides sufficient context for a creation 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?
Two sentences with no wasted words. The first sentence states purpose and features; the second adds critical default behavior and output. Front-loaded and efficiently structured.
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 15 parameters, no output schema, and no annotations, the description covers general purpose and outcome but omits details like required parameters (none), uniqueness constraints, or parameter relationships. It is adequate but leaves gaps for complex usage.
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 0%, so the description must add meaning. It summarizes parameter categories (device URLs, UTM, targeting, etc.) and clarifies template fallback behavior. However, with 15 parameters, a brief list lacks depth for many fields like projectId or customCode constraints, providing only marginal improvement over 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?
The description clearly states 'Create a new deep link in LinkForty' with a specific verb and resource. It lists supported features (device-specific URLs, UTM parameters, targeting rules, etc.), which distinguishes it from sibling tools like bulk_create_links and update_link.
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 does not explicitly state when to use this tool versus alternatives. It implies creation context but lacks guidance on scenarios favoring this over bulk_create_links or update_link. The mention of template default fallback is a behavior note, not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project to group related links. Returns the created project. Use the project ID when creating links to associate them with this project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description states return but lacks details on side effects, permissions, or error handling.
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 focused sentences with no redundant information. Front-loads purpose and return.
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?
Adequate for a simple creation tool but lacks parameter details and error scenarios.
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 has no descriptions (0% coverage) and description text does not clarify what 'name' or 'description' values should be.
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?
Clear verb+resource+reason: 'Create a new project to group related links.' Distinguishes from sibling tools like create_link and list_projects.
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?
Provides some guidance on using the project ID for links, but no explicit when-to-use or alternatives context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new link template. Templates let you define default destinations (iOS/Android/web), UTM parameters, targeting rules, and attribution windows that new links inherit. Useful for ensuring consistency across campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No | ||
| isDefault | No | ||
| settings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the creation action and the template's purpose, but does not specify persistence, idempotency, authorization requirements, or what happens on duplicate names. The description is adequate but lacks depth 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?
The description is three sentences long, front-loaded with the verb and resource, and every sentence adds value. No redundant or vague phrasing.
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 the tool's complexity (nested object, no output schema), the description covers the main purpose and use case. It lacks details on return value, error handling, and whether settings are optional, but it provides sufficient context for an agent to understand the tool's role among siblings.
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?
With 0% schema description coverage, the description compensates partially by explaining that settings include default destinations, UTM parameters, targeting rules, and attribution windows. However, it does not mention the required 'name' parameter, nor 'description', 'isDefault', or 'expiresAfterDays'. Nested fields are hinted but not fully detailed.
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 clearly states the verb 'Create' and the resource 'link template', and explains what templates do (default destinations, UTM parameters, targeting rules, attribution windows). It distinguishes from siblings like create_link and set_default_template by focusing on creating a reusable template, not a link or setting defaults.
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 mentions that templates are 'useful for ensuring consistency across campaigns', implying when to use, but does not provide explicit when-not-to-use conditions or alternative tools. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a deep link by ID. This action cannot be undone — historical click events for the link are also removed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Link UUID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that deletion is irreversible and also removes historical click events. Without annotations, this provides essential behavioral context for a destructive action.
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, no wasted words; front-loaded with main action, then consequence.
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 delete tool with one param and no output schema, the description covers purpose, irreversibility, and data impact adequately.
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 has 100% coverage describing 'id' as 'Link UUID to delete'. Description adds no additional meaning beyond that.
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?
Description clearly states it permanently deletes a deep link by ID and removes historical click events, distinguishing it from siblings like create_link or update_link.
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?
No explicit guidance on when to use this tool versus alternatives like deactivating a link. The description only notes the consequence (permanent and removes click events).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the iOS/Android app configuration for the current workspace, including app scheme, bundle IDs, package name, Universal Link/App Link domains, app store URLs, and SHA256 fingerprints. Use this to know how to integrate the SDK or build deep link URLs that open the right app.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes what is returned but does not disclose side effects, permissions requirements, error behavior, or read-only nature. It is adequate but not rich in behavioral 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?
Two sentences with no wasted words. The first sentence states the purpose and lists outputs; the second gives a practical use case. Perfectly concise and 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?
For a tool with no parameters and no output schema, the description adequately lists the returned fields and indicates it is workspace-specific. It could mention error handling or availability of configuration, but the information provided covers essential usage.
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 has zero parameters, so schema coverage is 100%. The description does not add parameter details because none are needed. Per guidelines, 0 parameters baseline is 4, and the description adds no unnecessary information.
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 clearly identifies the tool as retrieving iOS/Android app configuration for the workspace. It enumerates specific data returned (app scheme, bundle IDs, etc.) and distinguishes from sibling tools that handle links, projects, or templates.
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 states an explicit use case: 'Use this to know how to integrate the SDK or build deep link URLs.' It implicitly suggests this is the correct tool for configuration queries, and no sibling tool overlaps. However, it does not explicitly exclude scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about the current workspace including subscription tier, member count, link count, project count, and settings. Returns the workspace bound to the active API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only says it returns details and is bound to the active API key. It does not disclose non-obvious behaviors like whether it causes side effects, requires specific permissions, or has rate limits.
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, no redundancy, all information is front-loaded and essential. Every clause adds value.
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 the zero-parameter input, no output schema, and low complexity, the description fully covers what the tool does and what it returns, meeting the completeness requirement.
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 tool has zero parameters, and the description adds value by enumerating the returned fields (subscription tier, member count, link count, project count, settings), which is not present in the empty 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?
The description clearly states the action (Get details) and resource (current workspace), listing specific fields returned. It distinguishes from siblings by specifying 'current' versus list of all workspaces.
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 when workspace details are needed, but does not explicitly compare to alternatives like list_workspaces or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the conversion funnel from clicks → installs → events for the workspace. Returns total clicks, unique clicks, total/attributed installs, click-to-install conversion rate, average/median/p75/p95 time to install, and the top converting links. Useful for understanding overall campaign efficiency. Note: requires the analytics:installs permission.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 30) | |
| projectId | No | Optional project UUID to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the required permission ('analytics:installs') and enumerates the return fields. It does not mention read-only nature or rate limits, but the permission and output description add value.
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 description is three sentences, front-loaded with the main purpose. It is concise and informative without unnecessary 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?
Given moderate complexity (2 optional params, no output schema), the description effectively covers the return values and a required permission. It is complete enough for an agent to understand what the tool produces and what 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%: both 'days' and 'projectId' have descriptions in the input schema. The tool description does not add additional semantics beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a conversion funnel from clicks to installs to events, listing specific metrics returned. This is a specific verb+resource. However, it does not explicitly distinguish from sibling analytics tools like get_link_analytics or get_overview_analytics.
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 mentions it is 'useful for understanding overall campaign efficiency,' implying usage context. However, it does not specify when not to use this tool or suggest alternatives among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get install attribution data showing how app installs are linked to clicks via device fingerprinting. Pass a linkId to get installs for a specific link, or omit it for workspace-wide stats. Returns total installs, attributed vs organic split, attribution rate, time series, platform breakdown, and recent installs. Note: requires the analytics:installs permission.
| Name | Required | Description | Default |
|---|---|---|---|
| linkId | No | Optional link UUID. Omit for workspace-wide stats. | |
| days | No | Lookback window in days (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully bears the burden. It lists specific return data (total installs, attribution split, time series, etc.) and notes the required permission. This provides good transparency for a non-destructive analytics 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?
Two sentences, front-loaded with purpose, then usage. Every sentence adds value; no fluff.
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, but description details the exact data returned. Covers parameters and permissions. Missing edge cases but sufficient for a tool with only two optional parameters.
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 adds value for linkId by explaining workspace-wide vs. per-link behavior, but days parameter adds nothing beyond the schema's description.
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 clearly states the tool's purpose: retrieving install attribution data, with specific mention of device fingerprinting. It distinguishes from sibling tools like get_link_analytics by focusing on installs rather than link clicks.
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?
Explicit guidance on when to include or omit the linkId parameter, and the required permission (analytics:installs). No explicit contrast with alternative tools, but the description provides clear context for typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single deep link by ID or short code. Use this to inspect a specific link's configuration, destinations, UTM parameters, and stats.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Link UUID. Use this OR shortCode. | |
| shortCode | No | Link short code (e.g. "abc123"). Use this OR id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It declares the tool as a read operation ('Get', 'inspect') and lists what it returns (configuration, destinations, UTM parameters, stats). This adequately covers the behavior for a simple retrieval 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?
Two sentences, no wasted words. First sentence defines action, second sentence explains output contents. Efficient and 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?
Given no output schema, the description covers what is returned. The sibling tool set provides context for alternatives. The tool is simple and the description is complete enough for an agent to invoke it correctly.
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 already explains both parameters well, including the relationship ('Use this OR id/code'). The description adds no additional parameter insight, 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 clearly states the tool retrieves a single deep link by ID or short code, specifies the verb 'Get' and resource 'deep link', and distinguishes it from siblings like 'list_links' (lists many) or 'create_link' (creates).
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 explicitly says 'Use this to inspect a specific link's configuration...', providing clear context for when to use it. It does not mention when not to use or alternatives, but the sibling tool set supplies that context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed analytics for a single deep link. Returns total clicks, unique clicks, time series, and breakdowns by country, city, region, timezone, device, and platform. Use the days parameter to control the lookback window (default: 30 days).
| Name | Required | Description | Default |
|---|---|---|---|
| linkId | Yes | Link UUID | |
| days | No | Lookback window in days (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It discloses the output structure (clicks, time series, breakdowns) and the effect of the days parameter. However, it does not mention error handling, caching, or data freshness, which are important for an analytics 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?
Two sentences precisely convey purpose and key parameter usage without unnecessary words. The description is front-loaded with the main action and then details output and parameter control.
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 no output schema, the description lists the main analytics components (total clicks, unique clicks, time series, breakdowns) which provides a solid understanding of the response. It is adequate but could mention error responses or response format for completeness.
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 description adds minimal value beyond the schema for 'days' (repeating the default) and nothing for 'linkId.' The baseline of 3 is appropriate as the description does not enhance parameter understanding.
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 clearly states 'Get detailed analytics for a single deep link.' This is a specific verb (Get) and resource (analytics for a single deep link), which distinguishes it from sibling tools like get_overview_analytics (workspace-level) and get_funnel (funnel-specific).
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 implicitly suggests use for a single deep link by naming the resource, and it explains the days parameter usage. However, it does not explicitly compare with siblings or state 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.
Get workspace-wide analytics across all links. Returns total clicks, unique clicks, time series, geo breakdown (country/city/region/timezone), device/platform/browser breakdown, hourly distribution, UTM parameter breakdown (source/medium/campaign), referrers, and top performing links. Default lookback is 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adequately discloses the tool's read-only nature by listing what it returns, but it could mention potential performance impacts or rate limiting. It is transparent about the data returned.
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 description is a single sentence with a clear structure, listing all return items concisely. It could be slightly shorter but is efficient and front-loaded with the purpose.
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 the tool's complexity (many analytics fields) and no output schema, the description thoroughly enumerates all return types, including geo, device, UTM, and top links. The single parameter is fully covered by the schema and description.
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 describes the only parameter 'days' and its default. The description merely repeats 'Default lookback is 30 days,' adding no new semantic meaning 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?
The description starts with 'Get workspace-wide analytics across all links,' which uses a specific verb and resource, clearly distinguishing it from per-link tools like get_link_analytics. It lists many specific data types (clicks, time series, breakdowns) that fully define the tool's scope.
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 states the default lookback of 30 days and implies the days parameter for adjustments, but does not explicitly state when to use this tool versus alternatives like get_link_analytics or get_top_links. However, the phrase 'workspace-wide across all links' strongly implies its use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a ready-to-paste SDK initialization snippet for a specific mobile platform. The snippet is pre-filled with the user's API key, base URL, and app config (bundle IDs, schemes, link domains) from the current workspace. Supported platforms: react-native, expo, ios, android, flutter. Use this to help a developer integrate LinkForty into their mobile app in under a minute.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the snippet is pre-filled with user's API key, base URL, and app config from the current workspace, and lists supported platforms. It does not mention error handling or what happens if config is missing, but the disclosed behaviors are sufficient for typical use.
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 description is three sentences with zero wasted words. The most critical information (what it does and supported platforms) appears first, 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?
Given the simple single-parameter input and no output schema, the description covers the tool's purpose, platforms, and typical use case. It could mention that the snippet is returned as a string or note prerequisites like workspace config existence, but is largely adequate.
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 single parameter 'platform' is fully described via enum in the schema, and the description reinforces it by listing the supported platforms explicitly. This adds context beyond the raw enum, clarifying it is for mobile platforms and snippet generation.
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 clearly states the action ('Generate a ready-to-paste SDK initialization snippet') and the resource ('SDK snippet for a specific mobile platform'). It distinguishes the tool from sibling tools, which focus on links, projects, and templates, making its unique purpose unmistakable.
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 explicitly tells when to use the tool: 'help a developer integrate LinkForty into their mobile app in under a minute'. It does not provide when-not-to-use or alternatives, but no sibling tool offers similar functionality, so the clarity is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the top performing links in the workspace ranked by total clicks. Returns each link's short code, title, total clicks, and unique clicks. Default lookback is 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 30) | |
| limit | No | Max number of links to return (default 10) |
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 that the tool returns top links ranked by total clicks, and specifies the fields (short code, title, total clicks, unique clicks). It also states the default lookback of 30 days. This is adequate transparency for a read-only 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?
The description is two sentences long, front-loaded with the core purpose, and every sentence adds value. No filler or redundancy.
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 the tool has 2 optional parameters, 100% schema coverage, and no output schema, the description explains the return fields (short code, title, clicks) and default behaviors. It is sufficiently complete for an agent to understand what the tool does and what to expect.
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 baseline is 3. The description mentions the defaults for 'days' (30) and 'limit' (10), but the schema already has these details ('Lookback window in days (default 30)', 'Max number of links to return (default 10)'). The description adds no meaningful extra meaning beyond what the schema provides.
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 clearly states the tool's purpose: 'Get the top performing links in the workspace ranked by total clicks.' It specifies the verb 'Get' and the resource 'top performing links', and distinguishes from sibling tools like 'get_link' (single link) and 'list_links' (all links) by focusing on the 'top performing' aspect.
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 mentions the default lookback period and indicates when to use the tool (to get top links). However, it does not explicitly state when not to use it or suggest alternatives like 'get_link_analytics' for deeper analytics. The context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List deep links in the current workspace. Supports filtering by status (active/inactive), source (dashboard/sdk/bulk/migration), project, search query (title/description/short code), and date range. Returns a paginated list with click counts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No | ||
| search | No | ||
| status | No | ||
| source | No | ||
| projectId | No | ||
| createdAfter | No | ||
| createdBefore | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description reveals pagination and click counts in the return. It also notes workspace scoping. However, it omits details like sorting order or rate limits, but is adequate for a read-only list 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?
Two sentences: first sentence states purpose, second sentence lists filters and output. No filler, front-loaded with essential 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?
No output schema exists; description only mentions 'paginated list with click counts'. Missing details about response structure (e.g., fields like id, title). For a tool with 8 optional parameters, more context on output would improve completeness.
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 has 0% description coverage, but description adds meaning for all 8 parameters by listing filter options (e.g., status enum values, source enum values, search scope). It provides context beyond parameter names.
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?
Description clearly states 'List deep links in the current workspace' with specific verb and resource. It distinguishes from sibling tools like get_link (single link) and create_link (write operation).
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?
No explicit when-to-use or alternatives are mentioned. The description implies usage for filtering and listing links, but doesn't contrast with other list tools like get_link or get_top_links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects in the current workspace. Projects are containers for organizing related deep links — for example, by campaign, product, or feature.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the action (list) but does not disclose traits like read-only nature, pagination, ordering, or rate limits. The tool is simple, so a score of 3 is adequate.
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 description is two sentences, front-loaded with the action and resource, and includes additional context without extra words. Every sentence earns its place.
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?
The description lacks information about the return format, behavior (e.g., whether it returns all projects or paginated), and any limitations. Given no output schema and no annotations, the description should provide more complete context.
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 is empty (0 parameters) and schema coverage is 100%. The description adds value by explaining what projects are, which provides context beyond the schema. Baseline for 0 params is 4.
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 clearly states it lists all projects in the current workspace and distinguishes it from other list tools by specifying the resource type. It also provides context by defining projects as containers for deep links.
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 indicates when to use the tool (current workspace) but does not explicitly specify when not to use it or provide alternatives. However, the context helps differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all link templates in the current workspace. Templates define default destinations, UTM parameters, and targeting rules that new links can inherit. Each template has a slug used for URL routing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but does not explicitly confirm or disclose behaviors like potential pagination, sorting, or error states. Since no annotations are provided, the description carries full burden and is adequate but minimal.
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 description is two sentences long, front-loaded with the main action, and every sentence adds value. No 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 parameterless list tool without an output schema, the description covers the purpose and context (what templates are, slug usage). It could mention the return format (e.g., array of templates) but 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?
The input schema has zero parameters, so schema coverage is 100%. As per guidelines, baseline is 4. The description adds no parameter information, but none is needed.
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 clearly states the verb ('list'), resource ('link templates'), and scope ('current workspace'). It distinguishes itself from sibling tools like list_links by specifying 'link templates' and adds value by explaining what templates are.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., list_links) or when not to use it. The description simply states what it does without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all workspaces accessible by the current API key. Note: API keys are scoped to a single workspace, so this typically returns one workspace. Use this to confirm which workspace the AI is connected to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses API key scoping and typical single workspace result. Lacks details on return format or error cases, but sufficient for a simple read 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?
Two efficient sentences with key information front-loaded. No unnecessary text.
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?
Covers purpose, usage, and behavioral context. Lacks output specification but acceptable for a simple list tool with no parameters.
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?
No parameters, so baseline is 4. Description does not need to add parameter info.
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?
Description clearly states the tool lists all workspaces accessible by the API key. The note about scoping differentiates it from sibling get_current_workspace.
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?
Explicitly says to use this to confirm which workspace is connected, and explains typical single-workspace behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a template as the default for the workspace. The default template is used by the SDK when creating links from mobile apps without specifying a template.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Template UUID to set as default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains the behavioral effect (used by SDK for mobile links), adding context beyond the obvious mutation. However, it does not mention that setting a new default replaces the previous default.
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 with no fluff. The action and rationale are front-loaded, making it efficient and clear.
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 tool with one parameter and no output schema, the description is fairly complete. It explains the purpose and the effect on SDK behavior. Minor improvement could be noting that the default is overridden.
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% with a single parameter 'id' described as 'Template UUID to set as default'. The description adds no extra meaning beyond the schema, so a baseline score of 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 clearly states the action 'Mark a template as the default for the workspace' and specifies the resource and scope, distinguishing it from sibling tools like create_template or list_templates.
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 when a default template is needed for mobile SDK link creation, but provides no explicit guidance on when to use this tool versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing deep link. All fields are optional — only provided fields are updated. Use this to change destinations, UTM parameters, targeting rules, status (active/inactive), or expiration.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Link UUID to update | |
| title | No | ||
| description | No | ||
| iosUrl | No | ||
| androidUrl | No | ||
| webFallbackUrl | No | ||
| customSchemeUrl | No | ||
| projectId | No | ||
| utmParameters | No | ||
| targetingRules | No | ||
| deepLinkParameters | No | ||
| attributionWindowHours | No | ||
| expiresAt | No | ||
| isActive | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses the partial update behavior. However, it lacks details on side effects, return value, authorization, or validation. The mutation nature is implied but not fully detailed.
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 description is two sentences with no superfluous text. The first sentence states the purpose, the second enumerates updateable aspects. Well-structured and 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?
Given the high complexity (14 params, nested objects, no output schema or annotations), the description is too brief. It lacks details on effects of omitted fields, return behavior, error conditions, and parameter constraints, making it insufficient for complete agent understanding.
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 only 7%, and the description adds value by listing parameter categories (destinations, UTM, targeting, etc.), but does not explain many parameters like deepLinkParameters or attributionWindowHours. It partially compensates but insufficient for 14 parameters.
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 clearly states the tool updates an existing deep link, specifying the resource and action. It lists the aspects that can be changed, distinguishing it from create_link and delete_link siblings.
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 explains that all fields are optional and only provided fields are updated, giving clear context for use. It lists example use cases like changing destinations or status, but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation or resource. Even the analytics tools (get_link_analytics, get_overview_analytics, get_top_links, get_funnel) are clearly differentiated by scope and purpose. No tools overlap significantly.
Most tools follow a consistent verb_noun pattern (e.g., create_link, list_links). The exception is bulk_create_links, which uses a prefix instead of a verb-first pattern, but it remains clear and predictable overall.
With 20 tools, the set is slightly above the ideal 3-15 range for clarity, but each tool provides distinct value for deep link management, analytics, and configuration. No tool feels redundant.
The toolset covers the full deep link lifecycle (CRUD, bulk creation, templates, projects, analytics, SDK integration). Minor gaps exist: no update or delete for templates and projects, but core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create short links, QR codes, UTM templates, vCards, and landing pages from your AI assistant.
Short-link service embedded in your AI workflow — shorten links, track campaigns, read stats.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Free URL shortener: manage short links, QR codes and click analytics from AI clients.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LinkForty/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
