Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AGENTHIVE_URLYesThe URL of your AgentHive host, e.g. https://your-agenthive-host
AGENTHIVE_TOKENYesYour personal AgentHive API token
AGENTHIVE_TEAM_IDYesYour AgentHive team ID

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
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
retrieve_contextA

Retrieve a bounded neighborhood of this team's reviewed, approved memory around a topic. Call this once at the start of a session, before starting work, so you inherit what teammates already learned instead of rediscovering it. anchor is the topic/title to search around (e.g. "Postgres connection pool exhaustion"); hops bounds how far the traversal spreads from it (default 2); hub_cutoff stops traversal through overly-connected "hub" nodes so one popular node doesn't pull in the whole graph. Returns a neighborhood list of memory nodes plus approx_tokens, what folding them into context would actually cost.

log_sessionA

Log what happened this session as a memory node for the team to reuse. Call this once at the end of a session that learned something worth keeping - a root cause, a fix, a decision, a gotcha. The node starts PENDING and is invisible to retrieve_context until an admin approves it (or it matches an auto-approve rule) - this is a deliberate review gate, not a bug. title is a short, searchable summary (this is what future retrieve_context anchors match against); body is the actual content; tags and links are optional and help retrieval and review. agent_id/task_id are optional ids from create_agent/create_task - attaching them lets an admin auto-approve by agent (see create_auto_approve_rule, admin-only) and lets future retrieval be scoped to a task.

create_agentA

Register an agent identity with the team, so logged sessions can be attributed to it (pass the returned id as log_session's agent_id) and so an admin can target it with an auto-approve rule. name is how it shows up in the review UI; description and system_prompt are optional context for reviewers.

list_agentsA

List the agent identities already registered with this team, e.g. to find an existing agent's id instead of creating a duplicate with create_agent.

create_taskA

Register a task with the team, so logged sessions can be scoped to it (pass the returned id as log_session's task_id) - useful when several sessions across one piece of work should be filterable together later. name is how it shows up in the review UI; description is optional context.

list_tasksA

List the tasks already registered with this team, e.g. to find an existing task's id instead of creating a duplicate with create_task.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct resource and action: retrieve_context and log_session cleanly split reading vs. writing team memory, while create/list pairs keep agents and tasks separate. No two tools could reasonably be confused for the same job.

Naming Consistency5/5

All six tools use the same lower_snake_case verb_noun pattern: retrieve_context, log_session, create_agent, list_agents, create_task, list_tasks. The convention is predictable and immediately conveys both action and resource.

Tool Count5/5

Six tools is a well-scoped size for a team-memory server: two core memory operations plus create/list pairs for the two supporting registries. Every tool earns its place and none are redundant.

Completeness4/5

The core agent-facing workflow is covered: retrieve context before working and log session afterwards, with agent/task registration for attribution. Minor gaps remain—no update/delete for agent/task registries and no admin approval/auto-approve tools despite log_session referencing the review gate—but agents can work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues