coolapk-mcp-pro

Overview Schema Source Related Servers Discussions Admin

coolapk_get_url

Fetch read-only Coolapk /v6/ API responses as trimmed JSON, including app details, sections, and nested comments. Rejects write endpoints and removes sensitive fields.

Instructions

只读透传：GET 任意酷安 /v6/ 只读接口路径并返回裁剪后的 JSON。

仅允许 api.coolapk.com 的 /v6/ 开头路径；含写动作的端点（点赞/回复/关注/发帖/私信等）一律 403 拒绝。响应保留原始结构（键名为酷安原始 camelCase），仅剔除 cookie/token 等敏感字段。适合获取列表页未覆盖的数据（应用详情、板块、二级评论等）。

Args: path: 接口路径或完整 URL，如 /v6/apk/detail?id=com.tencent.mm

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "coolapk_get_url"
  }
}

Input Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.0Nov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden, and it discloses a lot: only api.coolapk.com /v6/ paths are allowed, write endpoints (like/reply/follow/post/DM) are rejected with 403, the response shape is preserved, and sensitive fields are stripped. It does not mention authentication requirements, rate limits, or pagination behavior.

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?

It is front-loaded with the purpose and immediately follows with the hard constraints, response behavior, and use case, then the argument example. Each sentence adds constraints or behavior rather than restating the name.

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?

An output schema exists, so the description does not need to describe the return payload. For a one-parameter passthrough, it covers the critical points and leaves minor gaps around auth and pagination that an agent would likely probe anyway.

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?

Schema coverage is 0%, so the description must compensate, and it does: it explains that `path` accepts either an API path or a full URL and gives a concrete example including a query string (/v6/apk/detail?id=com.tencent.mm). It does not say where an agent can discover valid paths.

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: read-only passthrough GET of any Coolapk /v6/ read-only endpoint path returning trimmed JSON. It also distinguishes itself from the sibling tools, which are all narrow endpoint wrappers, by positioning this as the general escape hatch for data those wrappers do not cover.

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?

Gives a clear selection context: use it for data the list pages do not cover (app detail, boards, second-level comments). It does not explicitly name which sibling to prefer for covered cases (for example, coolapk_feed_detail), so the routing rule is implied rather than spelled out.

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

Deploy Server