Fetch the full markdown twin of any shipshapedata.com page (articles, services, industries, case studies). Pass the page URL or path, e.g. "/resources/data-architecture/data-cleaning/".
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page URL or absolute path on shipshapedata.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context by specifying the output is a 'full markdown twin', which tells the agent what kind of content to expect and implies the returned format is markdown rather than raw HTML or JSON metadata.
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 sentences with no wasted words. The core behavior is front-loaded, the scope is stated clearly, and the example is compact and illustrative.
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 single-parameter read-only tool with rich annotations and no output schema, the description is sufficient. It states what is fetched, what input to provide, and what the return format looks like. Nothing essential is missing for an agent to invoke it correctly.
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 coverage is 100%, so the schema already documents the single parameter. The description adds value by giving a usage pattern ('Pass the page URL or path') and a realistic example path, which clarifies the expected format beyond the schema's plain description.
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 uses a specific verb ('Fetch') and resource ('full markdown twin of any shipshapedata.com page'), with page types enumerated. The example path further clarifies exactly what the tool operates on, making it easy to distinguish from the sibling tools that list sections or search docs.
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 calling instructions ('Pass the page URL or path') and a concrete example, which implies the intended use. However, it does not explicitly state when to prefer this over list_sections or search_docs, so exclusionary guidance is left to inference.
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 serves a clearly distinct purpose: search_docs finds relevant content, list_sections provides structural orientation, and get_page retrieves a specific page's content. There is no meaningful overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern: get_page, list_sections, search_docs. The naming is uniform, predictable, and immediately conveys each tool's action.
Three tools are well-scoped for a documentation-oriented server. Each tool covers a distinct need—searching, exploring structure, and retrieving content—without redundancy or unnecessary bloat.
The tool set provides full coverage for navigating and consuming documentation: discover via search, orient via section listings, and retrieve via page fetch. No obvious gaps or dead ends exist for the stated purpose.