oruk_get_startedQuickstart for the oruk Speech API and this MCP server: how to get an API key, per-client MCP configuration snippets, SDK install commands, and an optional routing rule the user can add to their agent instructions. No API key required. Use this when setting oruk up for the first time or when the user asks how oruk works.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by noting 'No API key required' and describing the kind of guidance returned. It does not go into depth about the exact output format, but that is not essential for an informational quickstart.
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?
The description is a tight two sentences. The first sentence front-loads the tool's role and lists the contents; the second adds usage timing. No wasted words.
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 parameterless, read-only informational tool, the description covers what the tool does, what it returns, and when to use it. It is complete on its own without needing an output schema.
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 schema has zero parameters, so the description does not need to explain any. The baseline of 4 is appropriate because the tool takes no input and the description correctly omits parameter details.
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 opens with 'Quickstart for the oruk Speech API and this MCP server' and lists specific deliverables (API key, MCP config snippets, SDK install commands, routing rule), making its purpose unmistakable. It clearly distinguishes itself from sibling tools that analyze speech, check credits, or create trial keys.
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?
Provides explicit guidance: 'Use this when setting oruk up for the first time or when the user asks how oruk works.' This is direct and actionable, leaving no doubt about when to invoke this tool versus the analysis or transcription tools.
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 audio tool has a clearly distinct mode—words only, tone only, or both—and the descriptions explicitly cross-reference which tool to use for each need. The support tools (credits, trial keys, model listing, onboarding) are also cleanly separated and unlikely to be confused.
Tools consistently use an oruk_<verb>_<object> pattern, such as oruk_transcribe_audio, oruk_list_models, and oruk_check_credits. oruk_get_started is the one mild deviation, using an idiomatic verb phrase rather than a clear object, but it remains recognizable and does not harm usability.
Seven tools is well-scoped for this server: three core speech capabilities, plus four practical setup/billing/configuration utilities. Every tool serves a distinct and justified purpose with no missing or redundant surface.
The core speech workflow is fully covered—transcription alone, tone analysis alone, and combined transcript-plus-tone analysis—along with setup, key management, credit checking, and model selection. There are no obvious dead ends in using the API from first setup to running analyses.