Docs Q&A: search 169 data and AI guides, fetch any page as markdown. Read-only, keyless.
Scored across 3 tools
The three tools have clearly distinct roles: search_docs discovers pages, list_sections provides orientation and category listings, and get_page retrieves full page content. While list_sections and search_docs both aid discovery, their descriptions make the boundary clear.
All tool names follow a consistent snake_case verb_noun pattern: get_page, list_sections, search_docs. There are no naming style deviations.
Three tools are well-scoped for a documentation retrieval server: discover, orient, and fetch. Each tool earns its place without unnecessary surface area.
The surface covers the full read-only documentation workflow: searching, listing sections/categories, and fetching full markdown pages. No obvious gaps 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: 200 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?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is corpus scope and return shape — it tells the agent results carry the questions each page answers plus URLs. That is exactly the context needed to plan a follow-up get_page call; only search semantics (keyword vs. semantic matching) are left unexplained.
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, both load-bearing: the first defines the corpus and its size, the second defines the return payload. No filler, and the most decision-relevant information is front-loaded.
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?
With no output schema, the description correctly compensates by naming what a result contains (question + URL). For a two-parameter read tool this is close to complete; what's missing is search behavior detail (relevance ranking, whether zero results are possible) and a pointer to get_page for full content.
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%, with both query and limit (max 25, default 5) documented in the schema itself. The description adds nothing about query phrasing strategy or how limit affects ranking, so baseline 3 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?
States a specific verb (search) and a well-scoped resource (Shipshape Data documentation, quantified as 200 guides plus service/industry pages), so an agent knows exactly what corpus is being queried. It does not explicitly differentiate itself from siblings get_page and list_sections, which is the one thing keeping it from a 5.
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?
Usage is implied: this is clearly the discovery step whose results (URLs) feed a page fetch. But there is no explicit 'use this when you need to find a page, use get_page when you already have the URL' routing statement, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and read Vector Panda docs: API operations, pricing, storage tiers, measured benchmarks.
Convert PDFs, Office docs, websites and audio into AI-ready Markdown, then search and ask your docs.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
Read-only search over the aidata.stream documentation, blog, changelog, pricing and FAQ.
Add one secure layer between your agents and this server.
