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, covering the safety profile. The description adds useful behavioral context beyond that: the exact content domains returned (who receives, purpose, retention, revocation, consent wording) and the machine-readable format. Nothing contradicts the 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 zero filler. The first sentence front-loads the full list of content areas the tool returns, and the second immediately conveys the practical use case and machine-readability. 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 simple zero-parameter read-only tool, the description is complete: it enumerates all return content categories, gives the exact timing for use (before request_agent_contact), states the format is machine readable, and annotations cover the safety profile. Nothing an agent needs to invoke it correctly is missing.
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?
With zero parameters and 100% schema description coverage, there is nothing for the description to explain. The baseline for 0 params is 4, and the description adds relevant context by specifying what the terms apply to ('anything you send us' / 'the exchange'), which helps an agent understand the tool's inputs without parameters.
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 states what the tool provides: data use terms covering recipients, purpose, retention, revocation, and consent wording. It distinguishes itself from siblings by explicitly referencing request_agent_contact as the action that requires this tool's consent wording, so an agent can tell it apart without inspecting the schema.
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 gives an explicit usage trigger: present this consent wording before request_agent_contact, and evaluate the exchange before making it. This is clear context for when to invoke the tool. It doesn't name alternative tools or exclusions, but with zero parameters and a unique informational role among siblings, there are no competing tools to rule out.
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.
Each public- to-consumer and agency-facing tool serves a clearly separate step in the workflow: eligibility, quotes, consent, contact, registration, status, queue draining, and data purchase. There is no meaningful overlap between tool purposes.
All tool names are snake_case and generally descriptive, but they mix action-oriented names like get_quotes and pull_requests with noun-style resource names like market_data and agency_status. This is a minor consistency deviation rather than a chaotic pattern.
Eight tools cover the platform's distinct functional areas without bloat: consumer quote/contact flow, agency registration and queue management, and data market access. Each tool appears necessary and the total count is well-scoped for the server's purpose.
The core workflows are supported end to end: eligibility check leads to quotes, consent leads to agent contact, and agencies can register, check status, and pull routed records. The main gaps are minor administrative operations such as updating agency details or an explicit tool for revoking consent, although POST /forget is referenced.