ULink MCP Server

Server Quality Checklist

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

Latest release: v0.1.17
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., create_project vs configure_project vs update_project are clearly separated by their descriptions). There is no meaningful overlap between link, domain, API key, subscription, or auth tools.
Naming Consistency5/5
All tool names follow the same lowercase snake_case verb_noun pattern (list_projects, create_link, verify_domain, etc.). 'authenticate' is a single verb but fits the pattern as a standalone action.
Tool Count3/5
With 24 tools, the server falls into the 'heavy' range (16-25). While the breadth of features (projects, links, domains, API keys, billing, analytics) justifies many tools, it still feels a bit much for an MCP server and could be trimmed.
Completeness3/5
There is a notable gap: no delete_project tool, despite having create/update/get/list for projects. This creates a dead end for project lifecycle management. Other domains (links, domains, API keys) have full CRUD or equivalent coverage.
Average 4.2/5 across 24 of 24 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Update' but does not disclose whether this is a partial update, permission requirements, effects on existing settings, or response behavior. The additional context about deep link resolution is useful but insufficient for a mutation tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first directly states the action and key examples, the second explains the purpose. It is front-loaded, avoids redundancy, and every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 optional parameters, no output schema, and no annotations, the description is too brief. It fails to clarify update semantics (e.g., whether only provided fields are changed), success/failure behavior, or the operational impact of these settings beyond deep link resolution. This leaves a significant gap for an agent to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters are already documented in the schema with individual descriptions. The tool description lists some parameter types (e.g., iOS bundle identifier, Android package name) but adds no extra syntax or behavioral detail beyond what the schema provides, matching the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update platform-specific configuration for a ULink project' and enumerates specific attributes (iOS bundle identifier, Android package name, deeplink schemas, SHA-256 fingerprints). This distinguishes it from generic sibling tools like update_project by focusing on platform-specific settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for mobile platform configuration but does not explicitly state when to use this tool versus alternatives such as update_project. It provides no exclusions or alternative tool suggestions, so the usage context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the required parameters but does not mention side effects, required permissions, reversibility, or what the response will contain. 'Create' implies mutation, but the description does not elaborate on the behavior beyond that, similar to the update_drive example which scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences. The first sentence states the core purpose, and the second adds essential domain context and requirements. Every word earns its place, with no redundancy or fillers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two parameters, and the schema covers parameter details. However, there is no output schema, so the description should explain the return value (e.g., the created project ID), and it does not. It also lacks any mention of permissions or side effects. While not completely inadequate, it leaves gaps given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, including the defaultUrl format and purpose. The description merely restates 'requires a name and a default fallback URL' without adding new semantic meaning. Since schema coverage is high, the baseline is 3, and the description does not add value beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Create a new ULink project.' It also explains what a project is ('top-level container for links, domains, and API keys'), which differentiates it from sibling tools like create_link or update_project. This is a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining that a project is the top-level container, implying it should be created before links, domains, or API keys. However, it does not explicitly say when not to use this tool or mention alternatives like update_project. It has clear context but no explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the important partial-update behavior ('Only the fields you provide will be modified'), which is beyond what the schema shows. However, it does not mention authentication requirements, error handling, or what happens to unspecified fields beyond the implied preservation, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and exactly three sentences, with the main purpose front-loaded. Each sentence provides essential information: the operation, the scope of editable fields, and the partial-update behavior. No wasteful or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with 10 parameters and no output schema. The description covers the operation and the partial-update semantics, which is valuable, but it omits what the response will be or any failure conditions. Given the rich schema, the description is minimally adequate but not fully complete for an agent to set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for all 10 parameters (100% coverage), so the description adds no new parameter-level meaning beyond the enumeration of categories. The baseline score of 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Update') and resource ('an existing link's properties'), and it explicitly enumerates the kinds of properties that can be modified (name, URLs, parameters, metadata). This distinguishes it from sibling tools like create_link, delete_link, and get_link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying existing links, which is clear from the first sentence, but it does not explicitly state when to prefer it over alternatives or mention any exclusions (e.g., 'use create_link for new links'). The partial-update note is a behavioral hint rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true in annotations, the read-only nature is already disclosed. The description adds value by mentioning pagination and the return format ('array of link objects with configuration, URLs, and metadata'), but it does not clarify default pagination behavior, ordering, or potential error conditions. This is moderate additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose and then succinctly states the return type. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a list operation, the description adequately covers the return format and pagination. It lacks an output schema, so explaining that it returns an array of link objects is beneficial. Minor gaps include missing details about default pagination and whether 'all' means no built-in filtering, but overall it is sufficiently complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description only mentions 'optional pagination' without adding details beyond the schema's own parameter descriptions for limit and offset. The schema fully documents each parameter, so the description contributes little extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all links in a ULink project with optional pagination.' It specifies a distinct verb ('list'), resource ('links'), and scope ('in a ULink project'), differentiating it from sibling tools like get_link (single link) and list_projects (projects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a collection of links, but it does not explicitly state when to prefer this over alternatives like get_link or provide exclusions. There is no mention of 'when not to use' or alternative tool names, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: idempotency via externalId, support for two link types, and required fields. It doesn't mention return values, error handling, or permissions, but the idempotency note is a valuable behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise with five sentences, each serving a purpose: purpose, types, requirements, optionals, idempotency. It is front-loaded with 'Create...' and avoids unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, nested objects, and no output schema, the description covers the creation requirements and idempotency but does not explain what the response contains, error scenarios, or authentication. This leaves gaps for an agent invoking the tool successfully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds minimal parameter meaning. It summarizes optional groups (platform URLs, fallback URLs, slug, metadata, parameters) but does not elaborate on individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new smart link in a ULink project' with a specific verb and resource, and further distinguishes the two link types. It differentiates from sibling tools like update_link, delete_link, and list_links by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit required fields (project, domain, link type) and notes optional settings, giving clear context for when to invoke. However, it doesn't explicitly mention when not to use this tool, such as when updating an existing link, so it lacks explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the readOnlyHint annotation by specifying that configuration, domains, and membership details are included, providing useful behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence conveys the purpose and return contents without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter, the description adequately summarizes the operation and returned data, though it omits error conditions or auth requirements that may be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description's 'by its ID' aligns with the schema's projectId description, adding no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific project by ID, distinguishing it from list_projects and create/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details for one project, but does not explicitly mention when to use this over list_projects or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description does not contradict this. It adds behavioral context by specifying the returned subscription attributes and reinforcing that subscriptions are scoped per project, which goes beyond the annotation and helps the agent understand the result scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core action, and every phrase adds meaningful information. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description covers the main purpose, the data returned, and the per-project scope. Although the output schema is absent, the description lists the key return fields, making the tool usable. It does not explicitly handle edge cases like missing subscription, but given the simplicity and annotations, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a full description for projectId, including its optional behavior and fallback to the user's first project. The tool description adds no additional parameter-level detail beyond 'for a specific project', so the baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'active subscription for a specific project', and it enumerates the returned fields (plan name, billing period, status, renewal date). This makes the tool's purpose unambiguous and distinct from siblings like list_plans or get_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Subscriptions are per-project' implies that this tool should be used when project-specific subscription details are needed, and it hints at a key constraint. However, it does not explicitly mention alternatives or when not to use this tool, leaving the usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool triggers verification, requires DNS configuration, and returns status. However, it does not reveal whether verification is asynchronous, how failures are surfaced, or any rate limits/auth requirements. Some behavioral context is present but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word adds value. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description covers the essential points: what it does, the prerequisite, and the return value. However, it omits operational details like expected latency or failure behavior, but given low complexity this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (domainId) has a comprehensive description in the schema (100% coverage). The tool description adds no additional meaning beyond identifying 'the domain', so it neither compensates nor detracts; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Trigger DNS verification') and the resource ('custom domain'), distinguishing it from sibling domain tools like add_domain/delete_domain/list_domains which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key prerequisite: DNS records must be correctly configured before verification succeeds. This gives clear context on when to use the tool, though it doesn't explicitly discuss alternatives or exclusions. Since no other verification tool exists among siblings, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses a key behavioral trait: the domain cannot be used until DNS records are configured and verified. This goes beyond the simple action but doesn't cover permissions or duplicate handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences; each adds value—purpose and necessary follow-up step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema, the description gives sufficient context for a successful add operation, including the critical post-requisite. Minor gaps like return value or error handling exist but are not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are well-documented in the schema. The description doesn't add parameter-specific details, so it meets the baseline without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a custom domain') and the target resource ('a ULink project'), distinguishing it from sibling tools like verify_domain and delete_domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides workflow context indicating that after adding, DNS configuration and verification are required before use. It doesn't explicitly name alternatives or exclusions, but the action is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds a critical behavioral warning: the full key value is returned only once and cannot be retrieved again, instructing the agent to store it securely. This goes beyond the schema and is valuable for correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, and every sentence adds necessary information. There is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter creation tool with no output schema, the description is quite complete. It covers what the tool does, the critical one-time-return behavior, and a security reminder. It could optionally detail the response shape, but that is not essential for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters (name and projectId), including a descriptive example for 'name'. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create a new API key for a ULink project.' This specific verb+resource combination distinguishes it from sibling tools like list_api_keys, revoke_api_key, and authenticate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool—when a new API key is needed for a ULink project. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous and distinct from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, and the description adds the requirement 'Requires authentication' and clarifies the content returned (setup steps complete and next steps). This goes beyond the annotation, though it doesn't cover error cases or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose. Each sentence adds value: purpose, authentication requirement, and usage context. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is adequately complete. It covers purpose, auth, and use case. It doesn't mention error behavior or null cases, but those are less critical for a simple status query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for projectId, and the parameter description in the schema is clear. The description doesn't add additional semantics beyond mentioning 'a ULink project' and 'after creating a project', which does not add actionable meaning to the parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the onboarding progress for a ULink project, including which setup steps are complete and what to do next.' This is specific and distinguishes it from siblings like get_project by focusing on onboarding status and next steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this after creating a project to guide users through setup.' This tells the agent when to use it, but does not explicitly mention alternatives or when not to use it. Could benefit from naming get_project as an alternative for other info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds meaningful behavioral context: which metrics are included (link clicks, links created, API calls), that usage is scoped to the active billing period, and that it is per-project. This goes beyond the annotation by clarifying the operational scope and data contents, though it stops short of describing response structure or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and key output details. Every sentence contributes meaning: the first states what is retrieved and the specific metrics, the second clarifies the project-level scope. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description adequately conveys the return contents (usage metrics against limits) and scope (per-project active period). It is complete enough for an agent to select and invoke the tool appropriately, though it could optionally mention whether historical periods are excluded or how limits are represented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description for projectId, including the fallback behavior when omitted. The tool description does not add additional parameter semantics beyond what the schema states, which matches the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'usage statistics', with specific detail on metrics (link clicks, links created, API calls) and scope (per-project, active billing period). This distinguishes it from siblings like get_subscription or list_plans, which focus on other billing aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the intended use case: retrieving usage for a specific project within the current billing period. It also notes 'Usage is per-project,' implying that other tools handle subscription-wide or plan-level data, but it does not explicitly name alternatives or exclusions. This amounts to clear context without formal when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by clarifying the scope ('shared domains and any custom domains') and disclosing that verification status is shown. This gives the agent useful behavioral context about what the tool returns without needing an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no redundant information. Every word earns its place, making it highly scannable for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description covers the essential return value (verification status) and scope. Without an output schema it could detail the response format more, but the description is adequate for confident tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description ('The project whose domains to list') is fully sufficient. The description's mention of 'ULink project' adds minor context but doesn't materially enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all domains for a ULink project, specifying that it includes shared and custom domains and shows verification status. This distinguishes it from sibling tools like add_domain, verify_domain, and delete_domain, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is the tool to use when you need to list domains for a project. While there's no explicit 'when not to use' or mention of alternatives, the sibling list makes it obvious that this is the read-only listing counterpart to domain mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait that only provided fields are changed, which is valuable. However, it does not mention error behavior (e.g., project not found), idempotency, or any side effects, leaving some uncertainty 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, scope, and key behavior with no filler or redundancy. Every part contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with no output schema and no annotations, the description covers the essential behavior: what it updates and the partial-update semantics. It does not cover edge cases like providing no fields beyond projectId, but the overall complexity is low and the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already documents each parameter with descriptions, the phrase 'Only the fields you provide will be changed' adds important semantic meaning beyond the schema: it clarifies that omitted optional parameters preserve their current values. This is a meaningful addition for parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with a clear resource ('existing ULink project') and names the exact fields ('name and/or default URL'). It clearly distinguishes from sibling tools like create_project (create vs update) and update_link (different resource type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing ULink project' clearly indicates this tool is for modifying already-created projects, not creating new ones. It implies the alternative use of create_project for new projects, and the partial-update note provides practical usage context. However, it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's a safe read. The description adds value by listing the returned content (platform URLs, parameters, metadata, current configuration), providing context beyond the annotation. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant information. Every word adds value, fitting within the ideal concise format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description adequately explains what is returned (platform URLs, parameters, metadata, configuration) and when to use it. No gaps remain given the annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (linkId described as 'The unique identifier of the link'), so the description adds no additional parameter meaning beyond reinforcing 'by its ID'. Baseline 3 is appropriate for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific link by its ID, specifying the action (retrieve), resource (link), and scope (by ID). It differentiates from siblings like list_links (plural listing) and get_link_analytics (analytics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific link ID is known and detailed information is needed. It does not explicitly name alternatives, but the context is clear given the sibling list_links, which is for listing. No exclusions are mentioned, so it gets a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and the description aligns with 'Retrieve'. It discloses the nature of the returned data (aggregated, breakdowns) and time period context, adding value beyond the annotation. No contradictions or missing behavioral caveats are evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the action and resource, then details the output. Every phrase is informative and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description sufficiently enumerates return categories (total clicks, unique clicks, breakdowns) so an agent knows what to expect. The tool is simple with only two parameters, and annotations provide the safety profile. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with full descriptions (linkId, period), including an enum for period. The description adds minimal context by referencing 'requested time period', which maps to period, but does not enrich beyond what the schema already provides. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'click analytics for a specific link', and enumerates specific data fields (total clicks, unique clicks, breakdowns by platform, country, referrer). This distinguishes it from sibling tools like get_link, which would return link configuration rather than analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: analytics for a single link over a specified time period. However, it does not explicitly mention when not to use this tool or provide alternatives. Since no other analytics tool exists among siblings, the context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, and the description adds valuable behavioral context: it returns key metadata (name, prefix, creation date) but never the full key value. This security-sensitive disclosure goes beyond the structured annotation and sets correct expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no redundant phrases. It efficiently conveys purpose, context, and return limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and read-only annotation, the description provides everything needed: what it lists, why it matters, and what it returns/excludes. The absence of an output schema is compensated by the explicit mention of returned metadata fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single parameter projectId with its own description, and the tool description does not add further parameter semantics. Per the rubric, with 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all API keys for a ULink project, using the specific verb 'List' and resource 'API keys'. It differentiates from sibling tools like create_api_key and revoke_api_key by focusing on listing metadata only. The addition that it returns metadata but not full key values further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining API keys are used for server-side and SDK authentication, and that the tool lists them by project. It does not explicitly name alternatives or state when not to use, but the sibling tool names and clear listing intent provide sufficient guidance for an agent to know when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation is consistent with the description's 'list' operation. The description adds context about what information is returned (features, limits, pricing), going beyond the annotation. No contradictions or hidden side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action, and includes a practical usage note. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with one optional parameter and no output schema, the description fully captures purpose, return content, and use case. The annotation and schema fill in the remaining details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter billingPeriod is fully described in the schema with enum values and default. The description doesn't mention it, but with 100% schema coverage, the parameter is already well-documented. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all ULink subscription plans with features, limits, and pricing. It uses a specific verb ('list') and resource ('ULink subscription plans'), and the additional note about comparing plans or upgrade options distinguishes it from related tools like get_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context ('useful for comparing plans or determining upgrade options'), which implies when to use it. It doesn't explicitly mention alternatives or exclusions, but the sibling list makes the distinction obvious, especially from get_subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive (destructiveHint=true). The description adds valuable context by specifying that links using this domain will stop working and that the action is irreversible, going beyond the annotation to describe the specific impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and consequence. Every sentence adds value with no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and a clear destructive annotation, the description sufficiently covers the action, its effect on links, and irreversibility. It doesn't mention return values, but that's minor for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter, domainId, as a UUID identifier. Schema coverage is 100%, so the description does not need to add parameter details. The description adds no additional semantic information about the parameter itself, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool removes a custom domain from a ULink project. The verb 'Remove' and resource 'custom domain' distinguish it from sibling tools like add_domain, verify_domain, and list_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that removing a domain will stop any links using it and that the action is irreversible, helping the agent understand when to use it. It does not explicitly name alternatives or exclusions, but the warning implies careful usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond the annotation: it opens a browser window, supports new account creation, and has a side effect of enabling other tools. The annotation only indicates readOnlyHint=false, so the description adds meaningful context about the interactive flow and outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, each earning its place: the core action, the account flexibility, and the usage guidance. It is front-loaded with the essential verb and resource, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is complete: it explains what happens, the prerequisite condition, and the post-condition. It also integrates well with sibling tools by referencing check_auth_status, providing enough context for an agent to sequence calls correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema coverage is trivially 100%, and the baseline for 0 params is 4. The description appropriately does not invent parameter explanations; it focuses on behavior and usage, which is sufficient here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Authenticate with ULink'), the method ('opening a browser window'), and covers both sign-in and sign-up. It distinguishes itself from siblings by referencing check_auth_status and positioning itself as the first tool to call for missing credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'This is the first tool to call if check_auth_status reports no valid credentials.' It also notes the consequence ('all other ULink tools become usable'), implying it's a prerequisite. However, it does not explicitly state when not to use it (e.g., if already authenticated), though this is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the destructiveHint annotation: it explicitly states irreversibility and immediate impact on the short URL. This gives the agent a clear understanding of the consequences, enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action, followed by two short sentences that each add value: consequences and a cautionary note. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with a clear destructive annotation, the description is complete. It covers the core action, the irreversible impact, and the immediate effect, which fully equips the agent to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a complete description for the only parameter (linkId: 'The unique identifier of the link to delete'), covering 100% of parameter semantics. The description adds no additional parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Permanently delete a link.' This distinguishes it from sibling tools like update_link, create_link, and list_links by emphasizing the destructive and permanent nature of the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting the action is irreversible and the short URL will stop working immediately, alongside the warning 'Use with caution.' This implies when the tool should be used (for permanent deletion) without explicitly naming alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds useful behavioral context beyond annotations by specifying the return format and ownership scoping, which is valuable given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only) and the lack of an output schema, the description fully covers scope and return fields, providing complete context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not introduce any parameter semantics, but none are needed because the tool takes no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List all ULink projects owned by or shared with the authenticated user' with a specific verb and resource, distinguishing it from siblings like get_project, create_project, and list_links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about scope ('owned by or shared with the authenticated user') but does not explicitly mention alternatives or when not to use it. This fits the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses critical behavioral consequences: permanence ('Permanently revoke'), immediate loss of access for applications, and irreversibility ('cannot be undone'). This adds substantial value beyond the bare annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each earning its place: the action, the immediate effect, and the irreversibility. No wasted words or redundancy, and it is fully front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive operation with no output schema, the description covers all essential aspects: permanent revocation, immediate access loss, and irreversibility. It is complete and appropriately sized for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the only parameter (apiKeyId) with a clear description: 'The unique identifier of the API key to revoke.' The tool description adds no additional parameter-specific meaning, but the schema is already fully descriptive, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently revoke an API key.' It uses a specific verb (revoke) and resource (API key), and distinguishes it from sibling tools like create_api_key and list_api_keys. The phrase 'This action cannot be undone' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by stating 'Any applications using this key will immediately lose access' and 'This action cannot be undone.' This implicitly advises caution and conveys the impact, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds valuable behavioral context by stating that the tool does not trigger any login flow and returns authentication state. This goes beyond the annotation but is not extremely detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding critical information: purpose, side-effect guarantee, and usage advice. It is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description fully covers what it does, when to call it, and its non-mutating nature. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters, and the baseline of 4 applies per the rubric for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('check') and resource ('authentication credentials') to state exactly what the tool does. It also explicitly notes that no login flow is triggered, distinguishing it from the sibling 'authenticate' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call this first' and explains how it relates to the 'authenticate' tool ('determine if the authenticate tool needs to be called'). This provides clear when-to-use guidance and names the alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FlywheelStudio/ulink-mcp-server'

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