Skip to main content
Glama
Sign In
Review Helper

Review Helper

by antoinebou12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

Provider sign-in

provider_connection

Start, poll, check, or clear local Azure DevOps and GitHub sign-in; returns user codes or status without exposing access tokens.

Instructions

Manage local Azure DevOps or GitHub sign-in; return user codes or status, never access tokens.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "provider": "<provider>",
      "action": "<action>"
    },
    "name": "provider_connection"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYesRead connection state, start user-initiated login, check completion, or clear local credentials.
login_idNoOpaque login ID returned by start; required for poll.
providerYesazure for Microsoft Entra, github for GitHub.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, but say nothing about credential handling. The description adds genuinely useful behavioral context beyond that: the credential store is local, the tool surfaces user codes or status, and it never returns access tokens — a security-relevant guarantee an agent cannot infer from structured fields. It does not explain side effects such as what logout removes, so it is short of a 5.

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?

A single front-loaded sentence with no filler, and the most important constraint (no access tokens) sits at the end where it still reads clearly. It is efficient, though the extreme brevity leaves the agent to derive the multi-step login flow from the schema alone.

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?

With no output schema, the description carries the burden of describing returns, and 'user codes or status' is thin for a poll/start flow where the agent needs to know what completion looks like. The security guarantee and local scope help, but side effects of logout and the polling cadence/expiry of user codes are unaddressed for a non-idempotent, open-world tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each action and provider value already documented in the input schema, so the baseline is 3. The description only reinforces that outputs are user codes or status. It adds no syntax, format, or pairing guidance (e.g., that login_id comes from a prior start) beyond what the schema states.

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

Purpose4/5

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

The description states a specific verb and resource: managing local Azure DevOps/GitHub sign-in, with the return payload characterized (user codes or status, no access tokens). It clearly does not overlap with the review/workspace siblings. It stops short of naming where the boundary lies relative to any auth-related alternative, but the domain is unambiguous.

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?

No explicit when-to-use or when-not-to-use guidance, and no alternatives are named. Usage is only implied by 'Manage local ... sign-in' plus the action enum in the schema (status, start, poll, logout), which the agent must read to figure out the workflow. Adequate but the sequencing (start then poll) is left to the schema.

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

Deploy Server

Other Tools