Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

everything: add focused annotation-presence registration tests

Open Beginner friendly
  • Is something wrong?
#5,156 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
62/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
nodejs, typescript
Domain
testing-qa

Research direction

Start with __tests__/registrations.test.ts in the everything server workspace, and read surface.test.ts to see the existing annotation snapshot. Add assertions that each standard, conditional and task tool registration sets readOnlyHint, destructiveHint, idempotentHint and openWorldHint as booleans, without changing snapshots or hint values. Done when npm test --workspace @modelcontextprotocol/server-everything -- __tests__/registrations.test.ts passes and npm run validate stays green.

Written by the indexing model from the issue text.

Description

Which server?

everything (@modelcontextprotocol/server-everything)

Protocol era

Both, or not era-specific. The local verification below covers SDK 1 only; the request should be evaluated against the current v2/main registration paths.

MCP client

Automated Vitest tests. No external or LLM client was used for this test-only change.

The problem

Following the current issue-only contribution policy, I am converting the suggestion in #4529 into a registration-test coverage request, without attaching a patch.

The existing surface.test.ts already snapshots advertised annotations. The smaller gap is that the registration suite does not explicitly check the presence and boolean type of all four hints across every supported standard, capability-dependent, and task registration path. A focused assertion would give a more local failure when a refactor drops metadata at registration.

This is not a report that current tools lack annotations. Annotation presence also does not establish tool safety or prove that a hint accurately describes its behavior.

Solution you have in mind (optional)

Add registration-level regression checks for readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, with the capabilities needed to exercise conditional/task paths enabled. Preserve the existing surface snapshots, capability tests, hint values, and validation gates. No runtime changes or provider-specific integration.

For current SDK 2 development, derive expectations from its modern/legacy registration paths rather than copying the SDK 1 counts below.

Which MCP feature does it demonstrate? (optional)

Existing MCP tool-annotation metadata and its registration paths.

Alternatives or workarounds you have tried

Relying on the existing wire-level snapshots alone remains a reasonable alternative if maintainers consider the additional registration check redundant.

I searched existing issues. #3401 concerns missing annotations in an older version, while #4854 tracks the completed broader coverage effort. This request does not repeat the older zero-annotations claim.

Already built it locally?

Yes, a test-only prototype against main at bbb701e7ac1e57f3edd1c2836b94c5457eaf7b9c (Everything 1.0.0, SDK 1). It preserves the ten existing registration test cases and adds two checks covering the 12 standard, six conditional, and one task registration in that snapshot. No production source changed. Those counts are not asserted for SDK 2.

Verified on 2026-10-15 with Node 22.18.0, npm 10.9.3 and Vitest 4.1.11:

  • npm test --workspace @modelcontextprotocol/server-everything -- __tests__/registrations.test.ts: 12 passed.
  • npm run validate --workspace @modelcontextprotocol/server-everything: formatting, lint, type checking, build, and 260 tests passed.
  • npm run coverage --workspace @modelcontextprotocol/server-everything: 260 tests passed and per-file coverage thresholds cleared.
  • git diff --check: passed.

These are scoped test/build results, not a claim that the repository-wide submission gate passed. The old PR's original commit predates the current DCO workflow. I have not rewritten that history or pushed the local repair.

Original repair prompt (exact quotation except two redacted local paths)

These historical instructions explain the local reproduction; this issue follows the current contribution policy instead of requesting a PR merge.

You own ONLY the existing clone [LOCAL_SERVERS_CLONE] for repairing https://github.com/modelcontextprotocol/servers/pull/4529 (author jw-ond). User authorized beginning the upstream repair plan. Parent handles promptfoo, CrewAI, Langfuse. Do not edit [UNRELATED_LOCAL_PROJECT] or other clones. No new worktree. First inspect git status/branch/remotes, applicable AGENTS/CONTRIBUTING, and live PR head. If unexpected conflicting user changes exist, stop/report. Fetch current base and fork PR head, preserve all existing commits; prefer a merge from upstream main rather than history rewriting/force. Reproduce the conflict, resolve preserving intended tool-annotation registration regression coverage and current upstream behavior. Use apply_patch for manual edits, run appropriate focused tests/build plus git diff --check. This is restoring compatibility, no feature expansion and no test weakening. You may make a scoped normal commit on the verified PR feature branch; DO NOT PUSH or POST until parent reviews. Return old/new SHAs, exact changed file set, test commands/results, and any blockers. Work directly in that clone and preserve unrelated files. Do not disable hooks/security gates or use --no-verify.

Before you submit

  • I searched existing issues and this is not a duplicate.
  • This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.
Dominant language
TypeScript
Stars
91.4k
Forks
11.8k
Avg merge
7h 51m
Merged PRs (30d)
121

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/servers

All issues in modelcontextprotocol/servers

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.