Skip to main content
Glama
Sign In

HypePaper

by app.hypepaper
OverviewDiscussionsAdmin

expert_ask

Ask any topic's expert a question (a topic without its own expert is answered from its nearest ancestor's, else from its own papers). The answer is written from the expert's knowledge graph, paper views, SOTA lanes, benchmark rows and notes; each sentence ends with [Cn] markers that citations resolves (hp:// pointer, kind, title, the quoted passage, the paper's URL), and it says what the evidence does not establish instead of guessing. [Free · 5 credits + AI credits]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "topic_id": "<topic_id>",
      "question": "<question>"
    },
    "name": "expert_ask"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionYes
topic_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden and does substantial work: it discloses the evidence sources used to compose the answer, the per-sentence [Cn] citation marker convention, the downstream tool that resolves those markers, the explicit refusal to guess, and the cost model (5 credits + AI credits). It omits error behavior, latency, and an explicit statement that the call is read-only, keeping it just short of a 5.

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?

Purpose is front-loaded in the first clause, with resolution rules and output contract following in priority order. The parenthetical citation-format passage is dense but earns its place by pre-empting the most likely follow-up question. No filler sentences.

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?

With no output schema, the description responsibly explains the return shape (sentences ending in [Cn] markers resolved via `citations`, plus explicit non-establishment statements) and the billing model. The remaining gap is input-side: nothing tells the agent how to phrase or bound the question beyond the schema's hard limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 0%, so both parameters rely on the description, which does explain topic resolution semantics (a topic without its own expert inherits the nearest ancestor's) — meaningful added context for topic_id. The question parameter is not elaborated at all (no note about the 500-character cap or what makes a good question), so the compensation is partial.

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 a specific verb and resource ('Ask any topic's expert a question') and immediately bounds the scope with the expert-resolution rules (own expert, else nearest ancestor's, else the topic's own papers). An agent knows exactly what it gets back: a cited answer synthesized from the knowledge graph, paper views, SOTA lanes, benchmark rows and notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the fallback condition that decides which expert answers, which is genuinely useful context for choosing this tool. However, it never states when to prefer this over sibling capabilities such as fact search or claim verification, nor when not to ask (e.g. factual lookups better served by a search tool). Usage is implied rather than directed.

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

All HypePaper 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