hwp-live-safe

by Jasujung99

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
The set contains several near-identical pairs, such as hwp_preview_profile_insert vs hwp_foreground_preview_profile_insert, hwp_apply_preview vs hwp_foreground_apply_preview, and hwp_status vs hwp_foreground_status. Although the descriptions carefully distinguish them, the similar names create real ambiguity when an agent must select among them.
Naming Consistency3/5
Most tools follow a hwp_<area>_<action>_<object> pattern, but there are deviations like hwp_undo_last and hwp_start_new_document, and action/object ordering varies between hwp_preview_edits and hwp_foreground_preview_text. The foreground prefix is used consistently, but the overall pattern is not fully uniform.
Tool Count4/5
15 tools is at the upper edge of a reasonable scope, and most tools correspond to distinct workflow steps in either the HWP Live or foreground experimental modes. The count feels slightly heavy because several tools repeat the same preview/apply concept for different targets, but it is still defensible.
Completeness3/5
The core workflow of checking status, starting a document, reading context, previewing edits, applying them, and undoing is covered, along with profile insertion and foreground window targeting. However, there is no explicit close/abandon document tool, and the foreground mode lacks any post-apply read-back or verification, leaving notable operational gaps.
Average 4/5 across 13 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses one useful trait ('without changing Hancom'), but it does not explain what 'forget' does to the selection, whether it is reversible, what happens if no window is selected, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The key action is front-loaded, and the important safety qualifier 'without changing Hancom' earns its place at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool with an output schema, the description is minimally viable: it identifies the action and a key non-effect. However, it leaves the notion of 'selected foreground window' undefined and offers no guidance on when to disconnect, so an agent has to infer context from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing about parameters the description needs to explain. Per the rubric, zero parameters gets a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the action ('Forget') and the resource ('the selected foreground window'), and adds a meaningful qualifier ('without changing Hancom') that distinguishes it from document-mutating operations. It is not a pure tautology, though using 'disconnect' instead of the colloquial 'forget' would have been even clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to call this tool versus siblings like hwp_foreground_select_window, hwp_foreground_apply_preview, or hwp_foreground_status. The description implies a cleanup/disconnect action but never states the conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It communicates the core undo action but does not explain what happens if the document has changed, whether the operation is destructive or reversible, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. The core action and the key precondition are front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a required parameter that is completely unexplained and no annotations to clarify safety or failure behavior. An output schema exists, but the invocation semantics are still too incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the required `expected_revision` parameter at all. An agent has no information about what value to supply or why it matters.
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 states a specific verb ('Undo'), a specific resource ('HWP Live's immediately preceding change'), and a clear condition. It distinguishes this tool from the sibling tools, none of which are undo operations.
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 phrase 'if the document is unchanged' provides a clear precondition for when this tool should be invoked. It does not name alternatives or exclusions, but the condition itself is actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden and does a good job: it discloses server-side resolution, exclusion from the MCP response, experimental status, and lack of automatic read-back or Undo. It does not clarify whether the preview mutates the document or how conflicts are handled, but the disclosed caveats are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no padding. The primary action is front-loaded, followed by a privacy note and an experimental caveat, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is reasonably complete for an experimental preview tool and an output schema exists, but four required parameters remain under-explained and no guidance distinguishes this from sibling preview tools. The invocation semantics are not fully recoverable from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's silence. It only vaguely references a 'profile value' and 'user-confirmed foreground caret', leaving expected_revision, the exact boolean semantics of user_confirms_collapsed_caret, and the relationship between profile_id and key unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Preview a local profile value') and a precise context ('user-confirmed foreground caret'). It is clear enough to be recognized as distinct from generic preview tools, though it does not explicitly differentiate itself from the sibling hwp_preview_profile_insert.
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?
The intended use case is implied: previewing a local profile value at a foreground caret after user confirmation. However, the description does not explicitly say when to choose this tool over hwp_preview_profile_insert or hwp_foreground_preview_text, and no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden, and it does add meaningful behavioral details: the preview must be 'fresh' and exactly one is applied. However, it does not disclose side effects, whether previous previews are replaced, or what happens if no automation-owned document is visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and target while adding only meaningful modifiers like 'exactly one,' 'fresh,' and 'automation-owned.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists, so return values need not be explained. However, the required plan_id parameter is entirely unexplained, and the behavioral consequences of applying the preview are vague, leaving the description incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the description never mentions the required 'plan_id' parameter. An agent has no way to know what plan_id refers to, what format it should take, or where to obtain it.
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 ('Apply'), a well-scoped resource ('exactly one fresh preview'), and a precise target ('the visible, automation-owned document'). This clearly distinguishes it from sibling hwp_foreground_apply_preview, which targets a foreground window rather than an automation-owned document.
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 provides clear context for when the tool is appropriate: apply a single fresh preview when the document is the visible, automation-owned one. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that values never leave the local server, that the preview does not return the inserted values, and that a plan is returned for later approval, which implies no mutation is applied by this tool. It could still be more explicit about side effects or failure modes, but this is meaningful behavioral context beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each carrying necessary information: the action, the critical privacy/return behavior, and the required workflow. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The workflow ordering and behavior are well covered, and an output schema exists for return values. However, key parameters such as expected_revision, style, and new_paragraph_after are unspecified, so an agent still lacks enough parameter-level information to invoke the tool confidently in varied cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It alludes to choosing a 'local profile value' (likely profile_id and key) and the caret location, but it does not explain expected_revision, style, or new_paragraph_after, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb ('Preview inserting'), a resource ('one local profile value'), and a location ('current HWP Live caret'). It clearly identifies the tool's action but does not explicitly contrast with the hwp_foreground_preview_profile_insert sibling, so the distinction is carried by the name and 'local server' rather than stated.
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 an explicit sequence: first call hwp_read_context, place or confirm the caret, then get approval before applying the returned plan. This tells an agent exactly when and in what order to use it, though it does not mention alternatives or exclusions such as when to choose the foreground counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that the tool never saves or closes a document, has no read-back, and no automatic Undo. It could add more about the selected-window prerequisite, but the core side effects are clearly surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler: the main action comes first, and the important caveats follow immediately. Every sentence earns its place.
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?
For a single-parameter tool with an output schema, the description covers the key behavioral safety points and when to invoke it. The main gap is the origin and meaning of plan_id, but the overall guidance is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain plan_id at all, and the input schema only provides 'Plan Id' as a title with 0% schema description coverage. Since coverage is low, the description needed to compensate but did not, leaving an agent to infer that plan_id identifies the plan to apply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: activate the selected Hancom window and type exactly one fresh foreground preview. It names a specific verb and resource, and the 'foreground' qualifier helps separate it from generic apply-preview siblings, though it does not explicitly contrast them.
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 clear usage timing: use only after the user has approved the preview, and it warns that there is no automatic Undo. It does not explicitly name alternatives such as hwp_apply_preview, but the condition and restriction are explicit enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and clearly discloses two important traits: the tool cannot read the document and cannot verify selection state. It also implies the preview is user-dependent. It does not explicitly state non-destructive behavior, but 'preview' plus its contrast with apply tools makes that reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences; the core operation is front-loaded and the caveat earns its place. There is no filler or repetition.
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?
For a narrow preview tool with an output schema, the description is largely complete: it names the target window, the action, and the critical user-confirmation requirement. The main holistic gap is the unexplained expected_revision parameter, which is already reflected in the parameter-semantics score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'text' and instructs when to set user_confirms_collapsed_caret, but says nothing about expected_revision, leaving a required parameter undefined for the agent.
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?
States a specific verb ('Preview'), resource ('literal text'), and location ('user-confirmed caret in the selected window'). The phrase 'literal text' sets it apart from sibling preview/edit/insert tools without needing to open their schemas.
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?
Description gives an explicit precondition: the user must confirm one collapsed caret rather than a selection, and it warns the mode cannot verify this itself. It does not enumerate alternative siblings or when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and uses it well: it discloses non-mutation (does not activate or edit), the short-lived nature of candidates, and the explicit user identification requirement. It does not detail what happens to any previously selected candidate, but this is a minor gap for a single-selection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences each carry distinct information: the first states the action, the second clarifies non-effects and the required user precondition. No filler or redundant restatement of the tool name.
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?
For a simple one-parameter selector with an output schema, the description covers what the tool does, what it does not do, and the key precondition. The main remaining omission is pointing the agent to the sibling listing tool that produces candidate_id, which is inferable from 'listed window' but not explicit.
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 coverage is 0%, so the description must compensate. It implies candidate_id refers to a listed 'candidate' for a Hancom window and ties it to the 'desired listed window', but it never explicitly says candidate_id comes from hwp_foreground_list_windows or describes its format/expiry semantics.
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 opening sentence names a specific verb ('Select'), a resource ('short-lived Hancom-window candidate'), and the intended effect ('for foreground typing'). It also distinguishes itself from activation/editing tools by explicitly stating it does not activate or edit the window.
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 sets a clear precondition—the user must explicitly identify the desired listed window and active tab before selection—and warns that this tool does not activate or edit. It does not name sibling tools like hwp_foreground_apply_preview as alternatives, so it stops short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure, and it does: it states the tool does not launch Hancom, edit a document, or access a user file, making its non-destructive, side-effect-free nature explicit. It does not define what 'ready' means, but the output schema can carry the return semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the key verb and resource front-loaded. Every sentence adds information: the first states the operation, the second explicitly rules out side effects.
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?
For a zero-parameter status tool with an output schema, the description is essentially complete for selecting the tool. The only gap is more explicit usage timing or a pointer to hwp_foreground_status for the foreground-window status variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no meaningful parameter information to add. Schema description coverage is 100% and baseline for no-parameter tools is 4; the description correctly avoids inventing parameter details.
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 ('Check') and a precise resource ('local Hancom 2022 automation bridge'), and clarifies it is a status/readiness operation. The negative clauses explicitly separate it from launch/edit/file-access behaviors, which distinguishes it from editing/launching sibling tools.
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?
The intended use is implied: call it to verify the automation bridge is ready before other operations. However, it does not explicitly state when to use it instead of hwp_foreground_status or other siblings, nor does it mention any alternatives by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool lists visible window titles, does not read or edit content, and warns that titles can reveal file names. This is meaningful behavioral context beyond the bare name, though it does not discuss return value structure or any system-level effects—acceptable given the zero-parameter, non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states exactly what the tool does, and the second adds the necessary privacy and usage caveat. No sentence is wasted, and the length is proportionate to the tool's trivial input schema.
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?
For a zero-parameter listing tool with an output schema present, the description covers the core behavioral contract: what it lists, what it does not do, and when it should be called. It is slightly terse around what 'experimental typing choice' means in practice, but the output schema handles return-value details, and the caveat about sensitive file names is strong contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description makes clear that the tool requires no input and simply lists visible windows. There is no parameter documentation burden for the description to carry.
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 opens with a specific verb and resource: 'List visible Hancom window titles.' It clearly distinguishes itself from read-only and editing tools by stating it does not read document text or edit anything, and the purpose—supporting an explicit experimental typing choice—sets it apart from sibling tools like hwp_foreground_status or hwp_foreground_select_window.
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 an explicit condition for use: 'call it only when the user asks to target an already-open Hancom window and is comfortable identifying it.' It also implies when not to use it by clarifying it does not read or edit. It does not name alternative tools or give exclusions beyond the privacy caveat, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states the operation does not touch Hancom, which is a valuable side-effect guarantee for an agent deciding whether to invoke it. It does not detail what exactly the state contains, but the existence of an output schema partially covers the return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the action and resource, then adds the critical non-mutating qualifier. Every word earns its place, with no filler or repetition.
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?
For a zero-parameter status tool with an output schema, the description is nearly complete: it identifies the operation's purpose and its key safety property. It could be slightly more explicit about what 'experimental foreground-typing session state' means, but the sibling context and output schema provide enough grounding for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is fully covered (100%), so there is nothing meaningful for the description to add. The baseline of 4 applies because no parameter documentation is needed.
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 uses a specific verb ('Show') and names the exact resource ('experimental foreground-typing session state'), clearly distinguishing this status check from the more general hwp_status sibling. It also adds the important qualifier 'without touching Hancom,' which reinforces the non-invasive nature of the operation.
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 phrase 'without touching Hancom' implies this is a safe, side-effect-free inspection tool, giving the agent a clear reason to prefer it when only status information is needed. However, it does not explicitly name alternatives or state when not to use it, though the sibling list suggests hwp_status may serve a broader purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of disclosure. It states the preview is non-mutating and has a 60-second lifetime, and it describes the required user-approval ordering before hwp_apply_preview. It does not discuss stale-revision failures or expiry handling, but the key behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: one states what the tool does, and two state the required workflow. There is no filler, and the core constraint (non-mutating, 60-second) is front-loaded.
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?
For a two-parameter tool with an output schema and related siblings, the description covers the full intended sequence and constraints. It could add a note about preview expiry or stale revisions, but as-is it gives an agent enough to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Top-level schema coverage is 0%, so the description must compensate. It maps edits to text or table insertions and maps expected_revision to the revision obtained from hwp_read_context. The nested schema definitions fill in remaining structure, so both required parameters gain useful meaning.
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 begins with a specific verb (create), object (preview), scope (text or table insertions), and key constraint (non-mutating, 60-second). It clearly positions this as the preview step in a read-preview-apply workflow, distinguishing it from hwp_apply_preview and hwp_read_context.
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 workflow guidance: call hwp_read_context first and pass its revision, show the preview, obtain user approval, and then call hwp_apply_preview. This is clear context for when to use the tool, though it does not spell out exclusions against siblings like hwp_preview_profile_insert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It clearly states the read-only behavior and the expected output ('text' and 'revision'). It does not cover error cases like when no document is open, but for a simple 0-parameter read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and resource, then states the return value. There is no wasted wording or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with an output schema present, the description is complete: it identifies the exact source ('current unsaved document'), the operation ('read text'), and the result ('return its revision'). No additional information is needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to explain. The description correctly focuses on behavior instead of inventing parameter details.
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: it reads text from HWP Live's current unsaved document and returns its revision. This clearly distinguishes the tool from siblings like hwp_status or hwp_foreground_preview_text by targeting the current unsaved document context.
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 phrase 'current unsaved document' gives clear context for when to use this tool: when the agent needs the text of the active unsaved HWP Live document. It does not explicitly name alternatives or exclusions, but the intended usage is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses a key side effect (launching Hancom), the ownership of the created document (HWP Live), and the non-destructive guarantee that it will not attach to or modify an existing user document. It does not mention every UI/focus side effect, but for a zero-parameter launcher this is solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core action in the first sentence. The second sentence earns its place by clarifying the tool's boundary relative to existing documents. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity, parameterless tool with an output schema present. The description covers what the tool does, the important non-destructive boundary, and is sufficient for an agent to decide to invoke it. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter burden for the description to carry. The baseline of 4 applies because there is nothing ambiguous for an agent to resolve.
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 uses a specific verb and resource: 'Launch Hancom and create a brand-new unsaved document owned by HWP Live.' The added boundary, 'never attaches to or changes an already-open user document,' makes its purpose clear and distinguishes it from the foreground/preview editing siblings.
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 clearly signals when to use the tool: when a fresh, unsaved HWP Live document is needed. It also states what it will not do ('never attaches to or changes an already-open user document'), though it does not name explicit alternatives such as hwp_apply_preview or hwp_foreground_apply_preview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, and it handles it well. It explicitly promises no Hancom launch, no document read, and no profile write, and clarifies that the returned data are only labels and configuration flags, never values. This effectively communicates a read-only, non-destructive behavior profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The primary behavior is stated in the first sentence, and the second paragraph adds necessary boundary conditions without repetition or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema already present, the description covers invocation expectations, data scope, and non-effects. Nothing needed to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so there is nothing for the description to add at the parameter level. The description does add semantic value by clarifying the scope of the listing: labels and configured status, not values. The 0-parameter baseline of 4 is appropriate.
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 uses a specific verb ('List') and a precise resource ('configured local profile keys'), and adds a hard constraint ('without returning any profile value'). The negative clauses ('does not open Hancom, read a document, or write a profile') separate it from the read/write sibling tools even though no sibling is named.
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 clearly establishes exclusions: it is not for opening Hancom, reading a document, or writing a profile, and if actual profile values are needed this tool is inappropriate because it only exposes labels and configured status. It does not explicitly name an alternative tool for obtaining profile values, so it falls just short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hwp-live-safe MCP server](https://glama.ai/mcp/servers/Jasujung99/hwp-live-safe/badges/card.svg)](https://glama.ai/mcp/servers/Jasujung99/hwp-live-safe)

Score Badge

Copy to your README.md:

[![hwp-live-safe MCP server](https://glama.ai/mcp/servers/Jasujung99/hwp-live-safe/badges/score.svg)](https://glama.ai/mcp/servers/Jasujung99/hwp-live-safe)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Jasujung99/hwp-live-safe'

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