A security reviewer is checking a tool definition returned by tools/list against the specification. Which set contains only fields that the Tool definition actually defines?
Select an answer to reveal the explanation.
Short Explanation
Picture a product label: name, a friendly title, a description, an icon, what goes in, what comes out, and a few behavior hints. That's the Tool definition you're checking. The trap is borrowing fields from resources, like uri and mimeType, or inventing permission fields.
Full Explanation
The tools specification defines a Tool with a name, its unique identifier; an optional title for display; a description of its functionality; optional icons; an inputSchema, a JSON Schema for the expected parameters that must be a valid schema object and not null; an optional outputSchema describing structured output; and optional annotations describing behavior. Reviewers check each of these, especially the description and annotations, since both are untrusted unless the server is trusted. The set with version, permissions and similar fields mixes in properties the Tool type does not define; version belongs to the implementation info in serverInfo, not to individual tools, and there is no permissions field. The set with parameters, returns, readOnly and requiredScopes uses names from other function-calling formats; MCP calls these inputSchema and outputSchema, and read-only behavior is expressed through the readOnlyHint annotation. The set with uri and mimeType borrows fields from the Resource definition, which describes addressable data rather than callable actions. Exam caveat: tool names should be 1 to 128 characters using letters, digits, underscore, hyphen and dot, and the default schema dialect is JSON Schema 2020-12. Operational check: validate each tools/list entry against the published schema and flag unknown fields or a null inputSchema.