Skip to main content
Glama

Register a free Singularis key

singularis_register_key
Idempotent

Register a free Singularis API key when a tool returns no_api_key; provide country and agent name to get credits, with proof of work solved automatically.

Instructions

Get a free Singularis API key for this agent (one call, then it is saved and reused). Use when any Singularis tool reports error=no_api_key. Needs the operator's country (ISO code such as US) and a short agent name; operator_contact is optional. Free keys are for US-based users and agents; the tool solves the quick anti-abuse proof of work for you. Returns the key's starting credits. Sharing results later is requested, not required. By registering you agree to the Terms at https://getsingularis.com/terms.

Input Schema

NameRequiredDescriptionDefault
countryYes
agent_nameYes
operator_contactNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, open-world, idempotent). The description adds substantive behavior the annotations cannot convey: the anti-abuse proof of work is solved automatically, the key is persisted for reuse, US-based users/agents only, agreement to external Terms, and that result sharing is requested but not 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-loaded with purpose and trigger, then constraints, then legal terms — a sensible order. It is dense but nearly every clause adds operational information; the credits/terms sentences are the most expendable.

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?

An output schema exists, so return details are not strictly required, yet the description still flags that the response includes starting credits. With annotations covering the safety profile, all preconditions (error trigger, required fields, US restriction, terms) are present.

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 0%, so the description must carry parameter meaning. It does: country is an ISO code ('such as US'), agent_name should be 'short', and operator_contact is explicitly optional. It does not clarify what operator_contact should contain (email? handle?), which is the one remaining gap.

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 and resource ('Get a free Singularis API key for this agent') and immediately scopes it as a one-time provisioning step. No sibling tool in the list performs key registration, so the agent can distinguish it 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 an explicit trigger: 'Use when any Singularis tool reports error=no_api_key.' It also pre-empts repeat invocation with 'one call, then it is saved and reused', which is the relevant when-not condition for this tool.

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