Skip to main content
Glama

AgentNexus.App

Submit an interface to the registry

submit_entry

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 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 for agent keys, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesPublic product name as its vendor spells it, 1-80 chars, e.g. 'Resend' or 'GitHub MCP Server'. Do not add the category or a tagline here; the slug is derived from this name plus the category.
tagsNoUp to 8 short domain labels for browsing, e.g. ['email','messaging']. Domains, not actions — actions belong in capabilities[].
pricingNoCost in one short phrase, e.g. 'Free', 'Free tier then $20/month', 'Usage-based, $0.001/call'. Agents filter on this, so be concrete.
summaryYesOne line an agent can rank on: what the interface does, 10-300 chars. State the capability, not the marketing (e.g. 'Send transactional email over HTTP with templates and delivery webhooks').
categoryYesWhich layer this interface belongs to: 'api' for an HTTP contract called directly, 'mcp' for a Model Context Protocol tool server, 'cli' for a command-line surface. Decides how endpoint is interpreted (URL vs command).
docs_urlNoAbsolute https URL of the developer documentation (not the marketing home page). Omit if none exists; submissions without it are approved more slowly.
endpointYesHow the interface is actually reached, max 500 chars. For category 'api' the base URL (https://api.example.com/v1); for 'mcp' the server URL (https://example.com/mcp) or stdio command; for 'cli' the install-and-run command (npx example-cli). Must be reachable: it is probed every 6 hours and a dead endpoint loses its reliability score.
auth_modeYesHow a caller authenticates, in a few words: 'none', 'Bearer API key', 'API key in query', 'OAuth 2.1', 'Basic auth'. Write 'none' rather than leaving it vague; auth_params carries the individual credentials.
rate_limitNoPublished quota in the vendor's own words, e.g. '100 requests/minute', '10k calls/month on the free tier'. Leave empty rather than guessing.
auth_paramsNoUp to 10 individual credentials the caller must supply, each {name, location, required}. Leave empty when auth_mode is 'none'. Never include credential values here, only their names.
descriptionNoOptional long form, max 4000 chars: what the interface does well, notable limits, quirks an agent should know before calling. Plain text; no HTML.
capabilitiesNoUp to 12 lowercase hyphenated verbs an agent's need is matched against, e.g. ['send-email','list-templates','verify-address']. This is the single field that drives discovery: an entry with no capabilities is rarely returned. One action per item, 2-40 chars, no sentences.
input_formatNoMIME type or shape the interface accepts, e.g. 'application/json', 'multipart/form-data', 'command-line flags'. Empty string when not applicable.
contact_emailNoOptional. Where to email the moderation decision (approved or rejected, with the reason). Never published, never shared.
output_formatNoMIME type or shape the interface returns, e.g. 'application/json', 'text/csv', 'stdout text'. Empty string when not applicable.
invocation_exampleNoOne copy-pasteable call that works: a curl command, a JSON-RPC body or a CLI line, max 1000 chars. Never include a real credential — use a placeholder such as $API_KEY. This is what reviewers check first.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYes
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false. The description goes far beyond that: it discloses that submissions are human-reviewed, not immediately visible, re-submissions create duplicate pending rows, nothing is overwritten or deleted, rate limits (20/hour members, 1/24h agent keys), and that the endpoint is health-probed every 6 hours. This is rich behavioral context that annotations cannot convey.

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?

The description is dense but well-organized: purpose, auth, write semantics, required fields, rate limits, return value, and sibling routing all appear in a logical order. It is long, but every sentence carries operational information an agent needs. A slight trim of the health-probe detail could tighten it, but nothing is redundant.

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?

For a 16-parameter write tool with an output schema, the description covers everything an agent needs to call it correctly: auth method, required fields, rate limits, review workflow, return shape, polling/email follow-up, and sibling tools. The output schema exists, so the description needn't enumerate return fields, and it doesn't. This is complete.

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 description coverage is 100%, so the schema already documents every parameter. The description adds value by prioritizing the five required fields, explaining that capabilities[] drives discovery, and noting that docs_url and invocation_example are what reviewers check first. It doesn't restate every schema detail, which is appropriate, but it does add decision-relevant semantics beyond the schema.

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 opens with a specific verb and resource ('Register a new interface... in the Agent Nexus catalogue') and immediately distinguishes the three accepted interface types (HTTP API, MCP server, CLI). It also clarifies the write semantics ('creates a pending row, it does NOT publish anything'), which separates it from read-only siblings like search_registry and get_entry. The purpose is unmistakable.

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?

The description gives explicit when-to-use guidance: authenticate as a member or with a free agent key, check the registry first with search_registry, and use list_my_submissions to review prior submissions. It also states what this tool is not for (it does not publish, update, or delete). This is exemplary routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources