data_use_termsWhat happens to anything you send us: who receives it, for what purpose, how long it is kept, how your human revokes it, and the exact consent wording to present before request_agent_contact. Machine readable so you can evaluate the exchange before making it.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by listing what information the tool exposes and noting that it is machine-readable so the exchange can be evaluated before it occurs. No contradiction with annotations.
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 with no filler. The first sentence front-loads all the content dimensions, and the second explains the practical value of the machine-readable format. Every clause earns 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 no output schema, the description sufficiently covers what to expect, when to call it, and why it is useful. The only minor gap is the precise output format, but 'machine readable' reasonably communicates that the result can be programmatically evaluated.
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 has zero parameters, so schema description coverage is effectively 100% and there is no parameter documentation burden on the description. The baseline of 4 applies since there is nothing for the description to add about parameter meaning.
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?
The description clearly identifies the resource — data use terms and consent wording — and enumerates the specific dimensions it covers: recipients, purpose, retention, revocation, and consent text. It distinguishes itself by anchoring to request_agent_contact, which is present in the sibling list. It lacks an explicit verb like 'get' or 'retrieve', but the function is unambiguous.
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?
The description states precisely when to use the tool: before calling request_agent_contact, to obtain the exact consent wording and evaluate the exchange. It gives a clear usage context and rationale. It does not discuss exclusions or when to prefer other siblings, but the specific trigger condition is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but some overlap exists: get_quotes and check_eligibility both relate to quotes, and market_data and pull_requests both involve data access. Still, they are functionally different enough to avoid major confusion.
All tool names follow a consistent lowercase_snake_case convention with action-oriented verbs (check, get, pull, register, request) or clear nouns (agency_status, market_data, data_use_terms). The naming pattern is uniform and predictable.
With 8 tools, the server is well-scoped for an insurance business—covering eligibility, quotes, registration, data access, and status checks. The number is neither too sparse nor overwhelming.
The toolkit covers the core workflow: eligibility, quotes, agency registration, status monitoring, and data handling. It lacks a tool for updating agency information or managing consumer consent revocation directly, but these gaps are minor given the described purpose.