Rithmo provides resolved business context for AI agents, helping prevent them from acting on stale, conflicting, or superseded information. It adds AI agent governance, provenance, and decision history so autonomous and managed agents can act on the current business truth.
Scored across 3 tools
Each tool serves a distinct role: polling state changes, querying the current decision, and verifying identity/scopes. There is no meaningful overlap, and the descriptions reinforce the boundaries.
list_decision_changes and query_decision follow a clear verb_noun pattern. whoami breaks that pattern, though it is a conventional CLI-style command for identity, so it is a minor deviation.
Three tools is small but exactly matches the narrow read-only decision-service scope. Each tool is necessary and there is no redundancy.
The surface covers the core read workflows: querying current authority, polling changes over time, and verifying connection scopes. A minor gap is no direct fetch by decision identifier, but the natural-language query and change stream handle the intended use cases.
Drain decisions whose state changed, since a cursor. Call with no since to start from now (returns an empty set + the current cursor); then call repeatedly with the returned cursor to get changes in order. Includes reversals (dropped/superseded). Read-only; poll this on a schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max changes to return (1–200, default 50). | |
| since | No | Opaque cursor from a previous call. Omit on the first call to start from now (no backfill). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden and meets it well. It discloses read-only safety, cursor semantics, the empty-initial-result behavior, ordering, inclusion of reversals, and the need to poll repeatedly. This is substantive behavioral context well beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences pack in action, cursor workflow, edge-case behavior, and safety guidance with no filler. The essential 'drain since cursor' semantics are front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description explains the calling pattern and return behavior sufficiently. It could be slightly more explicit about how a caller knows the drain is complete beyond 'call repeatedly,' but it is otherwise complete for an agent to invoke and iterate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds useful cross-call semantics for `since`: it explains it starts from now when omitted and that the returned cursor should be reused. This goes slightly beyond the schema's 'Opaque cursor from a previous call' phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Drain decisions whose state changed') and a specific resource, clearly distinguishing it from siblings like query_decision and whoami. The phrase 'Read-only; poll this on a schedule' further reinforces that this is a streaming/change-feed tool, not a query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear, actionable usage context: call with no `since` for an initial empty set and cursor, then repeat with the returned cursor to get ordered changes. It does not explicitly name query_decision as the alternative for point-in-time reads, so it misses the 'when-not-to-use' exclusion, but the polling context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the current authoritative decision for a natural-language question, before an execution step. Returns the answer, its owner, its source, and status; result="found_record" when the subject record holds the answer; or result="no_record" with a typed refusal (record: closed with its disposition, no_record with a reason, or not_observed when the surface is not connected) carrying premise_check.safe_to_proceed=false — do NOT act on the premise when the record refuses. Read-only; the record is Rithmo's, the action is yours.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Optional: topical/area hint to bias retrieval. | |
| type | No | Optional: restrict to one commitment type. Default: all. | |
| owner | No | Optional: restrict to a named owner. | |
| surface | No | Optional: the external system this task concerns (e.g. "jira", "salesforce"). When that surface is not one Rithmo observes, a miss returns a typed not_observed instead of no_record — absence on an unobserved surface is UNKNOWN, not "no". | |
| question | Yes | Natural-language question, e.g. "Are we still shipping the new onboarding flow?" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers: read-only nature, return fields, result enum values (found_record vs no_record), typed refusal variants (closed/no_record/not_observed), and the safe_to_proceed flag. This is rich, decision-relevant behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every clause adds information: purpose, return contract, refusal semantics, safety directive, and ownership. It is dense but structured with semicolons and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Because there is no output schema, the description fully specifies the return contract and the failure modes an agent must handle. It also clarifies ownership and the action boundary, leaving no critical ambiguity for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics for surface (not_observed vs no_record on unobserved surfaces) and for the question. Other parameters (area, type, owner) are adequately handled by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Look up'), a specific resource ('current authoritative decision'), a query mode ('natural-language'), and a temporal placement ('before an execution step'). This clearly distinguishes it from sibling list_decision_changes (current vs changes) and whoami (identity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames the tool as a pre-execution lookup and instructs the agent not to act on a premise when the record refuses via premise_check.safe_to_proceed=false. It does not name sibling alternatives or exclusions directly, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the organization this MCP connection is scoped to and its granted scopes. Takes no arguments. Use it to verify the connection and the service token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well: it clarifies the tool is a read-only introspection call, takes no arguments, and returns specific information (organization and granted scopes). It doesn't describe error behavior or exact output format, but for a simple whoami-style tool, the behavioral surface is small and adequately covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The return-value information is front-loaded, followed by the use case, and every sentence earns its place. It is compact enough to be read quickly and complete enough to be actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument, read-only tool with no output schema, the description is complete: it states what the tool returns, that it takes no arguments, and the intended use case. An agent has everything needed to select and call it correctly. The absence of output schema details is acceptable because the description sufficiently describes the return domain (organization and scopes).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is already empty, so the description's explicit 'Takes no arguments' adds useful confirmation for an agent. This matches the baseline for parameterless tools: no parameter documentation burden exists, and the description reinforces the no-argument contract without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') tied to a clear resource: the organization the connection is scoped to and its granted scopes. This clearly distinguishes it from sibling tools like list_decision_changes and query_decision, which operate on decision data rather than connection/auth context. The title 'Who am I' reinforces the identity-check purpose without any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it: 'Use it to verify the connection and the service token.' This gives an agent a concrete trigger condition and makes the tool's role in an auth/connectivity workflow obvious. It doesn't need to exclude siblings because its subject matter is fundamentally different from the decision-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_decision_changesquery_decisionwhoami
Add one secure layer between your agents and this server.