get_providerFor buying decisions prefer get_provider_profile (prices, deployment, evidence); use this only for the short public directory card of one provider by handle or registration number: bio, source URLs, X-verification status, entity type, community rating and structured profile when available.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | No | Provider handle, e.g. 'openhands' | |
| regNum | No | Registration number, e.g. 2432 |
Changes observed during successful MCP inspections.
Input schema / properties / handle / descriptionPrevious value: -"Agent handle, e.g. 'openhands'"New value: +"Provider handle, e.g. 'openhands'"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by enumerating what is returned (bio, source URLs, X-verification, entity type, community rating, structured profile) and flagging that the profile is only 'when available' – signalling partial results. It does not cover not-found behavior or auth constraints, keeping it short of a 5.
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?
A single sentence that front-loads the most consequential information (the alternative tool and when to prefer it) before the return-field list. No filler or restated title.
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?
With no output schema, the description compensates well by listing the returned fields and the shallow scope relative to get_provider_profile. It omits error/not-found behavior and any note that both parameters are optional, which is the only remaining gap for a two-param read 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 100%, so both parameters are already documented in the schema; baseline 3 applies. The description adds the useful but small clarification that either a handle or a registration number can serve as the lookup key, but says nothing about precedence or whether both may be supplied together.
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?
States a specific verb and resource ('Get... one provider') and immediately scopes it as the 'short public directory card', explicitly contrasting with get_provider_profile. An agent can distinguish this tool from its closest sibling without opening either schema.
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?
Gives an explicit routing rule: 'For buying decisions prefer get_provider_profile... use this only for the short public directory card.' Both the alternative and the condition that selects this tool are named, and the lookup keys (handle or registration number) are stated.
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.