Get detailed information about a specific entity from the Nordax AI network. Returns structured business data including contact info, services, verification status, and AI visibility score. Use the entity slug (from search results) or entity name.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The entity slug (e.g. 'acme-plumbing-abc123') or entity name to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It describes what data is returned but does not mention that it is a read-only operation, any authentication requirements, or potential side effects. This is adequate but leaves gaps for a fresh tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and return value. No redundant or filler content. Efficiently conveys the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool, it describes the return structure sufficiently. No output schema exists, so the description covers the return data well. Missing details on error cases or non-existence, but overall complete enough for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter well (100% coverage). The description adds a slight improvement by noting the slug comes from search results, aiding the agent in understanding where to obtain the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves detailed information about a specific entity, listing specific data categories (contact info, services, etc.) that distinguish it from more specific sibling tools like get_entity_credential or get_entity_verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use the entity slug from search results or the entity name, providing practical guidance. However, it does not explicitly state when not to use this tool (e.g., when only a specific field is needed) or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Multiple tools have overlapping purposes: 'fetch' and 'get_entity' both retrieve entity details; 'search' and 'search_entities' are nearly identical; 'attest_entity' and 'get_entity_credential' both provide cryptographic proofs. This ambiguity makes it difficult for an agent to select the correct tool.
Tool names use snake_case but with inconsistent verb choices (e.g., 'get' vs 'fetch', 'check' vs 'verify') and varying levels of detail (e.g., 'list_entities_by_category' is verbose while 'search' is generic). Some names are distinct but the pattern is not uniform.
With 13 tools, the server is well-scoped for an entity trust network. The number covers search, details, verification, attestation, authorization, and feedback without being overwhelming. Slightly on the higher side but reasonable.
The tool set covers core read and verify operations well, but lacks tools for creating or updating entities (e.g., register_entity). Feedback is included for improving trust scores, but the surface feels incomplete for full lifecycle management, though that may be intentional.
