GetAuthInfoGet Secureship API authentication instructions. Call this FIRST before generating any code examples with authentication headers. Secureship uses X-API-KEY header authentication, NOT Bearer tokens.
| 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, so the safety profile is known. The description adds valuable behavioral context beyond the annotations: it reveals the specific authentication scheme (X-API-KEY header) and explicitly warns against Bearer tokens. This gives the agent actionable knowledge it wouldn't get from the schema or annotations alone, though it doesn't describe the exact response format.
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 extremely concise—two sentences totaling about 20 words. The first sentence front-loads the core purpose, and the second delivers a critical usage instruction plus a key distinguishing detail. No words are wasted, and every piece of information earns its place.
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 (zero parameters, no output schema), the description is complete: it states what the tool does, when to call it, and the essential authentication detail. It also implicitly distinguishes itself from sibling tools by focusing on auth info. For an informational tool, this fully covers the agent's needs.
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 tool has zero parameters, and the schema coverage is trivially 100%. Per the baseline for 0-parameter tools, this scores a 4. The description doesn't need to explain parameters, but it does clarify that the tool returns 'authentication instructions' and highlights the key header type, adding semantic value beyond the empty schema.
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's purpose: 'Get Secureship API authentication instructions.' It uses a specific verb ('Get') and a specific resource ('authentication instructions'), and it distinguishes itself from sibling tools (GetEndpointDetail, ListEndpoints, SearchDocs) by focusing solely on authentication. The explicit instruction to 'Call this FIRST' further clarifies its unique role.
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 provides explicit usage guidance: 'Call this FIRST before generating any code examples with authentication headers.' This tells the agent exactly when to invoke the tool. It also warns against using Bearer tokens, which helps prevent incorrect usage. While it doesn't name alternative tools, the context makes it clear that this is the preliminary step for authentication-related tasks.
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 purpose with no overlap: GetAuthInfo provides authentication instructions, ListEndpoints offers discovery, SearchDocs enables targeted searching, and GetEndpointDetail gives detailed schemas. The descriptions explicitly guide when to use each tool, preventing misselection.
All tool names follow a consistent verb_noun pattern (GetAuthInfo, GetEndpointDetail, ListEndpoints, SearchDocs) with clear, descriptive naming. There are no deviations in style or convention, making the set predictable and readable.
With 4 tools, this server is well-scoped for its purpose of API documentation and discovery. Each tool earns its place by covering essential steps: authentication guidance, endpoint listing, searching, and detailed schema retrieval, without being overly sparse or bloated.
The tool set provides complete coverage for the domain of API exploration and usage. It supports the full workflow from initial authentication to endpoint discovery, search, and detailed schema access, with no obvious gaps that would hinder an agent in interacting with the Secureship API.