Docs Q&A: search 169 data and AI guides, fetch any page as markdown. Read-only, keyless.
Scored across 3 tools
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.
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.
The site's sections and resource categories with article counts, for orientation before searching. Pass a category name to list every guide in it.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional: a resource category name (e.g. "Data & architecture") to list its guides |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond that: the output includes article counts, and passing a category lists every guide in that category. No contradiction with the 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?
Two short sentences with every word earning its place: the first states the main purpose and output, the second explains optional usage. It is front-loaded and easy to scan.
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 tool with one optional parameter and no required arguments, the description covers purpose, parameter behavior, and the substance of the return value (sections, categories, counts, guides). It does not explicitly contrast with siblings beyond the orientation framing, but the tool's complexity is low and the annotations cover safety.
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 input schema already documents the single optional category parameter fully, including an example. The description largely repeats this guidance ('Pass a category name to list every guide in it') rather than adding new semantic detail, so the baseline score of 3 for full schema coverage applies.
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 verb ('list') and resource ('the site's sections and resource categories with article counts'), and frames it as 'orientation before searching,' which distinguishes it from the sibling tools search_docs and get_page. The optional category behavior is also explicitly described.
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 'for orientation before searching' gives a clear usage context and implies this should be called before search_docs rather than for page retrieval. It does not name alternatives or state when-not-to-use conditions, so it stops short of full explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Shipshape Data's documentation: 169 practical guides on data and AI plus the service and industry pages. Results include the questions each page answers and its URL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 5 | |
| query | Yes | What you want to know, e.g. "what is data lineage" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context by specifying the result shape (questions each page answers and URL), which goes beyond what annotations provide.
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?
A single sentence that front-loads the action and scope, then concludes with the key result detail. No wasted words or repetition of schema or annotation information.
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 search tool with two well-documented parameters and read-only/idempotent annotations, the description covers the essential behavior and result contents. It could explain more about result ordering or how to use the returned URL, but it is adequate for correct selection and invocation.
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%: both query and limit are fully described in the input schema. The description does not add parameter-level details beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 identifies a specific verb ('Search') and a specific resource ('Shipshape Data's documentation'), and further narrows the scope to 169 guides plus service/industry pages. This distinguishes it from sibling tools like get_page and list_sections by action and purpose.
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 implies search_docs is for finding documentation content, but it does not explicitly say when to use it over get_page or list_sections. There is no exclusion or alternative guidance, only a clear statement of what the tool searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_pagelist_sectionssearch_docsSearch and read Vector Panda docs: API operations, pricing, storage tiers, measured benchmarks.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Read-only search and Markdown access to liz's public docs, prompts, resources, and an MCP App.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Add one secure layer between your agents and this server.
