Skip to main content
Glama

Get account info

get-account-info
Read-onlyIdempotent

Get information about the current fynk account.

Use this tool when:

  • You need details about the active account (e.g. default document locale, signature settings) before tailoring a response

  • You are tailoring guidance to the account's business, and need what it reported about itself when signing up (industry, company size, the department the person who signed up works in)

For information about the current user, use get-user-info

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": "get-account-info"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
nameNo
localeNoDefault account language, e.g. en-GB, de-AT. This language will be preselected for newly created documents/templates. fynk will generate AI summaries in this language. Prefer describing the locale in natural language (e.g. 'British English') rather than showing the raw code.
statusNoThe account's subscription status. May fence access to certain app features
created_atNoWhen the account was created
_entity_typeNoOnly relevant for tooling. Do not show to the user
sso_enforcedNoIf true, account users must authenticate via SSO rather than logging in with a password
trial_ends_atNoIf the account is in 'trial' status, when the trial ends and the account reverts to 'free'
onboarding_profileNoWhat the account told us about its company when signing up. Self-reported and unverified - use it to tailor guidance, not as authoritative facts about the company. Fields that are not set are omitted
default_comment_scopeNoControls the default visibility of comments and proposals in documents
default_signature_typeNoThe default eIDAS assurance level to use when signing documents. May be overridden on individual documents
finished_onboarding_atNoWhen the account completed the initial onboarding flow. Absent if onboarding has not yet been finished
require_team_assignmentNoWhen true, all documents, imports, and automations must have at least one team assigned
auto_apply_ai_analysis_by_defaultNoWhen true, AI analysis results will be automatically applied when importing documents
two_factor_authentication_enabledNoIf true, users in the account must enable 2FA and use it when logging in
require_template_for_document_creationNoWhen true, a template must be selected when creating a document from scratch or uploading a PDF to sign

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds value beyond that by enumerating the kinds of account attributes returned (locale, signature settings, signup-reported industry, company size, department), which tells the agent what this call is good for. It does not need to describe return structure since an output schema exists.

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-loaded one-line purpose followed by a scannable bullet list and a routing sentence, with no redundant restatement of the title. The bullets are somewhat wordy ('what it reported about itself when signing up'), which slightly blunts conciseness but still earns its space.

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?

For a zero-parameter, read-only tool with rich annotations and an output schema, the definition supplies everything needed: purpose, when-to-use triggers, the notable data fields available, and the sibling alternative. Nothing an agent needs to select or invoke it is missing.

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 correctly implies a no-argument call scoped to the 'current' account, leaving nothing ambiguous about how to invoke it.

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 ('Get') and resource ('current fynk account information') in the first line. It also names the sibling it could be confused with (get-user-info), so an agent can distinguish account-level from user-level data without opening schemas.

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?

Two explicit when-to-use bullets give concrete triggers (tailoring responses to default locale or signature settings; adapting guidance to the account's reported industry/company size/department). It closes with the exclusion rule: 'For information about the current user, use get-user-info.'

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