Retrieve or search recent pull requests, ranking by relevance if a query is given, otherwise by date. Indexed PR text and review comments help identify who recently changed code.
최근 Pull Request 목록/검색 (github_prs 커넥터 필요). query를 주면 관련도순, 없으면 최신순. PR 본문·리뷰 코멘트가 인덱싱되어 있어 "이거 최근에 누가 건드렸지" 류 질문에 답한다.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| query | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations means the description carries the full burden. It discloses a runtime dependency (github_prs connector), the ordering switch with/without a query, and the fact that PR body and review comments are indexed. These are non-obvious facts that help the agent predict behavior, although it omits pagination, auth, and output-shape details (which are partly covered by the output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The two Korean sentences are efficient and front-loaded: they state the operation, sort behavior, connector requirement, and use case in 28 words. No word is wasted, and the value proposition is immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no required params, defaulted ints, output schema available), the description covers the core commissioning: recent issue, query ordering, connector dependency. The only noticeable gap is that it never ties the recent window to the days parameter or explains the limit parameter, but the schema defaults and the output schema make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must give meaning to the three parameters. Only query is actually explained in terms of relevance ordering and indexed content; days and limit are left to their schema defaults with no unit or scope explanation. With low coverage and 3 params, the description should compensate more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '최근 Pull Request 목록/검색', a clear verb/resource pair, and differentiates it from PR-related tools by specifying recentness and relevance sorting. The keyword-search semantics also make it distinguishable from siblings like search_code, search, and recent_changes, meeting the strongest standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use the tool: for recent-PR questions ('who touched this recently') and it explains that the query parameter changes the result order from latest to relevance. It does not name alternatives or exclusions, but the context is clear enough to select it over generic search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.