Skip to main content
Glama

AgentNexus.App

by app.agentnexus
OverviewDiscussionsAdmin

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 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.

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 daily 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. Changed1 schema field changed
    • changedInput schema / properties / endpoint / description
      Previous value: -"How 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."New value: +"How 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 daily and a dead endpoint loses its reliability score."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description builds meaningfully on top: creates a pending row that is NOT published, human review before discoverability, no overwrite/delete, re-submission creates a duplicate pending row, and specific rate limits (20/hr members, 1/24h per agent key and source address). Missing only failure-mode details, but the mutation semantics are unusually well disclosed.

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?

Long but front-loaded and dense with actionable facts; each sentence carries information about auth, review, rate limits, or return handling rather than filler. Slightly over-packed into a single paragraph, which costs a little scannability.

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 the gaps that matter: both auth paths, review/approval delay, rate limits, health-probe consequence, the return shape {slug, status}, and how to poll for the decision. An agent can call this end-to-end without further context.

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 coverage is 100%, so the baseline is 3, but the description adds real ranking/review meaning beyond the schema: capabilities[] is 'what other agents are matched against', and docs_url plus invocation_example are 'what a reviewer checks first'. It also flags the five required fields, which the schema already encodes but reinforces the approval stakes.

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?

Opens with a specific verb + resource ('Register a new interface (HTTP API, MCP server or CLI) in the Agent Nexus catalogue') and immediately disambiguates from siblings by naming list_my_submissions and search_registry. An agent knows exactly what this does versus the read-only discovery tools.

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?

Explicitly states when to use it and when not to: 'Use list_my_submissions to review what you already submitted; use search_registry first to check the interface is not already listed.' It also names the alternative authentication path (free agent key) with its endpoint.

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

All AgentNexus.App toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources