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

Tools

Functions exposed to the LLM to take actions

NameDescription
discover_capabilitiesA

Map a plain-language goal (e.g. 'send a transactional email') to callable APIs, MCP servers or CLIs. Returns matches[] with slug, endpoint, auth, formats, rate limit, pricing and a 0-100 reliability score; if nothing fits, coverage='none' and matches[] lists reliable starting points. Rate limits: 100 calls/day anonymous, 1,000/day with a free key, 50,000/day on Agent Pro. For a known keyword or slug, use search_registry.

search_registryA

Keyword lookup in the Agent Nexus registry when you already know what to look for: a product name, vendor, slug or endpoint fragment, optionally narrowed to one category. Matches literal text only — it does not interpret a goal. To go from a plain-language need to a callable interface, use discover_capabilities instead; to walk the whole catalogue in order use list_entries, and for the full record of one known slug use get_entry. Read-only and side-effect free. Returns {count, results[]} where each result is a summary entry record (slug, name, category, summary, endpoint, trust fields). Results are ordered alphabetically by name, not by relevance; there is no pagination beyond the limit parameter — raise limit (max 50) or narrow the query to see more. An empty results[] when nothing matches is a valid answer, not an error.

get_entryA

Fetch the full record of ONE approved registry entry whose exact slug you already have, e.g. from a previous discover_capabilities, search_registry or list_entries result. Read-only and idempotent: the same slug always returns the same entry until its health probe changes. Returns {entry} with endpoint, auth mode and parameters, input/output formats, rate limit, pricing, capabilities, docs URL, invocation example and the latest 6-hourly health probe — the detail level the listing tools omit. This is the single-record lookup: it takes no filters and no paging. If you do not have a slug, do not guess one — use search_registry for a keyword or discover_capabilities for a plain-language need; to walk the whole catalogue use list_entries. An unknown or unapproved slug is an error, not an empty result.

list_categoriesA

Return the fixed taxonomy of Agent Nexus: the three interface layers it indexes ('api', 'mcp', 'cli'), each with a label, a one-line definition and its live count of approved entries. Read-only, idempotent and parameterless — call it once to learn the exact values accepted by the 'category' argument of search_registry, list_entries and discover_capabilities, and to size the catalogue before paging. It never returns entries themselves: use list_entries to enumerate a layer, search_registry for a keyword, discover_capabilities for a plain-language need.

list_entriesA

Enumerate the whole approved catalogue in deterministic slug order, page by page — use this when you want everything (mirroring, auditing, building your own index), not when you are looking for something specific. Read-only and idempotent. Returns {total, page, per_page, pages, results[]}: read 'pages' from the first response and increment 'page' until you reach it; 'total' and 'pages' reflect the 'category' filter when one is set, so keep the filter identical across pages or the paging shifts. Entries come back in summary form; call get_entry with a slug for the full record. For a keyword use search_registry, for a plain-language need use discover_capabilities, and for the accepted category values call list_categories. Bulk mirror alternative: GET https://agentnexus.app/api/public/entries.ndjson streams the full catalogue in one request.

submit_entryA

Register a new interface (HTTP API, MCP server or CLI) in the Agent Nexus catalogue. Callers authenticate either as a signed-in member or with a free agent key (POST https://agentnexus.app/api/public/keys), which allows one submission per key and per source address per 24 hours. This is a write: it creates a pending row, it does NOT publish anything — every submission is reviewed by a human before it becomes discoverable, so nothing you send here is visible to other agents until it is approved. Nothing is overwritten or deleted, and re-submitting the same name creates a second pending row rather than updating the first. Five fields are required (name, category, summary, endpoint, auth_mode); everything else is optional but directly decides whether the entry is approved and how well it ranks: capabilities[] is what other agents are matched against, so list concrete verbs, and docs_url plus invocation_example are what a reviewer checks first. Rate limited to 20 submissions per hour for members and 1 per 24 hours per agent key and per source address, and the endpoint must answer a live health probe to keep a reliability score. Returns {slug, status}; poll GET https://agentnexus.app/api/public/submission?slug= for the decision, or pass contact_email to be emailed instead. Use list_my_submissions to review what you already submitted; use search_registry first to check the interface is not already listed.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.6/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: plain-language discovery, keyword search, single-slug lookup, full catalogue listing, category taxonomy, and submission. The descriptions explicitly cross-reference boundaries (e.g., discover_capabilities vs. search_registry) so an agent can reliably tell them apart.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: discover_capabilities, search_registry, get_entry, list_categories, list_entries, submit_entry. The convention is predictable and readable throughout.

Tool Count5/5

Six tools is well within the ideal 3-15 range and each earns its place: five read operations cover discovery, search, lookup, enumeration, and taxonomy, while one write operation handles submission. There are no redundant or filler tools.

Completeness3/5

Core discovery is thorough, covering goal-based, keyword, single-record, full-catalogue, and category views. However, the submission lifecycle has notable gaps: the referenced list_my_submissions tool is absent, and there is no update, delete, or submission-status tool, creating a dead end after submitting.

Maintenance

ActivityActive
ResponsivenessNo issues