Loading ToolBench
MCP server for Nuclide, the public cited knowledge graph of radiopharmaceuticals: search, get_entity, list_kind, ask (grounded cited answers), context (Markdown), compare, biomarker matching, regimens, calendar, toxicity comparison, graph paths, and live trial lookup.
Nuclide MCP demonstrates solid tool design with comprehensive descriptions (avg 180 chars), well-structured schemas, and clear enum constraints. All 8 tools have descriptions and input schemas with proper types. Tool names follow verb_noun convention (search, get_entity, list_kind, ask, context, compare). However, output schemas are not explicitly documented in the visible code, and error handling guidance is minimal. The server targets a specialized domain (radiopharmaceuticals) with domain-specific enums and constraints that are well-articulated. Composition is clean, each tool has a single responsibility. Parameter descriptions are generally strong, though some lack explicit format/range guidance.
Answer a radiopharmaceutical question with sentences taken from Nuclide records only, each with a numbered citation and source URL. This is the same pipeline as https://nuclide.cc/ask/: it resolves the records the question names, classifies the intent (definition, treatments, approval, mechanism, side effects, trials, results, comparison, prognosis, who makes it, cost) and fills a template from the records' structured fields. Nothing is generated; if Nuclide has no record on the point it says so. Call this before summarising anything about radiopharmaceuticals so every claim carries an Nuclide URL. Optional region (US, EU, UK, JP, CN, AU) tailors approval answers.
Two Nuclide records side by side (ideally the same kind: two drugs, two trials, two indications): each field with both values and a differs flag, the list of differing fields, the records they both connect to, and whether they link to each other directly. Use search to find ids first.
One clean Markdown document for a record: TL;DR, summary, structured fields, sources and connected records, ready to paste into a prompt. Same content as https://nuclide.cc/api/v1/context/<id>.md.
The full record for one Nuclide id (or page route or URL): every field the site has, the page URL, the Markdown context URL, and the connected records grouped by kind with their URLs. Cite the url after any fact taken from it.
Output schemas not documented. Tools return complex nested structures (connected records, differing fields, citations) but LLMs cannot see the response shape. This forces agents to guess field names and risks extraction errors.
Duplicate tools with inconsistent naming. 'search' and 'nuclide_search' appear to do the same thing; 'get_entity' and 'nuclide_get_entity' are near-duplicates. LLMs waste reasoning cycles deciding between them. Consolidate to one canonical set.
Error handling lacks recovery guidance. No indication of what to do if a search returns no results, if an entity ID is invalid, or if the ask pipeline cannot classify intent. Errors should guide the LLM to retry, refine, or use an alternative tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Every record of one kind as id, name, status, tldr and url, optionally filtered by field. Filters are key=value pairs matched case-insensitively against the record's fields; arrays match on membership, "key=" matches records where the field is empty. Examples: status=approved, modality=ADC, phase=3, targets=trop2.
Read a public Nuclide record using an exact ID from nuclide_search. Returns the full dated record, primary-source links and connected records. Verify facts at source; not medical advice.
Search Nuclide's public radiopharmaceutical records by name, alias, or keywords (lexical search). Returns record IDs, summaries and page URLs; optionally filter by kind. Not personalised medical advice.
Find Nuclide records (indications, drugs, isotopes, targets, trials, companies, institutions, people, terms and more) by name or meaning. Runs the site's word search (names, aliases, TL;DRs, tags) and concept search (record text plus the names of linked records) and fuses them, so paraphrases such as "PSMA radioligand for prostate cancer" work. Returns id, kind, name, status, tldr, url and why each matched. Use the id with get_entity, context or compare.
'context' tool description is vague ('One clean Markdown document'). Does not explain when to call it vs get_entity, what 'clean' means, or why an LLM would prefer Markdown over structured JSON. Clarify the use case.
'list_kind' filter parameter lacks format guidance. Description says 'key=value pairs' but does not specify case sensitivity, array matching behavior, or what happens if a filter key does not exist. LLMs may pass invalid filters.