Skip to main content
Glama
saidsef

GitHub PR Issue Analyser

by saidsef

Github Set Assignees

github_set_assignees
Idempotent

Set assignees for a GitHub issue or pull request by providing repository details, issue number, and a list of usernames.

Instructions

Updates the assignees for a specific issue or pull request.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assigneesYes
repo_nameYes
repo_ownerYes
issue_numberYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv42.0.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already convey mutability, idempotence, and non-destructiveness, so the description only needs to add behavioral context. It correctly says 'Updates' but does not disclose whether the assignee list replaces existing assignees, appends to them, or how an empty array behaves.

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

Conciseness5/5

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

The description is a single sentence with no filler or redundant information. It is front-loaded with the action and target, making it easy for an agent to process quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple tool with an output schema and annotations covering safety, the description is minimally viable. However, because the schema has no parameter descriptions and the description adds little detail, an agent may not know key semantics like replacing assignees or expected username format.

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 description coverage is 0%, so the description must compensate by explaining parameters. It only references 'assignees' and 'issue or pull request' generically, leaving repo_owner, repo_name, issue_number, and the expected format of assignees (e.g., GitHub usernames) to inference.

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 uses a specific verb ('Updates') and names the exact resource ('assignees for a specific issue or pull request'). It clearly distinguishes this tool from sibling tools like github_set_issue_milestone or github_set_pr_draft.

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 intended use is implied: use this tool when assignees need to be changed on a GitHub issue or pull request. However, it does not explicitly mention alternatives or state when not to use it, such as using github_update_issue for other issue fields.

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