Skip to main content
Glama

未决问题

get_unresolved

Retrieve unresolved questions and issues raised in a conversation so agents can revisit open tasks. Use heuristics to surface items not yet addressed, with optional project scoping.

Instructions

会话中提出但(启发式判定)未解决的问题

Input Schema

NameRequiredDescriptionDefault
limitNo
projectNo项目根绝对路径。仅当服务端提示 unresolved_project(多项目/未自动识别)时选择传此参;传一次后本连接记住

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the entire behavioural burden. It does disclose one non-obvious trait, that 'unresolved' is a heuristic judgement rather than ground truth, but it says nothing about read-only nature, default scoping (current session vs. all sessions), ordering, or what an empty result means.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short sentence with no filler, so it is concise, but it is under-specified rather than efficient — the heuristic caveat is worth keeping, yet the sentence spends its only clause on it and never establishes the action or scope.

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?

With no annotations, no output schema, half-documented parameters, and a session-scoping question left unanswered, the definition is not sufficient for an agent to call this tool confidently. The heuristic caveat is a good start but leaves most of the operational picture missing.

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 coverage is only 50%, and the description adds no parameter information at all. `limit` is undocumented in both schema and description (no default, no max, no semantics), and while `project` has a schema description, the description does not reinforce or explain how scoping changes the results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (issues raised in a session that remain unresolved) and adds a useful qualifier that resolution is heuristic, but it is a noun phrase with no verb and no differentiation from siblings such as get_decisions or search_sessions. An agent can roughly infer what it returns, yet it cannot tell confidently what it does versus the neighboring retrieval tools.

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 statement of when to use this tool, when not to, or which sibling to prefer for resolved items, decisions, or broader session search. The only usage hint in the whole definition lives in the schema for `project` (pass it when the server signals unresolved_project), not in the description itself.

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