Scrappey.com의 웹 자동화 및 스크래핑 기능과 상호 작용하기 위한 모델 컨텍스트 프로토콜(MCP) 서버입니다. smithery.ai/server/@pim97/mcp-server-scrappey 에서 직접 사용해 보세요.
이 MCP 서버는 AI 모델과 Scrappey의 웹 자동화 플랫폼 간의 브리지 역할을 하여 다음을 수행할 수 있습니다.
브라우저 세션을 생성하고 관리합니다
Scrappey 인프라를 통해 HTTP 요청 보내기
브라우저 동작(클릭, 입력, 스크롤 등)을 실행합니다.
다양한 봇 방지 보호 기능을 자동으로 처리합니다.
Related MCP server: MCP Operator
Scrappey.com 에서 Scrappey API 키를 받으세요
환경 변수를 설정하세요:
지엑스피1
scrappey_create_session )쿠키와 기타 상태를 유지하는 새로운 브라우저 세션을 만듭니다.
{
"proxy": "http://user:pass@ip:port" // Optional: Custom proxy, leave empty for default
}scrappey_destroy_session )브라우저 세션을 올바르게 닫습니다.
{
"session": "session_id_here" // Required: The session ID to destroy
}scrappey_request )Scrappey 인프라를 통해 HTTP 요청을 보냅니다.
{
"cmd": "request.get", // Required: request.get, request.post, etc.
"url": "https://example.com", // Required: Target URL
"session": "session_id_here", // Required: Session ID to use
"postData": "key=value", // Optional: POST data
"customHeaders": { // Optional: Custom headers
"User-Agent": "custom-agent"
}
}scrappey_browser_action )브라우저 자동화 작업을 실행합니다.
{
"session": "session_id_here", // Required: Session ID to use
"browserActions": [ // Required: Array of actions to perform
{
"type": "click", // Action type: click, hover, type, scroll, wait
"cssSelector": ".button", // CSS selector for element
"text": "Hello", // Text to type (for type action)
"wait": 1000 // Wait time in ms
}
]
}세션을 생성하세요:
{
"name": "scrappey_create_session"
}반환된 세션 ID를 후속 요청에 사용합니다.
{
"name": "scrappey_request",
"cmd": "request.get",
"url": "https://example.com",
"session": "returned_session_id"
}필요한 경우 브라우저 작업을 수행합니다.
{
"name": "scrappey_browser_action",
"session": "returned_session_id",
"browserActions": [
{
"type": "click",
"cssSelector": "#login-button"
},
{
"type": "type",
"cssSelector": "#username",
"text": "myuser"
}
]
}완료되면 세션을 삭제하여 정리합니다.
{
"name": "scrappey_destroy_session",
"session": "returned_session_id"
}상태 유지를 위한 세션 지속성
자동 봇 방지 처리
사용자 정의 프록시 지원
브라우저 자동화 기능
HTTP 요청 방법(GET, POST, PUT, DELETE, PATCH)
사용자 정의 헤더 및 쿠키 지원
세션을 마치면 항상 파기하세요.
동일한 사이트에 여러 요청을 할 때 세션을 재사용합니다.
더욱 인간적인 행동을 위해 작업 사이에 적절한 대기 시간을 사용하세요.
사용하기 전에 세션이 존재하는지 확인하세요
문제가 발생하면 서버에서 자세한 내용이 포함된 오류 메시지를 반환합니다. 일반적인 오류는 다음과 같습니다.
잘못된 세션 ID
네트워크 시간 초과
브라우저 작업에 대한 잘못된 선택기
봇 방지 보호 실패
MIT 라이센스
Execute browser automation actions in a session. Supports clicking, typing, scrolling, waiting, JavaScript execution, captcha solving, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session ID to use | |
| url | Yes | URL to navigate to before actions | |
| cmd | Yes | HTTP method for initial navigation | |
| browserActions | Yes | Array of browser actions to execute sequentially | |
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| cloudflareBypass | No | Enable Cloudflare-specific bypass | |
| datadomeBypass | No | Enable Datadome bypass using specialized solver | |
| kasadaBypass | No | Enable Kasada bypass | |
| disableAntiBot | No | Disable automatic antibot detection | |
| automaticallySolveCaptchas | No | Automatically detect and solve captchas on the page | |
| alwaysLoad | No | Always load specific captcha types: 'recaptcha', 'hcaptcha', 'turnstile' | |
| cssSelector | No | Extract content matching this CSS selector | |
| innerText | No | Include inner text of page elements | |
| includeImages | No | Include all image URLs in the response | |
| includeLinks | No | Include all link URLs in the response | |
| screenshot | No | Capture page screenshot | |
| screenshotWidth | No | Screenshot width in pixels | |
| screenshotHeight | No | Screenshot height in pixels | |
| filter | No | Return only specified fields: 'response', 'cookies', 'statusCode', 'innerText', etc. | |
| video | No | Record browser session as video | |
| No | Generate PDF of the page | ||
| interceptFetchRequest | No | URL pattern to intercept and return response data | |
| abortOnDetection | No | URL patterns to block (e.g., analytics, tracking scripts) | |
| whitelistedDomains | No | Only allow requests to these domains | |
| blackListedDomains | No | Block requests to these domains | |
| blockCookieBanners | No | Automatically block cookie consent banners | |
| mouseMovements | No | Enable human-like mouse movements | |
| forceMouseMovement | No | Force mouse movement simulation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions supported actions but lacks critical behavioral details: it doesn't specify error handling (e.g., what happens if an action fails), performance characteristics (e.g., timeouts, rate limits), authentication needs, or side effects (e.g., whether actions are reversible). The list of actions is informative but insufficient for a tool with 32 parameters and complex automation capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that states the core purpose and enumerates key actions. Every word earns its place by conveying essential information without redundancy or fluff, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (32 parameters, no annotations, no output schema), the description is inadequate. It lacks information on output format, error responses, session dependencies, and behavioral constraints. For a powerful automation tool with many configuration options, the description should provide more context about how actions are executed, what results to expect, and common pitfalls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 32 parameters thoroughly. The description adds minimal value beyond the schema by listing action types (e.g., 'clicking, typing, scrolling') but doesn't explain parameter interactions, defaults, or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute browser automation actions in a session' with a list of supported actions (clicking, typing, etc.). It specifies the verb ('execute') and resource ('browser automation actions'), but doesn't explicitly differentiate from sibling tools like scrappey_request or scrappey_screenshot, which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a session from scrappey_create_session), exclusions, or comparisons to sibling tools like scrappey_request (for simpler requests) or scrappey_screenshot (for just screenshots). Usage is implied by the action list but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new browser session in Scrappey. Sessions persist browser state (cookies, localStorage) across requests.
| Name | Required | Description | Default |
|---|---|---|---|
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| browser | No | Browser specification: [{"name": "firefox", "minVersion": 120, "maxVersion": 130}] | |
| userAgent | No | Custom user agent string | |
| locales | No | Browser locale settings (e.g., ['en-US', 'en']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that sessions 'persist browser state across requests,' which hints at statefulness, but doesn't cover critical aspects like authentication needs, rate limits, error handling, or what happens on failure. For a creation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a clarifying detail about session persistence. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating a browser session with multiple configuration options (8 parameters) and no annotations or output schema, the description is incomplete. It lacks information on return values, error conditions, or how the session integrates with other tools, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3. It doesn't compensate for any gaps because there are none in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new browser session') and resource ('in Scrappey'), with additional context about what sessions persist ('browser state like cookies, localStorage across requests'). It distinguishes from siblings like 'scrappey_destroy_session' and 'scrappey_list_sessions' by focusing on creation rather than management or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, when to choose this over other session-related tools, or any specific scenarios where creating a session is necessary versus using direct requests. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Destroy an existing browser session in Scrappey to free resources
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session ID to destroy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool destroys a session to free resources, indicating a destructive action, but doesn't mention behavioral traits like whether destruction is irreversible, what happens to associated data, error conditions, or rate limits. For a destructive tool with zero annotation coverage, this leaves significant gaps in understanding the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose and benefit ('to free resources'). It is front-loaded with the core action and avoids unnecessary details, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive action with one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but doesn't address return values, error handling, or resource implications. For a destructive tool, more context on outcomes or safety would improve completeness, but it meets a baseline level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'session' documented as 'Session ID to destroy.' The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately defines the parameter without extra description needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Destroy') and resource ('existing browser session in Scrappey'), making the purpose unambiguous. It distinguishes from siblings like 'scrappey_create_session' and 'scrappey_list_sessions' by focusing on termination rather than creation or listing. However, it doesn't explicitly contrast with 'scrappey_session_active' which might check session status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to 'free resources,' suggesting it's for cleanup after session use. However, it doesn't specify when to use this tool versus alternatives (e.g., whether to destroy vs. keep sessions active for reuse) or provide explicit exclusions. The context is clear but lacks detailed guidance on timing or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active sessions for the current user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it lists active sessions but doesn't mention what 'active' means, whether it's read-only or has side effects, or any rate limits or authentication requirements. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters and no output schema, the description is minimally adequate by stating what it does. However, with no annotations and sibling tools present, it lacks details on behavior, usage context, and output format, making it incomplete for optimal agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and a baseline of 4 is applied since it doesn't add unnecessary information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all') and target resource ('active sessions for the current user'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'scrappey_session_active' which might serve a similar purpose, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'scrappey_session_active' or 'scrappey_destroy_session'. It lacks context about prerequisites, such as whether authentication is required, or any explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an HTTP request using Scrappey with antibot bypass capabilities. Supports GET, POST, PUT, DELETE, PATCH methods.
| Name | Required | Description | Default |
|---|---|---|---|
| cmd | Yes | HTTP method to use | |
| url | Yes | Target URL to request | |
| session | No | Session ID for session persistence | |
| postData | No | Data to send with POST/PUT/PATCH requests | |
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| cloudflareBypass | No | Enable Cloudflare-specific bypass | |
| datadomeBypass | No | Enable Datadome bypass using specialized solver | |
| kasadaBypass | No | Enable Kasada bypass | |
| disableAntiBot | No | Disable automatic antibot detection | |
| automaticallySolveCaptchas | No | Automatically detect and solve captchas on the page | |
| alwaysLoad | No | Always load specific captcha types: 'recaptcha', 'hcaptcha', 'turnstile' | |
| cssSelector | No | Extract content matching this CSS selector | |
| innerText | No | Include inner text of page elements | |
| includeImages | No | Include all image URLs in the response | |
| includeLinks | No | Include all link URLs in the response | |
| screenshot | No | Capture page screenshot | |
| screenshotWidth | No | Screenshot width in pixels | |
| screenshotHeight | No | Screenshot height in pixels | |
| filter | No | Return only specified fields: 'response', 'cookies', 'statusCode', 'innerText', etc. | |
| video | No | Record browser session as video | |
| No | Generate PDF of the page | ||
| interceptFetchRequest | No | URL pattern to intercept and return response data | |
| abortOnDetection | No | URL patterns to block (e.g., analytics, tracking scripts) | |
| whitelistedDomains | No | Only allow requests to these domains | |
| blackListedDomains | No | Block requests to these domains | |
| blockCookieBanners | No | Automatically block cookie consent banners | |
| customHeaders | No | Custom HTTP headers to send | |
| cookies | No | Cookie string to set | |
| cookiejar | No | Cookie jar array format | |
| localStorage | No | LocalStorage data to set | |
| referer | No | HTTP Referer header value | |
| userAgent | No | Custom user agent string | |
| timeout | No | Request timeout in milliseconds | |
| retries | No | Number of retry attempts on failure | |
| fullPageLoad | No | Wait for full page load | |
| listAllRedirects | No | Track and return all redirect URLs | |
| removeIframes | No | Remove all iframes from page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'antibot bypass capabilities,' it fails to describe critical behavioral traits: whether this is a read-only or destructive operation, authentication requirements, rate limits, error handling, or what the response format looks like. For a complex tool with 41 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that captures the core functionality. Every word earns its place with no redundancy or unnecessary elaboration. This is an excellent example of efficient communication for a tool with extensive schema documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (41 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't address what the tool returns, error conditions, performance characteristics, or how it integrates with sibling tools. While the schema covers parameters well, the description fails to provide the broader context needed for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 41 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain parameter relationships, default behaviors, or practical examples. The baseline score of 3 reflects adequate coverage through the schema alone, with no extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Send an HTTP request using Scrappey with antibot bypass capabilities. Supports GET, POST, PUT, DELETE, PATCH methods.' This specifies the verb ('Send an HTTP request'), resource ('using Scrappey'), and key capability ('antibot bypass'). However, it doesn't explicitly differentiate from sibling tools like 'scrappey_browser_action' or 'scrappey_create_session', which likely have overlapping web interaction functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It mentions 'antibot bypass capabilities' but doesn't explain when this is needed compared to simpler HTTP requests or other sibling tools. There are no usage prerequisites, exclusions, or named alternatives provided, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of a webpage. Optionally execute browser actions before capturing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to screenshot | |
| session | No | Optional session ID to use | |
| screenshotWidth | No | Screenshot width in pixels (default: 1920) | |
| screenshotHeight | No | Screenshot height in pixels (default: 1080) | |
| fullPage | No | Capture full page instead of viewport | |
| browserActions | No | Optional actions to execute before screenshot | |
| proxy | No | Proxy in format http://user:pass@ip:port. Leave blank to use built-in proxy. | |
| proxyCountry | No | Request proxy from specific country (e.g., 'UnitedStates', 'Germany', 'UnitedKingdom') | |
| premiumProxy | No | Use premium residential-like proxies for better success rates | |
| mobileProxy | No | Use mobile carrier proxies | |
| noProxy | No | Disable proxy usage entirely | |
| cloudflareBypass | No | Enable Cloudflare-specific bypass | |
| datadomeBypass | No | Enable Datadome bypass using specialized solver | |
| kasadaBypass | No | Enable Kasada bypass | |
| disableAntiBot | No | Disable automatic antibot detection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the optional browser actions capability but doesn't describe important behaviors: whether this is a read-only operation (likely, but not stated), what happens with sessions, rate limits, authentication needs, error handling, or what the output looks like (image format, size). The description is minimal for a tool with 15 parameters and complex functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each add value. First sentence states core functionality, second adds the key optional capability. No wasted words, front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (image data format? file? URL?), doesn't mention performance characteristics, error conditions, or practical constraints. The agent would need to infer too much from the parameter schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 15 parameters thoroughly. The description adds no parameter-specific information beyond implying that 'browserActions' can be used before capturing. It doesn't explain parameter relationships, default behaviors, or practical usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Take a screenshot of a webpage' (specific verb+resource). It adds 'Optionally execute browser actions before capturing' which distinguishes it from basic screenshot tools, though it doesn't explicitly differentiate from sibling tools like 'scrappey_browser_action' which might handle browser actions separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention sibling tools like 'scrappey_browser_action' (for actions without screenshot), 'scrappey_request' (for non-browser requests), or 'scrappey_create_session' (for session management). There's no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a specific session is currently active
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session ID to check |
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 states the tool checks session activity but doesn't describe what 'active' means (e.g., browser session status, timeout behavior), response format (e.g., boolean, status details), error handling, or any rate limits. This leaves significant gaps for a tool that likely interacts with session management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple check operation, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'active' entails, the return value (e.g., true/false, status object), or error cases (e.g., invalid session ID). For a session management tool with no structured output, more context is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter semantics beyond what the input schema provides. The schema has 100% description coverage, clearly documenting the single required 'session' parameter as a session ID to check. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as checking if a specific session is active, using the verb 'check' and specifying the resource 'session'. It distinguishes from siblings like 'scrappey_list_sessions' (which lists sessions) and 'scrappey_destroy_session' (which destroys sessions), but doesn't explicitly differentiate from all siblings like 'scrappey_browser_action' or 'scrappey_request'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a valid session ID), exclusions, or relationships with sibling tools like 'scrappey_list_sessions' (which might be used to get session IDs first). Usage 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.0.0scrappey_browser_actionscrappey_create_sessionscrappey_destroy_sessionscrappey_list_sessionsscrappey_requestscrappey_screenshotscrappey_session_activeEach tool has a clearly distinct purpose with no ambiguity. scrappey_browser_action handles automation interactions, scrappey_request manages HTTP requests, scrappey_screenshot captures visual content, and the session tools (create, destroy, list, active) each manage specific session lifecycle aspects without overlap.
All tools follow a perfect 'scrappey_verb_noun' pattern with consistent snake_case throughout. The naming convention is predictable and uniform across all seven tools, making them easily identifiable as part of the same server.
Seven tools is well-scoped for a browser automation and web scraping server. Each tool earns its place by covering distinct aspects: session management, browser automation, HTTP requests, and screenshot capabilities without being overwhelming or insufficient.
The toolset provides complete coverage for browser automation and web scraping workflows. It includes full session lifecycle management (create, destroy, list, check), core automation actions, HTTP requests with antibot bypass, and screenshot functionality, leaving no obvious gaps for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Zenrows MCP server — Fetch, Extract, Batch, and Browser Sessions for AI coding assistants
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pim97/mcp-server-scrappey'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
