Skip to main content
Glama
Sign In
MisarBlog MCP Server

MisarBlog MCP Server

by Misar-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Log in via browser

login

Authenticate with your Misar.Blog account through a browser to review permissions, authorize this client, and save the returned API key locally without copy-pasting.

Instructions

Authenticate with your Misar.Blog account via browser — no API key copy-paste needed. Opens the Misar.Blog authorization page where you review the requested permissions and click 'Authorize'. Your API key is delivered straight back to this client and saved to ~/.misarblog/config.json.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "login"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNoLocal callback port (9001–9099). Random by default.
forceNoForce re-authentication even if already logged in (rotates your API key).
base_urlNoMisar.Blog base URL for self-hosted instances.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv5.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changedv5.1.3
    • changedInput schema / properties / base_url / description
      Previous value: -"Base URL of a self-hosted Misar.Blog. Omit for the hosted service."New value: +"Misar.Blog base URL for self-hosted instances."
    • changedInput schema / properties / force / description
      Previous value: -"Re-authenticate even when already logged in. This ROTATES the API key and breaks any other client using the old one — only on explicit request."New value: +"Force re-authentication even if already logged in (rotates your API key)."
    • changedInput schema / properties / port / description
      Previous value: -"Local port for the one-shot callback listener, 9001-9099. Random by default; set it only when a firewall requires a fixed port."New value: +"Local callback port (9001–9099). Random by default."
  3. Changed3 schema fields changedv5.1.0
    • changedInput schema / properties / base_url / description
      Previous value: -"Misar.Blog base URL for self-hosted instances."New value: +"Base URL of a self-hosted Misar.Blog. Omit for the hosted service."
    • changedInput schema / properties / force / description
      Previous value: -"Force re-authentication even if already logged in (rotates your API key)."New value: +"Re-authenticate even when already logged in. This ROTATES the API key and breaks any other client using the old one — only on explicit request."
    • changedInput schema / properties / port / description
      Previous value: -"Local callback port (9001–9099). Random by default."New value: +"Local port for the one-shot callback listener, 9001-9099. Random by default; set it only when a firewall requires a fixed port."
  4. First observedv2.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses meaningful behavior: it opens an external authorization page, requires the human to review permissions and click 'Authorize', and persists the resulting key to ~/.misarblog/config.json. That file-write location and the interactive/blocking nature of the flow are exactly what annotations can't convey. It stops short of saying what happens on timeout or denial, or that the key rotation risk lives behind `force`.

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?

Three short sentences in a logical order: what it does, what the user will see, where the result lands. Slightly promotional framing ("no API key copy-paste needed", "delivered straight back to this client") but it carries useful contrast and nothing is redundant.

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 three-optional-parameter, no-output-schema tool, the description covers the flow, the human interaction, and the credential persistence — enough to call it correctly. The remaining gap (failure/denial behavior, and the fact that `force` rotates an existing key) is either minor or already handled by the schema.

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 description coverage is 100%, so port, force, and base_url are already fully documented with ranges and defaults; the description adds no parameter-level meaning such as when to override the port or set base_url. Baseline 3 applies because the schema does all the work here.

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 and resource ("Authenticate with your Misar.Blog account") and immediately names the mechanism ("via browser"), which cleanly separates it from every sibling tool — none of which is an auth flow. An agent can tell that this is the entry-point/credential tool without inspecting any schema.

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 phrase "no API key copy-paste needed" implies this is the setup path for getting credentials, but the description never states when to call it (first run, expired config, 401 error) or when to prefer it over checking `status` first. No explicit exclusions or prerequisites are given.

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

Deploy Server

Other Tools