Search, summarize and save insights on your ParrotNotes in-person meeting notes.
Scored across 9 tools
Each tool targets a distinct resource-action pair: single-note retrieval (get_note), its insights/labels as sub-resources, bulk retrieval (recent/by-label/search), and account status. The apparent look-alikes (get_note_labels vs get_user_labels) are clearly separated by scope in their descriptions. No two tools appear interchangeable.
Uniform snake_case with a predictable verb_noun shape: get_* for reads (with clear noun qualifiers like _insights, _labels, _by_label, _recent), search_notes, and save_note_insight for the write. The convention is applied consistently across all nine tools.
Nine tools is well within the sweet spot and each one earns its place: retrieval, search, listing, label lookups, insights, and subscription status. No redundant or filler tools inflate the surface.
The read surface is thorough (get, list, search, labels, insights), but writes are nearly absent: there is no create_note, update_note, or delete_note, and no way to assign or manage labels despite being able to read them. save_note_insight is the only mutation, so note lifecycle coverage is a notable gap.
Get the full details of a specific note or recording by its ID, including the complete transcript or text content.
| Name | Required | Description | Default |
|---|---|---|---|
| note_id | Yes | The ID of the note to retrieve |
| Name | Required | Description |
|---|---|---|
| id | Yes | Server-side note ID (use with get_note) |
| dateTime | Yes | ISO 8601 timestamp of the note |
| duration | Yes | Audio duration in seconds |
| noteType | Yes | 'audio' for voice recordings, 'text' for written notes |
| transcript | Yes | Transcript of an audio note, if transcribed |
| displayName | Yes | Note title |
| textContent | Yes | Body of a text note |
| localRecordingId | Yes | Device-local note ID (use with insight and label tools) |
| transcriptionStatus | Yes | Transcription pipeline status for audio notes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds only that the response contains the full transcript/text, which is modest return-shape context; it says nothing about auth, size limits, or error behavior for a bad ID.
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?
A single front-loaded sentence with no filler; the verb, resource, identifier requirement, and payload are all delivered without waste.
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 one-parameter read tool with full annotation coverage and an output schema, the description covers what is needed to call it correctly. It is slightly thin on how to obtain the ID and on behavior for invalid IDs, but nothing essential 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?
Schema coverage is 100% with a single documented parameter ('The ID of the note to retrieve'), so the schema already carries the meaning. The description's 'by its ID' adds no format or sourcing detail beyond it, making the baseline 3 appropriate.
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?
States a specific verb and resource ('Get the full details of a specific note or recording by its ID') and clarifies the payload ('complete transcript or text content'). It implicitly distinguishes itself from siblings like get_note_insights or search_notes by promising full details, though it never names an alternative.
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 phrase 'by its ID' implies this is the retrieval-by-identifier path (as opposed to search_notes, which finds notes), but the description never states when to use this tool versus the sibling lookups. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AI-generated insights for a specific note or recording, such as summaries, action items, sentiment analysis, or translations.
| Name | Required | Description | Default |
|---|---|---|---|
| insight_type | No | Filter by insight type (e.g., 'summary', 'action_items', 'sentiment', 'translation') | |
| local_recording_id | Yes | The local recording ID to fetch insights for |
| Name | Required | Description |
|---|---|---|
| insights | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds that the content is AI-generated (summaries, action items, sentiment, translation), which is useful but modest added context; it says nothing about auth requirements, rate limits, or when insights may be absent.
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?
A single efficient sentence that front-loads the action and resource, with examples trailing. No wasted wording, though the example list is somewhat redundant with the schema.
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?
An output schema exists, so return values need not be described. The description is adequate for a simple two-parameter read tool whose annotations already carry the safety profile; only explicit sibling routing 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?
Schema description coverage is 100%, so both parameters are already documented. The description's list of insight types merely echoes the schema's own example values for insight_type, adding no syntax or filtering detail beyond the structured field. Baseline 3 applies.
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?
States a specific verb and resource ('Get AI-generated insights for a specific note or recording') and enumerates the insight kinds returned. This implicitly distinguishes it from siblings like get_note (raw content) and save_note_insight (write), but never names those alternatives explicitly.
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 phrase 'for a specific note or recording' implies the usage context, but there is no explicit when-to-use guidance, no exclusions, and no routing to siblings such as get_note or save_note_insight. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all labels/tags assigned to a specific note.
| Name | Required | Description | Default |
|---|---|---|---|
| local_recording_id | Yes | The local recording ID of the note (from localRecordingId field) |
| Name | Required | Description |
|---|---|---|
| labels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds no behavioral context beyond that — no return shape, no ordering, no empty-result behavior.
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?
A single front-loaded sentence with zero filler. It is efficient, though it is arguably too terse to carry any routing or behavioral information.
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?
An output schema exists, so the description need not explain return values, and annotations cover the safety profile. For a simple single-parameter read, the definition is adequately complete, with the sibling ambiguity as the only real gap.
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?
Only one parameter, and schema description coverage is 100% — the schema already documents local_recording_id and its source field. The description adds no meaning beyond the schema, so the baseline 3 applies.
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?
States a specific verb (Get) and resource (labels/tags assigned to a specific note), which is clearly parseable. It does not differentiate from the sibling get_notes_by_label, which performs the inverse mapping, leaving that distinction to the agent's inference.
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?
No when-to-use guidance, no prerequisites, and no mention of the near-identical sibling get_notes_by_label. Usage is only implied by the phrasing 'assigned to a specific note'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all notes that have a specific label/tag assigned.
| Name | Required | Description | Default |
|---|---|---|---|
| local_label_id | Yes | The local label ID (from localLabelId field in get_user_labels) |
| Name | Required | Description |
|---|---|---|
| notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that — no note about ordering, pagination, or how many notes are returned for a heavily used label.
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?
A single front-loaded sentence with zero filler that states the resource and its filter immediately. Nothing in it needs trimming.
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?
With an output schema present, an annotated single-parameter read tool needs little prose, and this definition covers the essentials. A brief note on result ordering or volume for a broad label would make it complete rather than merely adequate.
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?
Schema description coverage is 100% and the single parameter is documented in-schema, including a cross-reference to the localLabelId field of get_user_labels. The description's 'label/tag' phrasing is consistent but adds no format or ID-resolution detail beyond the schema.
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?
States a specific verb and resource ('Get all notes') plus the filtering dimension ('specific label/tag assigned'), so an agent knows exactly what it returns. It does not explicitly differentiate itself from lookalike siblings such as get_recent_notes or search_notes, which also return note collections.
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 conveys the retrieval filter but gives no when-to-use guidance, no conditions selecting it over get_recent_notes/get_note_labels/search_notes, and no prerequisites. The use case is only weakly implied by the presence of a label filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the user's recent notes and recordings, sorted by date descending. Supports pagination and optional filtering by note type (audio or text).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Number of notes to return | |
| offset | Yes | Number of notes to skip for pagination | |
| note_type | No | Filter by note type: 'audio' for voice recordings, 'text' for written notes |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| hasMore | Yes | True when more notes exist beyond this page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: results are ordered by date descending, pagination is supported, and filtering is optional, which helps an agent reason about result shape and iteration.
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 short sentences with zero filler; the core behavior (list recent notes, date descending) is front-loaded and the secondary capabilities follow. 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?
With a full output schema, 100% parameter coverage and annotations covering safety, the description needs only to frame the operation, which it does. It could go one step further by clarifying scope (e.g., current user only, how far back 'recent' reaches), but nothing essential is missing for correct invocation.
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?
Schema description coverage is 100%, so limit, offset and note_type are already fully documented including enum meanings. The description only restates that pagination and note-type filtering exist, adding no syntax or constraint detail beyond the schema, making the baseline 3 correct.
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?
States a specific verb and resource ('List the user's recent notes and recordings') plus the ordering ('sorted by date descending'), so the agent knows exactly what comes back. It does not name or differentiate itself from siblings like search_notes or get_notes_by_label, which is the only thing keeping it from a 5.
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 'recent notes' framing implies an exploratory, no-query browse use case, and it notes that filtering by note type is optional. However, it never says when to prefer this over search_notes or get_notes_by_label, nor any prerequisites, so usage is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the user's ParrotNotes subscription status, including whether it is currently active and when it expires.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| isActive | Yes | True when the subscription is active or trialing and not expired |
| subscription | Yes | Null when the user has no subscription record |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that the response includes active state and expiration, which is return-content detail; with an output schema present, that is modest added value rather than rich behavioral disclosure.
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?
A single front-loaded sentence: verb first, resource second, then the two fields of interest. No waste, no repetition, and nothing buried.
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 parameterless read-only tool with rich annotations and an output schema, the description supplies the remaining user-facing context: what subscription status includes (active state and expiration). Nothing needed for correct invocation or selection 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?
There are zero parameters, so the rubric baseline is 4 and no parameter semantics are needed. The description correctly avoids inventing parameter details that do not exist.
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?
States a specific verb ('Check') and resource ('the user's ParrotNotes subscription status'), then names the two data points returned: active state and expiration. It is clearly distinct from every sibling tool, all of which concern notes rather than subscriptions.
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 makes the use case clear: retrieve the current user's subscription status. No sibling tool covers subscriptions, so no alternative needs to be named, and the only small gap is the absence of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all of the user's labels/tags used to organize notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| labels | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the mild clarification that labels are 'used to organize notes' and says nothing about ordering, pagination, or volume, which is the minimum-viable level given 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?
A single front-loaded sentence with the resource and scope stated immediately and no filler. Nothing in it fails to earn 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?
An output schema exists so return values need not be described, and annotations cover the safety profile. The description is adequate, though it omits any note on result ordering or whether the list is paginated.
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 takes zero parameters, so the baseline is 4 and there is no parameter syntax for the description to compensate for. Schema coverage is 100% and the empty schema is self-explanatory.
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?
States a specific verb (list) and resource (labels/tags) plus scope ('all of the user's'), which distinguishes it from the per-note sibling get_note_labels. It does not name that sibling, so differentiation is implicit rather than explicit.
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 phrase 'all of the user's labels' implies this is the account-wide listing rather than a per-note lookup, but no when-to-use, exclusions, or alternative tools are stated. Usage must be inferred from the scope wording alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate and save an AI insight for a specific note. Upserts based on the combination of note, insight type, and target language.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The insight content text | |
| insight_type | Yes | The type of insight to save | |
| target_language | No | Target language code for translations (e.g., 'es', 'fr', 'de'). Required when insight_type is 'translate'. | |
| local_recording_id | Yes | The local recording ID of the note (from localRecordingId field) |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| content | Yes | Insight text |
| insightType | Yes | Kind of insight, e.g. summary, action_items, translate |
| targetLanguage | Yes | Language code for translations, otherwise null |
| localRecordingId | Yes | Device-local ID of the note the insight belongs to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true; the description adds the concrete upsert key (note + insight type + target language), which explains both why repeated calls are idempotent and what existing row gets overwritten. It does not explicitly say prior content is replaced, but the upsert wording carries most of that.
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 tight sentences with the purpose front-loaded and the upsert semantics immediately following; no filler, 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?
An output schema exists so return values need no explanation, and the upsert behavior is disclosed. The one remaining ambiguity is what 'generate' entails (whether an LLM call occurs or content must be supplied), but the required content parameter largely resolves that.
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?
Schema description coverage is 100%, so the schema already documents all four parameters including the enum values and the target_language/translate relationship. The description restates the upsert key but adds no format or syntax detail beyond structured fields, so baseline 3 applies.
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?
'Generate and save an AI insight for a specific note' states a clear verb (generate/save) and resource (AI insight on a note), and 'generate' implies a write, distinguishing it from the read-oriented sibling get_note_insights. It stops short of naming the sibling explicitly, so it is clear but not fully differentiated.
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 implies usage (persist an AI insight onto a note) and the upsert sentence conveys repeat-call behavior, but it never states when to use this vs. get_note_insights or other siblings, nor any prerequisites. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the user's notes and recordings by keyword. Matches against note titles, transcripts, and text content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Maximum number of results | |
| query | Yes | Search keyword or phrase |
| Name | Required | Description |
|---|---|---|
| notes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds which fields are matched (titles, transcripts, text content), but says nothing about ranking, pagination, or empty-result behavior.
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 short sentences, front-loaded with the action and resource, with the second sentence delivering the match-scope detail. No filler or redundancy.
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 two-parameter read-only search with a full schema, rich annotations, and an output schema, the description covers purpose and match scope adequately. Minor gaps (result ordering, whether recordings and notes are returned together) remain but are low impact.
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?
Schema description coverage is 100% and both parameters are documented with defaults and bounds in the schema itself. The description adds no syntax guidance for query (e.g., multi-word or phrase handling), so baseline 3 applies.
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?
States a specific verb and resource ('Search the user's notes and recordings') plus the matching scope (titles, transcripts, text content). It is clearly distinguished from retrieval-by-id siblings like get_note, though it does not explicitly name an alternative like get_recent_notes or get_notes_by_label.
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 phrase 'by keyword' implies when this tool applies versus ID-based or recency-based siblings, but there is no explicit when-to-use or when-not-to-use statement. An agent must infer that keyword lookup is the trigger condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_noteget_note_insightsget_note_labelsget_notes_by_labelget_recent_notesget_subscription_statusget_user_labelssave_note_insightsearch_notesSearch and read your recorded meetings: notes, action items, participants, transcripts.
Search and analyze meeting transcripts, summaries, soundbites and analytics from Fireflies.ai
Search, read and export MeetNotes meeting transcripts, minutes and action items (getmeetnotes.com).
Search, read and ask questions about your AudioMap transcripts, notes, speakers and clips.
Add one secure layer between your agents and this server.