Skip to main content
Glama

ClearMind Capital

Find a company's 401(k) plan

find_401k_plan
Read-onlyIdempotent

Search the public U.S. Department of Labor Form 5500-SF filings that power the ClearMind 401(k) Scorecard. Covers 401(k) plans in all 50 states and DC that file the 5500-SF (usually under 100 participants); larger plans file the full Form 5500 and are not included, and a miss returns an empty list with a link to request a hand-built Scorecard. Search by name needs the two-letter state the company files from; an EIN works in any state. Returns up to 5 plans with sponsor, city, state, plan year, participant count, and plan_id. No auth. Step 1 of 2: pass the plan_id to get_401k_scorecard_preview for the score.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "find_401k_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesCompany or plan name (e.g. 'Acme Tool'), a 9-digit EIN, or a 12-digit EIN plus plan number. Dashes and spaces are ignored.
stateNoTwo-letter state (or DC) of the company's address on its filing, e.g. OH or TX. Required to search by name; ignored for an EIN.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / state
      Added value: +{
      +  "description": "Two-letter state (or DC) of the company's address on its filing, e.g. OH or TX. Required to search by name; ignored for an EIN.",
      +  "maxLength": 2,
      +  "minLength": 2,
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Company or plan name, or EIN."New value: +"Company or plan name (e.g. 'Acme Tool'), a 9-digit EIN, or a 12-digit EIN plus plan number. Dashes and spaces are ignored."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral facts: dataset coverage limits (only 5500-SF, usually under 100 participants), the empty-list miss behavior with a link to request a hand-built Scorecard, the result cap of 5, and that no auth is required.

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

Conciseness4/5

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

Front-loads the corpus being searched, then coverage limits, then parameters, then the handoff. Dense but every clause carries operational meaning; slightly long as a single paragraph, though nothing is wasted.

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

Completeness5/5

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

No output schema exists, and the description compensates by enumerating the returned fields (sponsor, city, state, plan year, participant count, plan_id) and the 5-result cap. For a two-parameter search tool, an agent has everything needed to call it correctly.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real conditional semantics beyond the schema: `state` is required to search by name and ignored for an EIN, and an EIN works in any state. The schema documents formats (9-digit / 12-digit) but not these cross-parameter rules.

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

Purpose5/5

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

States a specific verb (search) plus a precisely scoped resource (public U.S. DOL Form 5500-SF filings) and explicitly names the downstream sibling get_401k_scorecard_preview as step 2. An agent can distinguish this from every sibling without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use context (searching 401(k) plans by name or EIN), states the exclusion (larger plans filing full Form 5500 are not included), describes the failure mode (a miss returns an empty list), and routes to the next tool. Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources