Agent Nexus

Check a service is up and how to call it

get_entry

Read-onlyIdempotent

Before calling a known service, check it is live right now and get its exact contract. Fetches 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 health probe (hourly for priority entries, otherwise on a rolling daily cycle) — 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.

Input Schema

Name	Required	Description	Default
`slug`	Yes	Exact lowercase slug of one entry, 1-80 chars, as returned in the 'slug' field of any other tool, e.g. 'stripe-api' or 'github-mcp'. Case-sensitive, no URL and no display name; only entries with status 'approved' resolve.

Output Schema

Name	Required	Description	Default
`entry`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 22, 2026

changedInput schema / properties / slug / description

Previous value: -"Entry slug, e.g. 'stripe-api'."New value: +"Exact lowercase slug of one entry, 1-80 chars, as returned in the 'slug' field of any other tool, e.g. 'stripe-api' or 'github-mcp'. Case-sensitive, no URL and no display name; only entries with status 'approved' resolve."

Changed1 schema field changedSep 21, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "entry": {}
+  },
+  "required": [
+    "entry"
+  ],
+  "type": "object"
+}

First observedSep 16, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well past them with error semantics ('An unknown or unapproved slug is an error, not an empty result') and health-probe freshness cadence (hourly for priority entries, otherwise rolling daily). It also flags the value proposition over siblings: 'the detail level the listing tools omit.'

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?

Front-loaded with the purpose, then scope, then return shape, then fallback routing — a logical order with no filler. It runs long at five sentences and repeats the read-only/idempotent point the annotations already carry, so it is slightly denser than necessary.

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?

Despite an output schema, it still previews the {entry} payload fields, which tells the agent this call is worth making versus a listing tool. Precondition, error behavior, and fallback paths are all present; nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already spells out case-sensitivity, 1-80 chars, no URL/display name, and approved-only resolution. The description reinforces the 'exact slug, don't guess' constraint but adds no format or syntax detail beyond the schema field.

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?

States a specific verb and resource ('Fetches the full record of ONE approved registry entry') and immediately scopes it ('takes no filters and no paging'). The distinction from search_registry, discover_capabilities and list_entries is explicit, so an agent can route without inspecting any schema.

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?

Gives the precondition ('whose exact slug you already have, e.g. from a previous ... result'), the alternatives for each missing-slug case ('use search_registry for a keyword or discover_capabilities for a plain-language need'), and an explicit prohibition ('do not guess one'). The catalogue-walk case is routed to list_entries as well.

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

All Agent Nexus tools Inspect

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.