rsi-search-pro-mcp

Official

by rsi-ai-platform

Overview Schema Related Servers Score Discussions

Python

Hybrid

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 some overlap exists between 'extract' and 'web_fetch_structured' (both do structured extraction) and between 'web_fetch' and 'web_fetch_structured'. Descriptions help disambiguate, but the similar names and functions could cause confusion.
Naming Consistency3/5
Tool names mix conventions: some are simple verbs ('act', 'extract'), some use noun_verb ('pdf_discover', 'web_fetch'), and others are verbose ('web_compare_across_sources', 'pick_authority_domains'). The pattern is not uniform, but names are still readable.
Tool Count5/5
With 15 tools, the set is well-scoped for a search and extraction server. Each tool serves a distinct need, and the count is neither too small nor too large for the domain.
Completeness4/5
The tool set covers major workflows: browsing, fetching, structured extraction, search, PDF handling, and cross-source comparison. Minor gaps exist, such as lack of support for other document formats or authentication, but core requirements are met.
Average 4.5/5 across 15 of 15 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 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 Apache 2.0.
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?
No annotations are provided, so the description carries the full burden. However, it only mentions 'Plain Tavily search' without disclosing any behavioral traits such as rate limits, response format, or side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences, front-loaded with the tool's purpose and usage guidance. Every sentence adds value.
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 7 parameters and no output schema, the description is incomplete. It does not explain what the search returns, how to use parameters, or any other contextual details necessary for correct invocation.
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 does not explain any of the 7 parameters. With 0% schema description coverage, the description adds zero semantic value beyond the schema itself.
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 'Plain Tavily search' and characterizes it as an 'escape hatch for free-form exploration', which distinguishes it from the authoritative sibling tool. The verb 'search' and resource 'web' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when not to use this tool: 'Prefer web_search_authoritative when the query has an authoritative answer.' This provides clear context and an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the processing pipeline (download, pypdf extraction, LLM pass) and the return shape. This provides good transparency for an agent, though it does not cover potential failure modes or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences plus a pipeline line. It is front-loaded with the core processing steps. Some structure could be improved, but it is effective and not verbose.
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 complexity (4 parameters, no output schema), the description is incomplete. It does not describe the parameters' roles, error handling, or return behavior in detail. The agent would lack critical information to use the tool correctly.
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%, meaning the description must compensate. However, the description does not explain any of the four parameters (url, focus, pages, max_pages) beyond the schema field names. This is a significant gap.
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: downloading a PDF, extracting with pypdf, passing through an LLM, and returning structured JSON. It also explicitly names the output fields and compares to web_fetch_structured, distinguishing it from siblings.
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 a clear when-to-use: 'Use when you have a PDF URL and want the values extracted into a structured shape rather than just raw text.' It does not explicitly say when not to use or list alternatives, but the comparison to web_fetch_structured provides implicit guidance.
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?
With no annotations, the description carries full burden. It mentions 'clean text' and PDF limitation but lacks details on error handling, rate limits, or auth needs. Adequate for a simple 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?
Three sentences, front-loaded with purpose, efficient and free of waste.
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 one-parameter tool with no output schema, the description covers purpose, usage guidelines, and a key limitation (PDFs). Sufficient for selection and invocation.
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 adds no extra meaning for the single 'url' parameter beyond its name and type. Should provide format or examples.
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 'returns clean text from a URL' with a specific verb and resource, and distinguishes from siblings web_fetch_structured and pdf_fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use web_fetch_structured for structured data and pdf_fetch for PDFs, providing clear context for alternatives.
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?
With no annotations, the description should fully disclose behavior. It explains the workflow (sitemap then search fallback) and return format, but omits potential issues like timeouts, rate limits, or prerequisites (e.g., domain must be valid). This is adequate but not comprehensive.
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 very concise: one sentence for core purpose, followed by bulleted Args and Returns. No filler, and the most important information is front-loaded.
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 no output schema, the Returns section compensates by showing the structure. The description covers purpose, parameters, and method. It could be more explicit about scoring criteria or edge cases, but overall it is sufficient for correct invocation.
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 lacks descriptions (0% coverage). The description adds concrete examples (domain: 'rbi.org.in', topic: 'press releases') and clarifies max_candidates range (1-20). This adds meaningful guidance beyond the bare schema, though more detailed constraints would be helpful.
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 states a specific action ('Locate the canonical landing page') with a clear method (via sitemap.xml, fallback to Tavily search). It distinguishes this tool from sibling tools like web_search and web_fetch by focusing on sitemap-based discovery and fallback behavior.
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 ('on an authority domain') and explains the fallback mechanism, helping the agent decide when to use it. However, it does not explicitly state when not to use this tool or compare it to alternatives like web_search_authoritative, which limits guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses LLM mediation, no hallucination of values, API key requirement, and return structure. Lacks error handling details.
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?
Well-structured with sections for Args and Returns. Front-loaded with main idea. Slightly verbose but informative.
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?
Covers purpose, usage context, parameter semantics, API key requirement, and return structure. Adequate given no output schema and minimal annotations.
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?
Args section explains both parameters; focus parameter includes an example. Schema has 0% coverage, so description adds significant 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?
Description clearly states it fetches a URL and extracts structured data via LLM, with specific use cases (numbers from long documents) that distinguish it from plain web_fetch.
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?
Explicitly says when to use over plain fetch (specific numbers from long documents) and mentions requirement for ANTHROPIC_API_KEY. Could be improved by stating when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key behavior: sending rendered text and screenshot to Sonnet, and default full_page_screenshot=True to capture charts below fold. However, it does not mention other behavioral aspects like error handling, rate limits, or destructive effects, though the tool appears read-only.
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 concise: a three-sentence introduction followed by bulleted Args and Returns sections. Every sentence provides value, front-loading the purpose and unique selling point. No filler or wasted words.
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 no output schema, the detailed Returns section adequately explains the return shape. All parameters are described. The description covers the key behavioral aspect (screenshot for canvas) and references sibling tools for structure consistency. It could be improved by mentioning potential failure modes or timeouts, but overall is sufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining all four parameters: url, focus (with example), wait_for_selector (with reference to visit), and full_page_screenshot (explaining default True for below-fold content). This adds significant meaning beyond the schema's bare names.
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: 'Visit a URL → focused Sonnet structured extraction.' It explains it sends both rendered text and screenshot to Sonnet, enabling extraction of canvas/SVG content not in DOM. It distinguishes itself from siblings like web_fetch_structured by highlighting this unique capability, and notes the returned shape is the same as pdf_fetch_structured/web_fetch_structured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by explaining the screenshot feature for canvas/SVG numbers, but does not explicitly state when to use this tool versus alternatives like web_fetch_structured. It provides clear context for when the tool is beneficial but lacks explicit exclusion conditions or alternative tool names.
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?
No annotations, so description carries full burden. Explains that it's an escape hatch for client-side AJAX calls, mentions referer requirement, and describes parse behavior. Could add details on rate limits or auth, but covers key operational traits.
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?
Well-structured with summary, context, example, and args/returns sections. Front-loaded with core functionality. Slightly verbose but every sentence contributes; minor redundancy in the example could be trimmed.
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?
No output schema, so description includes return format. Covers all key aspects: URL, form, referer, parse. Differentiates from siblings and provides a realistic example. Lacks error handling details, but sufficient for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description thoroughly explains each parameter (url, form, referer, parse) with example values and purpose. Clarifies that referer is often required and parse has three modes. Adds significant value beyond schema types.
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?
Explicitly states it POSTs a form with content type application/x-www-form-urlencoded and returns JSON. Distinguishes from sibling tools pdf_discover and web_fetch by targeting AJAX POSTs that don't change the page URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this when a landing page's dropdown isn't a <select> whose value becomes a query param.' Names sibling tools that cannot handle such cases, and includes a concrete example with a government site.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a UTC date and lists the returned fields (iso_date, iso_datetime, year, etc.). It does not mention any side effects, but given the read-only nature, this is sufficient. The behavioral context is well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose in the first sentence and no unnecessary words. It includes a bulleted list of return fields, which is efficient. Slightly front-loaded with important usage advice. Could be marginally tighter, but still effective.
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?
Given the tool's simplicity (no parameters, no output schema), the description fully covers what the tool does, when to use it, and what it returns. It addresses potential confusion about temporal anchoring. The sibling tools are diverse, so no risk of overlap.
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 input schema is empty. Per guidelines, baseline is 4. The description adds value beyond the schema by explaining the return format and usage context, making it informative.
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 returns the server's current date in UTC, using a specific verb ('Return') and resource ('SERVER'S CURRENT DATE'). It distinguishes from sibling tools which are focused on fetching, searching, or acting, making the tool's unique role obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool first when the user mentions temporal phrases like 'today' or 'this quarter', and warns that the training data cutoff is unreliable. This provides clear when-to-use guidance and distinguishes it from alternatives.
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?
Discloses that the tool returns PDF URLs and anchor text, notes client-side filters, and explains the return structure. No annotations provided, so description handles burden. Lacks mention of error cases or rate limits, but adequate.
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?
Well-structured with sections for description, workflow, args, and returns. Each sentence is informative; no wasted words.
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 no output schema, the description provides a clear return structure and workflow context. Moderate complexity tool; description is complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description explains each parameter in detail with examples (e.g., link_text_filter with '2026-27', max_links default 40), adding significant meaning beyond 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?
Clearly states 'list every PDF link on an HTML landing page, with its anchor text' and provides specific examples of hub pages, distinguishing it from siblings like pdf_fetch_structured.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this on HUB pages' with concrete examples and outlines a workflow (pdf_discover → pick by anchor text → pdf_fetch_structured), guiding when to use and what to do next.
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?
No annotations provided, so description carries full burden. It transparently describes extraction with pypdf, parameter effects, and return structure. Could mention potential size/rate limits, but overall it's well-covered for a read-only tool.
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?
Well-structured with a clear 'when to use' section followed by Args. Every sentence adds value. Slightly verbose but not excessive; could be tightened slightly but still highly effective.
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?
Given 3 parameters, no output schema, no annotations, the description fully explains usage, parameter details, return format, and use cases. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds full meaning: url as PDF URL, pages as 1-indexed list, max_pages as auto-extraction cap. Explains defaults and behavior when pages is omitted. This compensates completely for the schema gap.
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?
Clearly states it downloads a PDF and extracts text with pypdf. Distinguishes from siblings like web_fetch by specifying when to use it (when binary/not extractable) and lists common use cases (PPAC reports, RBI bulletins, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this WHENEVER a web_fetch or web_fetch_structured call comes back saying the content was binary or not extractable', providing clear context and alternatives. The description of common cases further guides correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains that the tool returns a ranked list with primary/secondary domains, hints (which must be followed), and landing pages (to be fetched directly). This is thorough and goes beyond basic expectations.
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 somewhat long but well-structured with a clear header, usage instruction, parameter list, and return value description. Every sentence adds value, though it could be slightly more concise without losing key information.
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?
Despite no output schema, the description provides a full breakdown of the return type: primary, secondary, sources, hints, landing pages, rationale, etc. The hints and landing pages instructions are particularly valuable. The description is complete for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description includes a detailed Args section explaining each parameter: query (free text), indicators (optional hints), jurisdiction (ISO code), topic_hint (enum values), additional_authority_sources (pre-resolved sources). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Decide which AUTHORITY domains a query should be restricted to.' It specifies that it is for authoritative queries and lists examples (regulators, statistical agencies). This distinguishes it from sibling tools like web_search and web_search_authoritative.
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 explicitly says 'Call this BEFORE any web search when the query has an authoritative answer' and provides examples of when to use. It does not explicitly state when not to use, but the context is clear. Alternative tools are not named directly, but the purpose implies this is a pre-filter step.
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?
No annotations provided, but description discloses use of real Chromium, screenshot size (~700KB-1MB), internal use by extract/act, text cap, and warnings about context window. Lacks mention of rate limits or redirect handling, but still very transparent.
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?
Well-structured with sections and bullet-like parameter explanations. Each sentence adds value, though slightly long due to necessary detail for 8 parameters.
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?
Covers all aspects: purpose, usage guidelines, parameter details, return values, and behavioral warnings. No output schema, so description fully explains output. Complete for a complex tool with 8 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates by explaining each of the 8 parameters with usage details, including default values, when to adjust, and impact (e.g., screenshot adds ~200ms, return_screenshot_b64 blows context).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly it opens a URL with Chromium and returns rendered state. Distinguishes from cheaper fetch tools by listing SPA, JS-rendered chart, login-walled, dropdown scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use (when cheaper fetch tools fail) and provides reasons (SPA, JS-rendered, login-walled). Mentions alternative tools by name (web_fetch, pdf_fetch, http_post_form).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the three-pass behavior, the fallback mechanism, and the return fields (pass, domains_used, authority_score, rationale). It also notes that if allow_open_web_fallback is False, the tool refuses pass 3. This covers all behavioral aspects beyond the schema.
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 well-structured with a summary, pass details, usage guidance, and parameter explanations. While comprehensive, it is slightly lengthy but every sentence serves a purpose. A minor reduction could improve conciseness.
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?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is remarkably complete. It explains the three-pass logic, the return shape, and all parameters, including references to sibling tools. The description leaves minimal ambiguity for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must compensate, and it does so thoroughly with an Args section explaining each parameter's purpose and behavior. For example, it clarifies that include_domains skips pick_authority_domains and that days is only relevant for news topic. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a three-pass authoritative web search, detailing each pass and explicitly distinguishing it from plain web search by stating 'Prefer this over plain web search when the query has an authoritative answer'. This specific verb+resource combination differentiates it from 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('when the query has an authoritative answer') and what it automates (include-domains discipline and fallback ladder). It does not explicitly mention when not to use it, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits. It details the sequence of steps, various action types (click, fill, select, etc.), timing, screenshots, and the return shape including step_results and final_url. No negative traits are concealed.
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 well-structured and front-loaded with a clear summary, but it is quite lengthy. However, every sentence adds value, and the example aids understanding.
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?
Given the complexity of 5 parameters and no output schema, the description is complete. It covers all input parameters, step types, and output fields, and provides a concrete example. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining each parameter: url, steps (with full vocabulary and examples), focus, timeout_ms, and full_page_screenshot. It also describes the return value structure, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drives a Chromium through steps and then extracts data using Sonnet. It distinguishes itself from sibling tools 'visit' and 'extract' by noting that they only read the page as loaded, while 'act' performs interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies when to use the tool: 'when the data is BEHIND an interaction' such as dropdowns, tabs, buttons, or forms. It also contrasts with alternatives, stating that 'visit' and 'extract' only read the page as it loaded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: it issues the same query across multiple domains, returns per-domain results and agreement matrix. No hidden side effects or unexpected actions.
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?
Concise and well-structured: one-sentence summary, usage guideline, annotated args, and return structure. No extraneous text.
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?
Despite no output schema, the description includes a return structure. Parameter coverage is complete. Usage context is provided. No gaps given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, yet description adds detailed semantics for all 3 parameters: claim_or_query explained as the claim to test, domains explained as authority domains with sweet spot, max_results_per_domain range noted. This fully compensates for 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?
Description clearly states the action: issuing the same query across multiple authority domains and returning per-domain top hits and an agreement matrix. It distinguishes from sibling tools like web_search by focusing on cross-validation across multiple domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to cross-validate a load-bearing number, and why: avoids writing N separate web_search calls. Provides domain count sweet spot (2-6) and parameter ranges.
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:

[![rsi-search-pro-mcp MCP server](https://glama.ai/mcp/servers/rsi-ai-platform/rsi-search-pro-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rsi-ai-platform/rsi-search-pro-mcp)

Score Badge

Copy to your README.md:

[![rsi-search-pro-mcp MCP server](https://glama.ai/mcp/servers/rsi-ai-platform/rsi-search-pro-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rsi-ai-platform/rsi-search-pro-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/rsi-ai-platform/rsi-search-pro-mcp'

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