Skip to main content
Glama

Run an autonomous research agent

deep_research

Start an autonomous web research task. The agent plans sub-questions, searches the web, reads the sources and writes a report with citations — this is real research, not a single model call, and takes 2-5 minutes. Returns a job_id immediately; poll check_job to get the report. Use this when you need sourced, current information rather than what a model already knows. Powered by gpt-researcher (29k stars) hosted at AI NetCafé. Example — tools/call deep_research {"topic":"State of MCP adoption in 2026?"} → poll check_job

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNoquick = outline only (~1 min); standard = full cited report (~3 min). Default standard.
topicYesThe research question. Phrase it as a question, not a keyword.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes
statusYes
poll_interval_secondsNo

TDQS

A4.6/5.0
Behavior4/5

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

The description discloses key behavioral traits beyond the annotations (which are all false): it is asynchronous ('Returns a job_id immediately'), takes 2-5 minutes, and is a multi-step process (plans, searches, reads, writes). It also mentions the underlying system (gpt-researcher, AI NetCafé). It does not mention potential failures or rate limits, but for this tool the disclosed context is substantial.

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 packed with useful information and is front-loaded with purpose. Each sentence serves a function: behavior, workflow, usage guidance, and example. The mention of '29k stars' is mildly extraneous for an AI agent, but it does not detract significantly; it could be trimmed without losing critical guidance.

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 asynchronous nature, 2 parameters, an output schema, and sibling check_job, the description covers the full workflow: what it does, how long it takes, what it returns immediately, how to follow up, and when to use it. The example ties everything together, making it complete 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds extra value by instructing to phrase the topic as a question rather than a keyword, and by providing a concrete example. The depth parameter is well-explained in the schema and the description's example reinforces the default.

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 starts with a strong verb+resource: 'Start an autonomous web research task.' It clearly distinguishes this from sibling tools like check_job by explaining it initiates a research process and returns a job_id immediately. The phrase 'real research, not a single model call' further clarifies its unique scope.

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?

Explicit guidance is given: 'Use this when you need sourced, current information rather than what a model already knows.' It also tells the agent to poll check_job for the result, naming the specific alternative/follow-up tool. This gives clear when-to-use and what-to-do-next context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0
Disambiguation5/5

Each tool targets a unique operation—conversions, extractions, translations, and utilities like resume checking or redaction—with no meaningful overlap. The few similar tools (e.g., convert_to_pdf vs. xlsx_to_pdf) are clearly distinguished by input type.

Naming Consistency3/5

Naming mixes conventions: verb_noun (extract_tables, redact_text), noun_to_noun (xlsx_to_pdf, pptx_to_pdf), and unusual forms like doc_translate_cn and what_can_you_do. While snake_case is consistent, the verb/noun pattern is not, making the set slightly less predictable.

Tool Count3/5

With 23 tools, the server sits at the heavy end of the acceptable range. Every tool has a distinct purpose, but the spread across PDF handling, research, audio, and accounting utilities feels more like a miscellaneous collection than a focused suite, which could overwhelm agents.

Completeness4/5

The server covers a broad spectrum of document-processing tasks—conversion, extraction, translation, redaction, and validation—with few dead ends. Minor gaps exist (e.g., no PDF merge/split, no OCR for all scanned PDFs, no explicit delete/update for resources), but core workflows are well supported.