get_techsList all technicians with their contact information and role flags. Data is cached for 30 minutes to minimize API requests.
List all technicians. Returns names, contact info, and role flags. Cached 30 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by stating that results are cached for 30 minutes and by summarizing the returned fields (names, contact info, role flags).
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 three short sentences with no filler. The primary action is front-loaded, and each sentence adds value: what it lists, what it returns, and how fresh the data is.
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 simple zero-parameter list endpoint, the description is complete. It covers the operation, the returned data shape, caching behavior, and the annotations cover safety. No output schema exists, but the description compensates by naming the return fields.
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 schema coverage is 100%, so there is nothing for the description to clarify. Baseline for a zero-parameter tool is 4.
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 states a specific verb and resource: 'List all technicians.' It also distinguishes itself from the sibling get_tech_details by focusing on the full list rather than a single technician's details.
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 phrase 'List all technicians' gives clear context for when to use this tool: when a complete list of technicians is needed. It does not explicitly name alternatives like get_tech_details, but the broad scope is clear and no exclusion criteria are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.