Skip to main content
Glama
log-10x

Log10x MCP Server

Official

Login status

log10x_login_status
Read-onlyIdempotent

Lists your Log10x account environments and reports login status, so you can check access and pick an environment to query.

Instructions

List the user's Log10x ACCOUNT environments and report credential / login state. Call this, and ONLY this, for any of these phrasings: 'which Log10x environments do I have', 'which environments are available to me', 'list my envs', 'what tenants/accounts can I query', 'am I logged in', 'switch envs'. For 'log me in' / 'sign me up' / 'create a Log10x account' / 'use my real account': call log10x_signin_start (browser Auth0 device flow; the model chains to log10x_signin_complete automatically), or call log10x_signin_complete directly with { api_key: "<key>" } if the user already has a key. Do NOT call log10x_discover_env for these questions: that tool scans the user's Kubernetes/AWS infrastructure, unrelated to Log10x account environments. In demo mode (no key set, or key failed validation), the response is a step-by-step config guide. In signed-in mode, lists the user's identity, every env they can reach with permissions (OWNER/WRITE/READ), the default env, and the most-recently used env this session. Read-only, takes no args.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
dataNo
toolYes
viewNosummary
imagesNo
actionsNo
summaryYes
warningsNo
truncatedNo
next_cursorNo
render_hintNo
generated_atYes
schema_epochYes
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.7

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: demo-mode fallback returns a step-by-step config guide versus signed-in mode returning identity, per-env permissions, default env, and last-used env. Some of this return detail overlaps the output schema, keeping it from a 5.

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?

Purpose and the primary routing rule are front-loaded, and every sentence carries actionable routing or mode information. The dense list of synonym phrasings and the parenthetical detail on the Auth0 device flow are slightly verbose, but nothing is wasted given 57 sibling tools.

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?

With annotations carrying safety and an output schema carrying return shape, the description only needs to cover purpose, routing, and mode behavior — all of which it does. An agent has everything required to select and 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?

Zero parameters, so the baseline is 4. The description explicitly confirms 'takes no args,' which is consistent with the empty schema and removes any doubt about argument shape.

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+resource ('List the user's Log10x ACCOUNT environments') plus secondary purpose ('report credential / login state'), and explicitly excludes the look-alike sibling log10x_discover_env. An agent can distinguish it from signin/signout/discover tools without opening any 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 trigger phrasings ('which environments do I have', 'am I logged in'), names the correct alternatives for adjacent intents (log10x_signin_start / log10x_signin_complete for login/signup), and states an explicit when-NOT rule for log10x_discover_env. Routing is fully specified.

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