A tool is a function your app can run, such as finding a course. The model can ask to use it. Your app decides whether to run it.

Think of a library desk. You can ask the librarian for one book. That request does not let you open every cupboard. Our first tool works the same way: it accepts one known course ID and returns public prerequisites, or courses to finish first.

A schema is a description of allowed inputs. Validation means checking those inputs in running code. You need both. Reject missing fields, unknown fields, long strings and unknown IDs. Check the returned data too. A tool description or read-only label is a hint; it cannot prove what another server does.

Do not accept SQL, web addresses, file paths or a caller-selected account. Keeping the tool small makes each permission check easier to explain. Later, you will add plan changes after the checks and approval steps work.

Before this course, complete AI Answers Grounded in Your Sources and Secure APIs and Student Data. Use Node.js 22 or newer; Node 24 is the current long-term support release. Required examples use built-in tools and fictional local samples. They need no paid API. Optional model calls need your own key and may cost money.

Save the following as agents-narrow-read-tool.mjs and run node agents-narrow-read-tool.mjs.

const courses = new Map([['js', { title: 'JavaScript', requires: ['html', 'css'] }]]);
function lookup(args) {
  if (!args || Array.isArray(args) || Object.keys(args).join(',') !== 'courseId' ||
      typeof args.courseId !== 'string' || !courses.has(args.courseId)) {
    throw new Error('invalid lookup arguments');
  }
  return structuredClone(courses.get(args.courseId));
}
console.log(lookup({ courseId: 'js' }));
try { lookup({ courseId: 'js', admin: true }); }
catch (e) { console.log(e.message); }

Expected behavior: The first call returns JavaScript with HTML and CSS prerequisites. The second call is rejected despite naming a real course.

1. Write a tool description stating its purpose, allowed inputs, output shape and absence of side effects.
2. Implement a local lookup over three fictional courses.
3. Add fixtures for a valid ID, unknown ID, missing field, oversized string, array input and an invented permission flag.
4. Return only the fields needed by the learner, and make a small table explaining why each rejected case should fail before any provider or database operation.

Add a generic query field that allows the caller to select arbitrary properties. Demonstrate how it expands the capability beyond course prerequisites, then remove it and explain the narrower replacement.

Question: Does a tool schema prove the server validates requests?

Answer: No. The runtime handler must enforce it.

Question: Who chooses whether a proposal executes?

Answer: Application code after permission checks.

Question: Why reject unknown fields?

Answer: They can hide accidental or malicious attempts to expand authority.

Deliver the read-only lookup, descriptor and failure fixtures. Keep this capability as the initial safe boundary before adding any learning-plan write operation.

Next lesson: Enforce account and resource permissions.

Vercel AI SDK tools and MCP tools. Reviewed 2026-10-07; the example is application code, not unverified SDK registration syntax.