Skip to main content
Glama

Scholar Feed

by io.github.YGao2005

Embed Text

embed_text
Read-only

Embed a text string into a 768-dim Gemini Flash vector. Use for HyDE-style retrieval: (1) write a hypothetical short paper that would perfectly answer the user's query, (2) embed it with task_type='RETRIEVAL_DOCUMENT' (default — matches the corpus embedding side), (3) pass the resulting embedding back through search-style tools to find real papers nearest to the hypothetical. task_type='RETRIEVAL_QUERY' matches the query side and is useful for direct user-query embedding without HyDE. Pro-only — requires an SF_API_KEY on a Pro account; anonymous and free callers get a 403 pro_required. Cost: ~$0.0001/call; rate-limited at 30/minute per API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesText to embed (1-8000 chars). For HyDE flows this is your hypothetical answer/abstract.
task_typeNoRETRIEVAL_DOCUMENT (default) matches paper-side embeddings — use for HyDE. RETRIEVAL_QUERY matches query-side semantic search.RETRIEVAL_DOCUMENT

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dimsNo
modelNo
embeddingNoThe embedding vector (768-dim Gemini Flash).
task_typeNo
dimensionsNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the operation read-only, and the description adds materially beyond that: Pro-account API-key requirement, 403 pro_required for anonymous/free callers, approximate cost per call, and 30/minute rate limit. It also clarifies that task_type changes which side (corpus/query) the embedding aligns with.

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 front-loaded with the core purpose and follows with a numbered workflow, task-type guidance, and operational constraints. Every sentence carries distinct information about how, when, or under what conditions to call the tool.

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?

The output schema exists, so the return embedding format need not be restated. The description covers the workflow, parameter semantics, auth prerequisites, failure mode, cost, and rate limit, leaving no practical gap 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?

Schema coverage is 100%, so the baseline is 3; the description then adds value by tying text to the hypothetical-answer step and task_type to embedding side. The schema already documents defaults and enum semantics, so the description's incremental parameter meaning is clear but not exhaustive.

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 names the exact operation — 'Embed a text string into a 768-dim Gemini Flash vector' — with a specific verb, resource, and dimensional output. It also frames the embedding in the context of HyDE-style retrieval, distinguishing it from sibling tools that operate on papers/collections rather than producing embeddings.

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?

It gives a concrete three-step HyDE recipe, explains when to use RETRIEVAL_DOCUMENT vs RETRIEVAL_QUERY, and explicitly routes the output to 'search-style tools.' It also states the Pro-only constraint and 403 failure mode, so an agent can select the tool only when credentials qualify.

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

All Scholar Feed toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools target a distinct resource and action — search vs. saved-library synthesis vs. citation analysis vs. article metadata — and the descriptions explicitly cross-reference one another to reduce confusion. A few retrieval/analysis tools (get_field_orientation, get_foundational_lineage, get_citations, check_drift) have adjacent purposes and could be misselected without reading their descriptions carefully.

Naming Consistency4/5

The overwhelming majority follow a clear verb_noun snake_case pattern: create_watch, delete_watch, list_library, save_paper, annotate_paper, fetch_fulltext, search_papers. Minor deviations like co_author_graph and the interchangeable retrieval verbs (search, find, get, check, ask) create slight inconsistency, but the overall convention is predictable.

Tool Count3/5

27 tools is on the heavy side, but the server covers several coherent subdomains: search/discovery, library/collection management, watches, annotations, and research analysis. The count is justifiable for the broad purpose, though some of the discovery/analysis tools could likely be consolidated or split into a separate server.

Completeness4/5

The tool surface covers the core lifecycle well: search, fetch, save, organize into collections, annotate, watch for new papers, and analyze citations/authors/gaps. Minor gaps exist — there is no collection deletion/rename, no explicit mark-as-read tool, and no unlike operation — but these are workable edge cases rather than blocking omissions.

Resources