Add context/navigator tool

[bmertens-datum]

Summary

Agents starting a session (or resuming mid-session) have no way to discover what org/project is currently active without making speculative tool calls. A dedicated context tool solves cold-start confusion and guides agents to their next required action.

Proposed behavior

Add a new context tool that returns current session state:

{
  "active_org": "my-org",
  "active_project": "my-project",
  "authenticated": true,
  "next_step": null
}

When state is incomplete, next_step provides explicit guidance:

{
  "active_org": null,
  "active_project": null,
  "authenticated": true,
  "next_step": "Call 'organizations' with action='list', choose an org, then call with action='set'"
}

This makes the tool act as a navigator, not just a status check.

Acceptance criteria

• context tool added and registered with the MCP server
• Returns active_org, active_project, authenticated fields
• next_step is populated with a concrete instruction whenever org or project is not set
• next_step is null when fully configured and ready to use

Ratings

Dimension	Score (1–5)
LOE	2
Impact	4
Agent XP	5

[jacobsmith928]

@scotwells @mattdjenkinson I think I heard some rumblings about this in another context. Can you weigh in here so we can decide if this fits into a short term sprint or a future scope?

[scotwells]

I'll need to investigate this a bit further. We'll likely want some way for agents to understand what contexts are available (projects, orgs, etc), but need to investigate how it memorizes which context to use when making tool calls and whether that memorization is something to bake into the MCP server itself or just have the agent take that responsibility. My instinct is the agent could handle it for now.

[scotwells]

Found some in-flight enhancements on the MCP specification in this area:

• Make MCP Stateless
• Sessionless MCP via Explicit State Handles

Based on these, we should avoid making our MCP stateful and push that responsibility into the agent.

The context tool is still worth adding, but scoped to a discovery tool only. It should return a set of organizations and projects the current session can access to give the agent a set of IDs to work with.

The agent flow:

1. Call context to discover available orgs/projects
2. Either infer the right one from its instructions, or ask the user to pick
3. Pass the chosen ID as an explicit parameter to subsequent tool calls

We can drop next_step. The guidance it would provide is static and belongs in tool descriptions. Tool descriptions are the right place to tell the agent "call context first to discover available orgs, then pass organization_id and project_id to other tools."