business.getInspection step: resolve one discovered business by its stable AgentPort registry slug and inspect its exact published capability/action keys. For actionable requests, this is not final resolution; call capability.resolve after the relevant canonical keys are known.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior, so the description adds useful context beyond that: the workflow stage, the stable-slug requirement, and the fact that the tool exposes exact published capability/action keys. This effectively explains what the call will return without contradicting the annotations.
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 with no filler. The inspection-step framing is front-loaded, the core action is stated immediately, and the routing guidance to capability.resolve is placed at the end without redundancy.
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?
Given the absence of an output schema, the description does a good job indicating what can be learned from the result: exact published capability/action keys. Combined with clear workflow positioning and sibling differentiation, little is left ambiguous for such a simple single-parameter read-only tool.
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?
Schema description coverage is 0%, but the description supplies important meaning for the single parameter: slug is a stable AgentPort registry slug for a discovered business. This tells the agent to use a canonical identifier from a prior discovery step rather than arbitrary text, complementing the schema's format pattern.
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?
The description clearly states the tool resolves and inspects a business by its stable AgentPort registry slug, with a specific purpose: to view exact published capability/action keys. It also distinguishes itself from capability.resolve by explicitly noting this is not final resolution for actionable requests.
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?
The description frames the tool as an 'inspection step' and tells the agent to call capability.resolve after canonical keys are known for actionable requests. It also implicitly scopes usage to already-discovered businesses, indicating business.search would be the discovery path.
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.
Each tool has a clearly distinct role: business.search finds candidates, business.get inspects a specific business's published capability keys, and capability.resolve maps a structured goal to execution paths. There is no meaningful overlap between them.
All tool names follow the same [domain].[verb] pattern: business.get, business.search, capability.resolve. The naming is consistent, readable, and predictable.
Three tools is well-scoped for a focused discovery server: search, inspect, and resolve. Each tool earns its place in the workflow without redundancy.
The tool surface covers the full discovery lifecycle: finding businesses, examining exact capability keys, and resolving actionable goals to execution paths. The cross-references between tools prevent dead ends and guide agents to the correct sequence.