Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
server_startA

Start the local transform server and wait until it answers.

Args: ssl: Serve over HTTPS. Requires generate_certs first. Both the Maltego desktop client and the Graph Browser require it.

server_stopB

Stop the running transform server.

server_restartA

Restart the server to pick up new or edited transform modules.

Args: ssl: Serve over HTTPS after restarting. Left unset, the scheme the server is already running under is preserved, so reloading an HTTPS server keeps the Maltego desktop client working.

server_statusA

Report whether the server is running, healthy, and how many transforms it serves.

server_logsA

Return recent server log output.

Args: lines: Number of trailing log lines to return.

list_transformsA

List every transform the running server advertises, with input and output types.

An output type of NONE means the transform function is missing a return annotation, which stops the Maltego client from routing to it.

get_transformA

Return the full detail document for one transform.

Args: transform_id: Fully qualified transform name from list_transforms.

list_entitiesA

List the entity types the running server advertises.

run_transformA

Run a transform against one input entity and return its results.

The output starts with the run state, then each status message prefixed with its severity ([INFO], [WARNING], [ERROR], [DEBUG]), then the entity count and the number of distinct (type, value) pairs, one line per entity: type value {property=value, ...} [link label], and the link count. A run that FAILED also shows the last Python traceback from the server log.

Check the entity count and the message severities: a transform can report success while producing nothing, and an upstream 403 or 500 logged as [ERROR] still ends the run in a success state; a run like that with no entities gets a Warning line under the state. An unknown transform id comes back with how to find the right one. See docs/transform-authoring.md.

Args: transform_id: Fully qualified transform name from list_transforms. entity_type: Maltego type of the input entity, e.g. maltego.Domain. entity_value: Value carried by the input entity. settings: Optional transform settings, keyed by setting name. timeout: Seconds to wait before cancelling the run. full: Return every entity and link as the full JSON the server sent instead of one line each. Use it when a property, display field, or overlay that the summary cuts short matters.

get_seed_urlA

Return the seed URL and the steps to register this server with Maltego.

generate_certsA

Generate a self-signed certificate for serving over HTTPS.

Args: force: Overwrite an existing certificate pair.

scaffold_transformA

Scaffold a new Maltego transform module from a cURL command or OpenAPI specification.

The output lists each transform by the id the server registers it under, its sample input, a ready-made run command, and a field inventory: every leaf path seen in the sample response or schema, its sample value, and what happened to it (mapped to an entity, attached as a property, or dropped and why). Read the inventory and the notes: data an investigator needs is often nested deeper than the scaffolder follows by default. Preview with dry_run=True, adjust records/mappings/primary until the inventory maps what matters, then call again without dry_run. Restart the server, then call run_transform with the transform id exactly as listed (it includes the namespace).

Args: service: Optional service name slug (e.g. 'greynoise', 'threatfox'). curl: A full cURL command string demonstrating an API request. openapi: An OpenAPI/Swagger spec in JSON or YAML: a URL, a file path, or the document itself (as text or as an object). Use list_operations first to pick operation_ids. sample_response: A real JSON response (as text or as the parsed value), to map outputs from. Works with curl, and with openapi when exactly one operation is scaffolded (name it in operation_ids); without it a spec with no response schema maps nothing. operation_ids: OpenAPI operation ids to scaffold. Without it every GET operation is scaffolded; POST operations are only scaffolded when named here. force: Replace an existing service: its whole directory and its project.py imports. name: Transform name for a curl scaffold (default '_lookup'), so one service can grow endpoint by endpoint. records: Dotted path to the list of records in the response, e.g. 'data' or 'containers.cna.references'. Each element becomes one record to map. mappings: Per-field overrides as 'dotted.path[].field=EntityType', e.g. 'containers.cna.affected[].vendor=Company'. EntityType 'Property' attaches the field to the record's entity as a property; 'Drop' ignores it. dry_run: Parse and report the plan (transforms, field inventory, notes, auth, and the files that would be written) without writing anything. sample_input: An input value the API answers for, e.g. the hash or id the sample_response came from. The generated transform skips the input when the response echoes it back (so the other fields enrich the input instead of a copy of it), and samples.json records it so the smoke test sends a value the endpoint accepts. A curl scaffold defaults to the value in the request; give it for an openapi scaffold, which otherwise only has the spec's example, if any. primary: Path of the field to use as each record's primary entity, the one every other field attaches to as a property, written like a mappings path (e.g. 'SHA-1' or 'hits.hits[]._id'). It must map to an entity type; the error names the valid candidates.

list_operationsA

List the operations in an OpenAPI spec and what scaffolding each would produce.

One row per operation: HTTP method, path, operation id (pass it to scaffold_transform's operation_ids), the transform id it would get, the inferred input entity, whether the spec has a response schema to map outputs from, and why an operation would be skipped. Nothing is written.

Args: openapi: An OpenAPI/Swagger spec in JSON or YAML: a URL, a file path, or the document itself (as text or as an object). service: The service name you will scaffold under, so the transform ids shown match the ones scaffold_transform generates.

remove_scaffoldA

Delete a scaffolded service directory and its imports in project.py.

Use this to undo a scaffold. Deleting server/transforms// by hand leaves its imports behind, and the server then fails to start. Restart the server afterwards. Only services the scaffolder generated are removed: a hand-written service (its api.py lacks the scaffold's generated marker) is refused, and the output says so.

Args: service: Service name slug, the directory name under server/transforms/.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 14 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: server lifecycle (start/stop/restart/status/logs), transform execution (run_transform), scaffolding (scaffold_transform, list_operations, remove_scaffold), listing (list_transforms, list_entities), and configuration (generate_certs, get_seed_url). No two tools overlap in a way that would cause misselection. Descriptions reinforce the boundaries.

Naming Consistency4/5

All names use snake_case, and most follow a verb_noun pattern (list_transforms, run_transform, get_transform). The server lifecycle tools use noun_verb (server_start, server_stop), which is a minor deviation but still predictable and grouped. No chaotic mixing.

Tool Count5/5

14 tools is well within the ideal range for this domain. Each tool earns its place, covering distinct operations without redundancy. The set is neither too thin nor too heavy.

Completeness5/5

The surface covers server lifecycle, transform listing and execution, scaffolding from APIs, removal of scaffolded services, entity listing, certificate generation, and seed URL setup. CRUD-like coverage for transforms is present (create via scaffold, read via list/get, run, delete via remove_scaffold for generated ones). Minor gaps like editing hand-written transforms are acceptable given the scaffold-centric workflow.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive