Skip to main content
Glama
CapMonsterCloud

capmonster-mcp

Official
by CapMonsterCloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Fetch CapMonster documentation

get_docs

Fetch CapMonster documentation pages to get exact captcha task parameters, extraction steps, and createTask/getTaskResult examples. Jump to specific sections or page through long docs.

Instructions

Fetch a CapMonster documentation page by its URL and return its text.

Use this to read a captcha type's docs (exact task parameters, how to extract them from a live page, and worked createTask/getTaskResult examples). Pick the URL from the llms.txt index (https://docs.capmonster.cloud/llms.txt) — it lists every doc page. Also accepts llms-full.txt and the OpenAPI spec URL.

Only URLs on docs.capmonster.cloud or api.capmonster.cloud are allowed.

Jumping to a section (preferred on big pages — avoids paging by hand):

  • Pass section="<heading>" to return just that ##/### section (from its heading down to the next same-or-higher-level heading). Matching is case-insensitive and substring-based, so section="Examples of solving" or even section="examples" works. Great for going straight to "Create task", "Get task result", or "Examples of solving …".

  • When a page is returned in chunks, the first chunk is prefixed with a section outline (each heading and the exact section="…" to jump to it), so you can pick the section you need in one follow-up call.

Paging (when you want the raw text, no section): Pages that don't fit in limit characters are returned one chunk at a time, starting at offset. The chunk is prefixed with a header showing the range, the total length, and (if there's more) the offset to pass on the next call — keep calling with that offset until the header says end of document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
limitNo
offsetNo
sectionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.11

TDQS

A5/5.0
Behavior5/5

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

With no annotations provided, the description fully discloses key behavior: it returns text, restricts allowed URL domains, describes section matching semantics, and details chunked paging with headers and continuation offsets. This is particularly strong for a tool with zero annotation support.

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 long but every section contributes distinct operational value: purpose, source selection, URL restriction, section jumping, and paging. Formatting with headers, bullets, and code literals makes it skimmable, and the most important advice is front-loaded.

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 4-parameter tool with no output schema and no annotations, this description is complete. It covers how to find URLs, what input each parameter expects, how to navigate large pages, and how to handle pagination. An agent has everything needed to call it correctly and interpret the response.

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?

Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It thoroughly explains url (with domain restriction and source index), section (case-insensitive substring matching), and limit/offset (chunked paging behavior and continuation instructions). All four parameters are richly documented.

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 opens with a specific verb and resource: 'Fetch a CapMonster documentation page by its URL and return its text.' This clearly distinguishes get_docs from sibling API tools like create_task or get_balance, as it is explicitly a documentation fetcher rather than a captcha operation.

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 gives explicit guidance on when to use the tool: 'Use this to read a captcha type's docs' and directs the agent to pick the URL from the llms.txt index. It also provides concrete selection rules for section-based extraction versus paging, covering both common and edge-case usage.

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