A TypeScript MCP server that gives AI tools only the data they need

An MCP server can publish tools, resources, and prompts. A tool is an action the client calls with arguments; a resource provides readable context; a prompt provides a prepared interaction pattern. One scenario is enough for a first project, such as listing open tasks. That makes it easier to see what information the agent actually needs and which permissions are required.

The TypeScript SDK supplies server structure and tool registration, but it does not design your trust boundary. A tool called run_any_query gives the model a broad action surface even if its UI looks tidy. A narrow name, strict parameter schema, and bounded response make behavior clearer for the client and safer for the data owner.

Input validation rejects malformed data: an unknown project, empty identifier, or unexpected field. It does not answer whether this user may see the project. Authorization must be enforced on the server for each request and all the way down to the data source. Do not trust a user identifier that the model supplied as an ordinary tool argument.

For a remote HTTP server, the SDK documents bearer authorization in front of the MCP route. A local stdio process has a different boundary: its capabilities follow the launching process and the secrets available to it. In both cases least privilege matters more than convenience. A read-only credential for a test resource is better than a universal administrative token.

A tool result should be small and structured: identifier, title, status, and link. Do not return an entire database record containing internal notes and personal fields when the agent needs only a summary. Limit the number of records, text size, and execution time. That reduces context cost and the chance that excess data leaks through a model response.

Treat errors as part of the contract. A missing project, access denial, unavailable backend, and exceeded limit are different outcomes. Logs should connect a call to a user, tool, and time without becoming copies of sensitive arguments and responses. A good audit trail helps investigate an issue without creating another one.

Run the server locally with test data and call the tool manually first. Cover an ordinary request, invalid schema, another user's project, and an empty result. Then connect one AI client and observe whether it selects the tool when appropriate and explains a denial correctly. Only after that should you add another tool or a remote transport.

A useful completion test is whether another developer can read the tool description, inspect inputs and outputs, reproduce the tests, and understand the required permission. If the workflow needs full database or shell access, the boundary is too broad. MCP is most valuable as a precise interface between AI and a system, not as a way around normal engineering discipline.

The decision concerns building a TypeScript MCP server for AI tools. Evaluate it within one read-only tool with a strict input schema and bounded access, not through an abstract demonstration.

The subject of building a TypeScript MCP server for AI tools easily turns into a debate about taste. An engineering decision starts somewhere else: record the current state, the expected outcome, and the cost of being wrong. Keep the pilot bounded to one read-only tool with a strict input schema and bounded access. A narrow boundary makes behavior before and after the change comparable, limits collateral work, and leaves a clean rollback path. It also forces the team to distinguish a product result from an attractive demonstration.

• Bound the pilot to one read-only tool with a strict input schema and bounded access.
• Define completion evidence in advance: a tool contract, call logs, and rejection tests.
• Choose one representative scenario: listing project tasks without permission to change or delete them.
• Pin versions, settings, permissions, and budget so another engineer can reproduce the experiment.
• Assign a human owner who can stop the pilot and judge quality without being influenced by the tool brand.

Agree on the criteria before the work begins. If success is defined after seeing the result, almost any outcome can be presented as a win.

A representative pilot is listing project tasks without permission to change or delete them: realistic enough to expose trade-offs, yet bounded enough to control.

A useful pilot does not begin with a repository-wide migration. It begins with one repeatable scenario, such as listing project tasks without permission to change or delete them. Record both the outcome and the path: how much context was required, where ambiguity appeared, how many iterations were needed, and which decisions still required a person. That history matters because a fast first answer can still create a slow review, while a deliberate workflow can produce a smaller and safer change.

1. Capture baseline measurements and preserve a clean rollback point before making changes.
2. Separate discovery, a minimal implementation, verification, and independent review instead of asking for everything in one opaque step.
3. Run checks proportional to the risk, including parameter validation, authorization, negative cases, and access audit.
4. Collect concrete artifacts such as a tool contract, call logs, and rejection tests, rather than relying on the final narrative alone.
5. Ask a reviewer to score the result against the acceptance criteria without knowing which tool or approach produced it.

At every stage, a developer should be able to stop, understand the current state, and continue manually. That makes the process resilient to failure and avoids locking the team into a single tool.

Pay special attention to granting the agent excessive reach through a broad tool or unsafe transport. Review this area separately instead of hiding it behind overall success.

The central risk in this case is granting the agent excessive reach through a broad tool or unsafe transport. No prompt, setting, or passing unit test removes it on its own. Use layered safeguards: least privilege, a small diff, an isolated environment, automated checks, and a human decision wherever failure affects users, data, security, or production. Evidence should be inspectable by somebody who did not operate the tool. A confident summary is useful navigation, but it is never a substitute for the changed code and observed behavior.

• Review the main risk explicitly: granting the agent excessive reach through a broad tool or unsafe transport.
• Do not broaden permissions or data access merely to make a demonstration run more smoothly.
• Keep migrations, broad refactoring, and product behavior changes in separate diffs so each decision can be reviewed and reversed.
• Treat a failing or non-deterministic check as a blocker, not as an invitation to weaken the expected result.
• Require explicit human approval for authentication, personal data, payments, public APIs, and production operations.

Safeguards should not depend on the operator remembering every instruction. Express critical boundaries through permissions, CI, validators, and an environment that ordinary prose cannot bypass.

A final decision needs a tool contract, call logs, and rejection tests and a trend in measured results, not a subjective reaction to the first run.

Call the pilot successful only when it improves a measurable part of the workflow. For building a TypeScript MCP server for AI tools, track successful calls, rejected requests, and review time. Capture a baseline first, observe a representative batch of tasks for two or three weeks, and only then decide whether to expand adoption. One unusually good result is not enough. The method should survive ordinary work, imperfect requirements, interrupted sessions, and a different engineer reviewing the output.

• Measure successful calls, rejected requests, and review time across a series of tasks, not only the best example.
• Compare the median with costly outliers because averages often hide rare but expensive failures.
• Include human time spent on task definition, intervention, review, and repair instead of counting only machine runtime.
• Track regressions, rollbacks, incidents, and follow-up changes that appear after the initial merge.
• Use the pilot findings to improve project instructions, checks, and boundaries even if the proposed tool is not adopted.

After the first cycle, revisit not only the tool choice but the process itself: which instructions were ambiguous, which checks were missing, and where review started too late.

Before making building a TypeScript MCP server for AI tools part of the normal workflow, answer a few questions in writing. What concrete problem are we solving, and how does the current process behave? Which data, credentials, commands, and external systems are involved? Who may approve the result, and who owns an incident? What evidence will prove that the outcome is correct? These answers turn a personal experiment into a controlled engineering change and expose missing responsibilities before they become production failures.

• What is the smallest one read-only tool with a strict input schema and bounded access scope that can produce a useful answer?
• How will the team collect a tool contract, call logs, and rejection tests?
• Which of parameter validation, authorization, negative cases, and access audit are mandatory, and which depend on risk?
• What signal will stop the pilot even when early results look promising?

If these questions do not have short, verifiable answers, the rollout is premature. An hour spent defining boundaries is cheaper than a week spent untangling an uncontrolled experiment.