fix: align everything server resource URI numbering with array indices

[olaservo]

Fixes issue #475 where array indices (0-based) didn't match URI numbers (1-based), causing confusion.

Changes

• Resource URIs now use 0-based numbering to match array indices
• Resource 0 is now accessed via test://static/resource/0
• Even indices now map to even URI numbers (more intuitive)

Resolves #475

Note: this is technically a breaking change, but since this is a demo server for testing, it seems like this shouldn't actually be an issue?

Generated with Claude Code

[domdomegg]

LGTM.

I am a bit confused why we used 1-indexing in the first place, so am a bit wary (something something Chesterton's Fence). But seems fairly low risk.

[cliffhall]

LGTM.

I am a bit confused why we used 1-indexing in the first place, so am a bit wary (something something Chesterton's Fence). But seems fairly low risk.

@domdomegg I'm guessing it was so that in the Inspector when you look at the resource list it is human-aligned, i.e., only programmers would not scratch their head at "Resource 0".

Guess we'll never really know, since this was part of the Initial Commit for the repo, and there is no associated detail in the commit message.

[cliffhall]

Is this what we want? Seems confusing.

[cliffhall]

This is what we had. The URI matched the resource name and resources started at 1 for human readability.

Now you have name out of sync with URI. The array index matches the URI, but is there a clear win in that? In the real world, URI and array index may have no correlation. I see no clear benefit to this change. You could make the resource name match the zero-based URI and index, I suppose, but I still don't see how it's an improvement that needs to be made.

Alternative approach?

I discussed with the author of issue #475 who agreed that the index is not important and that it probably has no correlation to URIs in the real world.

I think the better thing to do here is take his alternative suggestion and just change the README to state that odd numbered resources are text and even numbered resources are blobs. Currently it is backward.

Current odd numbered resources are text

Current event numbered resources are blobs

Current README says the opposite

[domdomegg]

Sorry to maybe cause more chaos by introducing a new idea (which might be wrong because I don't have a huge amount of context on this server), but maybe we avoid all this weirdness by just using intentionally random ids?

E.g. just generate a uuid for everything, and either:

• drop the note about odd/evens being particular types of resources
• put things under proper paths if we want the paths to convey this info e.g. test://static/resource/text/{uuid} and test://static/resource/blob/{uuid}

[cliffhall]

Sorry to maybe cause more chaos by introducing a new idea (which might be wrong because I don't have a huge amount of context on this server), but maybe we avoid all this weirdness by just using intentionally random ids?

E.g. just generate a uuid for everything, and either:

• drop the note about odd/evens being particular types of resources
• put things under proper paths if we want the paths to convey this info e.g. test://static/resource/text/{uuid} and test://static/resource/blob/{uuid}

@domdomegg excellent suggestion. Removes any assumptions about array index being meaningful, axes the admittedly strange "even/odd" language from the description, and delivers the point that URIs can carry meaning.

[domdomegg]

@claude can you give a shot at implementing the proposal from @domdomegg above? create it as a separate branch, if you can please.

[claude]

Claude finished @domdomegg's task —— View job

---

Implementation Complete! ✅

Successfully implemented UUID-based resources as proposed by @domdomegg.

Changes Made

• Read repository setup instructions (CLAUDE.md)
• Examine current everything server implementation
• Create new branch for UUID implementation
• Replace array index-based URIs with UUID-based system
• Update resource paths to be more semantic (text/blob separation)
• Update README documentation
• Test the implementation
• Commit and push changes

Summary

Created a new branch uuid-based-resources that implements the UUID-based resource system:

Key Changes:

• 100 resources now use UUID-based identifiers instead of array indices
• Semantic paths:
  • Text resources: test://static/resource/text/{uuid}
  • Blob resources: test://static/resource/blob/{uuid}
• Clear naming: "Text Resource 1-50" and "Blob Resource 1-50"
• Updated tools: getResourceReference now accepts resourceUri instead of resourceId
• Updated prompts: resource_prompt argument changed to resourceUri
• Eliminated confusion between 0-based array indices and 1-based display numbers

Benefits:

• No more index/URI numbering mismatch issues
• Clear resource type indication through paths (/text/ vs /blob/)
• UUIDs provide truly unique identifiers
• More realistic real-world URI patterns

The implementation builds successfully and the server starts without errors. You can create a PR from the new branch: https://github.com/modelcontextprotocol/servers/pull/new/uuid-based-resources