OpenTor MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but a few close pairs exist: tor_get_links versus tor_extract_threads/posts, and tor_screenshot versus tor_screenshot_element. The captcha tools also have overlapping functionality, though they differ in auto-solving versus manual reading.
Naming Consistency5/5
All tool names follow a consistent pattern: 'tor_' followed by a verb and an optional noun (e.g., tor_navigate, tor_click, tor_list_sessions). There is no mixing of camelCase or different verb styles, making the naming predictable and uniform.
Tool Count2/5
With 27 tools, the server exceeds the 25-tool threshold that the rubric marks as 'too many'. While the domain of Tor browsing is broad, many tools could be consolidated (e.g., session management, captcha handling, or extraction tools). The count feels heavy for typical MCP servers.
Completeness4/5
The tool set covers the core lifecycle of browsing: navigation, interaction, content extraction, screenshots, session management, and captcha handling. Minor gaps exist, such as no dedicated form submission, file upload, or element attribute retrieval tool, but these are workaroundable with evaluate_js or click/type.
Average 3.6/5 across 27 of 27 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
Annotations are present but the description adds no behavioral context. It doesn't disclose whether the search has side effects, rate limits, or authentication requirements. Given readOnlyHint is false and openWorldHint is true, the description offers no additional transparency beyond what annotations already indicate.
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 very brief and front-loaded with the core action (search). However, it omits essential details, making it under-specified rather than appropriately compact. It's not verbose or redundant, but it sacrifices clarity for brevity.
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 search tool with an output schema and multiple parameters, the description is insufficient. It doesn't explain what results are returned, how pagination works, or the differences between the engines. The sibling tools suggest a rich context that this description fails to address.
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?
Schema description coverage is 0%, so the description carries the full burden for parameter explanation. It only lists engine names, which map to the engine parameter, but provides no explanation of query, limit, or max_chars. The description fails to compensate for the schema's lack of descriptive text.
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 that the tool performs a search using specific engines (Ahmia, Torch, DuckDuckGo, Haystack). This distinguishes it from sibling tools like tor_navigate or tor_read_page. However, it doesn't specify what kind of content is being searched (e.g., Tor network, general web), so it's not fully specific.
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. The description implies a search function but doesn't mention use cases, prerequisites, or any exclusions. Users are left to infer the appropriate context from the tool name and the list of engines.
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?
The description adds no behavioral details beyond what annotations already declare (destructiveHint=true). It doesn't mention side effects, whether the archive overwrites existing content, or any permissions needed. The annotation already signals mutation, so the description provides minimal added context.
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 or repetition. It is front-loaded with the action and target. While extremely short, it is not padded; however, it sacrifices necessary detail for brevity.
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?
Despite being a simple tool, the description is incomplete for effective use. It omits the meaning of the required 'name' parameter, any successful output details (despite an output schema being present), and lacks context on the destructive nature beyond the annotation. The description alone is insufficient for an agent to invoke it confidently.
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 input schema has a required 'name' parameter with zero description. The tool description does not explain what 'name' refers to (e.g., archive name, filename). With 0% schema coverage, the description completely fails to compensate or clarify the parameter's meaning.
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 ('Archive') and the resource ('the current page') along with the destination ('the configured local archive root'). This is specific and distinguishes it from sibling tools like tor_screenshot or tor_read_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?
No guidance is provided on when to use this tool versus alternatives or any prerequisites (e.g., navigating to a page first). The description only states what it does, not when to invoke it.
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?
The description merely states the obvious action without revealing behavioral traits like whether it clears the existing field content, how it handles non-focusable elements, or what happens if the selector is invalid. The annotations indicate destructiveHint=true, but the description adds no extra context to help the agent anticipate 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, front-loaded sentence with no filler. Every word is necessary, and it is appropriately concise for the tool's simplicity.
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 the tool has an output schema and annotations, the description is extremely sparse. It lacks any mention of error handling, waiting behavior, or how the selector is interpreted. This makes it incomplete for an agent to correctly invoke the tool in unfamiliar situations, especially since parameter semantics are undocumented.
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?
With 0% schema description coverage, the description must explain the parameters, but it does not. The description says 'Type text into an input field' but does not clarify that 'selector' is a CSS/XPath selector or that 'text' is the string to enter. The parameter names alone are insufficient, so the description fails to add meaningful value.
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 'Type' and the resource 'an input field', making it distinct from siblings like tor_click or tor_press_key. The verb+resource structure leaves no ambiguity about the tool's primary 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?
The description offers no guidance on when to use this tool versus alternatives such as tor_press_key or tor_click. It does not mention any conditions, prerequisites, or contexts where typing is preferred over other input methods.
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 already indicate the tool is not read-only, not destructive, and not idempotent. The description adds that it saves cookies to 'owner-only local storage', providing some context. However, it does not mention overwrite behavior or whether a session with the same name is replaced.
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 directly states the core function. No redundant words or unnecessary 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?
While the tool is simple and an output schema exists, the description fails to explain crucial context: what 'name' refers to, whether it overwrites existing sessions, and when to save a session. The lack of parameter semantics and usage guidance leaves the agent guessing.
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 completely ignores the single required parameter 'name'. The schema only labels it as 'Name' with no description, and schema description coverage is 0%. The agent receives no help understanding what value to provide for 'name'.
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 uses a specific verb ('save') and resource ('cookies') and clearly distinguishes this from sibling tools like tor_load_session, tor_list_sessions, and tor_delete_session. It's immediately obvious what action the tool performs.
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. It does not mention that it complements tor_load_session or that sessions are named via the 'name' parameter. There is no context about appropriate 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?
Annotations already indicate readOnlyHint false, openWorldHint true, and idempotentHint false, but the description adds no behavioral context beyond the basic action. It does not disclose that scrolling may trigger lazy loading, affect page state, or that 'top'/'bottom' are absolute jumps. With annotations present, the description still fails to provide meaningful side-effect information.
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 brief and front-loaded, with the action stated in the first sentence and the parameter details in the second. No fluff or repetition appears. It could be considered slightly under-specified, but that is a completeness issue, not a conciseness one.
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?
The tool is simple, but the description fails to cover key contextual aspects: no usage guidance, no behavioral side-effect warnings, and incomplete parameter semantics for 'amount'. The output schema likely covers return values, but even so, the overall description is not sufficient for an agent to correctly select and invoke the tool in all situations.
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 0%, so the description carries full parameter-semantics burden. It adds value by enumerating valid values for 'direction' (up/down/top/bottom), which the schema leaves undefined. However, it omits any explanation of 'amount' (e.g., pixel units, range, or behavior when omitted), leaving a significant gap.
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 tool's function ('Scroll the page') and lists the valid direction values, making the purpose unambiguous. It distinguishes itself from sibling navigation tools like tor_back/forward and content-reading tools like tor_read_page, though it doesn't explicitly differentiate from other scrolling tools.
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 ('Scroll the page') and lists direction options, but provides no explicit guidance on when to use this tool versus alternatives like tor_navigate or tor_back. There is no mention of scenarios where scrolling is appropriate, such as lazy-loading content or adjusting viewport focus.
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?
Annotations provide no safety hints (all false), so the description bears the burden of disclosing side effects. It implies a state change (loading cookies into the browser) but does not explain whether it replaces current cookies, requires navigation, or affects the current page. This lack of detail leaves significant behavioral ambiguity.
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 is front-loaded with the action and resource. Every word earns its place, and there is no redundancy.
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 low-complexity tool with one parameter and an output schema, the description is minimally viable but incomplete. The lack of parameter explanation and behavioral/usage context leaves gaps, though the output schema covers return values. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'name' with no description (0% coverage). The description does not mention the parameter or clarify that 'name' refers to the saved session identifier. Without this, the agent cannot confidently determine what value to supply.
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 'Load previously saved cookies into the browser' uses a specific verb and resource, clearly indicating the action and distinguishing it from sibling tools like tor_save_session and tor_delete_session. The phrase 'previously saved' also clarifies that it operates on stored session 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?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., a session must already be saved), and no mention of the expected context. It simply states the action without usage 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?
Annotations already declare destructiveHint=true, so the destructive nature is covered. However, the description adds minimal behavioral context beyond the selector method; it doesn't mention waiting behavior, scrolling into view, or potential page state changes. With annotations present, this is acceptable but not rich.
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?
One short, front-loaded sentence that gets straight to the point. Every word earns its place; there is no fluff or redundancy.
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?
This is a simple click tool with two parameters, annotations, and an output schema. The annotations cover the destructive nature, and the output schema presumably documents return values. However, the lack of usage guidelines and limited parameter semantics leaves important context gaps, making it merely adequate.
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?
The description mentions 'by CSS selector', which clarifies that the selector parameter is a CSS selector, adding some meaning beyond the schema's string type. However, the timeout parameter is completely unaddressed. Given 0% schema description coverage, the description should compensate more but only partially does.
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 uses a specific verb ('Click') and identifies the resource ('an element') and method ('by CSS selector'). It clearly distinguishes this from sibling tools like tor_type or tor_press_key, which have different actions.
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 tor_evaluate_js for clicking or tor_query_elements for locating elements. It also doesn't mention prerequisites or special conditions for use.
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 already declare destructiveHint=true and readOnlyHint=false, and the description adds the context that a session credential file is deleted. However, it does not disclose any additional behavioral traits such as whether deletion is permanent, requires confirmation, or fails if the session doesn't exist. With annotations present, this minimal addition is acceptable but not rich.
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 front-loads the action and object. Every word earns its place, and there is no redundant information.
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 deletion tool with annotations and an output schema, the description is minimal but functional. It lacks guidance on necessary prerequisites (e.g., the session must exist) or consequences (e.g., irreversible deletion). It could benefit from mentioning related tools for session management, but overall it provides the core 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?
The schema has one required parameter 'name' with no description (0% coverage). The description implies that 'name' refers to a saved session file, but it does not explicitly define the parameter's format, accepted values, or relationship to list_sessions. The compensation is minimal.
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 (delete) and specific resource (saved session credential file), distinguishing it from sibling tools like tor_save_session, tor_load_session, and tor_list_sessions. The verb+object structure is 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 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. It does not mention related tools (e.g., tor_list_sessions for finding session names) or any prerequisites/exclusions. Users must infer usage from the tool name alone.
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 already indicate this is a safe, read-only operation (readOnlyHint=true, destructiveHint=false). The description adds 'bounded page', which suggests that only a limited set of links is returned, but it doesn't clarify pagination behavior or whether links are deduplicated or absolute/relative. Since annotations cover the safety profile, a score of 3 is appropriate for the added context.
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 with no filler words. It gets straight to the point with a clear verb and object. It is well-structured and front-loaded, making it easy to parse quickly.
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 tool has only 2 optional parameters and an output schema, which covers return values. However, the description is extremely sparse: it doesn't explain what 'bounded page' means concretely, how limit/offset interplay, or what types of links are extracted. Given the simplistic nature, it is adequate but leaves gaps that may confuse an agent.
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. It only says 'bounded page', which loosely maps to limit and offset but doesn't explicitly state that 'limit' caps the number of links and 'offset' skips a number. The parameter names are self-explanatory to a degree, but without any description, the agent lacks clarity on exact semantics.
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 uses a specific verb 'Extract' with a clear resource 'links from the current page'. It also mentions 'bounded page', which hints at pagination and distinguishes this tool from sibling tools like tor_read_page (reads full page) or tor_query_elements (queries arbitrary elements). This makes the purpose highly clear and distinct.
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 other link-extraction or querying tools. There is no mention of alternatives like tor_query_elements or tor_extract_posts, nor any exclusions or recommended contexts. The only implied usage is from the tool name itself, which is not enough.
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 annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that it returns native MCP image content, which is useful. However, it does not mention any behavioral aspects like requiring an active page or potential side effects of capturing the screenshot. It adds minimal context beyond 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 a single concise sentence of 10 words. It efficiently conveys the tool's purpose without any redundant information. 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?
For a simple tool with one optional parameter and no output schema, the description is minimally viable. However, it lacks usage guidance (e.g., distinguishing from tor_screenshot_element) and parameter semantics, making it incomplete for a new agent to know exactly when and how to invoke it. Annotations cover safety, but the description leaves gaps.
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?
The input schema has one parameter, full_page, with no description, and schema description coverage is 0%. The description does not explain this parameter at all. The parameter name 'full_page' is somewhat self-explanatory, but the description fails to clarify when to set it true (full page) versus false (viewport). The description provides no added semantics for 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?
The description clearly states 'Take a screenshot' with a specific verb and resource, and adds the return type 'native MCP image content.' It distinguishes itself from sibling tools like tor_screenshot_element (which captures a specific element) and tor_read_page (which reads page content). This is a clear and specific purpose.
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. There is no mention of using it for a full-page capture versus tor_screenshot_element for element captures, nor any exclusions or prerequisites. The description only states what it does, not when to choose it.
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 already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds 'bounded page' but does not disclose ordering, exact page semantics, or whether it operates on the current thread/forum. With annotation coverage, the added context is modest but not misleading.
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 front-loaded sentence that communicates the essential purpose and scope. No filler or redundancy.
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 tool is simple (2 optional params, read-only, has output schema) and the description covers core purpose. However, it lacks usage context versus sibling tools and enough parameter detail, making the overall package adequate but not fully 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?
Schema description coverage is 0%, so the description must compensate. 'Bounded page' hints at limit/offset pagination, and the parameter names are self-explanatory, but the description does not explicitly explain units, maximum limits, or how offset relates to result sets. Minimal compensation only.
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 'Extract a bounded page of forum posts' names a specific verb (extract), a clear resource (forum posts), and the bounded/paginated nature. It also distinguishes from the sibling tool tor_extract_threads by targeting posts rather than threads.
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 given on when to use this tool instead of alternatives such as tor_extract_threads, nor any mention of typical scenarios, exclusions, or prerequisites. The description only states what it does, not when to choose it.
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?
The description provides no behavioral traits beyond the simple action. It doesn't mention side effects (e.g., page state changes), error conditions (e.g., no forward history), or interactions with the session. Annotations do not add context, so the description carries the burden and fails to disclose any non-obvious 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?
The description is a single short sentence that perfectly conveys the action without any fluff. Every word earns its place, and it is appropriately sized for a tool with no parameters.
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 tool's extreme simplicity (no params, a single action) and the presence of an output schema, the description is largely sufficient. However, it could be improved by mentioning edge cases like the behavior when no forward history exists, which would make it more complete.
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 no parameters (0 params, schema coverage 100%), so there is nothing to explain. The baseline of 4 is appropriate because no parameter semantics are needed.
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 'Go forward to the next page' clearly states the action (go forward) and the resource (page). It distinguishes from sibling 'tor_back' by implying the opposite direction, though it doesn't explicitly mention 'browser history' to remove ambiguity.
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?
Usage is implied by the name and action: use when you need to move forward in the browsing history. However, there is no explicit guidance on when to use this over alternatives like tor_navigate or tor_back, nor any mention of preconditions (e.g., having a forward history).
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?
Annotations already indicate destructive, non-idempotent, and open-world behavior. The description adds no additional context, such as potential form submission or navigation triggering when pressing Enter, focus requirements, or whether the key press targets the active element or entire page.
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 with valuable examples. It is front-loaded and contains no superfluous information, making it an efficient definition.
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 tool is simple and an output schema exists, so return values are covered. However, the description omits potential side effects (e.g., pressing Enter may submit a form) and does not clarify the operational context (e.g., whether a page or element must be focused). Given the destructiveHint, more behavioral context would make it 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 only parameter 'key' has zero schema description coverage, but the description provides examples (Enter, Tab, Escape) that hint at the expected format. However, it doesn't specify the full set of accepted values, case sensitivity, or how to represent special keys, leaving some ambiguity.
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 ('Press a keyboard key') and provides specific examples (Enter, Tab, Escape). It is easily distinguishable from sibling tools like tor_type (typing text) and tor_click (clicking).
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?
There is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites mentioned. The examples imply usage for key-based interactions, but this is indirect rather than explicit.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=false, covering the safety profile. The description adds 'bounded page', which hints at pagination behavior, but does not detail how limit/offset operate or what happens at boundaries.
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, front-loaded sentence with no redundant words. It immediately identifies the action and resource.
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 presence of an output schema and annotations, the description is adequate for a simple read tool, but it omits parameter semantics and practical usage context. It is minimally viable but leaves gaps when an agent needs to invoke with specific limits or offsets.
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%, and the description does not explicitly explain limit or offset. 'Bounded page' vaguely implies pagination but fails to define parameter roles, leaving the agent to infer from names and defaults.
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 uses a specific verb 'Extract' and resource 'forum thread listings', clearly distinguishing it from sibling tools like tor_extract_posts. 'Bounded page' signals pagination, reinforcing its specialized role.
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 a use case (getting thread listings) but does not explicitly state when to use this tool over alternatives. No exclusionary guidance is provided, though the name and wording create a clear contextual hint.
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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds 'bounded page' which hints at pagination behavior, but it does not explain result ordering, empty-result behavior, or whether the selector returns all matches or just the first. No contradiction with 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 a single, front-loaded sentence with no filler. Every word earns its place, and 'bounded page' efficiently communicates the pagination constraint.
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 presence of an output schema and annotations, the description covers the core purpose and key pagination constraint. It leaves some ambiguity around what 'bounded page' means precisely and does not mention how the results relate to the DOM, but for a simple read-only query tool it is reasonably 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?
Schema description coverage is 0%, so the description must compensate. It identifies the selector as a CSS selector and 'bounded page' implies limit/offset semantics, but it does not explain the meaning of limit or offset beyond their names and defaults. This is adequate but minimal compensation for the missing schema descriptions.
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 (Query), target (DOM elements), mechanism (CSS selector), and scope (bounded page). It distinguishes itself from sibling tools like tor_get_links (which extracts links) and tor_read_page (which reads page text).
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. It does not mention typical workflows, prerequisites, or scenarios where another sibling tool might be more appropriate. The usage context is entirely implied.
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?
The description does not disclose any behavioral traits beyond what the annotations already specify. Refresh may trigger page reloads that discard unsaved form data or re-send POST requests, but this is not mentioned. With annotations already stating readOnlyHint=false and destructiveHint=false, the description adds no extra context about side effects or state changes.
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, front-loaded sentence that conveys the exact action with no extraneous information. Every word earns its place, and the structure is appropriately minimal for a tool of this simplicity.
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 tool's low complexity (no parameters, simple action), the description is largely complete. It clearly states what the tool does, and the output schema exists to handle return value expectations. However, it lacks mention of edge cases like unsaved data or timing, so it is not a perfect 5.
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 tool has zero parameters, and the schema is empty with 100% coverage. Per the baseline, a description is not required to compensate for missing parameter info. The description correctly omits parameter details since there are none, making it appropriate for 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 'Refresh the current page.' uses a clear, specific verb and resource. It distinguishes the tool from siblings like tor_navigate, tor_back, and tor_forward, which have different navigation actions. It unambiguously states the tool's 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?
The description offers no guidance on when to use this tool versus alternatives. It does not mention scenarios where a refresh is preferable to re-navigating, nor does it note any prerequisites or conditions. The agent receives no contextual help for tool selection.
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 is minimal and does not add much beyond the annotations. It implies a state change (non-read-only) but doesn't disclose edge cases like an empty history. This is acceptable because annotations already cover basic safety profile, but the lack of extra context keeps it at a mid score.
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 sentence, front-loaded and free of waste. It delivers the core purpose without any fluff.
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 tool's simplicity and the presence of an output schema, the description covers the essential behavior. It lacks usage guidance but is otherwise sufficient for an agent to understand the action.
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 tool has zero parameters, so the schema is trivially complete. The baseline for 0 params is 4, and the description adds no parameter information because none 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 ('Go back') and the target resource ('the previous page'), making it specific and distinguishable from sibling tools like tor_forward and tor_navigate.
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. It does not mention browser history behavior, prerequisites, or exclusions, leaving the agent without context for selection.
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 annotations already indicating read-only and non-destructive behavior, the description adds useful behavioral context: it attempts local OCR as a hint and emphasizes the agent's vision as the primary reading mechanism. No annotation contradiction is present.
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?
Three concise sentences front-load the core purpose, mention the OCR hint, and provide the follow-up action. Every sentence earns its place with no filler or redundancy.
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 covers the return type (image), OCR hint, and workflow, but leaves the selector parameter undefined and doesn't describe possible failure modes or return format details. For a simple read-only tool, it's adequate but has clear gaps.
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 single required parameter `selector` is never explained in the description. Schema description coverage is 0%, so the description must compensate, but it provides no guidance on how the selector should be specified (e.g., CSS selector for the CAPTCHA element).
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 captures a CAPTCHA image and returns it for the agent to read, distinguishing it from sibling tools like tor_screenshot_element (generic element screenshot) and tor_solve_captcha (automatic solving). The verb 'Capture' and specific resource 'CAPTCHA image' make the purpose unmistakable.
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 on when to use the tool ('Primary strategy: YOU read the image') and instructs the next step ('After reading, call tor_type to fill in the answer'). It doesn't explicitly name alternatives or exclusions, but the usage context is well-defined.
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 already indicate that the tool is not read-only, is open-world, and is non-idempotent, so the description does not need to restate those. It adds value by restricting the URL scheme to HTTP(S) and highlighting .onion support, which is a behavioral constraint. However, it does not describe what happens during navigation (e.g., waiting for page load, handling errors, or timeouts), so additional context would have been useful.
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 front-loads the core action and provides a key feature (.onion support). Every word adds value with no extraneous content.
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 tool is relatively simple (navigate to a URL), and an output schema exists, so return values are covered. However, the description leaves gaps such as the meaning of the timeout parameter, whether it waits for full page load, and any prerequisites (e.g., an active Tor session). Given the richness of the sibling tools and the annotations, this is adequate but could be more helpful.
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?
The schema has 0% description coverage for parameters. The description mentions 'URL' which aligns with the 'url' parameter but adds no meaningful info beyond the parameter name. The 'timeout' parameter is completely unexplained, and the description fails to compensate for the schema's lack of parameter descriptions.
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 (Navigate) and the resource (HTTP(S) URL), with an important differentiator (.onion supported). It distinguishes from sibling tools like tor_back/forward/refresh, which are about navigating the current session, whereas this explicitly targets a new URL.
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 clearly implies when to use this tool: whenever the goal is to load a specific HTTP(S) URL. It does not explicitly mention alternatives or exclusions, but the context is clear enough that an agent can infer the appropriate scenario. There is no mention of when NOT to use it, but the action is specific.
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 already indicate read-only and non-destructive behavior, so the description adds the 'native MCP image content' return format, which is useful. However, it does not disclose potential caveats such as element visibility requirements, selector validity, or failure behavior. The description adds some context beyond annotations but not much.
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 is front-loaded with the core action and resource. Every word contributes to understanding the tool, with no filler or repetition.
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 simple tool with one parameter and no output schema, the description covers the primary purpose and return format. It is adequate for basic usage, though it omits edge cases like missing elements or scrolling. Overall, it is sufficiently complete for the tool's simplicity.
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 0%, so the description must compensate. It mentions 'CSS-selected element,' which implies the 'selector' parameter is a CSS selector, adding meaning to the otherwise bare schema field. However, it does not elaborate on selector syntax, required format, or limitations, offering only minimal extra semantics.
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 function: to screenshot a CSS-selected element. It specifies the verb (screenshot), the resource (CSS-selected element), and the output format (native MCP image content). This distinguishes it from sibling tor_screenshot, which is likely for full-page captures.
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?
Usage context is implied but not explicit. The description says 'screenshot a CSS-selected element,' which suggests it is used when capturing a specific element, but it does not mention alternatives or when not to use it. There is no explicit comparison to tor_screenshot or other tools.
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 already communicate destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds the gating condition TOR_ALLOW_JAVASCRIPT, providing extra context about when the tool will actually execute. However, it doesn't disclose details about script execution side effects or failure behavior when the environment variable is not set, leaving some behavioral aspects implicit.
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, front-loaded with the main action ('Execute JavaScript') and followed by a concise condition. Every word contributes meaning, with zero redundancy or filler.
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 tool's low complexity (one param) and the presence of an output schema, the description is largely adequate. It specifies the essential precondition (TOR_ALLOW_JAVASCRIPT=true) and the action. However, it could have also noted potential side effects or behavior when the condition is unmet, but with annotations covering destructive intent and a simple param, the description meets most needs.
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%, and the description does not explain what the 'script' parameter should contain or any format expectations. While the parameter name is self-explanatory (a JavaScript string), the description adds no semantic value beyond the schema's parameter name and type. The tool description lacks explicit documentation for the sole required 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?
The description 'Execute JavaScript only when TOR_ALLOW_JAVASCRIPT=true' uses a specific verb ('Execute') and resource ('JavaScript'), clearly distinguishing it from sibling browser automation tools like clicking, typing, or navigation. The condition is a unique qualifier that makes the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage condition ('only when TOR_ALLOW_JAVASCRIPT=true'), which is a functional guideline for when this tool should be used. It doesn't mention alternatives, but among the listed siblings there is no other JavaScript execution tool, so the condition effectively communicates the tool's niche.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds no extra behavioral context such as whether it requires an active page, what 'element counts' includes, or any limitations. With no additional context beyond annotations, the description does little to enhance transparency.
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, focused sentence. It front-loads the primary action ('Get page metadata') and lists the specific outputs with no unnecessary words. Every word earns its place.
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?
This is a parameterless read-only tool with an output schema, and the description enumerates the key metadata fields returned. There are no hidden prerequisites or side effects to disclose, making the description sufficiently complete for its simple use case.
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 and 100% coverage, so the description does not need to explain parameters. Per the rubric, a tool with 0 parameters receives a baseline score of 4.
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 identifies the tool as retrieving page metadata (URL, title, description, element counts), using a specific verb and resource. It distinguishes itself from sibling tools like tor_get_links and tor_read_page, which handle links and page content respectively.
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 when to use this tool (when you need page metadata) but does not explicitly state alternatives or exclusions. There is no mention of when not to use it or how it compares to similar tools like tor_query_elements or tor_read_page, so the guidance is only implicit.
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 adds behavioral detail beyond annotations: it captures the image, reads it, and types the answer. It also discloses a failure mode (OCR fails and returns the image), which is valuable context not captured by the annotations. The annotations already indicate destructive hint and non-read-only, so the description complements rather than contradicts them.
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 highly concise: two sentences, first states the primary action, second states the fallback. Every word is purposeful and front-loaded with the tool's main function.
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 tool has no output schema, and the description does not explain what happens on success (e.g., confirmation or resulting state). It only mentions returning the image on OCR failure. Also, the lack of parameter syntax details leaves gaps. However, given the tool's low complexity, the description is mostly adequate but not fully complete.
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?
The schema has 0% description coverage and the description does not explicitly explain the two parameters (captcha_img_selector and captcha_input_selector). While the workflow implies that one selector locates the image and the other the input, it does not clarify the selector format (e.g., CSS vs XPath) or provide examples. With no schema descriptions, the description should compensate but does not sufficiently.
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 function: 'Auto-solve a CAPTCHA using local OCR' followed by the workflow (captures, reads, types). This specific verb+resource distinguishes it from siblings like tor_get_captcha (which likely only retrieves) and tor_type (which types).
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 provides clear context for when to use the tool: when a CAPTCHA needs solving, it automates via OCR. It also gives a fallback scenario ('If OCR fails, returns the image for you to read with vision instead'), implying an alternative approach. However, it does not explicitly name alternative tools or state when not to use this tool (e.g., for complex CAPTCHAs).
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?
Annotations already declare readOnlyHint and destructiveHint false, so the safety profile is known. The description adds valuable context beyond annotations by mentioning 'bounded amount' and 'untrusted markdown', which informs the agent about the limited read scope and the need to treat content as potentially unreliable.
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 with no redundant words. It is front-loaded with the verb 'Read' and conveys all necessary information efficiently.
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 read tool with one optional parameter, readOnly annotations, and an output schema, the description is sufficiently complete. It covers the action, resource, bounded nature, and output format, while annotations handle safety and schema handles return structure.
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 has one param, max_chars, with no description (0% coverage). The description's phrase 'bounded amount' relates to the concept of max_chars but does not explicitly name or explain the parameter. Since the parameter name is self-explanatory and optional, this is adequate but does not fully compensate for the lack of schema 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 uses a specific verb 'Read' with a clear resource 'the current page' and specifies the output format as 'untrusted markdown'. This clearly distinguishes it from sibling tools like tor_get_page_info or tor_screenshot, which serve different functions.
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 the tool is for reading current page content as markdown, but it does not explicitly state when to use it versus alternatives or mention any when-not scenarios. Usage is inferred rather than explicitly guided.
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?
Annotations already establish read-only and non-destructive behavior. The description adds valuable context by explaining the temporary page mechanism and explicitly stating that the active page is unchanged, going beyond the generic annotation hints. It does not reveal potential network behavior or cleanup of the temporary page, but the added context is meaningful.
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, direct sentence with no unnecessary words. It front-loads the action ('Verify Tor') and then qualifies it with the key constraint, making it highly scannable and efficient.
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 zero-parameter, simple check tool with an output schema, the description is complete: it states the purpose, the mechanism (temporary page), and the principal side-effect (no change to active page). No critical invocation-related information is missing.
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 tool has no parameters, and the input schema is empty (100% coverage by definition). The description correctly avoids parameter details, and per the baseline for zero-parameter tools, this is a 4.
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 with a specific verb ('Verify Tor'), describes the mechanism (temporary page), and notes the key side-effect (no active page change). This distinguishes it from sibling navigation or identity tools.
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 this is a safe check that doesn't disturb the current page, but it doesn't explicitly state when to use it versus alternatives like tor_new_identity or tor_navigate. The 'without changing the active page' suggests appropriateness for checks during active workflows, but no exclusions or alternatives are mentioned.
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 annotations already declare readOnly, idempotent, and non-destructive behavior, but the description adds a critical behavioral guarantee: it never returns cookie values. This is beyond the annotations and helps the agent understand the tool won't expose sensitive data, which is valuable context for a session-management tool.
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, compact sentence with no filler words. It front-loads the core action and adds a necessary clarification, making it perfectly sized for its purpose.
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 tool with no parameters and a clear list operation, the description is entirely sufficient. The output schema is already present, so it doesn't need to explain return values, and the safety annotations cover behavioral expectations. The only addition, 'never cookie values,' strengthens completeness.
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?
With zero parameters, the schema fully describes the invocation contract (empty object), and the rule for 0 parameters sets a baseline of 4. The description doesn't elaborate on parameters, but none exist, so this is appropriate.
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 uses a specific verb 'List' and a distinct resource 'saved session metadata,' clarifying that it enumerates sessions rather than loading, saving, or deleting them. The parenthetical 'never cookie values' further distinguishes its scope, making the purpose unambiguous even among many sibling tools.
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 that this tool is used to view existing saved sessions, but it does not explicitly state when to choose it over alternatives like tor_load_session or tor_delete_session. There is no scenario guidance or exclusionary language, so it only partially helps the agent decide when to invoke it.
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?
Annotations already declare destructiveHint=true and openWorldHint=true. The description adds specific behavioral context by naming the two concrete effects (new circuit and cookie clearing), which goes beyond the annotations and clarifies what is destroyed.
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 compact, front-loaded, and free of unnecessary words. It precisely communicates the tool's behavior.
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?
With zero parameters and an output schema present, the description fully captures the tool's purpose and key effects. No further details are needed for an agent to select and invoke this tool 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 input schema is empty with no parameters, so there is nothing to document. Baseline for 0 parameters is 4; the description adds no parameter info because none 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 'Request a new Tor circuit and clear browser cookies' clearly states a specific action with a specific resource (Tor circuit and cookies). It distinguishes itself from sibling tools like navigation, clicking, and extraction by focusing on identity reset.
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 when to use the tool (when a new Tor circuit or cookie clearing is needed) but does not explicitly state usage context or alternatives. Since there are no directly similar sibling tools, this is acceptable 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:

[![opentor-mcp MCP server](https://glama.ai/mcp/servers/Medamine-cheddadi/opentor-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Medamine-cheddadi/opentor-mcp)

Score Badge

Copy to your README.md:

[![opentor-mcp MCP server](https://glama.ai/mcp/servers/Medamine-cheddadi/opentor-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Medamine-cheddadi/opentor-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/Medamine-cheddadi/opentor-mcp'

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