Skip to main content
Glama
haiyunsky

HPSILab - Quant Finance MCP Server for Stock Analysis and Options Analytics

register_account

Create a free HPSILab account with your email and receive an API key for stock and options analysis; confirm the emailed verification link to activate the trial allowance.

Instructions

Register a free HPSILab account from the client and receive an API key.

Use this tool when:

  • The user has no API key yet and asks to sign up from here, with their own email address. This is the only tool that works without HPSILAB_API_KEY; the user can also register at https://hpsilab.com/register.

  • The user already has a key and asks for a fresh one for the same account.

It creates an account and sends a verification email, so call it only when the user asks, never to get around another tool's error on your own.

After it succeeds, set HPSILAB_API_KEY to the returned api_key so the other tools authenticate as this account. The account is also bound to this caller server-side, so calls from here are recognised even before the environment variable is updated.

The account is created unverified, with only a capped evaluation allowance and no trial Credits, until the emailed link is confirmed; confirming it grants the one-time 100-Credit Registered Trial (14 days). Tell the operator to click that link.

Calling again returns the same account and a fresh key rather than creating a second one, so it is safe to retry if a key was lost. An address that already belongs to a different account is refused — you cannot attach yourself to someone else's account.

Returns

dict email : str — the registered address tier : str — plan name, "free" on registration email_verified : bool — false until the emailed link is clicked api_key : str — set this as HPSILAB_API_KEY already_registered: bool — true when this caller already had an account message : str — next step, in plain language

Input Schema

NameRequiredDescriptionDefault
emailYesA real email address to own the account. Use the operator's address if you have one — the verification link is sent there, and an address nobody reads leaves the account permanently at the anonymous allowance.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.11.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations, the description discloses key side effects and lifecycle details: a verification email is sent, the account starts unverified with no trial Credits, confirmation grants a one-time 100-Credit trial, and the account is bound server-side. It also explains retry behavior and refusal when an email belongs to another account.

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?

The description is front-loaded and organized into clear sections, but it is longer than strictly necessary. The returns block repeats information that an output schema likely already contains, and some verification-email details appear in multiple places.

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?

Given the auth-related complexity, side effects, and the presence of an output schema, the description is complete. It covers prerequisites, post-success API key handling, account verification state, retry semantics, and failure cases.

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

Parameters3/5

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

Schema description coverage is 100%, so the single `email` parameter is already well documented. The description reinforces that the user's own address should be used, but it does not add substantial syntax or constraint detail beyond the schema.

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?

The description states a specific verb and resource: registering a free HPSILab account and receiving an API key. It also distinguishes this tool from all sibling stock-analysis tools by noting it is the only tool that works without HPSILAB_API_KEY.

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?

The description gives explicit when-to-use bullets, including the no-key signup case and the fresh-key-for-existing-account case. It also states when not to use it: never to work around another tool's error, and only when the user asks.

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