What legal work does an MCP server or agent tool need before launch?

Terms, privacy, security, and third-party API questions for anyone publishing an MCP server or another tool that AI agents call, with a checklist an agent can run against the code.

Short answer

An MCP server is a product with two audiences: the people who connect it to their agents, and the agents that call its tools. Before launch, you need four things: (1) terms that say who may use the server and what you are responsible for; (2) a privacy policy that matches the data flowing through the tools; (3) security that assumes the calling agent can be manipulated; and (4) permission under the terms of any third-party API the server relies on. Most problems come from the last two.

The questions that matter

• Whose data passes through the tools? Tool arguments often carry user content: prompts, file contents, emails, customer records. If your server sees personal information, you need a privacy policy that says so, a retention period for logs, and, for business customers, usually a data processing agreement. Logging full tool inputs "for debugging" is the most common gap.
• Do the API terms allow what your server does? If your server is a front end to someone else's service, that service's API license and developer policies govern what you can do. The restrictions vary by service. Common ones limit sublicensing, resale, automated access, working around rate limits, caching, storage, redistribution, and using retrieved content to train AI. Google's API terms, for example, require documented access methods and prohibit circumventing usage limits, sublicensing the APIs, and storing or redistributing returned content without authorization. Other providers expressly allow some of these uses on certain plans. Either way, permission to use an API doesn't necessarily include permission to offer its features or data to other people's agents through your server.
• Who acts, and who is responsible? A tool that sends, buys, deletes, or publishes something has real-world effects. Decide which tools need a person's confirmation, mark read-only tools as read-only, and say in your terms that users are responsible for the instructions their agents give. See Can my AI agent buy things for users? and Who is responsible when my agent uses another company's website?
• What can a malicious prompt make your tools do? Agents can follow instructions hidden in the content they read, so treat every tool call as untrusted input. Authorize each call for the user making it, scope tokens narrowly, cap what one call can do, and never return secrets or other users' data in tool output.
• How do users authenticate? Prefer OAuth with scoped, revocable tokens over API keys pasted into configuration files. If you hold users' credentials for other services, see How should my agent handle users' passwords and logins?
• Are your listings accurate? Descriptions in MCP registries, agent directories, and tool marketplaces can be advertising, subject to the FTC Act and state consumer-protection laws. No special rule applies to registries; the test is the usual one, whether a claim is likely to mislead people in a way that matters. Claims about functionality, integrations, permissions, data access, privacy, security, and affiliations must be accurate and substantiated. Don't call an integration "official" just because it works with a company's public API.
• Is the code open source? If you publish the server's code, choose a license deliberately, check your dependencies' licenses, and keep secrets out of the repository history.

What your terms should cover

• Use. Who may use the server, and what is prohibited, such as unlawful use, abusing rate limits, and trying to break its security.
• Responsibility. Users are responsible for their agents' instructions and for checking results before relying on them.
• Your limits. Rate limits, any availability commitment, a disclaimer of accuracy, and a limitation of liability sized to what you charge.
• Data. What you log, how long you keep it, whether you use it to improve the service or train models, and how users can delete it.
• Third-party services. The server depends on other providers, and their terms also apply.
• Changes and suspension. How you change tools or terms, and when you can cut off abusive use.

Checklist an agent can run against the codebase

• List every tool, and mark which ones only read and which ones change something outside the server (send, buy, write, delete, publish).
• Confirm read-only tools are annotated readOnlyHint: true and write tools are not.
• For each write tool, find where a person must confirm the action, or note that no confirmation is required.
• Find every place tool arguments or results are logged, and note what is kept and for how long.
• Check that tool output never includes API keys, tokens, or another user's data.
• List every third-party API the server calls, link each one's license and developer policies, and note any limits on storage, caching, redistribution, resale, or AI use.
• Check how users authenticate, how tokens are scoped, and how a user revokes access.
• Check that each user can reach only their own data, including when the server uses a shared credential.
• Compare the registry and directory descriptions with what the tools actually do, including any claim of an official integration.
• If the code is public, check the license file and scan the repository history for committed secrets.

Sources

• FTC Policy Statement Regarding Advertising Substantiation

If this applies to you

An agent product review covers the authority model, terms, and third-party access for an MCP server or agent tool. For one new tool that sends, buys, or deletes, a pre-build feature check covers that change.