Sofya
Server Details
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.8/5 across 4 of 4 tools scored.
Each tool serves a clearly distinct purpose: search for web queries, fetch for raw page content, extract for structured data extraction, and research for comprehensive synthesis. Descriptions are detailed enough to prevent confusion.
All tool names are single lowercase verbs (extract, fetch, research, search), following a consistent and predictable pattern. No mixing of styles or non-standard conventions.
With 4 tools, the set covers the core needs of web information retrieval and research without being bloated. Each tool earns its place, and the count is ideal for the domain.
The tool surface provides a complete workflow: search to find sources, fetch to retrieve full content, extract to pull specific data, and research to synthesize multiple sources. No obvious gaps for typical agent tasks.
Available Tools
4 toolsextractAInspect
Fetch a webpage and extract specific information using AI. Use this when you need structured data from a page (e.g. pricing, specs, contact info) rather than the raw content. Costs 5 credits.
If the page has no usable text (empty or JavaScript-rendered body), the model is NOT called: content comes back empty and usage.low_content is true, rather than a fabricated answer. Gate on usage.low_content (or usage.content_chars) to detect pages you cannot ground on.
Returns: content (the extracted text), url, credits_used, credits_remaining, usage (input_tokens, output_tokens, content_chars, low_content).
Args: url: The URL to extract from prompt: What information to extract (e.g. "list all pricing tiers with features" or "extract the author name and publication date")
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| prompt | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It details behavior on empty/JavaScript-rendered pages (no fabricated answer, low_content flag), cost (5 credits), and return fields including usage metrics. This provides comprehensive behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, usage, edge case, returns, args). It is slightly verbose but every sentence adds value. Could be trimmed slightly, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all return fields (content, url, credits_used, etc.) and explains usage, edge cases, and parameters. It fully prepares the agent for correct invocation and interpretation of results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains both parameters thoroughly: 'url' as the page to extract from, and 'prompt' with examples (e.g., 'list all pricing tiers with features'). This adds significant meaning beyond the schema's minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a webpage and extract specific information using AI' and provides examples like pricing, specs, contact info. It effectively distinguishes from siblings 'fetch', 'research', and 'search' by specifying structured data extraction rather than raw content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool when structured data is needed, implying alternatives like 'fetch' for raw content. It mentions cost and edge case behavior but lacks explicit 'when not to use' guidance, though the examples serve that purpose well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchAInspect
Fetch one or more URLs and return their content as clean markdown. Use this to read articles, documentation, blog posts, or any page where you need the complete text, not just a snippet from search. Also supports PDF, DOCX, and other document formats. Costs 1 credit per URL. Max 10 URLs per request. Failed URLs are not charged.
Set include_raw_html=true to also get the raw HTML source in each result. Useful for inspecting embedded URLs, data attributes, iframes, or script tags that are stripped during markdown conversion. Returns null for non-HTML content (PDF, DOCX, etc.). Same cost.
Returns: results (array of {title, url, content, raw_html, published_time, success, error}), credits_used, credits_remaining.
Args: urls: List of URLs to fetch (max 10) include_raw_html: Include raw HTML source in each result (default false)
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| include_raw_html | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses cost (1 credit per URL), maximum URLs (10), that failed URLs are not charged, the optional raw HTML inclusion, its behavior on non-HTML content, and the exact return structure. This is comprehensive for a fetch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate paragraphs for when to use, optional behavior, and output. Every sentence adds value, though it could be slightly more concise (e.g., merging some sentences). It front-loads the core purpose and then provides details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a detailed return structure including fields (title, url, content, raw_html, etc.) and metadata (credits_used, credits_remaining). It covers input validation, cost, error handling, and optional behavior. For a simple tool with two parameters, this is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the description thoroughly explains both parameters: 'urls' (list, max 10) and 'include_raw_html' (optional, default false, and its effect). It adds meaning beyond the schema's type and title fields, making the parameters fully understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches URLs and returns clean markdown content. It distinguishes from sibling tools like 'search' by emphasizing it provides complete text rather than snippets, and mentions support for PDF/DOCX. The verb 'fetch' and resource 'URLs' are specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool (reading articles, documentation, etc.) and implicitly contrasts with search. It also provides practical details like max URLs, cost, and error handling that help the agent decide. However, it does not explicitly mention when not to use it or name alternatives like 'extract' or 'research' for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
researchAInspect
Perform comprehensive research on a topic. Decomposes your query into sub-queries, searches and reads multiple sources in parallel, then synthesizes a structured report with citations. Best for open-ended or comparative questions that need coverage from many angles. For simple factual lookups, use search instead (optionally with include_answer=true for cheap synthesis). Costs 25 credits.
Returns: query, report (structured markdown with citations), sources (array of {title, url, fetched}), sub_queries (the decomposed queries), credits_used, credits_remaining, usage (token counts).
Args: query: The research question or topic topic: "general" (default) or "news" (prioritize recent news articles) freshness: Filter by recency - "day", "week", "month", "year", or "YYYY-MM-DD:YYYY-MM-DD" max_sources: Maximum number of sources to use, 5-30 (default 20)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| topic | No | general | |
| freshness | No | ||
| max_sources | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the inner workings (decompose, parallel search, synthesis with citations) and return types. Without annotations, it covers key behavioral aspects. Lacks mention of error handling or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose, when to use, returns, args. Slightly verbose but efficient; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: purpose, usage, parameters, and return format (including fields like sources, sub_queries). No output schema, so description compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the input schema: clarifies query as 'research question or topic', explains topic options (general/news), freshness as recency filter, and max_sources range (5-30). Schema has 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform comprehensive research on a topic' and explains the process of decomposing queries, searching multiple sources, and synthesizing a report. It distinguishes from sibling tools by explicitly contrasting with 'search' for simple lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Best for open-ended or comparative questions' and directs to 'use search instead' for factual lookups. Also mentions cost (25 credits) as a consideration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspect
Search the web for current information on any topic. Returns extracted page content, not just snippets. Best for factual lookups, specific questions, or when you need a list of sources. For open-ended questions that need synthesis across many sources, use the research tool instead.
For news queries (current events, breaking news, politics, world events), set topic="news" to search news sources specifically. This returns recent articles with publication dates.
Set include_answer=true to get an AI-synthesized answer alongside results (adds 5 credits). This is the sweet spot for most agent tasks, e.g. basic + include_answer = 8 credits, much cheaper than a full 25-credit research call.
Returns: query, answer (if requested), results (array of {title, url, content, description, fetched, published_date}), search_depth, topic, elapsed_ms, credits_used, credits_remaining, altered_query.
Args: query: The search query search_depth: "basic" (default) for extracted page content (3 credits), "snippets" for SERP snippets only without page fetching (1 credit) max_results: Number of results (default 10, max 20) include_answer: Generate an AI answer that synthesizes the search results (adds 5 credits) include_domains: Only include results from these domains (max 10) exclude_domains: Exclude results from these domains (max 10) topic: "general" for web search, "news" for news articles. use "news" for current events, breaking news, politics, or any time-sensitive query freshness: Filter by recency - "day", "week", "month", "year", or "YYYY-MM-DD:YYYY-MM-DD"
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| topic | No | general | |
| freshness | No | ||
| max_results | No | ||
| search_depth | No | basic | |
| include_answer | No | ||
| exclude_domains | No | ||
| include_domains | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that search returns extracted page content (not just snippets), explains credit costs for different search depths and include_answer, and lists all returned fields. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear two-sentence introduction followed by detailed parameter explanations. However, it is lengthy due to the number of parameters and examples. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 params, no output schema, no annotations), the description fully covers purpose, usage guidelines, parameter details, return fields, and credit costs. An agent can correctly invoke this tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains every parameter in detail: query, search_depth, max_results, include_answer, include_domains, exclude_domains, topic, freshness. This adds significant meaning beyond the schema's title and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search the web for current information on any topic.' It uses a specific verb (search) and resource (web), and differentiates from sibling tools like 'research' for synthesis, and implicitly from 'extract' and 'fetch'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Best for factual lookups, specific questions, or when you need a list of sources.' Also provides when-not: 'For open-ended questions that need synthesis across many sources, use the research tool instead.' Includes guidance for news queries with topic='news'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!