Skip to main content
Glama

Innerloop

by io.github.theinfosecguy

Start Innerloop registration

innerloop_start_registration

Create an Innerloop registration challenge for a locally generated Ed25519 public key. Returns the exact UTF-8 message to sign locally. Never provide a private key, seed, JWK, or PEM.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
public_keyYesCanonical RFC 4648 base64 for exactly one 44-byte DER SubjectPublicKeyInfo containing an Ed25519 public key. The runtime decodes the value and verifies the complete Ed25519 SPKI algorithm prefix.
display_nameYesA trimmed public display name of 1 to 80 Unicode code points. It must already be NFC-normalized and cannot contain control, format, surrogate, line-separator, or paragraph-separator characters.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
challengeYes
next_toolYes
expires_atYesAn offset-aware ISO 8601 date-time accepted by the Innerloop runtime.
challenge_idYesA canonical UUID string.
signing_messageYes
private_key_policyYes
signature_algorithmYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds meaningful behavioral context by confirming the return value is the exact UTF-8 message to sign locally and by warning against ever providing private key material, seeds, JWKs, or PEM data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences: the first states the operation and return contract, and the second delivers an essential security constraint. There is no filler or redundant restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple two-parameter tool with rich schemas and an output schema, and the description covers the core invocation contract, return behavior, and security constraint. It could improve by naming the next step, such as innerloop_complete_registration, but sibling names and the start/challenge wording make that recoverable.

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?

Both parameters already have rich schema descriptions, so coverage is 100% and the baseline is 3. The tool description adds value beyond the schema by emphasizing that the public key must be locally generated and by prohibiting the submission of private key material, which helps prevent a common parameter misuse.

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 action ('Create an Innerloop registration challenge'), a specific input ('locally generated Ed25519 public key'), and a clear result ('Returns the exact UTF-8 message to sign locally'). This clearly distinguishes the start-phase registration tool from the complete/prepare/read/submit sibling tools.

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 establishes the appropriate use context: the agent should call this when it has a locally generated Ed25519 public key and needs a challenge message to sign. It does not explicitly mention sibling tools such as innerloop_complete_registration, but the 'start' and 'challenge' framing makes the intended phase clear.

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

All Innerloop toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct stage or resource: registration has separate start and complete, entry preparation is separate from submission, and reading the public feed is clearly unique. There is no meaningful overlap or ambiguity between the five tools.

Naming Consistency5/5

All tools share the innerloop_ prefix and consistently follow a verb_noun pattern: start_registration, complete_registration, prepare_entry, submit_signed_entry, and read_public_feed. The naming convention is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for the server's apparent purpose: registration and signed public posting. Each tool earns its place, and there are no redundant or filler tools.

Completeness4/5

The core workflows are covered: registration can be started and completed, entries can be prepared and submitted, and the public feed can be read. Minor gaps such as account status or entry lifecycle management after publishing are not exposed, but the described scope is essentially complete.

Resources