How to contact the Shipshape Data team on a user's behalf (email; a person replies, usually within one working day). This server has no write tools.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the annotations: contact is via email, a human replies, and replies usually arrive within one working day. It also reinforces the read-only nature by stating the server has no write tools. This is consistent with the readOnlyHint, idempotentHint, and destructiveHint annotations.
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 compact and front-loaded with the core purpose, followed by a concise behavioral note. Both sentences add meaningful information: the first explains what the tool does, and the second sets server-level read-only expectations. There is no redundancy or filler.
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 zero-parameter, no-output-schema tool, the description is complete. It covers how to contact the team, what kind of response to expect, and the server-level constraint that no write tools exist. An agent has enough information to decide when and how to use 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?
The tool has zero parameters, so there is no parameter semantics burden on the description. The empty schema is fully self-explanatory, and the description appropriately focuses on the tool's behavior rather than inputs.
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: contacting the Shipshape Data team on a user's behalf via email. It also adds the expected response behavior (a person replies, usually within one working day), which makes the tool's role unambiguous and distinguishes it from the content-oriented sibling tools.
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 gives clear context for when this tool is appropriate: when an agent needs to contact the team on a user's behalf. It also notes that the server has no write tools, which helps set expectations. It does not explicitly name alternatives or exclusion criteria, but no sibling tool is a direct alternative.
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: retrieving assessment questions, scoring assessment answers, listing services, retrieving case studies, searching resources, and providing contact info. The only related pair—get_ai_readiness_questions and score_ai_readiness—are complementary rather than overlapping, with one delivering the questions and the other processing the answers.
All tool names follow a consistent snake_case verb_noun pattern: get, list, score, and search. The naming style is uniform and predictable, making it easy for an agent to infer behavior from the tool name alone.
Six tools is a well-scoped size for a company information and readiness-assessment server. Each tool contributes a distinct function with no redundancy, and the count is comfortably within the ideal range.
The tool surface covers the server's apparent purpose comprehensively: services, case studies, resources, contact information, and a complete AI readiness assessment flow. The explicit note that the server has no write tools appropriately sets expectations, and users can obtain URLs/markdown for deeper content.