Skip to main content
Glama
Sign In
Rocket Money MCP

Rocket Money MCP

by aidanouckama
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

session_status

Read-onlyIdempotent

Check whether locally stored Rocket Money session credentials are present without exposing them or making a network request; an active result means stored, not live-verified.

Instructions

Local session status without revealing credentials or making a network request. Active means stored, not verified live.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "session_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes beyond the annotations by disclosing three things they do not: no network request is made, credentials are not exposed, and the "active" flag reflects stored state only. That last point is critical for interpreting the result correctly. Minor tension with openWorldHint=true, since a purely local, non-networked read is not obviously open-world, but the readOnly/idempotent/non-destructive hints are consistent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both load-bearing, with the semantic caveat ("stored, not verified live") front-loaded right after the purpose. Nothing is padded or restated from the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and no output schema, the description covers the main interpretive risk (what "active" means) and the safety profile. It stops short of describing what status fields or values are returned, which is the one remaining thing an agent must discover by calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes no parameters, so there is nothing for the description to disambiguate and the baseline applies. No misleading parameter language is introduced.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and scope: "Local session status", and immediately qualifies the meaning of that status ("Active means stored, not verified live"). An agent can distinguish this from a live connectivity check, though the description never names the sibling that performs one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrases "without making a network request" and "not verified live" implicitly tell the agent this is the cheap local check rather than a live verification, but no alternative tool is named and no explicit when-to-use/when-not-to-use rule is stated. Usage is inferable rather than prescribed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools