Skip to main content
Glama

lawmadi-os

by io.github.peter120525-cmd

chat_leader

특정 리더와 1:1로 대화합니다. get_leaders에서 얻은 leader_id(예: 'L01', 'L32', 'CCO')를 넘기세요. 하루 무료 5회를 넘기면 추가 이용에 크레딧이 듭니다 — 그때는 비용을 알려 주는 응답이 오고, confirm: true 로 다시 부를 때만 차감합니다(기본값 false, 확인 없이는 절대 차감하지 않습니다). / Chat 1:1 with a specific legal leader. Provide the leader_id (e.g. 'L01', 'L32', 'CCO') from get_leaders. Past the free daily allowance the call returns the exact cost; credits are spent only when you retry with confirm: true (default false).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesQuestion to ask the leader (max 2000 chars).
confirmNoSpend credits when the free daily allowance is used up. Default false — nothing is ever charged without this. Only set it after a call returned status 'payment_required' telling you the cost.
leader_idYesLeader identifier (e.g. 'L01'). See get_leaders.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Spend credits when the free daily allowance is used up. Default false — nothing is ever charged without this. Only set it after a call returned status 'payment_required' telling you the cost.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so well. It discloses the daily free allowance, the cost-return behavior, and that credits are never deducted unless confirm=true (default false). This is exactly the side-effect and cost behavior an agent needs.

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 content is front-loaded with purpose, then parameter guidance, then cost behavior. However, the full description is duplicated in Korean and English, which adds unnecessary length even if it may support bilingual users.

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?

The description covers the critical invocation details and charging workflow. It does not describe what a successful response contains, but for a chat tool this is low-risk and the absence of an output schema makes that less critical.

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?

Schema coverage is 100%, so the schema already documents all parameters. The description adds value by tying leader_id to get_leaders and giving rich semantics for confirm: only set after payment_required, never charged by default.

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 action: chat 1:1 with a particular legal leader, and requires a leader_id obtained from get_leaders. This clearly differentiates it from generic ask/ask_expert tools even though those siblings are not 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?

It gives explicit context: use a leader_id from get_leaders, and it explains the confirm flow for paid usage. It does not explicitly name alternatives or state when not to use this tool, but the leader-specific guidance is sufficient for selection.

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

All lawmadi-os toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools target clearly distinct resources (statutes, precedents, bar exam, documents, content, account), and cross-references in descriptions explicitly disambiguate similar actions like search vs lookup_statute vs lookup_precedent. A few close pairs exist (ask vs ask_expert, latest_content vs get_daily_content, bar_exam_search vs get_exam_answer), but each pair has clear differentiators.

Naming Consistency4/5

The set predominantly follows snake_case verb_noun naming (get_account, lookup_statute, verify_citations, generate_document). Minor deviations like latest_content (no verb) and bar_exam_search (noun-first) break the pattern, but the overall convention is readable and predictable.

Tool Count4/5

At 19 tools, the surface is on the heavier side but each tool addresses a distinct need across a broad legal domain (Q&A, research, document generation, bar exam corpus, content, account management). The count feels justified for the stated scope, though it approaches the upper boundary of reasonable.

Completeness4/5

The server covers the main legal workflows well: Q&A (ask, chat_leader), research (lookup_statute, lookup_precedent, search, verify_citations), document drafting (generate_document), and bar exam prep (bar_exam_search, get_exam_answer). Minor gaps exist, such as no browse/list-all endpoints for statutes or precedents and no way to manage generated documents, but agents can work around these.

Resources