Return domain name suggestions for an idea: available .com, .io and .ai domains matched to the concept. Use it to secure a name once you have decided to build. Read-only and free; pass an ideaId you own.
| Name | Required | Description | Default |
|---|---|---|---|
| ideaId | Yes | The idea ID |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | The tool result rendered as human and AI readable text or markdown. |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "result": {
+ "description": "The tool result rendered as human and AI readable text or markdown.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "result"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'Read-only and free; pass an ideaId you own' beyond annotations (readOnlyHint: true, openWorldHint: true). This clarifies cost implications and ownership requirement, which annotations don't cover. Slight deduction because it doesn't describe what happens if the ideaId doesn't exist or if domains are unavailable, but overall strong behavioral context.
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 clear sentences, no redundant phrases, highly efficient. The first sentence states the core function, the second adds behavioral and usage context. Every word adds value.
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 tool's simplicity (single required param, no enums, output schema exists, read-only), the description fully covers purpose, usage, and behavioral traits. The output schema handles return value documentation. No gaps remain for an agent to misinterpret this 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% with the ideaId parameter already described as 'The idea ID' in the input schema. The description adds no new parameter-level detail beyond the schema's existing description. Per guidelines, baseline is 3 when coverage is high, and no extra semantics are provided.
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 returns domain name suggestions for an idea, specifying it covers available .com, .io, and .ai domains matched to the concept. It uses a specific verb ('Return') and resource ('domain name suggestions'), and distinguishes from siblings like get_pivot_suggestions or get_similar_startups by focusing on domain availability.
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 states when to use it: 'Use it to secure a name once you have decided to build.' This guides the agent to invoke it after concept validation, before domain purchase. No alternatives or exclusions are needed given the unique niche; the sibling list includes no other domain tools, making the guidance unambiguous.
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.