Find 13 free campervan/RV worksheets, plan trip records, and view companion-book information.
Scored across 4 tools
Each tool has a distinct role: directory metadata (get_rv_library_info), single-item retrieval by ID (get_rv_worksheet), topic search (search_rv_worksheets), and workflow orchestration (plan_first_rv_trip). Minor overlap between the directory and search tools since both return worksheet summaries, but the boundaries are clear enough.
All names use snake_case with a verb_noun structure (get_rv_library_info, get_rv_worksheet, plan_first_rv_trip, search_rv_worksheets). The verbs vary (get/get/plan/search) but remain readable and predictable.
Four tools is slightly lean, but each earns its place for a static read-only worksheet library: browse, retrieve, search, and plan. No tool appears redundant or unnecessary.
The surface covers the full read-only lifecycle of the library: overall metadata, individual worksheet access, search, and a usage helper. As a public free-content library, no create/update/delete operations are expected, though there is no bulk export or multi-worksheet fetch beyond planning.
Return the complete public library directory: all 13 free worksheet summaries, the 30-page blank PDF pack, eight-page fictional examples, ZIP and printing help, plus optional companion-book title, author and three purchase options: PDF + EPUB on Gumroad, Kindle on Amazon, and paperback on Amazon, with separate formats, listed USD prices, verified purchase URLs and Amazon.fr alternatives. Free worksheets require no book purchase. This tool supplies metadata and links; it does not fetch downloads, buy anything or return paid book text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| library | Yes | |
| publisher | Yes | |
| worksheets | Yes | |
| catalog_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. On top of that the description adds real behavioral context: it returns metadata and links only, does not fetch binaries, does not transact, and does not expose paid book text.
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?
Front-loaded and single-purpose, but the long middle sentence is a packed run-on that enumerates counts ('all 13', '30-page', 'eight-page') and formats (PDF, EPUB, Kindle, paperback, Amazon.fr) that the output schema already describes. Given an output schema exists, much of that inventory is spend that doesn't earn its place.
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 read-only tool with full annotations and an output schema, the agent has everything it needs: what the call returns, that it is side-effect free, and what it will not do. The only gap is that it never routes the agent to a sibling for the actual download.
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 takes zero parameters, so there are no argument semantics to clarify; the baseline of 4 applies. The description correctly avoids inventing parameters and doesn't claim any filtering capability the schema lacks.
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 and resource ('Return the complete public library directory') and enumerates what the directory contains, so the agent knows exactly what comes back. It does not name any sibling tool, so the differentiation from get_rv_worksheet / search_rv_worksheets is only implied by 'it does not fetch downloads.'
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?
Provides explicit exclusions: 'it does not fetch downloads, buy anything or return paid book text,' plus the condition that free worksheets require no purchase. That tells the agent when this tool is and isn't appropriate, though it never names the alternative tool to use when the agent does want a download.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one public blank worksheet by its two-digit catalog ID (01–13): purpose, public section/field labels, limits, pages and verified download link. It never requests, stores, or returns completed form values, and gives no equipment diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| publisher | Yes | |
| worksheet | Yes | |
| catalog_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, destructive=false, openWorld=false), so the bar is lower, and the description still adds real behavioral context: it returns metadata only, never completed form values, and performs no diagnosis. It also advertises that a verified download link is included. It stops short of describing pagination or any rate/access constraints, but the data-handling posture is unusually clear.
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, front-loaded with the action and identifier format, followed by boundaries. Every clause earns its place — the returned fields, the ID format, and the two explicit exclusions — with no filler or restatement of the name.
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?
The tool is low-complexity (one required scalar parameter) and an output schema already exists, so return-value documentation is not strictly required — yet the description still summarizes the payload. Combined with the exclusions and the ID range, an agent has everything needed to call 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 description coverage is 0% and the single parameter is required, so the description must carry the meaning — and it does, stating the ID is a 'two-digit catalog ID (01–13)', which fully matches the schema pattern ^(0[1-9]|1[0-3])$ and the 01–13 range. It even pre-announces the returned fields, though it adds no example values or lookup guidance beyond the range.
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?
Specific verb (Return) plus resource (one public blank worksheet), scoped by the identifier format (two-digit catalog ID 01–13), and it enumerates the returned payload (purpose, labels, limits, pages, download link). The singular 'one ... worksheet' contrasts cleanly with the sibling search_rv_worksheets, so an agent can select between them without opening either schema.
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 by the required catalog ID and by the explicit exclusions ('never ... returns completed form values', 'gives no equipment diagnosis'), which tell the agent when this tool is not the right one. However, no alternative tool is named and there is no explicit 'use this when you already know the ID, otherwise use search_rv_worksheets' routing statement, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select and order existing public worksheets for a first trip, overnight stop and follow-up. Options add the equipment-specific storage inventory or technician report. It does not plan a route, calculate equipment capacity, diagnose faults, or approve safety. No names, addresses, VINs or contact details are required.
| Name | Required | Description | Default |
|---|---|---|---|
| trip_days | No | ||
| cold_weather | No | ||
| vehicle_type | Yes | ||
| returning_from_storage | No | ||
| unresolved_equipment_issue | No |
| Name | Required | Description |
|---|---|---|
| scope | Yes | |
| limits | Yes | |
| phases | Yes | |
| publisher | Yes | |
| trip_days | Yes | |
| vehicle_type | Yes | |
| catalog_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the privacy/data disclosure: 'No names, addresses, VINs or contact details are required,' plus the fact that it operates on *existing public* worksheets. Useful context beyond the annotations, though nothing on auth or scoping limits.
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?
Three compact sentences, front-loaded with purpose, then options, then scope limits. No filler and each sentence adds a distinct piece of 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?
An output schema exists, so return values need not be described, and annotations cover safety semantics. With purpose, exclusions and privacy stated, the definition is nearly complete; the remaining gap is the 5-parameter semantic layer that the description only vaguely touches.
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 description coverage is 0% across 5 parameters, so the description must carry the load and largely does not. The 'options add the equipment-specific storage inventory or technician report' sentence vaguely gestures at returning_from_storage and unresolved_equipment_issue, but trip_days and cold_weather get no mention and no parameter is named or explained.
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 and resource ('Select and order existing public worksheets') scoped to a first trip, overnight stop and follow-up. The scope is distinctive, but it never names a sibling to differentiate itself from search_rv_worksheets or get_rv_worksheet, so the boundary is inferred rather than stated.
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?
Gives clear when-to-use context (first campervan/RV trip planning) plus explicit when-not exclusions: 'does not plan a route, calculate equipment capacity, diagnose faults, or approve safety.' Strong exclusion framing, but it does not route the agent to the tool that *does* handle those tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a bounded catalog of 13 free blank U.S. campervan/RV worksheets by a short topic. Returns matching form summaries and verified PDF links; it does not search the web or provide general RV advice. Use topic words, not personal details.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| vehicle_type | No | rv |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| scope | Yes | |
| results | Yes | |
| publisher | Yes | |
| vehicle_type | Yes | |
| total_matching | Yes | |
| catalog_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld=false/idempotent/non-destructive, so the bar is low, and the description still adds meaningful behavior: the catalog is bounded to 13 items, the return is matching form summaries plus verified PDF links, and it explicitly does not touch the web. The main omission is pagination/ordering behavior of the result set.
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 dense sentences, front-loaded with what is searched and how, followed by output shape and explicit boundaries. No filler or restatement of the tool name.
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 an output schema present, the description need not explain return values — yet it still summarizes them, and annotations carry the safety profile. Scope, boundaries, and query semantics are all covered; the only real gap is the undocumented vehicle_type filter, which matters for a multi-vehicle-type catalog.
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 description coverage is 0% across 3 parameters, so the description must carry the load. It adds useful meaning for 'query' ('short topic', topic words not personal details), but says nothing about 'vehicle_type' (an enum filter with a default of 'rv') and only glancingly implies 'limit' via 'catalog of 13'. One of three parameters is effectively undocumented.
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?
Clear verb + resource with hard scope: 'Search a bounded catalog of 13 free blank U.S. campervan/RV worksheets by a short topic.' That is far more specific than a generic search tool, and it rules out web search and advice. However, no sibling (e.g., get_rv_worksheet for a single form, get_rv_library_info for catalog facts) is named, so the search-vs-fetch distinction is left to inference.
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?
It gives one real usage instruction ('Use topic words, not personal details') and negative scope ('does not search the web or provide general RV advice'), which implicitly steers agents away from advice/planning siblings. But it never states when to choose this over get_rv_worksheet or get_rv_library_info, so the routing guidance is only implied.
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_rv_library_info4 fields changedOutput schema / properties / library / properties / book / properties / all_formatsAdded value: +{
+ "items": {
+ "enum": [
+ "PDF",
+ "EPUB",
+ "Kindle",
+ "Paperback"
+ ],
+ "type": "string"
+ },
+ "maxItems": 4,
+ "minItems": 4,
+ "type": "array"
+}Output schema / properties / library / properties / book / properties / default_purchase_option_idAdded value: +{
+ "const": "gumroad-pdf-epub",
+ "type": "string"
+}Output schema / properties / library / properties / book / properties / purchase_optionsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alternate_urls": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "marketplace": {
+ "const": "Amazon.fr",
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "marketplace",
+ "url"
+ ],
+ "type": "object"
+ },
+ "maxItems": 1,
+ "type": "array"
+ },
+ "asin": {
+ "pattern": "^[A-Z0-9]{10}$",
+ "type": "string"
+ },
+ "availability": {
+ "const": "available",
+ "type": "string"
+ },
+ "currency": {
+ "const": "USD",
+ "type": "string"
+ },
+ "formats": {
+ "items": {
+ "enum": [
+ "PDF",
+ "EPUB",
+ "Kindle",
+ "Paperback"
+ ],
+ "type": "string"
+ },
+ "maxItems": 2,
+ "minItems": 1,
+ "type": "array"
+ },
+ "id": {
+ "enum": [
+ "gumroad-pdf-epub",
+ "amazon-kindle",
+ "amazon-paperback"
+ ],
+ "type": "string"
+ },
+ "isbn": {
+ "pattern": "^[0-9]{13}$",
+ "type": "string"
+ },
+ "marketplace": {
+ "enum": [
+ "Gumroad",
+ "Amazon.com"
+ ],
+ "type": "string"
+ },
+ "price": {
+ "exclusiveMinimum": 0,
+ "type": "number"
+ },
+ "price_type": {
+ "enum": [
+ "listed_bundle_price",
+ "publisher_list_price"
+ ],
+ "type": "string"
+ },
+ "retailer": {
+ "enum": [
+ "Gumroad",
+ "Amazon"
+ ],
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ },
+ "verified_on": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "retailer",
+ "formats",
+ "url",
+ "price",
+ "currency",
+ "marketplace",
+ "price_type",
+ "availability",
+ "verified_on",
+ "alternate_urls"
+ ],
+ "type": "object"
+ },
+ "maxItems": 3,
+ "minItems": 3,
+ "type": "array"
+}Output schema / properties / library / properties / book / requiredPrevious value: -[
- "title",
- "author",
- "publisher",
- "information_url",
- "purchase_url",
- "cover_url",
- "availability",
- "formats",
- "price",
- "currency",
- "pricing_note",
- "language",
- "edition",
- "pdf_pages",
- "chapters",
- "practical_problem_cases",
- "description"
-]New value: +[
+ "title",
+ "author",
+ "publisher",
+ "information_url",
+ "purchase_url",
+ "cover_url",
+ "availability",
+ "formats",
+ "price",
+ "currency",
+ "pricing_note",
+ "language",
+ "edition",
+ "pdf_pages",
+ "chapters",
+ "practical_problem_cases",
+ "description",
+ "all_formats",
+ "default_purchase_option_id",
+ "purchase_options"
+]get_rv_library_infoget_rv_worksheetplan_first_rv_tripsearch_rv_worksheetsVanlife & RV data: roadbooks, fuel, tolls, ferries, visas, holidays, hazards, weather. openvan.camp
Search Australian campsites, caravan parks and free camps; weather, gear, road trips and booking.
Search campervans and motorhomes worldwide. 300+ rental companies. AU, NZ, US, CA, UK and more.
Plan trips on a map: routed transport, day-by-day itineraries, and a plan you can share.
Add one secure layer between your agents and this server.
