feat: [UX/RFC] Redesign AssemblyMCP tool experience using KoreaLawMCP patterns#61
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the project status and introduces a comprehensive UX redesign plan (docs/UX_REDESIGN_PLAN.md) for AssemblyMCP under Issue #60, aiming to transition the toolset into a workflow-oriented legislative research product. The reviewer feedback focuses on refining the proposed tool contracts to make them more robust for LLM consumption, specifically by suggesting an optional target_type parameter for legislative_impact_map, expanding the parameters of watch_action_plan to support specific bills or committees, and introducing structured schemas for verify_legislative_claims.
| ### `legislative_impact_map(target)` | ||
|
|
||
| User job: "What is connected to this bill/topic/member/committee?" | ||
|
|
||
| This should return structured relations, not just prose. | ||
|
|
||
| Target types: | ||
|
|
||
| - `topic` | ||
| - `bill` | ||
| - `member` | ||
| - `committee` |
There was a problem hiding this comment.
In legislative_impact_map(target), using a single target parameter can lead to ambiguity when resolving the entity type (e.g., a keyword/topic that matches a member's name or a committee). To make the tool contract more robust for LLMs, consider adding an optional target_type parameter (e.g., Literal["topic", "bill", "member", "committee"]) or explicitly defining the resolution order/heuristics in the tool's system prompt.
| ### `legislative_impact_map(target)` | |
| User job: "What is connected to this bill/topic/member/committee?" | |
| This should return structured relations, not just prose. | |
| Target types: | |
| - `topic` | |
| - `bill` | |
| - `member` | |
| - `committee` | |
| ### legislative_impact_map(target, target_type=None) | |
| User job: "What is connected to this bill/topic/member/committee?" | |
| This should return structured relations, not just prose. | |
| Inputs: | |
| - target: str | |
| - target_type: str | None = None (topic, bill, member, or committee) |
| ### `watch_action_plan(topic)` | ||
|
|
||
| User job: "How should I keep tracking or responding to this issue?" | ||
|
|
||
| This is the AssemblyMCP-native version of KoreaLawMCP's `action_plan`. It should | ||
| not give legal advice. It should give legislative monitoring steps. | ||
|
|
||
| Steps: | ||
|
|
||
| 1. Normalize topic and alternate keywords. | ||
| 2. Identify relevant bills and committees. | ||
| 3. Identify meeting/schedule sources to monitor. | ||
| 4. Identify voting/report signals. | ||
| 5. Provide next queries and tool calls. |
There was a problem hiding this comment.
The watch_action_plan(topic) tool is currently designed to accept only a topic. However, users often want to track the progress of a specific bill (e.g., 'How do I track Bill No. 2200001?') or a specific committee's schedule. Consider expanding the input parameters to accept optional bill_id or committee_name fields, or renaming the parameter to target (similar to legislative_impact_map) to support tracking specific legislative entities.
| ### Tool: `verify_legislative_claims(citations_or_text)` | ||
|
|
||
| This should verify structured citations and eventually free-form text. | ||
|
|
||
| Supported claim types: | ||
|
|
||
| - `bill`: bill title, `BILL_ID`, or `BILL_NO` | ||
| - `member`: member name | ||
| - `committee`: committee name or code | ||
| - `vote`: bill vote count/result claim | ||
| - `meeting`: committee/date/bill meeting claim |
There was a problem hiding this comment.
For verify_legislative_claims(citations_or_text), parsing free-form text or mixed citations can be highly complex and prone to errors. To improve reliability, consider defining a structured input schema (e.g., allowing a JSON-serialized list of structured claim objects) alongside the free-form text input. Additionally, defining the expected structured output schema for the verification results (e.g., status, expected value, actual value, and failure markers) would help the LLM process the verification results programmatically.
|
Closing this planning-doc PR. The UX redesign should be tracked as Gira/GitHub issues first rather than merging a PRD-style document into the open-source repo. Follow-up implementation will be split into smaller tickets under #60. |
StatPan
deleted the
issue-60-ux-rfc-redesign-assemblymcp-tool-experience-using-korealawmcp-patterns
branch
1 participant
Summary
Follow-up
Related to #60