Class Profiles

Discussion prototype 0.1 Not a standard

Research question

Can one small Calendar contract describe the same job across unlike backends?

A Capability Class Profile is a proposal for naming a capability and its behavior separately from one server’s tool names. This page examines that proposal with a narrow Calendar example.

Worked example

A fixed request, shown step by step

Both simulations receive the two profile requests below. The switch changes only the implementation path displayed beside them.

Scenario
Find 45 minutes Thursday afternoon and book Design review.

Fixture date: 2026-02-26 · America/New_York

Profile side

Requests supplied to either simulation

Fixed input
  1. 01 calendar.find_free_time 
    {
  "duration_minutes": 45,
  "window_start": "2026-02-26T13:00:00-05:00",
  "window_end": "2026-02-26T17:00:00-05:00",
  "max_results": 3
}
  2. 02 calendar.create_event 
    {
  "title": "Design review",
  "start": "2026-02-26T15:00:00-05:00",
  "end": "2026-02-26T15:45:00-05:00",
  "timezone": "America/New_York"
}
Implementation side

Native simulation

Speaks the profile directly

Display a backend trace
  1. 01 calendar.find_free_time direct
    Arguments and result
    Arguments
    { "duration_minutes": 45, "window_start": "2026-02-26T13:00:00-05:00", "window_end": "2026-02-26T17:00:00-05:00", "max_results": 3 }
    Result
    { "slots": [{ "start": "2026-02-26T15:00:00-05:00", "end": "2026-02-26T17:00:00-05:00" }] }
  2. 02 calendar.create_event direct
    Arguments and result
    Arguments
    { "title": "Design review", "start": "2026-02-26T15:00:00-05:00", "end": "2026-02-26T15:45:00-05:00", "timezone": "America/New_York" }
    Result
    { "title": "Design review", "start": "2026-02-26T15:00:00-05:00", "end": "2026-02-26T15:45:00-05:00", "timezone": "America/New_York", "state": "confirmed" }

Native simulation ready.

Compared result

Thursday, February 26, 2026

America/New_York

The comparison includes free intervals plus event title, start, end, timezone, and state. Opaque backend IDs are intentionally excluded.

Interpretation

What can be said about this result?

What this page shows

  • The two simulation functions receive identical profile request objects.
  • The projected path translates those requests into a differently shaped API trace.
  • Compared fields match in this fixture.
  • The comparison can be inspected in source rather than inferred from the animation.

What this page does not show

  • Behavior against two independently maintained Calendar servers.
  • MCP discovery, transport, authentication, retries, or failure recovery.
  • Conformance of any implementation or completeness of the proposed contract.
  • A stable specification, official runner, passing Claim, or receipt.

Inspect the comparison

The relevant artifacts are public.

Simulation sourceBoth execution paths and the comparison fields Comparison testAssertions for requests, traces, outcomes, and opaque IDs Calendar profileAuthoritative proposed surface for 0.1 Core fixturesBehavior cases beyond the page’s single scenario

Prototype 0.1 surface

One draft Calendar profile

This is the complete declared scope of the package, not a roadmap.

Profile state
draft
Core baseline
org.classprofiles.calendar/core@1
Core operations
6
Optional facets
3
Fixture cases
15 across 5 files
Reference week
2026-02-23 · America/New_York

Core operations

  • calendar.list_events
  • calendar.get_event
  • calendar.create_event
  • calendar.update_event
  • calendar.cancel_event
  • calendar.find_free_time

Optional facets

  • calendar/recurrence@1
  • calendar/rsvp@1
  • calendar/reminders@1

A vendor travel-buffer member is included only as an extension example.

Open questions

Points the prototype leaves unresolved

Discussion is more useful when it refers to a contract field or fixture case.

  1. 01

    Are the six Core operations the right behavioral floor for a Calendar capability?

  2. 02

    Which result fields should count when two implementations are compared, and which must remain backend-specific?

  3. 03

    What review evidence should a projection mapping provide?

  4. 04

    Which edge cases are required before results from independent servers would be informative?

Review the artifacts or open an issue in the repository →

Prior art and alternatives

Interop projects worth comparing

  • Standard Schema defines a small consumer interface across TypeScript schema libraries.
  • OpenFeature places provider translations behind a shared feature-flag API.
  • Debug Adapter Protocol separates development tools from debugger-specific adapters.
  • CommonMark pairs a written specification with tests and a reference implementation.

Alternatives to a shared profile

  • Keep per-server tool discovery and write server-specific agent guidance.
  • Maintain host-specific adapters without a shared public contract.
  • Use an existing domain protocol directly where both sides already support it.

Prototype 0.1 exists to make those tradeoffs discussable with one concrete package.