Skip to main content
Glama

my_account

YOUR membership tier + today's live-fetch quota for THIS connection.

Tells you the plan you're authenticated as (free / pro), how many of today's shared live-fetch pulls you've used (real-time search / view refresh / debate / x-sentiment all draw from one daily pool), and that DB-read tools are uncapped. Reflects ONLY your own account — never any global / operator data. Sign in via OAuth browser-login or a kc_ member key to be recognized as a member.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses behavior: it reports the user's own account data, is read-only, and specifies exact outputs (plan, used pulls, uncapped DB-reads). No contradictions or omissions.

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 well-structured with clear topics, but a few phrases like 'shared live-fetch pulls' could be streamlined. Still, it is relatively concise and front-loaded with the main purpose.

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 zero parameters and an existing output schema, the description fully explains the tool's purpose, output contents, and authentication needs. It leaves no ambiguity for the agent.

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?

There are no parameters, so schema coverage is trivial. The description adds value by detailing what the output contains, which is essential since the schema is empty.

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 clearly states it returns the membership tier and live-fetch quota for the user's connection. It uses specific terms like 'free/pro' plan and daily pull count, distinguishing it from sibling tools which are all analysis-focused.

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

Usage Guidelines4/5

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

The description implies usage when needing account status or quota info. It mentions authentication methods but does not explicitly state when not to use or compare with alternatives. However, the tool's unique purpose makes this sufficient.

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.

TDQS

A3.5/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (e.g., analyst_views fetches views, analyst_debate compares them, analyst_track_record scores accuracy). Some overlap exists between sentiment tools (stocktwits_symbol, ticker_social_sentiment) but descriptions clarify boundaries. Overall, an agent can differentiate them.

Naming Consistency3/5

Naming is mostly lowercase with underscores, but conventions vary: some use prefixes (analyst_, direction_review_), some are single words (quote, leaderboard), and others are verb_noun (score_ticker, screen_stocks). This inconsistency makes patterns less predictable, though prefixes help group related tools.

Tool Count3/5

With 24 tools, the server is slightly above the ideal range of 3-15 for coherence. While each tool seems justified for the financial analysis domain, the volume could be overwhelming. Some tools (e.g., tweet_store_stats, direction_review_batch) are operator-only, reducing the surface for typical agents.

Completeness4/5

The tool set covers core workflows: fetching analyst views, tracking accuracy, SEC fundamentals, insider activity, material events, live quotes, social sentiment, and screening. Gaps like earnings calendar or portfolio management are minor given the focus on analyst-driven analysis. The operator tools for direction review add internal completeness.

Resources