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, destructiveHint=false, so the description does not need to repeat safety traits. It adds the machine-readable evaluation factor and notes the content (receivers, purpose, retention, revocation, consent wording), which goes beyond the schema. No contradictions. A 3 is fair because the description relies on annotations for the behavioral profile.
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?
The description is compact and information-dense, front-loading the core meaning ('What happens to anything you send us') and ending with the operational cue. Only minor redundancy: 'exact consent wording' and 'Machine readable so you can evaluate' are both needed and neither is wasted.
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?
Given there is no output schema, the description does a good job of conveying what response the agent can expect (data terms + consent wording, machine readable). It directly ties to the sibling tool, covering the main use case. It does not mention any auth or permission needs, but a read-only data-terms lookup likely requires none, so the gap is minor.
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 schema has zero parameters, so the description has no parameter semantics burden. It correctly spends the space describing what the tool returns and why it matters. Baseline for 0 params is 4.
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 uses a clear verb ('evaluates') and specifies an explicit topic: the data-use terms and consent wording for what happens to a user's sent data. It names the exact sibling ('request_agent_contact') from which it should be used before, so it is well distinguished from siblings.
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 when to use the tool ('before request_agent_contact') but does not explicitly state when not to use it or name alternatives for other purposes. Still, that timing guidance is actionable and contextual.
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.
The tools mostly partition the workflow: eligibility, quotes, agent contact, agency registration/status, and data pulls each have distinct roles. Check_eligibility and agency_status both surface licensing state, and market_data/pull_requests both involve retrieving records, so a couple pairs need careful reading, but the descriptions disambiguate them.
Most tools follow a verb_noun pattern (check_eligibility, get_quotes, register_agency, request_agent_contact, pull_requests), but agency_status, data_use_terms, and market_data are noun phrases with the action implied. The mixed style is readable but not fully consistent.
Eight tools cover the main consumer, agency, and data workflows without redundancy or bloat. Each tool has a clear place in the domain.
The surface supports the main loop from eligibility to quote to consented agent contact, plus agency registration, queue draining, status, terms, and market data. Minor gaps exist, such as no tool for updating agency registration or explicitly managing credits, but they do not create dead ends.