Skip to main content
Glama
Sign In

Elements Live

by com.elements-live
OverviewDiscussionsAdmin

Top papers for an element

get_element_papers
Read-onlyIdempotent

The top papers for one element, narrowed with keyword to one of its materials or applications (e.g. symbol='Al', keyword='aluminum nitride'; the keyword must name one of the element's topics exactly, case aside -- search_subjects finds topic names). Returns title, DOI, venue, year, citations. sort=impact (default) favours recent, well-cited work; sort=foundational gives the most-cited classics; sort=newest the latest. Each paper carries its abstract where one is on file (about 6 in 10). Requires a Personal+ account. Capped at 100 papers with no pagination. Without a key, pay per call: $0.02 for up to 20 papers, $0.10 for up to 100, in USDC on Base or Solana via x402 (send the payment in _meta["x402/payment"]).

Input Schema

NameRequiredDescriptionDefault
sortNoimpact = citation-impact ranking (default); newest = most recently published first; foundational = most-cited first (the classics a reading list starts from).impact
limitNo
symbolYesElement symbol, e.g. 'Fe' (a name like 'Iron' or an atomic number like '26' also works)
keywordNoOptional: narrow to one application keyword.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / symbol / description
      Previous value: -"Element symbol, e.g. 'Fe'"New value: +"Element symbol, e.g. 'Fe' (a name like 'Iron' or an atomic number like '26' also works)"
  2. Changed2 schema fields changed
    • changedInput schema / properties / sort / description
      Previous value: -"impact = citation-impact ranking (default); newest = most recently published first."New value: +"impact = citation-impact ranking (default); newest = most recently published first; foundational = most-cited first (the classics a reading list starts from)."
    • changedInput schema / properties / sort / enum
      Previous value: -[
-  "impact",
-  "newest"
-]New value: +[
+  "impact",
+  "newest",
+  "foundational"
+]
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses substantial operational facts: Personal+ account requirement, a hard 100-paper cap with no pagination, abstract coverage of roughly 60%, and full pay-per-call pricing tiers with the x402 payment field. This is exactly the kind of context annotations cannot carry.

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?

Front-loaded with the core purpose and example, then ranking behavior, then access/pricing constraints — a sensible ordering with little waste. The x402 payment sentence is long but carries information an agent cannot get elsewhere.

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 no output schema, the description compensates by naming the returned fields (title, DOI, venue, year, citations) and abstract availability, and it covers auth, caps, and payment. An agent has everything needed to call it and understand the response shape.

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 75%, and the description adds the critical non-obvious constraint that keyword must name one of the element's topics exactly (case aside) plus the 100-item ceiling on limit. The sort explanation partly duplicates the enum's own schema description, keeping it from a 5.

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?

States a specific verb+resource: 'The top papers for one element,' with the keyword narrowing scope spelled out and a concrete example (symbol='Al', keyword='aluminum nitride'). It does not explicitly distinguish itself from the close sibling get_subject_papers, so an agent must infer the element-vs-subject split.

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?

Gives clear usage context: keyword is optional and must exactly match one of the element's topic names, and it names search_subjects as the way to discover those names. It also explains which sort mode to pick (impact default, foundational for classics, newest for recency). No explicit when-not or contrast with get_subject_papers/get_element_ri.

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

All Elements Live toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources