It is a read-only MCP server that helps plan, write, and audit lesion network mapping papers by serving structured knowledge about study designs, reporting standards, limitations, and phraseology.
List the six study designs and the claims they can establish (lnm_list_designs).
Classify a free-text study description into the best-matching design, returning matched signals and expected analyses (lnm_classify_design).
Generate a section-by-section paper outline with word budgets, obligations, gaps, and sentence frames (lnm_outline_paper).
List and retrieve long-form guidance documents on methods, statistics, figures, and argumentation (lnm_list_guidance, lnm_get_guidance).
Produce a 66-item reporting checklist graded required/expected/optional, filterable by design and section (lnm_methods_checklist).
Get 59 sentence frames grouped by section and purpose (lnm_phrasebook).
Get study-specific limitations with counters, and retired entries as strengths (lnm_limitations).
Audit a manuscript draft with 36 deterministic checks, flagging missing reporting elements and overstatements with quoted text (lnm_audit_manuscript).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lnm-writer Audit my lesion network mapping draft for missing methods and overstatements."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Agent Skills and an MCP server for writing, refereeing, and illustrating papers in the lesion network mapping literature — the family of studies that localize a symptom or a therapeutic effect to a brain network using causal evidence and a normative connectome.
Covers six designs: lesion network mapping, voxel-based lesion-symptom mapping, DBS sweet-spot and probabilistic stimulation mapping, DBS network mapping, convergent causal mapping, and coordinate or atrophy network mapping.
The knowledge base was distilled from a close structural reading of fourteen published papers in this literature. It encodes the section skeletons, the reporting obligations each design carries, the statistics and their failure modes, the figure conventions, the limitations bank, and the sentence frames the genre uses. It contains no text from those papers.
Capability | Skill | MCP tool |
Decide which design a study is |
|
|
Plan the sections, and find the analyses that are missing |
|
|
Get the reporting checklist for a design |
|
|
Read the guidance on methods, statistics, argument, figures | all |
|
Get sentence frames for a section |
|
|
Get the limitations that actually apply to this study |
|
|
Audit a draft for missing reporting elements and overstatement |
|
|
Plan the figure set, sized to a journal's column |
|
|
Check a caption for the elements the genre requires |
|
|
Render brain figures, and audit a finished figure file |
|
|
The server holds no model and writes no prose. It serves the structure of the genre; the calling agent does the writing. Pixels are a separate concern: lnmfig, the Python package in this repository, does the rendering.
Related MCP server: NIH Research MCP Demo
pip install -e '.[all]'
lnmfig whole-brain map.nii.gz -o fig3 --threshold 2.5 --journal nature --column double
lnmfig montage map.nii.gz -o fig2 --plane axial --cuts=-26,-14,2,18,34 --threshold 2.5
lnmfig overlap lesions/*.nii.gz -o fig1a --save-counts overlap.nii.gz
lnmfig convergence mapA.nii.gz mapB.nii.gz -o fig4 --threshold 2.5 --similarity
lnmfig audit fig3.pdf --journal nature --column double --caption caption.txtRenders the field's visual grammar: the inflated cortex, the SUIT cerebellar flatmap, slice montages on an anatomical underlay, glass-brain overlap maps, the convergence overlay, predicted-against-empirical scatters with their confidence band, permutation nulls, and JAMA-style forest tables. Reads Lead-DBS atlases and electrode reconstructions without MATLAB.
Three properties it enforces that a bare plotting call does not:
One scale, resolved once. A cortex panel and a cerebellum panel of the same map share limits, threshold, and colormap, because a reader compares them and they are only comparable if the scale is identical.
True printed size. Figures are authored at the journal's column width in inches and exported without cropping to content, so the declared canvas is the delivered canvas and nothing silently drops below the minimum legible font size.
Provenance. Every render carries the scale that produced it, so lnmfig caption builds a caption stub from the render, with a bracketed placeholder for every fact it does not have.
lnmfig audit checks a finished file against a journal's rules: resolution at the printed size, canvas width against the column, colour mode, greyscale legibility, Type 3 fonts, and whether the caption carries the threshold, correction, template, test, and sample size.
git clone https://github.com/nielspac177/lnm-writer.git ~/.claude/skills/lnm-writer && cd ~/.claude/skills/lnm-writer && npm installThe repository carries a .claude-plugin/plugin.json, so any folder under a skills directory containing that manifest loads as a plugin on the next session — with no marketplace and no install step. Restart Claude Code, approve the MCP server when prompted, and all three skills plus the nine tools are available.
npx skills add nielspac177/lnm-writerInstalls to Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, opencode, Zed, and the rest of the agents that CLI supports. Add -g for a global install, or --skill lnm-paper to take just one. The skills are self-contained: each carries its own copy of the references it reads, so they work with no MCP server present.
git clone https://github.com/nielspac177/lnm-writer.git && cd lnm-writer && npm installnpm install builds dist/. Then register the server with your client.
Claude Code:
claude mcp add lnm-writer -- node /absolute/path/to/lnm-writer/dist/index.jsCodex, in ~/.codex/config.toml:
[mcp_servers.lnm-writer]
command = "node"
args = ["/absolute/path/to/lnm-writer/dist/index.js"]Any client that reads an mcpServers block, including Cursor, Gemini CLI, and Claude Desktop:
{
"mcpServers": {
"lnm-writer": {
"command": "node",
"args": ["/absolute/path/to/lnm-writer/dist/index.js"]
}
}
}Transport is stdio. The knowledge base is bundled and local, so there is no remote state, no credential, and no network call at runtime.
All nine are read-only and annotated as such.
lnm_list_designs — the six designs, with the claim each one can establish.
lnm_classify_design — scores a free-text study description against every design and returns a ranked list with the signals it matched, plus the analyses reviewers of the winner expect. Declines to guess when nothing matches, and says which facts to add.
lnm_outline_paper — a section-by-section plan: subsections in the literature's order, word budgets, per-section reporting obligations, and sentence frames. Leads with the gaps: analyses the design normally has to defend that nothing in the described study covers.
lnm_list_guidance / lnm_get_guidance — the five long-form documents, whole or sliced to one heading.
lnm_methods_checklist — 66 reporting items graded required, expected, or optional, each with the reason it matters, filterable by design and section.
lnm_phrasebook — 59 sentence frames across 12 groups, by section and purpose.
lnm_limitations — the limitations bank filtered by what the study actually did. Each entry pairs the concession with the counter published papers use. Entries the study already answers come back separately as retired, so they are reported as strengths rather than conceded.
lnm_audit_manuscript — 36 deterministic checks over a draft, graded blocking, address-before-submission, and consider. Half look for missing reporting elements; the rest look for phrasings that overstate what the design supports, and quote the text that triggered them.
Resources are exposed at lnm://guidance/{id}. Two prompts, write_lnm_paper and review_lnm_manuscript, drive the full workflow.
It is a text search for required reporting elements. It tells you whether a manuscript says an analysis was done; it cannot tell you whether the analysis was done well. A clean audit is a floor, not a verdict.
knowledge/ single source of truth: 5 markdown documents + 8 JSON data files
skills/ three Agent Skills, each with a committed copy of the references it reads
src/ MCP server (TypeScript, stdio, @modelcontextprotocol/sdk)
lnmfig/ the figure toolkit (Python, nilearn + SUITPy + matplotlib)
scripts/ sync-knowledge.mjs keeps the skill copies identical to knowledge/
test/ smoke.mjs drives the server over a real MCP client session
tests/ test_lnmfig.py covers the toolkit, skipping renderers when extras are absentEdit files in knowledge/, then npm run sync. npm run build fails if the copies drift.
npm install # installs and builds the MCP server
npm run build # compile, then verify the skill copies are in sync
npm run sync # propagate knowledge/ into skills/*/references/
node test/smoke.mjs # 51 end-to-end checks over a real MCP client session
npm run inspect # open the MCP Inspector against the server
uv venv .venv && uv pip install --python .venv/bin/python -e '.[all]' pytest scikit-image
.venv/bin/python -m pytest tests/ # 39 checks over the figure toolkitknowledge/journals.json is a copy of lnmfig/data/journals.json, which is the source: the Python package has to install standalone, and the MCP server has to serve the same numbers without importing Python. npm run sync propagates it and npm run build fails if it drifts.
This encodes the conventions of a specific literature. It will make a manuscript conform to that literature's expectations; it will not make a study sound, and it cannot see your data.
The tools never generate numbers. Where a value is missing, the skills write an explicit placeholder and collect them for you to fill in. A fabricated coordinate or p-value in a neuroimaging manuscript is a research-integrity problem, so this is a hard rule rather than a preference.
MIT. See LICENSE.
Search a draft for the reporting elements this design requires, and for phrasings that overstate what the design supports.
Findings come in three grades: blocking (a reviewer will reject or major-revise on it), address before submission, and consider. Each finding names the section, the problem, and the fix. Overstatement findings quote the text that triggered them.
This is a text search, not a review. It tells you whether the manuscript says an analysis was done; it cannot tell you whether the analysis was done well. A clean audit is a floor, not a verdict.
Args:
manuscript: the full text, or at minimum one complete section (120+ words)
design: optional design id; supplying it adds that design's specific checks
Returns: counts, then findings grouped by severity.
| Name | Required | Description | Default |
|---|---|---|---|
| design | No | Design id, to add design-specific checks. | |
| manuscript | Yes | Manuscript text to audit. Full text preferred; a complete section is the minimum. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior; the description adds substantial context beyond that by explaining severity grades, finding contents, quoted overstatement triggers, and the limitation that a clean audit is not a quality endorsement. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured and front-loaded, but the Args section largely duplicates the input schema. Each paragraph still earns its place: grades, limitations, and return shape are distinct pieces of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value: counts followed by findings grouped by severity, with each finding containing section, problem, and fix. It also specifies input minimums and the optional design parameter, so an agent has enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description mostly restates the schema, with minor additions like the 120+ word minimum and the effect of supplying a design id, but it does not materially deepen parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: it searches a draft for required reporting elements and for overstating phrasings. It also distinguishes itself from a review, making its scope clear relative to sibling checklist/guidance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: supply a manuscript or complete section, optionally a design id, and expect a text search rather than a quality verdict. It explicitly states what the tool cannot do, but it does not name sibling alternatives or provide direct when-not-to-use comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide which lesion/stimulation mapping design a described study belongs to.
Pass a free-text description of the data: the cohorts you have, where they came from, what the outcome variable is, and whether a second cohort exists for validation. The tool scores every design against that description and returns a ranked list with the signals it matched, plus the analyses reviewers of the winning design expect before they will believe the central claim.
Example input: "We traced 21 published lesion cases causing acute-onset vertigo, compared them against 30 control lesions causing other brainstem syndromes, and seeded connectivity in the GSP1000 connectome."
Returns: best match, a confidence flag, a ranked table, and the mandatory analyses. Error handling: when nothing matches, the response says which facts to add to the description rather than guessing a design.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Free-text description of the study: cohorts, data sources, outcome measure, validation. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds significant behavioral detail: it scores every design, returns matched signals, lists reviewer-expected analyses, and explicitly refuses to guess when no design matches, instead requesting more facts. This is valuable transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by instructions, an example, return values, and error handling. Every section earns its place, and the format is scannable for a complex classification tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers the return contract: best match, confidence flag, ranked table, mandatory analyses, and error-handling behavior. Input requirements are explicit, so an agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds value by specifying exactly what the free-text description should include (cohorts, provenance, outcome variable, validation cohort) and by providing a concrete example input. This exceeds the baseline but is not fully transformative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Decide which lesion/stimulation mapping design a described study belongs to.' It clearly distinguishes itself from siblings like lnm_list_designs by stating the tool classifies rather than lists, and it explains what is returned: a ranked list, confidence flag, and mandatory analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: pass a free-text description containing cohorts, origins, outcome variable, and validation cohort. It provides an example and explains error-handling behavior when nothing matches. It does not explicitly name alternative sibling tools or state when not to use it, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one guidance document, or one heading within it.
Documents run to several thousand words. Pass 'section' with part of a heading to pull just that heading and its subheadings; without it you get the whole document, truncated at 25,000 characters with a note saying so.
Args:
id: a document id from lnm_list_guidance
section: optional, substring of a heading, e.g. 'specificity' or 'permutation'
Error handling: an unknown id lists the valid ids; a heading that matches nothing lists the headings that document actually has.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document id from lnm_list_guidance. | |
| section | No | Substring of a heading, to fetch one section. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnly/idempotent annotations by disclosing the 25,000-character truncation behavior, the 'section' retrieval semantics, and detailed error handling for unknown ids and unmatched headings. An agent can predict important edge-case behavior before calling the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a behavior paragraph, an Args list, and an Error handling line. Every sentence adds information and there is no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool, the description is complete: it explains source of ids, optional section behavior, truncation, and error responses. Even without an output schema, an agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters clearly, but the description adds useful nuance: 'section' is a substring, it retrieves the heading plus subheadings, and omitting it returns the whole truncated document. The examples 'specificity' and 'permutation' help clarify acceptable inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states the exact operation: 'Fetch one guidance document, or one heading within it.' This clearly conveys the verb, resource, and optional narrower scope, and it is easily distinguished from sibling tools like lnm_list_guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use the 'section' parameter: pass part of a heading to get one section, or omit it for the full document. It also points to lnm_list_guidance as the source for valid ids, though it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the limitations a reviewer of this design will raise, filtered to the ones that are actually yours.
Every entry pairs the concession with the counter that published papers use, because a bare concession invites the reviewer to finish the sentence. Entries your study already answers are listed separately as 'retired', so you report them as strengths in the Methods instead of conceding them in the Discussion.
Args:
design: design id
study_features: what your study did, one string per feature, e.g. ['prospective cohort', 'lesions traced from 3D MRI', 'out-of-sample validation cohort', 'age-matched connectome']. These both trigger and retire entries.
Returns: an ordered list to write as one Discussion paragraph, plus the retired set.
| Name | Required | Description | Default |
|---|---|---|---|
| design | No | Design id; omit for limitations common to every design. | |
| study_features | No | Features of your study, used to include and retire limitations. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the tool's core behavior: entries are filtered by study_features, concessions are paired with counters, and already-answered entries are moved into a separate 'retired' set. This gives the agent a clear model of what the tool will and will not return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and immediate purpose, then explains the concession-counter rationale, then lists args and returns. Every sentence earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 stating the return shape ('ordered list to write as one Discussion paragraph, plus the retired set'). All three parameters are meaningfully contextualized, including a concrete example for study_features, making the tool fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains that design can be omitted for limitations common to every design and that study_features 'both trigger and retire entries.' The example feature list clarifies the expected granularity and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the limitations a reviewer of this design will raise, filtered to the ones that are actually yours.' It also clarifies what the output is for ('to write as one Discussion paragraph') and distinguishes itself from a generic guidance tool by emphasizing study-specific filtering and concession-counter pairs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains how to use the tool: provide design and study_features, and it explains the 'retired' concept so the user knows to report those points as strengths in the Methods rather than concessions in the Discussion. It does not explicitly list when-not-to-use or alternatives, but the guidance given is strong and contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every study design this server can plan, check, and audit.
Use this first when you do not yet know which design a study is, or to show a user the options. Each row names the design, an id you pass to the other tools, and the claim that design is able to establish.
Designs covered: lesion network mapping, voxel-based lesion-symptom mapping, DBS sweet-spot/probabilistic stimulation mapping, DBS network mapping (connectivity to the stimulation volume), convergent multi-modal mapping, and coordinate network mapping of published findings.
Returns: a table of id, name, and what the design establishes. Don't use when: you already know the design id — call lnm_outline_paper directly.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful behavioral context beyond annotations: it returns a table of id, name, and what the design establishes, and explains that the id is passed to other tools. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose, then covers when to use it, what designs are included, what is returned, and when not to use it. Every sentence adds useful information and nothing is redundant or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with only one optional parameter, the description is complete: it states the purpose, usage timing, scope, return format, and routing alternative. The annotations cover safety and idempotency, so nothing an agent needs to invoke correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, response_format, is fully described in the schema with an enum and a clear explanation of markdown vs json. Since schema description coverage is 100%, the description does not need to add parameter details; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List every study design this server can plan, check, and audit.' It also names the exact design types covered and explicitly differentiates this tool from lnm_outline_paper by saying not to use it when the design id is already known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: 'Use this first when you do not yet know which design a study is, or to show a user the options.' It also provides a clear exclusion and alternative: 'Don't use when: you already know the design id — call lnm_outline_paper directly.' This fully routes an agent to the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the long-form guidance documents bundled with this server.
These are the prose references behind the other tools: how each design works, how the Methods are written, which statistics the genre uses and what they are for, figure conventions, and how the Discussion is argued. Filter by design or topic.
Returns: id, title, what it covers, and the resource URI for each document. Fetch one with lnm_get_guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Substring match against document topics, e.g. 'statistics'. | |
| design | No | Restrict to documents relevant to this design id. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose read-only, idempotent, non-destructive behavior, so the bar for additional behavioral disclosure is lower. The description adds useful context about the documents being bundled with the server and the returned fields (id, title, coverage, resource URI), but does not mention pagination or ordering. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core list action and scope, then uses a compact paragraph to explain the document contents, filtering, and return fields. Every sentence earns its place, and the final pointer to lnm_get_guidance is a useful, minimal next-step instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema, the description adequately specifies what is returned and how to fetch a full document. It could more explicitly draw boundaries against sibling list tools, but the content areas and the mention of document IDs and URIs give an agent enough to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds only the general 'Filter by design or topic' guidance, which mirrors the schema. Baseline 3 is appropriate because the schema carries the parameter-documentation load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List the long-form guidance documents bundled with this server.' It clearly distinguishes itself from siblings by describing the document set as 'the prose references behind the other tools' and explicitly directs single-document retrieval to lnm_get_guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides useful context on when to use the tool: it lists the reference documents and says to 'Fetch one with lnm_get_guidance.' It also explains the documents are background prose for other tools and offers filtering by design or topic. It does not explicitly exclude sibling tools such as lnm_list_designs or lnm_methods_checklist, so selection guidance is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the reporting checklist for a design as a tickable table.
Items are graded: 'required' means a reviewer of this design will ask for it by name, 'expected' means its absence reads as carelessness, 'optional' means it strengthens the paper. Each item carries the reason it matters, so you can decide rather than comply.
Use while drafting the Methods, and again before submission. For a check against finished text instead of a list to work from, use lnm_audit_manuscript.
Args:
design: optional design id; omitted returns items common to every design
section: optional, e.g. 'Methods', 'Results', 'Discussion'
include_optional: default false
| Name | Required | Description | Default |
|---|---|---|---|
| design | No | Design id; omit for the design-independent core. | |
| section | No | Restrict to one section, e.g. 'Methods'. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
| include_optional | No | Include items graded 'optional'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so no contradiction exists. The description adds meaningful behavioral context beyond those hints: items are graded 'required', 'expected', or 'optional', each item carries its rationale, and the checklist is meant for drafting rather than exhaustive auditing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-line purpose, a compact explanation of grading semantics, explicit usage timing, a sibling alternative, and a clearly formatted Args list. Every sentence adds value without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a read-only checklist tool: it explains what is returned, how items are graded, when to use it, when not to use it, and what each parameter does. Although there is no output schema, the 'tickable table' and item-grading description cover the key output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning: it explains that omitting design returns items common to every design, that section restricts to a section, and that include_optional controls optional-item inclusion. The only minor gap is that response_format is not mentioned in the Args list, though the schema documents it fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the reporting checklist for a design as a tickable table.' It clearly distinguishes the tool from its sibling lnm_audit_manuscript by contrasting a working list with a check against finished text, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Use while drafting the Methods, and again before submission') and names the alternative for a different task ('For a check against finished text instead of a list to work from, use lnm_audit_manuscript'). This gives the agent actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce a section-by-section plan for a paper of a given design.
The plan gives, per section: the subsections in the order the literature uses them, a word budget, what the section has to accomplish, the reporting elements that must appear in it, and sentence frames to start from. Before the skeleton it lists the gaps: analyses this design normally has to defend that nothing in the study you described covers.
Call lnm_classify_design first if you do not know the design id.
Args:
design: a design id or name, e.g. 'lnm', 'dbs-network', 'convergent'
topic: the symptom, syndrome, or effect being localized, e.g. 'freezing of gait'
cohorts: one string per cohort, e.g. ['14 published lesion cases', '36 ET patients, VIM-DBS']
connectome: the normative connectome, e.g. 'GSP1000 rs-fMRI, n=1000'
analyses_done: analyses already run, e.g. ['leave-one-out cross-validation']
target_journal: used only to remind you to check word and figure limits
Returns: gaps, a skeleton table, and per-section obligations.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The symptom, syndrome, or therapeutic effect being localized. | |
| design | Yes | Design id or name. Run lnm_list_designs to see valid ids. | |
| cohorts | No | One entry per cohort, with n and provenance. | |
| connectome | No | Normative connectome name, n, and modality. | |
| analyses_done | No | Analyses already run, for gap detection. | |
| target_journal | No | Target journal, for word and figure limits. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by detailing what the tool produces, including per-section subsections, word budgets, reporting elements, sentence frames, and a gap analysis. It also honestly notes what it does not cover: analyses that the design must defend but the study does not mention. This is strong behavioral disclosure for a read-only planning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses a clear Args list that is easy to scan. The Returns line partially restates the earlier output description, which is a small redundancy, but overall the length is justified for a tool with seven parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of producing a section-by-section paper plan, the description is remarkably complete. It explains the shape of the output, the prerequisite step, parameter meanings, and the target_journal constraint, so an agent has enough context to invoke the tool correctly without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers all parameters, the description adds concrete examples for design, topic, cohorts, connectome, and analyses_done, and clarifies that target_journal is 'used only to remind you to check word and figure limits.' This provides real selection guidance beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Produce a section-by-section plan for a paper of a given design', which clearly names a specific verb and deliverable. It also distinguishes itself from sibling tools like lnm_classify_design by describing its own output: a plan with subsections, word budgets, obligations, and sentence frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to call lnm_classify_design first when the design id is unknown, and clarifies the limited role of target_journal and the role of analyses_done in gap detection. It does not explicitly contrast with checklist or audit siblings, but the sequencing note and purpose make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the sentence frames this literature uses, grouped by section and purpose.
These are the recurring moves: how a lesion cohort is introduced, how a sensitivity result is stated, how a specificity contrast is phrased, how a cross-validated prediction is reported, how a limitation is conceded. They exist to get the register right, not to be pasted in — a paper built from unedited frames reads like a form.
Args:
section: optional, e.g. 'Abstract', 'Methods', 'Results', 'Discussion'
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Section or purpose to filter by. | |
| response_format | No | Output format: 'markdown' to read, 'json' for machine processing. | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the safety profile is covered. The description adds useful context beyond that: results are recurring moves grouped by section/purpose, and the output is meant to inform register, not to be copied verbatim. This extra caveat helps the agent set correct expectations about the returned content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and then gives a compact set of examples and a pragmatic warning. Every sentence adds useful context, and the Args note is minimal without being redundant. The length is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does enough to convey what kind of output to expect: grouped sentence frames for common literature moves. It also communicates the practical limitation that frames should not be pasted verbatim. It does not enumerate all possible sections or describe the exact formatting, but those are minor gaps for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds example values for the section parameter, which is helpful, but mostly repeats what the schema says and does not discuss response_format. This fits the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line says exactly what the tool does: return sentence frames, grouped by section and purpose. The examples of recurring moves further specify the kind of content the agent can expect. This distinguishes it from sibling tools like lnm_get_guidance or lnm_limitations, which have different outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear the tool is for matching the register of the literature and explicitly warns against pasting frames in unedited. It does not explicitly name sibling tools as alternatives or state when not to use it, so it stops short of a 5. The context is nevertheless clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct role: design listing/classification, paper outlining, guidance retrieval, checklist generation, phrasebook lookup, limitations, and manuscript audit. Even the closely related checklist and audit tools are clearly differentiated by drafting versus finished-text use.
All tools share the lnm_ prefix and snake_case convention, and most follow verb_noun naming (list_designs, classify_design, outline_paper, get_guidance, audit_manuscript). A few noun-only names (methods_checklist, phrasebook, limitations) are minor deviations from the pattern.
Nine tools is well within the ideal range and each tool earns its place by supporting a distinct stage of the study-design-to-manuscript workflow. The count feels neither sparse nor bloated.
The toolset covers the full workflow this server promises: design identification, paper outlining, guidance retrieval, methods checklisting, phrase support, limitations handling, and final manuscript audit. There are no obvious dead ends or missing stages within its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only tools over the Psychopathia Machinalis nosology: 79 conditions, 11 tools.
Native Clarity decision mapping, MindScan episode reflection, and read-only evidence tools.
Read-only game, setup, place, evidence and travel decision tools with explicit provenance.
Read-only MCP over the LivingMeta AI-in-Research corpus: 12,400 papers, gaps, priority agenda.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nielspac177/lnm-writer'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
