Skip to main content
Glama
Sign In
monacloud-mcp

monacloud-mcp

Official
by mona-software
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Công cụ MONA affiliate link

cloud_affiliate_link
Read-onlyIdempotent

Retrieve the MONA Cloud referral link and revenue-share rates so users can review terms before publishing.

Instructions

Lấy link giới thiệu MONA Cloud và mức chia sẻ doanh thu để người dùng duyệt trước khi đăng. / Get the MONA Cloud referral link and revenue-share rates.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cloud_affiliate_link"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.11.0

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered and the description is consistent with them. The description adds that the payload includes revenue-share rates alongside the link, but says nothing about account/auth requirements or whether the referral code is user-specific.

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?

Two short sentences (bilingual duplication) with the action and payload front-loaded and no filler. The mirrored Vietnamese/English text is redundant for an agent but adds no ambiguity or bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool the description is nearly sufficient: it names the returned artifacts (referral link, revenue-share rates), which compensates for the absent output schema. It could still note that it only retrieves and does not claim, linking to cloud_affiliate_claim.

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 schema accepts no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (get) and two concrete resources: the MONA Cloud referral link and its revenue-share rates. It clearly separates itself from cloud_affiliate_stats and cloud_affiliate_claim, though it gives no hint about the near-identical vibecloud_affiliate_link sibling.

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 clause 'so the user can review before publishing' implies a preview workflow, which is useful context. However, it states no conditions for choosing this tool over cloud_affiliate_stats or vibecloud_affiliate_link, and offers no exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools