cotti-admin-mcp

by zchangechen

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are mostly distinct; activity_copy_save and activity_edit_save both modify activities but one creates a copy while the other edits existing, and descriptions clarify the difference. activity_get vs activity_get_full also clearly separated by detail level.
Naming Consistency4/5
Most tools follow resource_verb pattern (e.g., activity_list, coupon_template_get), but admin_login and admin_status use verb_noun or less consistent structure. Overall pattern is recognizable.
Tool Count5/5
12 tools cover the main operations for activity and coupon management plus admin session handling. This is a well-scoped number for the domain.
Completeness4/5
Core workflows (create/edit/list/get/online toggle for activities, create/get/list for coupons, session management) are covered. Minor gaps like missing delete operations or direct create without copy, but these can be worked around.
Average 2.9/5 across 12 of 12 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations, the description must fully disclose behavior. It mentions 'copy' and 'patch' but does not explain side effects, permissions, or whether the operation creates a new entity or modifies an existing one. The mention of Playwright suggests UI automation but no details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though short, the description is cryptic rather than concise. It reads like a developer note and does not effectively convey the tool's function in a clear, structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, no output schema, no annotations), the description is severely incomplete. It does not explain the copy workflow, what 'patch name/desc/SPU only' entails, or what the output is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema. Schema coverage is low (33%), and the description does not compensate by explaining how parameters like sourceTemplateNo or products are used in the copy/patch process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses jargon ('UI copy reference coupon', 'patch name/desc/SPU only') without defining terms, making it unclear what the tool accomplishes. It does not clearly state the verb-resource relationship beyond a cryptic sequence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 over sibling tools like activity_copy_save or others. The description lacks any context for selection.
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 provided, so description must disclose behavior. It only mentions country param support, ignoring pagination, filtering by name/number, response structure, and side effects. Major gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one short sentence), but lacks critical details. Front-loaded but insufficient for usability.
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?
With 5 parameters, no output schema, and missing descriptions, the tool definition is incomplete. Pagination, filtering, and response format are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only country described). Description adds minimal value: 'supports country param' repeats the schema. No info on activityNo, activityName, pageNum, pageSize.
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?
The description clearly states 'List marketing activities' with a specific verb and resource. However, it does not differentiate from sibling tools like activity_get or activity_get_full, leaving ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., activity_get for a single activity) or any exclusions. The description only states basic functionality without context.
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 provided, so description carries full burden. It only repeats schema info about country parameter. No disclosure of return format, pagination behavior, idempotency, or side effects (e.g., read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with no fluff, but at the cost of missing critical information. Adequate for conciseness but lacks necessary detail.
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 6 parameters, no output schema, low schema coverage, and sibling tools, the description is incomplete. It does not explain filtering, ordering, default behavior, or the effect of omitting the country parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'country' has a description). The description adds no meaning beyond the schema for the other 5 parameters (pageNum, pageSize, couponName, templateNo, templateName), failing to compensate for the low coverage.
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?
Description clearly states 'List coupon templates' as verb+resource, but does not distinguish from sibling 'coupon_template_get' which likely retrieves a single template. Missing mention of pagination parameters (pageNum, pageSize) which are part of the function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'coupon_template_get'. No exclusions or prerequisites mentioned. The 'supports country header' hint is basic and does not help in decision-making.
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 full burden. It adds that the tool is UI-based and requires Playwright, and patches specific fields (name/time/coupon). However, it does not disclose side effects, required permissions, or whether the operation is destructive. The behavioral insight is moderate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 7 words plus a requirement note, which is efficient but borderline cryptic. It lacks structure and any breakdown of steps or parameters. Conciseness is acceptable, but the information density is low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is woefully incomplete. It does not explain the overall workflow, prerequisites, return format, or error behavior. An agent cannot reliably invoke this tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 29%. The description mentions 'patch name/time/coupon' mapping roughly to 'activityDate' and 'couponTemplateNo', but 'name' is not a parameter. It does not explain 'sourceId', 'sourceActivityNo', 'country', 'channel', or 'publish'. The added value beyond the schema is minimal and insufficient for compensating the low coverage.
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?
The description states it copies a reference activity, patches name/time/coupon, and saves as a general activity. This verb+resource combination clearly indicates a copy operation, distinguishing it from sibling tools like 'activity_edit_save' which edits existing activities. However, 'reference activity' is vague without further context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'UI copy' and 'Requires Playwright', implying it is a browser automation tool, but provides no explicit guidance on when to use this tool versus alternatives like 'activity_edit_save' for editing or 'activity_list' for listing. It lacks when-not-to-use or alternative recommendations.
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 provided. Description only says 'Get', implying a read operation, but does not disclose any behavioral traits such as side effects, authentication requirements, or performance characteristics. Without annotations, the description carries full burden and fails to provide sufficient transparency.
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 a single sentence of 8 words, very concise. However, it sacrifices informativeness. While every word earns its place, it could be more helpful without becoming verbose.
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?
For a tool with no output schema and a sibling 'activity_get_full', the description lacks critical context. It does not specify what 'detail' includes, nor how it differs from 'full'. An agent cannot decide whether to use this tool over alternatives without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%: only 'country' has description). Description adds no parameter information beyond 'by id or activityNo'. It does not clarify whether 'id' or 'activityNo' is required, their formats, or the relationship between them. The description fails to compensate for the poor schema coverage.
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?
Description states 'Get activity detail by id or activityNo', clearly specifying the verb and resource. However, it does not distinguish from sibling tool 'activity_get_full', which likely returns more detail. The purpose is clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'activity_get_full' or 'activity_list'. No exclusions or context provided. The description implies basic usage but does not help an agent decide between similar tools.
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 fully disclose behavior. It states 'excludes 作废' and 'latest', but does not clarify whether the tool returns one or multiple results, whether it mutates data, or if it requires specific permissions. The description is too minimal for safe autonomous invocation.
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 concise—two sentences—with the main function front-loaded. However, the use of Chinese characters ('私域', '作废') may require translation effort, slightly reducing efficiency. Overall, every sentence adds value.
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?
Without an output schema, the description should indicate what is returned (e.g., IDs, names, expiration). It mentions 'activity + coupon' but no structure. Sibling tools suggest copy operations expect specific references. The description is insufficient for an agent to fully understand the tool's contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with only country having a description. The description adds no extra meaning to the channel parameter (enum WX/WA) beyond what the schema provides, nor does it explain the default or when to choose one. For parameters with enums, more context could help the agent select correctly.
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?
The description clearly states 'Find latest activity + coupon for a country', specifying the verb, resource, and scope. The Chinese characters and term '私域' may reduce clarity for non-Chinese users, but the overall purpose is understandable and distinguishes it from siblings like activity_get or coupon_template_list.
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 'Use before copy' provides a usage hint linking it to copy operations, which aligns with sibling tools like activity_copy_save. However, it does not explicitly state when not to use or provide alternatives, leaving the agent to infer context.
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?
Description implies read-only operation via 'Get', but does not explicitly state it's non-destructive. No annotations provided; description could be more transparent about side effects or requirements.
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?
Single sentence with key output fields listed concisely. No redundancy, though could be structured with bullet points for clarity.
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?
With 3 optional parameters, no output schema, and no context on return structure or when to use, the description is incomplete. It doesn't explain how the parsed landing page differs from other activity tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 33% of parameters have schema descriptions; the tool description does not add any parameter-level guidance beyond listing fields in output. It fails to compensate for low 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?
Description clearly states the tool retrieves an activity with parsed landing page details (h5Url, longLink, title, bg image). This differentiates it from sibling tool 'activity_get' which likely returns raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like activity_get or other siblings. Description does not specify prerequisites or context.
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?
Without annotations, the description must disclose behavioral traits such as idempotency, caching details, or what happens on invalid session. The brief statement 'Check cached Admin session validity' does not cover these aspects.
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 sentence that is front-loaded and contains no extraneous words. It is concise and to the point.
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 no output schema, the description does not specify what the tool returns (e.g., boolean or session status object). It is functionally complete for its purpose but lacks return value documentation, which is important for an agent.
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?
There are zero parameters, so the input schema fully defines lack of inputs. The description adds no parameter information, but with no parameters, this is acceptable (baseline 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?
The description clearly states the action ('Check') and the target resource ('cached Admin session validity'). It distinguishes from sibling tools like admin_login which focuses on authentication, and others unrelated to session state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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., admin_login to establish a session). The description lacks context about prerequisites or typical usage scenarios.
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 provided; description does not disclose permissions, side effects, or behavior beyond 'edit'. Insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with key information, though the Chinese parenthetical is slightly repetitive.
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?
Incomplete for 6-parameter tool with no output schema or annotations; missing details on return value, prerequisites, and full parameter semantics.
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?
Description maps 'time, landing page, title' to schema properties (activityDate, landPageTitle, landingImagePath), but other parameters (activityId, activityNo, country) remain unexplained. Schema coverage is 33%.
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?
Explicitly states 'Edit existing activity' with editable fields (time, landing page, title). Distinguishes from sibling 'activity_copy_save' via 'Not copy'.
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?
Indicates usage for editing (not copying), but lacks broader guidance on when to use this tool versus other siblings like activity_get or activity_set_online.
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 bears full burden. It indicates a destructive action (force refresh) but does not disclose consequences like session termination, authentication requirements, or side effects.
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 sentence, well-structured, and front-loaded with the action and resource. It contains no superfluous text.
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 no output schema and no annotations, the description is minimal. It explains the action and scope but lacks information on prerequisites, behavior outcomes, or return values. Adequate for a simple tool but could be more complete.
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 tool has zero parameters, and schema coverage is 100%. Baseline 4 is warranted, but the description adds no extra information about parameters. It does not confirm that no input is needed, so score 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 verb 'Force refresh' and resource 'Cotti Admin SSO session', with a specific scope 'APAC global admin'. This distinguishes it from sibling tools that handle activities, coupons, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'admin_status'. It does not mention prerequisites or situations where refresh is needed.
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, description explains the online parameter values (1=List, 0=Off shelves), but lacks disclosure of permissions, side effects, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that front-loads the core purpose with no wasted words.
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?
Simple tool with 3 parameters and no output schema; description suffices for basic understanding but lacks detail on return values, constraints, or error states.
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?
Adds meaning for the online parameter beyond schema (boolean true/false mapped to publish/unpublish), but does not clarify activityId or country beyond schema; schema coverage is low (33%).
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?
Clearly states the verb (publish/unpublish) and resource (activity), and distinguishes it from siblings like activity_list or activity_get by specifying the online status toggle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites or when-not-to-use stated.
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?
With no annotations, the description carries full burden for behavioral disclosure. It states a read operation but does not mention whether multiple identifiers can be provided, if any are required (schema shows none required), or any side effects, authorization needs, or rate limits. The description is minimal.
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 sentence of 9 words with no redundancy. It front-loads the verb and resource, making it easy to scan. Every word earns its place.
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 the low complexity (single get operation, no output schema), the description is moderately complete. It covers the action and primary parameters but lacks details on parameter interaction (e.g., behavior when multiple identifiers provided), required parameters (none in schema but implied need), and return value structure. It is adequate but not thorough.
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 low (25%: only country has a description). The description adds meaning for three parameters (templateNo, couponNo, id) by explaining they are lookup keys. However, the country parameter's role remains unexplained, and it's unclear if multiple identifiers can be used together. The description partially compensates for the schema gaps.
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 'get' and the resource 'coupon template detail' with explicit lookup keys (templateNo, couponNo, id). This distinguishes it from sibling tools like coupon_template_list (list vs detail) and coupon_copy_save (save vs retrieve).
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 have one of the three identifiers, but it does not explicitly state when to use this tool over others, nor does it provide exclusions or alternative recommendations. The context is implied but not explicit.
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:

[![cotti-admin-mcp MCP server](https://glama.ai/mcp/servers/zchangechen/cotti-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zchangechen/cotti-admin-mcp)

Score Badge

Copy to your README.md:

[![cotti-admin-mcp MCP server](https://glama.ai/mcp/servers/zchangechen/cotti-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zchangechen/cotti-admin-mcp)

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/zchangechen/cotti-admin-mcp'

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