Skip to main content
Glama
cflorczyk9

margins-mcp

by cflorczyk9

propose_compile_from_raw

Compile raw documents like PDFs, MD, DOCX into wiki source page proposals with wikilinks and metadata, creating structured knowledge artifacts for retrieval.

Instructions

Compile a supported source file (.adoc, .asciidoc, .conf, .csv, .docx, .eml, .epub, .htm, .html, .ini, .json, .log, .markdown, .md, .mdx, .odp, .ods, .odt, .org, .ott, .pdf, .pptx, .rst, .rtf, .srt, .tex, .text, .toml, .tsv, .txt, .vtt, .xlsm, .xlsx, .xml, .yaml, .yml) into a wiki source page proposal staged at proposed/.

IMPORTANT — produce a knowledge artifact, not a topic recap. The page you stage is the substrate the user (and future Claude sessions) will retrieve from. Thin pages = thin retrieval.

Before calling, call get_vault_context to know which entity slugs and active project slugs to wikilink, and which semantic tags are already in use.

For a meeting/call/transcript: pick content-specific H2 headings that reflect what was actually discussed (e.g. 'Practice Overview', 'Service Philosophy', 'Succession Status' — NOT 'Summary' / 'Bullets' / 'Takeaways'). Quote verbatim where the exact phrasing matters. Wikilink every entity using slugs from get_vault_context. Include a relevanceCallout naming the active projects/decisions this source bears on. Surface 2-4 concrete applications.

For a synthesis page (pageType='synthesis'): pass the source URLs as sources, structure body sections around the argument, include a relevanceCallout.

For a concept page (pageType='concept'): structure as snapshot + context + source log.

Legacy callers can still pass summary + summaryBullets + takeaways and skip sections — Margins will fall back to the simple template. But the rich path is what produces a knowledge artifact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoSemantic tags (topical, people slugs, firm slugs). DO NOT include region/X or vibrance/X — those are auto-computed by scripts/wiki_regions.py and will be overwritten.
forceNoReplace an existing source page for this raw file. Without bucket/destination_path override, the existing source page is replaced IN PLACE (same path). With override, the source moves to the new location. Default false.
quietNoOmit the full staged markdown from the response. The page still lands at proposed/<destinationPath> — set quiet=true when compiling many files in one turn so the response payload stays small. Default false.
splitNoSplit-mode trigger. When set, the raw file is segmented at the chosen boundary and Margins stages one source page per segment plus a hub page that wikilinks them. 'heading-h1' / 'heading-h2' segment by Markdown-style heading level (works for MD/HTML and any extractor that emits H markers like XLSX/PPTX). 'sheet' is alias for h2 splits, ergonomic for spreadsheets. 'auto' picks h2 for spreadsheets and h1 elsewhere. Summary is not required in split mode.
titleNoTitle for the page. Defaults to titlecased filename.
bucketNoWiki bucket folder. 'sources', 'projects', 'ideas', 'meetings', 'career'. Pick by topic, not page-type.
rawPathYesVault-relative path of the source file. Examples: 'raw/foo.pdf', 'meetings/march-7.md'. Pass list_unprocessed paths directly. Bare filename (e.g. 'foo.pdf') resolves to raw/foo.pdf unless an actual root-level foo.pdf exists and raw/foo.pdf does not.
relatedNoRelated wiki pages. Either bare slug strings or {slug, note} objects. Renders as `## Related` with `[[wikilinks]]`.
sourcesNoFor synthesis pages: list of evidence URLs. Renders as a sources frontmatter list.
summaryNoRich multi-clause summary (NOT 1-3 sentences). REQUIRED unless split mode is set — in split mode each segment is auto-titled from its heading and no summary is needed. For single-source compile this becomes the frontmatter summary used by retrieval.
keyLinksNoWikilink slugs for the frontmatter key_links field, e.g. ['ellis-rutili', 'centric-wm', 'briefly']. Use slugs from get_vault_context.
pageTypeNoPage shape. 'source' = faithful summary of one raw file (default). 'concept' = durable theme/idea. 'synthesis' = connection-point across multiple sources.
sectionsNoPrimary body — array of {heading, body} sections. Pick content-specific H2 headings that fit the source. Body is markdown; may include [[wikilinks]], tables, blockquotes, bold key terms. Quote verbatim where phrasing matters. If you provide sections, the legacy summary/bullets/takeaways template is skipped.
eventDateNoDate the source event occurred (YYYY-MM-DD). Defaults to today.
hubBucketNoBucket folder for the hub + segment pages when split mode is set. Defaults to bucket if provided, else 'sources'.
sourceUrlNoExternal URL if the source has one (YouTube, blog post, public PDF). Renders as a markdown link in the header block.
takeawaysNoLEGACY — for the simple template only. If you provide `sections`, this is unused. Either strings or {point, evidence} objects.
headerNoteNoShort paragraph under the H1 giving venue/runtime/context (e.g. 'Stanford GSB fireside chat, ~45 min, published 2026-05-04').
maxSegmentsNoCap on segments staged in a single split call. Default 50. Extra headings beyond the cap are noted in the hub but not staged.
applicationsNoConcrete questions or applications. Renders as `## Personal applications worth tracking`. 2-4 items typical.
participantsNoFor meeting/call pages: participant names. Renders as a participants frontmatter list.
sourceCaveatNoSource-quality warning — renders as a `> [!info]+ Source caveat` callout. Use when the source has limitations (e.g. 'Granola summary, no transcript available').
summaryBulletsNoLEGACY — for the simple template only. If you provide `sections`, this is unused.
destination_pathNoOverride destination path, e.g. 'wiki/career/source-2026-05-13-something.md'.
propagationNotesNoEntity/concept creation decisions made or refused (per operator-manual rule #4). Renders as `## Propagation Notes`.
relevanceCalloutNoConnor-relevance synthesis. Renders as `> [!claude-note]+ Connor-relevance — Claude synthesis`. Body is markdown. Links is an array of wikilink slugs to active projects/decisions this source bears on.
Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false) are supplemented by description details: the 'force' parameter can replace existing source pages, split mode stages multiple pages, and tags are auto-computed. This adds valuable behavioral context 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections for different page types and parameter guidance. While it is somewhat verbose (e.g., listing all file extensions), the length is justified by the tool's complexity and the need to disambiguate usage.

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?

Given 26 parameters and no output schema, the description covers file types, page types, parameter usage, prerequisites, and legacy mode comprehensively. It lacks details on return values, but the complexity is high and the description is fairly complete for an agent.

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

Parameters5/5

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

With 100% schema description coverage, the description further enriches parameter meanings, e.g., providing content-specific heading instructions for meetings, warning against certain tags, and clarifying legacy vs rich paths. This adds significant value beyond the schema alone.

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 clearly states the tool compiles supported source files into wiki source page proposals at 'proposed/<wiki path>', listing many file extensions. It distinguishes from sibling tools like propose_page by emphasizing knowledge artifacts vs topic recaps and providing specific page-type guidance.

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?

The description gives explicit usage guidance: call get_vault_context first, avoid certain tags, and follow different patterns for meetings, synthesis, and concept pages. It also explains the legacy vs rich path. However, it does not explicitly state when NOT to use this tool versus alternatives like propose_page.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cflorczyk9/Margins'

If you have feedback or need assistance with the MCP directory API, please join our Discord server