Loading ToolBench
Unofficial MCP server: knowledge and codegen assistant for the Partner Center REST API (not affiliated with Microsoft)
Partner Center MCP has 29 tools with consistent naming (pc_* prefix, verb-first pattern) and comprehensive descriptions (avg 150+ chars). All tools are READ_ONLY with clear risk classification. However, input schemas are inferred from TypeScript code rather than explicitly visible in JSON Schema format. Parameter descriptions exist but lack formal type constraints (enums, ranges, patterns). Output schemas are not documented. Error handling is minimal, tools return generic objects without recovery guidance. The server demonstrates domain expertise but lacks production-grade schema rigor and error classification.
Current Partner Center authentication guidance for app-only or app+user, per national cloud, with deprecation and MFA notes.
Build a ready-to-send request for a scenario: substitutes path placeholders from params, fills headers (Bearer + generated MS-RequestId on writes), and produces a body skeleton from the scenario's required fields.
Lint a Partner Center auth/client snippet for retired patterns (graph.windows.net, ADAL, archived SDK, AzureAD PS) and return fixes.
Paste a Partner Center error response (JSON or text). Decodes the error code with causes + remediation, links scenarios, and surfaces the correlation id.
Diagnose a Partner Center API problem by symptom.
What changed between releases of this knowledge pack, newest first: scenarios added, removed, or whose route, auth, headers, fields, response shape or documented constraints moved. Re-verifying a scenario is not a change. For Microsoft's own deprecation deadlines use pc_whats_new.
Input schemas not explicitly visible in JSON Schema format. Parameter types and constraints are inferred from TypeScript code (e.g., DataTools.cs shows string? parameters) but not formally declared in tool registration. This prevents LLMs from understanding valid enum values, ranges, or patterns without reading descriptions.
Output schemas are not documented. Tools return objects (e.g., GetEnums returns a list with 'name', 'description', 'count' fields) but the response structure is not declared in tool metadata. LLMs cannot plan downstream calls or extract required fields without trial-and-error.
Error handling lacks recovery guidance. Tools return generic error objects (e.g., 'No enum named X') without actionable next steps. No error classification (retryable vs user-fixable vs fatal). LLMs cannot determine whether to retry, ask the user, or abandon the operation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
The subscription lifecycle state machine: which operations (increase-seats, decrease-seats, upgrade, cancel, renew-change, suspend, reactivate, migrate, transfer) are legal from which state, the field to read off the live subscription before attempting each one, the scenario that performs it, and the errors a failed precondition returns. Omit operation for the whole machine.
Explain Partner Center policies and documented rules.
Generate a current Partner Center REST call for a scenario in curl/csharp/typescript/powershell, with per-scenario notes. Never emits the archived .NET SDK.
Look up Partner Center enum values (billingCycle, termDuration, targetView, segment, transitionType, subscriptionStatus, qualification, agreementType, billingType, provisioningStatus). Omit name to list all.
Partner Center REST reference: base-urls, headers, versioning, sandbox, rate-limits, national-clouds.
Field dictionary for Partner Center resources (Customer, Subscription, Order, Invoice, CartLineItem). Omit name to list all.
Full detail for one Partner Center scenario by id: method, path, headers, examples, gotchas.
List supported Partner Center REST scenarios, optionally filtered by area.
Decode a Partner Center REST error by error code: meaning, causes, remediation, related scenarios.
Translate archived Partner Center .NET SDK code into the equivalent current REST scenario(s).
The ordered CSP (Cloud Solution Provider) onboarding workflow.
The ordered GDAP (Granular Delegated Admin Privileges) onboarding workflow.
The ordered order lifecycle workflow.
For any scenario, the ordered calls that produce the ids its path needs, plus the parameters you supply yourself. Answers "I want to call this, what do I need first" for every operation in the pack. For a business sequence and its preconditions prefer the curated pc_plan_* workflows.
The ordered New Commerce purchase workflow: product -> SKU availability -> cart -> checkout -> subscriptions.
The ordered reconciliation workflow (v1 to v2 API migration).
The ordered subscription change workflow (increase-seats, decrease-seats, upgrade, cancel, renew-change, suspend, reactivate, migrate, transfer).
The ordered subscription transfer workflow (from one partner to another).
The ordered user offboarding workflow.
The ordered user onboarding workflow.
Search Partner Center documentation by keyword.
Lint a Partner Center REST call (method, URL, headers, auth) against the known scenarios.
Partner Center API deprecations and deadlines (MFA enforcement, graph.windows.net retirement, DAP->GDAP, v1->v2 reconciliation, SDK/ADAL retirements) with dates and the action to take.
Parameter descriptions lack formal constraints. E.g., pc_get_reference accepts 'topic' as a free-form string with description 'base-urls|headers|...' but no enum constraint. pc_whats_new 'status' parameter lists valid values in description text, not as an enum. LLMs may hallucinate invalid values.
Tool composition: 29 tools with overlapping concerns (e.g., pc_lookup_error, pc_decode_error, pc_diagnose all address error handling). No clear guidance on which to call for a given scenario. LLMs waste reasoning cycles choosing between similar tools.