get tools working - #11
Merged
Merged
Conversation
This was referenced Oct 8, 2024
Merged
Merged
Merged
Merged
Merged
jspahrsummers
approved these changes
Oct 9, 2024
| {key} | ||
| </Label> | ||
| <Input | ||
| type={value.type === "number" ? "number" : "text"} |
Member
There was a problem hiding this comment.
Probably useful to at least handle booleans as well, by rendering a checkbox. (This could be a follow-up though)
cliffhall
added a commit
that referenced
this pull request
Apr 11, 2026
The interfaces doc was produced by parallel research subagents that were instructed to prefix uncertain hook names with (likely) rather than fail to fill in a section. The result is 52 instances of "likely" in v2_ux_interfaces.md, almost all attached to hook names that were never cross-checked against v1.5/main. Several are actively wrong: - useTools / usePrompts / useResources do not exist in v1.5; the actual hooks are useManagedTools / useManagedPrompts / useManagedResources. - useTasks does not exist; v1.5 has useManagedRequestorTasks (and Task itself is a raw SDK 1.x type, not an Inspector wrapper). - useMcpClient does not exist; v1.5 has useInspectorClient. - useLogs conflates three v1.5 hooks: useMessageLog, useStderrLog, useFetchRequestLog. - useHistory does not exist; v1.5 uses useMessageLog as the history. - useElicitation / useSampling / useRoots do not exist as discrete React hooks in v1.5; those flows are handled inside InspectorClient via SDK request handlers. - useServerCapabilities is not a separate hook; capabilities live on useInspectorClient's result. - Appendix A's "v1.5 bundles primitive logic in App.tsx" claim is wrong about v1.5 in this repo; that's true of upstream modelcontextprotocol/inspector v1.x mainline, not v1.5/main here, which has the full core/react/* split. Adds Phase 0.3 to walk every (likely) instance and either resolve it against v1.5 source or strike it, with a confirmed rename table and explicit definition-of-done (zero "likely" matches in v2_ux_interfaces.md after the pass). Adds Risk #11 capturing the underlying rule: hedging words next to type/hook/file claims must be vetted before a planning doc ships. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This was referenced Jul 27, 2026
cliffhall
added a commit
that referenced
this pull request
Aug 1, 2026
Board #11 had the same gap as #28 — no state for "filed but not yet triaged" — so a v1 security-fix issue had nowhere to sit that didn't assert maintainer approval. Adds Incoming there too. AGENTS.md carried no v1 board recipes at all, only a link, so anyone boarding a v1 issue had to discover the project and field ids by hand and was liable to reach for #28's (which are rejected, but only after the attempt). Adds a V1 board section with its ids, states that Incoming is the default status for new items on both boards, and notes that Priority is v2-only — #11 has no such field. The Incoming option was added with all four existing option ids echoed back, and a before/after item-list diff confirms all 74 cards kept their Status. Three cards on #11 carry no Status; that predates this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU
cliffhall
added a commit
that referenced
this pull request
Aug 1, 2026
) Copilot review on #1892 flagged three places that still read as Status-only now that the section covers Priority too: - the version-label bullet said a v2 issue needs "a board card with a Status"; it needs a Status and a Priority (v1 needs only a Status, since board #11 has no Priority field) - the updateProjectV2Field hazard said a bad edit "orphans the Status of every card"; it orphans whichever field was edited - the recovery recipe is genuinely Status-specific (reads .status, writes the Status field id), so say so and give the two substitutions for a Priority deletion Verified `gh project item-list --format json` exposes both .status and .priority before documenting the .priority swap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU
cliffhall
added a commit
that referenced
this pull request
Aug 1, 2026
…ocument the triage rubric (#1892) * docs: add Incoming board status, adopt Priority field, document triage rubric (#1891) Board #28 had no state for "filed but not yet triaged" — Todo means maintainer-approved, so parking unreviewed issues there falsely asserted sign-off. Adds an Incoming status ahead of Todo. The board's Priority single-select existed but was unused (0 of 264 cards) and undocumented, with P0/P1/P2 options matching no vocabulary in the repo. Re-optioned to Urgent/High/Medium/Low and documented alongside Status. Completes the priority rubric: fills in the score bands (12+/9-11/6-8/<=5), expands both axes into scored tables, and fixes the truncated signal-indicator line. Severity alone tops out at High by design. Also drops the "V2 Go Live" status reference — that option is not in the field's option list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU * docs: correct the Done option id and harden the deleted-column guidance (#1891) The Done Status option was deleted from board #28, blanking the Status of all 247 cards that held it. Restored from a pre-change item-list snapshot; verified all 247 are Done again and no other card was disturbed. A recreated option never regains its old id, so Done is now 259d6aab rather than 248a3910 — updated in the option table and the merge step. The hazard callout recommended the web UI as the safe path, which is what made this look safe. It is not: deleting an option blanks its cards in the UI exactly as it does via the API, with no undo. Corrects that, adds a snapshot-first rule, and documents the recovery recipe used here — including the grouping check that proves the orphaned set is exactly the deleted option's cards before re-applying. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU * docs: add Incoming to the v1 board and document its recipes (#1891) Board #11 had the same gap as #28 — no state for "filed but not yet triaged" — so a v1 security-fix issue had nowhere to sit that didn't assert maintainer approval. Adds Incoming there too. AGENTS.md carried no v1 board recipes at all, only a link, so anyone boarding a v1 issue had to discover the project and field ids by hand and was liable to reach for #28's (which are rejected, but only after the attempt). Adds a V1 board section with its ids, states that Incoming is the default status for new items on both boards, and notes that Priority is v2-only — #11 has no such field. The Incoming option was added with all four existing option ids echoed back, and a before/after item-list diff confirms all 74 cards kept their Status. Three cards on #11 carry no Status; that predates this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU * docs: distinguish the board Priority from the org-level issue field (#1891) An issue page shows two fields named "Priority" and nothing syncs them. Ours is the project field on board #28. The other is a GitHub issue field (IFSS_kgDOAdAWeg) defined at the modelcontextprotocol org and shared by every repo in it, alongside Effort/Start date/Target date. Same name, same four option names, unrelated storage — #1891 sat at Urgent in Fields and High on the board simultaneously. Adds a table naming both, states that no pass-through exists in either direction, and says to leave the org-level one alone: it is not repo-scoped, so deleting it would strip Priority from every other org repo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU * docs: mark the org Priority field untrusted and cap it at a +1 signal (#1891) Both boards are private (public: false, verified), so maintainer-assigned Status and Priority are invisible to reporters — board priority is a working queue, not a published commitment. The org-level Fields -> Priority is the opposite: public on the issue page and not part of triage. A value there is a reporter's preference, not an assessment, so it is untrusted input. It now feeds the rubric as a sixth signal bonus — flat +1 for Urgent or High, identical for both — and never maps to a band. Urgent needs 12, so nothing a reporter types reaches it alone; the issue must already sit at 11 on maintainer-assessed axes. Supersedes the earlier "it is noise" framing: the signal is worth keeping, it just cannot be allowed to decide the outcome. Also corrects the band arithmetic (2-15 -> 2-16) now that a sixth bonus exists, and notes that scores recorded on 2026-08-01 cite the old /15 denominator. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU * docs: drop the /15 denominator caveat now the recorded scores are restated (#1891) The 51 triage comments were rewritten from /15 to /16, so the note saying they cite the old denominator no longer describes anything. No total moved: the reporter-set signal only scores for Urgent or High, and the one scored issue carrying an org-field value (#1826) had Low, which earns nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU * docs: describe the board-option hazard per field, not Status-only (#1891) Copilot review on #1892 flagged three places that still read as Status-only now that the section covers Priority too: - the version-label bullet said a v2 issue needs "a board card with a Status"; it needs a Status and a Priority (v1 needs only a Status, since board #11 has no Priority field) - the updateProjectV2Field hazard said a bad edit "orphans the Status of every card"; it orphans whichever field was edited - the recovery recipe is genuinely Status-specific (reads .status, writes the Status field id), so say so and give the two substitutions for a Priority deletion Verified `gh project item-list --format json` exposes both .status and .priority before documenting the .priority swap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 5, 2026
cliffhall
added a commit
that referenced
this pull request
Aug 5, 2026
…d audit Follow-up on the same issue: the triage rules were clear on the happy path but three gaps meant a bare "triage new issues" would diverge from what a maintainer actually does. Define triage by STATE, not authorship. An issue needs triage when it arrives with no board card and no milestone — whoever filed it. Framing it as "externally-filed" was wrong: a maintainer opening an issue by hand in the GitHub UI lands in exactly the same state, because write access makes the board reachable, not automatic. What puts an issue in Todo is somebody performing the approval, not who owns the account. Renamed the section and reworded every dependent passage accordingly. Fix the discovery query, which diffed open issues against board #28 only. Verified against the live boards: it reports #1929 as unboarded when that issue is correctly carded on #11, so following it literally double-boards the issue — recreating a defect a past sweep introduced. Now diffs against the union of both boards, filtered by .content.repository (an org project can hold other repos' issues; #11 carries one from modelcontextprotocol/ servers), and prints each hit's destination, since an unboarded issue that already has a milestone is approved and belongs in Todo, not Incoming. Add "The board audit" — the other drift classes a single-issue rule can't catch (double-boarded, non-Issue items, statusless cards, the Incoming ⇔ milestone invariant in both directions, wrong board for label, missing version label, missing Priority), as a table of invariant + fix plus one runnable jq check that should print 0 across the board. Both snippets were executed verbatim against the live boards. Add "Recording the score". The rubric claimed its reasoning "survives in a form someone can argue with later", but the board stores only the result and is private, so nothing kept that promise. Triage now posts the axes, the bonuses claimed, and the total as a comment. Also scope pass 2 explicitly to a human — deciding what ships in which release is not inferable from a rubric — and correct the stale note about three statusless cards on #11. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YAt8rqxysNbhYWLhoRm3fU
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #10
Review in this order:
See #12 for demo video.