ops-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action on a distinct resource: adtech tools manage campaigns (status, bids, launch, list), lpb tools handle landing pages with full CRUD, and system_query_audit is separate. No two tools perform the same operation on the same resource.
Naming Consistency5/5
Tool names follow a consistent pattern of prefix_verb_noun: adtech_* for campaign operations, lpb_* for landing page operations, and system_* for audit. All verbs are clear and parallel (list, get, create, update, delete, set, adjust, launch).
Tool Count5/5
With 10 tools total, the set is well-scoped and not excessive. It covers two domains (adtech and landing pages) plus a system utility, each with a manageable number of operations that fit within the typical 3-15 range.
Completeness4/5
The landing page surface is complete with CRUD (list, get, create, update, delete). The adtech surface covers list, status changes, bid adjustments, and launch, but lacks a dedicated single-campaign get/read operation (though list may suffice) and no delete/stop operation beyond status changes. Overall, the core workflows are well covered.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
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

Behavior3/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 of behavioral disclosure. It does disclose two meaningful traits — that the operation is read-only ('读') and restricted to internal use ('仅限内部'). However, it does not describe pagination behavior, response format, or whether any side effects occur, leaving the behavioral picture incomplete.
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?
A single compact sentence with no filler. The key information — what it queries, that it is read-only, and that it is internal — is front-loaded. For a simple one-parameter tool this is an efficient length, though it errs slightly toward under-specification rather than over-length.
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?
For a simple read-only query tool with one parameter and no output schema, the description is mostly adequate, but it omits return-format details and any mention of the limit parameter's behavior. An agent calling this would understand the intent but not fully what to expect back or how to shape the call.
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 0%, so the description must compensate, but it mentions no parameters at all. The single 'limit' parameter is inferred from its name and schema constraints (default 50, max 200), but the description adds zero meaning about how limit affects the result set. This is a clear gap given zero 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?
The description states a specific verb ('查询' = query), a resource (this MCP's operation audit log), and a scope ('本 MCP' = this MCP). It is clearly differentiated from the siblings, which are all adtech/lpb campaign and page management tools in unrelated domains. It lacks the 'distinguishes from siblings' explicitness of a top-tier definition but is unambiguous about what it does.
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 context by noting it is a read operation ('读') and restricted to internal use ('仅限内部'), which tells an agent this is an audit/introspection tool rather than a business action. However, it gives no explicit when-to-use vs. when-not-to-use guidance and names no alternatives, even though the sibling set makes it obvious this is the system-level tool.
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 the full burden. It states '读' (read), but this merely repeats the 'get' in the tool name and adds no further behavioral context such as error handling, return format, or permission requirements.
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 concise sentence that front-loads the purpose and includes the read-only qualifier, with zero 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?
Adequate for a simple one-parameter read tool, but the description lacks explicit information about the return value, error behavior, or usage context. With no output schema, a brief mention of what the response contains would improve completeness.
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 adds no additional meaning about the 'id' parameter beyond what the schema already provides. Baseline 3 applies because the schema fully documents the parameter.
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?
States a specific verb (获取) and resource (单个落地页), and explicitly notes it's a read operation (读). This distinguishes it from sibling CRUD tools like lpb_create_page or lpb_list_pages.
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 purpose implies when to use it (to fetch details of a specific page), but the description does not explicitly mention alternatives or exclusion criteria. There's no guidance on when to prefer this over lpb_list_pages or other siblings.
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?
The description discloses that it is a write operation requiring confirmation (需 confirm), and indicates it reuses an underlying NL→campaign capability. However, it does not explain what the 'M4 合流点' means, what side effects occur (e.g., creating a campaign), or whether the operation is reversible. With no annotations, the description bears the full burden but only partially fulfills it.
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) and front-loads the core purpose. However, the second sentence contains opaque jargon ('M4 合流点') that adds little for a general reader, slightly reducing clarity and efficiency.
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 tool's complexity (4 params, no output schema), the description lacks important context such as what a launch entails, what the dry-run preview will look like, and the meaning of the 'M4 合流点' reference. It is not fully self-contained for an agent to understand all consequences of invocation.
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 covers all four parameters with clear descriptions (text, op_id, reason, confirm). The tool description adds minimal extra meaning beyond the schema—it reiterates the NL launch and confirmation requirement but does not elaborate on idempotency, audit purpose, or dry-run behavior beyond what the schema 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 the tool's purpose: launching a campaign from a one-sentence natural language description (NL→campaign). It identifies the verb (起投/launch), the object (campaign), and the method (NL), and distinguishes it from sibling tools that list, adjust, or set campaign status.
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 creating/launching new campaigns via natural language, and mentions reusing an existing ad-tech-labs capability. However, it does not explicitly state when to use this tool versus alternatives (e.g., adtech_set_campaign_status or adtech_adjust_bid), leaving the decision to inference.
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 burden. It transparently states that this is a write operation, requires confirmation (需 confirm), and persists to a mock server (mock-server 落库). This discloses the key side effects and risk of the operation.
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 with no fluff. It conveys the essential info (create, write, requires confirm, mock-server persistence) efficiently. Slightly terse but well-structured.
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 description explains the core behavior and confirm flag necessity, but does not mention what the tool returns (e.g., created page) or how the dry-run preview is presented. Given the tool's moderate complexity (dry-run vs confirm), this is a minor 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?
Schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description itself adds no extra parameter meaning beyond what is already in the schema. The schema descriptions are informative but not supplemented by the tool description.
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 creates a landing page (创建落地页), which is a specific verb and resource. It also distinguishes from sibling tools by noting it is a write operation requiring confirmation, and the name 'create' contrasts with update/delete/list/get siblings.
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 does not explicitly state when to use this tool versus alternatives. It mentions it is a write operation and requires confirm, but gives no guidance on choosing this over lpb_update_page or lpb_delete_page. No mention of scenarios or conditions.
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 carries the full burden. It only says '读' (read), which implies non-destructive behavior, but it does not disclose output format, potential side effects, required permissions, or any 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 extremely concise: two short sentences that front-load the action and read-only nature. Every word contributes meaning, with no unnecessary details.
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 description states the purpose and source (lpb mock-server), but it omits any details about the return value or possible query capabilities (e.g., pagination, filters). For a simple list operation this may be sufficient, but it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty object, so there are no parameters to describe. The description adds nothing beyond the schema, but since the schema already fully defines the absence of inputs, no further clarification is needed.
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 ('列出' / list) and the resource ('落地页' / landing pages), and explicitly marks it as a read operation ('读'). This distinguishes it from sibling tools like lpb_get_page (retrieve one), lpb_create_page, lpb_update_page, and lpb_delete_page.
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?
Beyond indicating the operation is a read, there is no guidance on when to use this tool versus alternatives. It does not say 'use this to list all pages, use lpb_get_page for a specific page' or mention any filtering or pagination.
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?
无 annotations，描述承担全部行为披露。描述标注了写操作和破坏性，但未说明删除是否可逆、是否影响关联数据或返回值；confirm 参数的 dry-run 行为仅在 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?
单句描述，无冗余信息，直接点明操作类型和风险提示，结构简洁高效。
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?
结合 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 覆盖 100% 参数描述，confirm 参数说明了 false/true 含义，reason 参数说明了审计用途，因此描述无需额外补充参数语义。
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?
描述明确指出'删除落地页'，动词+宾语清晰，并注明'写'和'破坏性操作'，与列表、获取、创建、更新等兄弟工具明确区分。
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?
描述提示需确认且强调破坏性，提供了清晰的使用前提，但未明确提及与替代方案的对比或何时不使用本工具。
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 that this is a write operation, requires confirmation, and goes through a budget gate and audit. This provides essential transparency about side effects and safeguards. It does not detail reversibility or error behavior, but the confirmation and audit mention adequately cover the main behavioral aspects for a 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 extremely concise—two short sentences in Chinese—and front-loads the core action. It packs essential information (write, confirm, budget gate, audit) without unnecessary verbiage, making it easy to parse and act upon.
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 relatively simple write tool with a nested body parameter, the description adequately covers the main behavioral aspects and points to the server contract for body details. It does not specify return values or error cases, but given the absence of an output schema and the tool's straightforward nature, this is acceptable. A perfect score would require explicit return/error 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?
The schema descriptions already fully cover each parameter (e.g., confirm false/true, reason required on execution, op_id for idempotency). The description adds minimal extra meaning beyond reinforcing the confirmation mechanism and overall purpose. Since schema coverage is 100%, the score aligns with the baseline 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 tool's primary function: adjusting campaign bid/budget. It explicitly mentions it is a write operation requiring confirmation, and the context of 'media-adapter budget gate + audit' further clarifies its purpose. This distinguishes it from sibling tools like adtech_set_campaign_status or adtech_launch_campaign.
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 implicitly indicates when to use this tool—whenever bid or budget adjustments are needed—by stating its function. It also mentions the confirmation requirement, which is a key usage condition. However, it does not explicitly contrast with sibling tools or provide additional guidance on selection criteria, so it falls slightly short of a perfect score.
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 carries full responsibility for behavioral disclosure. It explicitly states the operation is read-only ('读') and notes tenant isolation, which are important behavioral traits. However, it omits other details like output format or error behavior, so it is not maximally transparent.
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, concise sentence that conveys the key points without superfluous words. It is well-structured for a simple read operation.
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 straightforward list operation with no parameters, the description provides sufficient context: it identifies the operation, the resource, the source, and the tenant isolation. It does not describe the return value, but this is a minor gap for a simple list tool.
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 score is 4. The description does not need to explain any parameters, and none are mentioned.
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 a specific action ('列出 campaign') and identifies the resource as campaigns. It also indicates the operation is read-only ('读'), and the source ('ad-tech-labs media-adapter') distinguishes it from sibling tools that perform write operations on campaigns or operate on other resources.
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 listing campaigns, but it does not explicitly contrast with alternatives such as adtech_set_campaign_status or lpb_list_pages. The mention of tenant isolation and source provides context, but no direct guidance on when to choose this tool over others.
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 carries the full burden. It discloses that the operation is a write and requires confirmation, implying a guarded action. It does not mention idempotency or response behavior, but the dry-run/execute distinction is partially implied by '需 confirm' and fully specified in the schema's confirm parameter description.
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 extremely concise—two short sentences—with no redundancy. It front-loads the core action and the key constraint (confirm requirement) efficiently.
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 simple update operation and the comprehensive schema, the description provides adequate context. It lacks explicit mention of output or error cases, but that is acceptable for a write tool and the schema covers the request structure thoroughly.
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 describes all parameters with 100% coverage. The main description adds only '按 id 更新字段' which reiterates the id role without providing additional semantic detail beyond the schema. Thus it meets the baseline but does not enhance parameter understanding.
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 updates a landing page by id, and distinguishes it from sibling tools like create, delete, list, and get. The verb '更新' (update) and resource '落地页' (landing page) are specific and unambiguous.
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 that this is a write operation requiring confirmation, which helps the agent understand when to use it. However, it does not explicitly mention alternatives or exclusions (e.g., 'use create for new pages, delete for removal'), so it falls short of full explicit 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?
With no annotations provided, the description must carry behavioral transparency. It correctly identifies the operation as a write ('写') and requires confirmation ('需 confirm'), hinting at a dry-run/execute flow. It does not detail side effects beyond status change, but for this simple operation it is sufficiently transparent.
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 extremely concise and to the point, containing only the essential information. No unnecessary words or 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?
For a simple status-change tool with no output schema, the description covers the necessary context: the action, the resource, the write nature, and the confirmation requirement. It is complete for an agent to invoke 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 schema already covers all parameters with descriptions, and the tool description adds meaningful value by explaining the status values ('active=恢复投放', 'paused=停投') and reiterating the confirm behavior. This goes beyond a simple restatement of 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 verb (pause/resume) and the resource (campaign), and explicitly distinguishes it from read-only listing tools by noting it is a write operation. This makes its purpose unambiguous.
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 explains the core action and the requirement for confirmation, but it does not explicitly state when to use this tool versus the sibling tools like adtech_adjust_bid or adtech_launch_campaign. It gives context but no explicit exclusions or alternative guidance.
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

ops-mcp-server MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![ops-mcp-server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ERVeepp/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ERVeepp/mcp-server)

Score Badge

Copy to your README.md:

[![ops-mcp-server MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/ERVeepp/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ERVeepp/mcp-server)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![ops-mcp-server MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2FERVeepp%2Fmcp-server%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/ERVeepp/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/ERVeepp/mcp-server'

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