asistonto-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pack_authoring_guideA | Read the pack-authoring guidance. Same text as the asistonto:// resources, for clients that cannot read resources. Topics: pack-format, four-part-questions, paraphrases, calibration, workflow, labels, example, all. |
| compose_questionA | Assemble one pack question from the four parts, placing each where the retrieval measurements say it belongs: the heading label and the question are indexed, the provenance and the stakes are not. Returns the question object plus what is still missing from it. |
| parse_meeting_notesA | Parse a corpus document into pack questions. Accepts both shapes the asistonto corpus uses: the four-part blockquote format and the older |
| check_paraphrasesA | Lint the paraphrases of one question before they go into a pack: count against the measured curve, phrasings that borrow document vocabulary from the provenance, phrasings that fit a sibling question better, duplicates and keywords. |
| validate_packA | Validate a pack against the schema the live copilot loads, and against what measurement says will under-perform silently. Errors mean it will not load; warnings mean it will load and then quietly do less than it should. |
| write_packB | Write a pack to a directory: brief.json, paraphrases.json and optionally background.txt and labels.json. Validates first and refuses to write a pack that would fail to load. |
| read_packB | Read a pack from disk the way the live server does, and validate it. Use this to review or extend a pack that already exists. |
| render_question_documentA | Render questions back into the four-part markdown a person can read and correct. Keep it next to the pack: the pack is for the machine, this is for the room. |
| pack_size_floorA | How many questions a pack needs before anything in it can fire, for a given gate. The live gate is a z-score over the pack's own scores, so a small pack has a ceiling below it and stays dark. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| build_pack_for_meeting | Turn raw meeting notes or product documents into a loadable asistonto pack. |
| write_paraphrases | Write the ten spoken phrasings for one question. |
| formulate_question | Turn one observation into a question in the four-part format. |
| review_pack | Review an existing pack and say what would fail silently. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| What a question pack is | The files a pack is made of, and the one rule that decides everything. |
| The four-part question format | Provenance, observation, question, stakes — and where each part goes. |
| Writing paraphrases | The four measured rules for phrasings that actually match speech. |
| Background, calibration and pack size | Why background.txt exists and why a pack needs at least 25 questions. |
| Building a pack end to end | The six steps from raw meeting notes to a loadable pack. |
| Measuring a pack afterwards | labels.json, and how to judge emissions honestly. |
| A worked example | One raw note turned into a question and its ten paraphrases. |
| brief.json schema | JSON Schema for the file the live copilot loads. |
TDQS
Scored across 9 tools
Most tools have clearly distinct purposes: parsing notes, composing questions, checking paraphrases, validating packs, rendering documents, and reading/writing packs all target different stages. The only minor overlap is between validate_pack and read_pack, since read_pack also validates, but the descriptions make the distinction clear.
The majority of tools follow a verb_noun pattern (compose_question, parse_meeting_notes, validate_pack, write_pack, read_pack), but two exceptions break the convention: pack_authoring_guide and pack_size_floor are noun phrases with no verb. This mixed pattern is readable but not fully consistent.
With 9 tools, the server is well-scoped for its purpose. Each tool covers a distinct step in the pack authoring workflow, and there is no obvious redundancy or bloat.
The tool set covers the full authoring lifecycle: guidance, parsing, composing, paraphrasing, validation, rendering, writing, reading, and sizing. Minor gaps exist (no explicit delete or update operation, no batch listing), but write_pack can overwrite packs and the core workflow is complete.