This server provides AI assistants with read-only, Free-tier access to Teralynk's file intelligence and compliance platform, exposing 13 tools for file operations, compliance monitoring, analytics, and conversation management.
File Management:
List files with filtering by search, starred status, or storage provider
Full-text search across file names and metadata
Retrieve file metadata including tags, compliance status, and a temporary (15-minute) presigned download URL
Generate a presigned download URL for any file
Access version history with timestamps and sizes
Compliance:
Get a real-time compliance health score (0–100), broken down by framework (e.g., HIPAA, GDPR, PCI-DSS)
List all available compliance frameworks with descriptions, control counts, and current coverage
Analytics & Billing:
View usage analytics: file count, storage used, AI queries, active workflows, scan statistics
Check billing period details: plan, credits remaining, scans used, storage consumed, renewal date
AI Conversations:
List past AI chat conversations with titles, previews, and model info
Retrieve full message history of a specific conversation
Notifications:
Fetch recent notifications for file shares, scan completions, violations, and workflow updates
Job Status:
Poll the status of asynchronous operations like compliance scans or report generation, with progress percentage
Note: Scanning files for PII, generating reports, running workflows, managing teams, webhooks, and 89+ other tools require an SMB or Enterprise plan.
Allows Teralynk to access and manage files stored in Dropbox, enabling file listing, searching, downloading, and compliance scanning across those files.
Allows Teralynk to access and manage files stored in Google Drive, enabling file listing, searching, downloading, and compliance scanning across those files.
Connect any MCP-compatible AI assistant to Teralynk — AI-native file intelligence, PII scanning, compliance automation, workflow execution, audit trails, and data subject rights management.
The Teralynk MCP Server exposes your entire Teralynk account as structured tools your AI can call directly. Ask Claude to scan a file for HIPAA violations, check your compliance score, generate a PDF report, run a workflow, or submit a GDPR data subject access request — all without leaving the conversation.
v1.6.1 — 102 tools across 13 categories with plan-based gating (free / SMB / enterprise), BYOK AI chat, per-tool metering, audit attribution, and remote feature flags.
Related MCP server: Spotter-SAST
Sign in at teralynk.com → Developer → API Keys → create a new key (starts with tlk_).
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"teralynk": {
"command": "npx",
"args": ["-y", "@teralynk/mcp-server"],
"env": {
"TERALYNK_API_KEY": "tlk_your_key_here"
}
}
}
}Restart Claude Desktop. The Teralynk tools appear automatically.
Command: npx -y @teralynk/mcp-server
Env: TERALYNK_API_KEY=tlk_your_key_hereTier | Tools | Includes |
Free | 13 tools | Read-only: list/search/get files, compliance score, analytics, notifications, billing, conversations, frameworks |
SMB / Pro | 72 tools | Free + upload, rename, move, copy, bulk ops, locking, version restore, content search, scanning, reports, file protection, workflows, tagging, agents |
Enterprise | All 102 tools | SMB + webhooks, security events, scheduled reports, API key management, team management, file retention, compliance certificates, DSARs, audit export |
Tool | Tier | Description |
| Free | List the authenticated user's files in Teralynk |
| Free | Full-text search across file names and metadata |
| Free | Get full metadata for a specific file: name, size, type, storage provider, tags, created/modified da |
| Free | Get a presigned download URL for a file |
| Free | List all versions of a file with timestamps and sizes |
| SMB | Permanently delete one or more files |
| SMB | Star or unstar a file for quick access later |
| SMB | Generate a shareable link for a file |
| SMB | Get a presigned upload URL for a file |
| SMB | Rename a file in Teralynk storage |
| SMB | Add one or more tags to a file |
| SMB | Remove one or more tags from a file |
| SMB | List files that currently have active share links |
| SMB | Revoke all active sharing links for a file |
| SMB | Get all tags currently applied to a file |
| SMB | Download and return the text content of a file (up to 100 KB) |
| SMB | Apply one or more tags to multiple files at once |
| SMB | Move a file to a different folder within your Teralynk storage |
| SMB | Create a new empty folder in your Teralynk storage |
| SMB | See who a file is currently shared with, link expiry, and permission level |
| SMB | Create a copy of a file in the same or a different folder |
| SMB | Restore a file to a previous version |
| SMB | Lock a file to prevent edits by other team members |
| SMB | Unlock a previously locked file so other team members can edit it |
| SMB | Get presigned download URLs for multiple files at once |
| SMB | Move multiple files to a destination folder in one operation |
| SMB | Delete multiple files at once |
| SMB | Semantic full-text search across file contents (not just filenames) |
Tool | Tier | Description |
| SMB | Scan a specific file for PII |
| SMB | Trigger a compliance scan across all of the user's files |
| SMB | Run a comprehensive blocking compliance scan of all files |
| SMB | Automatically remediate open compliance violations using AI-generated fixes |
| Enterprise | Generate a cross-file PII exposure report: which files contain SSNs, credit cards, emails, phone num |
| SMB | List previous compliance scan results with dates, findings counts, and status |
| SMB | Get full details of a specific compliance scan run — files scanned, findings, duration, and status |
Tool | Tier | Description |
| SMB | List PII-specific violations found during file scans |
| SMB | Mark a PII violation as resolved |
| SMB | List org-level compliance violations — policy breaches, rule failures, and framework gaps |
| Free | Get the user's real-time compliance health score (0–100) with a breakdown by framework |
| SMB | Get an aggregate compliance health summary: total files scanned, open violation counts by severity, |
| Enterprise | List all 201 compliance frameworks available on the Teralynk platform, grouped by industry (Finance, |
| SMB | Get a risk score (0–100) for a specific file based on PII density, sharing status, access frequency, |
| SMB | Compare two files side-by-side: metadata, compliance status, PII violations, and protection policies |
| SMB | Use AI to automatically classify a file's sensitivity level (public, internal, confidential, restric |
| Enterprise | Create a recurring compliance scan schedule |
| Enterprise | Get compliance violations added since a specific date |
| Enterprise | Generate an AI-powered step-by-step remediation plan for all open compliance violations |
| Enterprise | Get a data map showing where PII flows across files and storage providers |
| SMB | Get full details of a specific compliance violation by ID — file, type, severity, context, and remed |
| Free | List all available compliance frameworks (HIPAA, GDPR, PCI-DSS, etc |
Tool | Tier | Description |
| SMB | List previously generated compliance reports with their status, framework coverage, and download URL |
| SMB | Generate a new compliance report as a PDF |
| Enterprise | Generate a compliance attestation certificate PDF for selected frameworks |
| SMB | Get the download URL for a previously generated compliance report PDF |
| Enterprise | Schedule a recurring report to be generated and emailed |
Tool | Tier | Description |
| SMB | Apply a compliance protection policy to one or more files |
| SMB | Remove compliance protection from one or more files |
| SMB | List active file protection policies |
| SMB | Get a summary of active file protections: total protected files, policy breakdown, and framework cov |
| Enterprise | Protect all files that match a compliance framework |
| Enterprise | Set a retention policy on files — automatically delete files older than the specified number of days |
Tool | Tier | Description |
| Enterprise | List compliance rules in effect — both global platform rules and any custom org rules |
| Enterprise | Create a custom compliance rule for the org |
| Enterprise | Get the compliance whitelist — domains, emails, IPs, file patterns, and users exempt from certain ru |
| Enterprise | Add an entry to the compliance whitelist to suppress false positives |
Tool | Tier | Description |
| Enterprise | Retrieve the tamper-evident compliance audit trail |
| Enterprise | Export the compliance audit trail as structured data (JSON) |
| SMB | Search the compliance audit log by action type, file ID, or other criteria |
| SMB | Get recent activity for a specific file: who accessed it, modifications, shares, and scans |
| Enterprise | Get recent security events: suspicious logins, unusual download patterns, access from new locations, |
Tool | Tier | Description |
| Enterprise | Submit a Data Subject Access Request (DSAR) — required under GDPR, CCPA, and similar regulations |
| Enterprise | List Data Subject Access Requests with their status, requester, type, and due dates |
Tool | Tier | Description |
| SMB | Get storage usage analytics: total bytes used, file count, breakdown by provider (S3, Google Drive, |
| SMB | List connected external storage providers (Google Drive, Dropbox, OneDrive, etc |
| SMB | Get AI-generated storage optimization recommendations: files to archive, duplicates to remove, provi |
Tool | Tier | Description |
| Free | Get usage analytics: file count, total storage used, AI query count, active workflows, and complianc |
| SMB | Mark one or all notifications as read |
Tool | Tier | Description |
| SMB | Send a message to an AI model (Claude, GPT-4o, Gemini, NVIDIA NIM) using YOUR OWN API key (BYOK) |
| Free | List previous AI chat conversations with title, last message preview, model used, and timestamps |
| Free | Get a specific AI chat conversation by ID, including full message history |
Tool | Tier | Description |
| Free | Check the status of a long-running async operation — full compliance scan, report generation, or DSA |
Tool | Tier | Description |
| SMB | List the user's saved workflows (automation pipelines) |
| SMB | Execute a workflow by ID |
| Enterprise | Create a new automation workflow with named steps |
| SMB | Get detailed status of a workflow run including step-by-step progress, which steps completed, which |
| SMB | Delete a workflow by ID |
| SMB | Update an existing workflow — change its name, description, or steps |
| SMB | Cancel a running workflow execution |
Tool | Tier | Description |
| Free | Get the current billing period usage: plan name, credits remaining, scans used, storage consumed, an |
| Enterprise | Generate a new Teralynk API key (tlk_-prefixed) |
| Enterprise | List all your active API keys with names, creation dates, and last used timestamps |
| Enterprise | Revoke (disable) an API key |
Tool | Tier | Description |
| Free | Get the user's recent notifications — file shares, scan completions, violation alerts, workflow upda |
Tool | Tier | Description |
| SMB | List all available AI agents (built-in and custom) |
| SMB | Run an AI agent with a task |
Tool | Tier | Description |
| Enterprise | List all members of your organization/team with their roles and last activity |
| Enterprise | Invite a new member to your organization by email |
| Enterprise | Change a team member's role (member, admin, compliance_admin) |
| Enterprise | Remove a member from your organization |
Tool | Tier | Description |
| Enterprise | Create a webhook that fires when specific events occur (file uploaded, scan completed, violation fou |
| Enterprise | List all configured webhooks with their URLs, events, and delivery status |
| Enterprise | Delete a webhook by ID |
Build custom tools, workflows, or integrations using Teralynk's API — then sell them on the Teralynk Marketplace and earn revenue.
Build — Create a custom MCP tool, workflow template, or compliance rule pack using Teralynk's API endpoints
List — Publish to the Teralynk Marketplace with your pricing
Earn — Get paid when other Teralynk users purchase or subscribe to your creation
Type | Example | Revenue model |
Custom MCP tools | Industry-specific compliance scanner | Per-install or subscription |
Workflow templates | "SOC 2 audit preparation pipeline" | One-time purchase |
Compliance rule packs | FINRA rules, NIST 800-53, ISO 27001 | Subscription |
AI agent templates | "Healthcare data classifier agent" | Per-use or subscription |
Integration connectors | Salesforce → Teralynk compliance sync | Monthly fee |
Visit teralynk.com/creator-store to register as a creator and publish your first listing.
Upload a file called quarterly-report.pdfScan file abc123 for HIPAA violations and show me what was foundWhat's my compliance score? Break it down by framework.Which of my files contain SSNs or credit card numbers?Generate a compliance certificate for HIPAA and SOXCreate a workflow that scans new files and protects any with PIIGive me a remediation plan to reach 100% complianceShow my audit trail for the past 7 days and export itWhat's the risk score for file abc123?Run my "weekly-cleanup" workflowLock file abc123 — I'm reviewing itShow me all my security events from the past weekVariable | Required | Description |
| ✅ | Your Teralynk API key (from Developer portal) |
| ❌ | Override the API base URL (for testing / self-hosted) |
| ❌ | Identifies the MCP host in audit logs (default: |
HIPAA · GDPR · PCI-DSS · SOX · CCPA · FERPA · GLBA · COPPA
Teralynk is available in 23 languages:
English · Spanish · French · German · Portuguese · Italian · Dutch · Polish · Russian · Turkish · Arabic · Hindi · Chinese · Japanese · Korean · Indonesian · Vietnamese · Thai · Swedish · Danish · Finnish · Norwegian · Ukrainian
The platform auto-detects your browser language. Users can switch languages at any time from settings.
Node.js 20+
A Teralynk account
MIT
Get usage analytics: file count, total storage used, AI query count, active workflows, and compliance scan statistics. Use get_storage_analytics for storage-specific breakdowns.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lists returned metrics but does not state read-only nature, rate limits, or potential side effects. For a read-only analytics tool, this is a moderate gap.
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 sentences, front-loaded with key metrics, no extraneous content.
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 tool without output schema, the description provides enough detail about return values and points to a sibling for deeper storage analysis. Could mention aggregate nature.
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?
No parameters in schema, so coverage is 100%. Description adds value by listing the specific metrics returned, which is helpful beyond the empty 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?
Clearly states the tool returns usage analytics with specific metrics (file count, storage, AI queries, etc.), and distinguishes from sibling get_storage_analytics.
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?
Explicitly tells when to use this tool and when to use get_storage_analytics for storage-specific breakdowns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current billing period usage: plan name, credits remaining, scans used, storage consumed, and renewal date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description implies read-only operation with no side effects. Lists output fields, giving sufficient behavioral context for a simple query.
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?
Single sentence, front-loaded with verb, concise and to the point with no wasted words.
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 tool with zero parameters, no output schema, and straightforward purpose, the description fully covers expected behavior and return fields.
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?
No parameters exist, so schema coverage is 100%. Baseline score of 4 applies; description adds no param details but none needed.
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?
Description clearly states action (Get) and resource (current billing period usage), listing specific data fields returned. No sibling tool overlaps, ensuring distinction.
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 explicit guidance on when to use or alternatives. However, the tool's simplicity and zero parameters make context self-evident; absence of exclusions is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's real-time compliance health score (0–100) with a breakdown by framework. Score reflects open violations, scan coverage, and policy adherence. A score ≥ 85 is typically considered compliant for enterprise audits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the score is real-time, ranges 0–100, includes a breakdown, and mentions a compliance threshold. However, it lacks details on auth requirements, side effects, error handling, or whether results are cached. This is adequate for a simple read tool but not exhaustive.
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 two sentences long, front-loading the purpose and key details. Every sentence adds value, no fluff or repetition. It is appropriately sized for the tool's simplicity.
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 tool with no output schema, the description covers the main aspects: what it returns (score and breakdown), score interpretation (≥85 compliant), and real-time nature. It could elaborate on the breakdown structure (e.g., list of framework scores), but overall it is sufficient.
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 input schema has no parameters, so schema description coverage is 100%. The description adds meaning beyond the schema by explaining the output (score range, breakdown, compliance threshold). Given no parameters, the description effectively compensates.
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 specific verb 'Get' and resource 'compliance health score', clearly indicating what the tool does. It also mentions a breakdown by framework, which distinguishes it from the sibling 'list_frameworks' tool that lists frameworks rather than providing a score.
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 implicitly implies when to use this tool (to get a compliance score), but it does not explicitly state when to use alternatives or provide any usage exclusions. The sibling 'list_frameworks' is related but no guidance on choosing between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific AI chat conversation by ID, including full message history. Useful for resuming context.
| Name | Required | Description | Default |
|---|---|---|---|
| conversationId | Yes | Conversation ID (from list_conversations) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a read operation ('Get') and mentions the return includes full message history, but fails to mention permissions, rate limits, error conditions (e.g., invalid ID), or that it is read-only.
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 two sentences, front-loaded with the core action, and contains no extraneous words. Every sentence 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 retrieval tool with one parameter and no output schema, the description covers the essential purpose and return value. It lacks details on error handling and read-only nature, but is largely sufficient.
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% and the parameter description already explains the conversationId comes from list_conversations. The tool description adds minimal value beyond the schema ('by ID'), so baseline score of 3 is 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?
The description explicitly states the tool retrieves a specific conversation by ID with full message history, clearly distinguishing it from list_conversations (which lists conversations). The verb 'Get' and resource 'AI chat conversation' are specific.
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 mentions 'Useful for resuming context' implying when to use, but does not explicitly state when not to use or contrast with siblings like list_conversations. No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for a specific file: name, size, type, storage provider, tags, created/modified dates, compliance protection status, and a 15-minute presigned download URL.
| Name | Required | Description | Default |
|---|---|---|---|
| fileId | Yes | Teralynk file ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the 15-minute presigned download URL behavior and lists metadata fields, but doesn't mention error handling, authentication, or rate limits.
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?
Single sentence, front-loaded with purpose, enumerates contents without wordiness. Every part is informative.
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 retrieval tool with one required param and no output schema, the description covers return fields adequately. Lacks error/edge-case info but is complete enough for typical use.
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?
Single parameter (fileId) is fully described in schema with description 'Teralynk file ID'. Description adds no extra meaning beyond that, meeting baseline for 100% schema coverage.
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?
Description clearly states it gets full metadata for a specific file, enumerating returned fields (name, size, type, etc.), and distinguishes from siblings like list_files and search_files by focusing on a single file.
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?
Implied usage (get metadata for a file) but no explicit guidance on when to use vs alternatives like get_file_download_url or get_file_versions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a presigned download URL for a file. URL is valid for 15 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| fileId | Yes | Teralynk file ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the URL is presigned and has a 15-minute validity, but does not mention authorization requirements, error cases (e.g., non-existent file), or what happens upon expiry. It adds some behavioral context but leaves gaps.
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 two sentences with no wasted words. It front-loads the core purpose in the first sentence. However, it could be slightly more informative without losing conciseness, e.g., mentioning that the URL can be used to download the file directly.
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?
The tool is simple (one parameter, no output schema, low complexity), but the description does not specify the return format (e.g., the URL string) or any necessary preconditions like file existence or permissions. While the URL validity info is useful, the description could be more complete given the lack of annotations and output schema.
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 input schema has 100% coverage with a description for fileId ('Teralynk file ID'). The tool description adds no additional meaning beyond that. Baseline 3 is appropriate because the schema already handles the parameter documentation.
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 'Get a presigned download URL for a file.' This uses a specific verb and resource, and distinguishes it from sibling tools like get_file (which downloads the file content) and list_files (which lists files).
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 does not provide guidance on when to use this tool versus alternatives. It only mentions the URL validity period (15 minutes), but no when/when-not or alternative tool suggestions. Given the sibling list, more explicit usage guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all versions of a file with timestamps and sizes. Useful before deciding to delete or restore.
| Name | Required | Description | Default |
|---|---|---|---|
| fileId | Yes | Teralynk file ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds some context (what is returned) but does not disclose read-only nature, permissions, or pagination 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 sentences, no wasted words, front-loaded with main purpose.
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?
Adequately covers purpose and usage for a simple listing tool with one parameter; could mention version sorting or limits.
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 fileId described; description adds no extra meaning 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?
Description clearly states verb 'list' and resource 'versions of a file', mentions output (timestamps and sizes), and distinguishes from siblings like get_file or list_files.
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?
Provides specific use case ('useful before deciding to delete or restore'), but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a long-running async operation — full compliance scan, report generation, or DSAR. Poll until status is "completed" or "failed". Returns progress percentage and result location when done.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job ID returned by the initiating tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool is for long-running operations, returns progress and result location, and implies polling behavior. Lacks details on side effects or idempotency, but sufficient for a read-only status check.
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 sentences, no extraneous words. Front-loaded with purpose and examples, followed by usage and return information. Every sentence adds value.
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?
No output schema, but description mentions return values (progress percentage, result location). Lacks explicit status enum or error behavior, but adequate for a simple polling tool given sibling tools don't overlap.
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 covers 100% of the single parameter (jobId) with a clear description ('Job ID returned by the initiating tool'). The tool description reinforces the polling context but adds no additional parameter semantics 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?
The description uses a specific verb ('Check the status') and resource ('long-running async operation'), with concrete examples (compliance scan, report generation, DSAR), clearly distinguishing from sibling tools that handle files or other operations.
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?
Explicitly states when to use (polling async operations) and what to expect (statuses 'completed' or 'failed'), but does not mention when not to use or provide alternative tools, though none are needed given its unique purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the user's recent notifications — file shares, scan completions, violation alerts, workflow updates, and system messages. Returns up to 20 most recent notifications.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the return size limit but omits authentication needs, rate limits, or side effects like marking as read. Adequate but not thorough.
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 concise sentences that quickly convey the tool's purpose and key constraint. No unnecessary words.
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 one-param tool with no output schema, the description adequately explains what is returned and the limit. It does not mention ordering (assumed most recent) or pagination, but is largely complete.
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%, and the description does not add meaning beyond the schema's 'limit' parameter. It reiterates the same info (returns up to 20). No extra details like valid range.
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 specific verb ('Get') and identifies the resource ('notifications'). It lists concrete types (file shares, scan completions, etc.), distinguishing it from sibling tools like list_files or get_analytics.
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 use for viewing recent notifications but offers no explicit guidance on when to use or when to avoid. No alternatives are mentioned. However, the context of siblings makes the domain clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List previous AI chat conversations with title, last message preview, model used, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation but fails to disclose any behavioral traits such as authentication needs, rate limits, or destructive effects. The minimal description assumes common sense but does not explicitly confirm safety.
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 a single concise sentence that is front-loaded with the purpose. It contains no fluff, though it could be slightly more structured (e.g., listing fields separately).
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 list tool with one parameter and no output schema, the description adequately specifies the output fields and the parameter. It lacks details on ordering or pagination but is sufficient for the tool's simplicity.
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 describes the only parameter 'limit' with type and default, achieving 100% coverage. The description adds no additional semantics beyond the schema, so a baseline of 3 is 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?
The description clearly states the verb 'List', the resource 'previous AI chat conversations', and the specific fields returned (title, last message preview, model used, timestamps). It distinguishes itself from siblings like list_files and get_conversation.
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 guidance is provided on when to use this tool versus alternatives like get_conversation. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the authenticated user's files in Teralynk. Supports search, pagination, and filtering by storage provider. Returns file IDs needed for scan_file_for_pii, get_file, delete_files, protect_files, and share_file.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 50) | |
| offset | No | Pagination offset | |
| search | No | Filename substring filter | |
| starred | No | If true, return only starred files | |
| provider | No | Filter by storage provider (e.g. "s3", "google-drive", "dropbox") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the operation is read-only or safe, nor does it disclose any potential side effects or limitations beyond the listed features.
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 sentences with no wasted words. Front-loaded with the main purpose and followed by supported features and usage context.
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 no output schema, the description explains the return value (file IDs needed for other tools) and supported features. Could be improved by mentioning default ordering or that it returns file metadata.
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 descriptions for each parameter. The description adds value by grouping parameters into features (search, pagination, filtering) and explaining the return value's purpose.
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 it lists the authenticated user's files, supports search, pagination, and filtering by provider, and distinguishes from sibling tools like search_files and get_file.
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 indicates when to use this tool (to get file IDs for dependent operations) and mentions supported features, but lacks explicit exclusions or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available compliance frameworks (HIPAA, GDPR, PCI-DSS, etc.) with descriptions, control counts, and your current coverage percentage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It accurately describes a read-only listing operation without side effects. However, it does not mention potential timeouts, permission requirements, or whether the coverage percentage is real-time or cached. Minor omission, but overall clear.
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, well-structured sentence that packs all necessary information without redundancy. Every word contributes to understanding the tool's purpose and outputs.
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 the tool has no parameters and no output schema, the description is comprehensive. It fully conveys the scope and content of the returned data. No gaps are apparent.
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, and the input schema coverage is 100% trivial. The description adds semantic value by detailing what the response includes (descriptions, control counts, coverage percentage), which goes beyond the empty 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?
The description clearly states the action ('list'), the resource ('compliance frameworks'), and provides concrete examples (HIPAA, GDPR) along with the returned fields (descriptions, control counts, coverage percentage). It effectively distinguishes from sibling tools like list_files and list_conversations.
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 for retrieving a high-level overview of available frameworks, but does not explicitly state when to use this tool versus the sibling get_compliance_score or any other tool. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across file names and metadata. Returns ranked results with file IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default 20) | |
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. Mentions ranked results but not ranking criteria, scope of metadata searched, or that tool is read-only. Leaves significant gaps for an agent.
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 sentences, front-loaded with key purpose. Efficient, though slight room for more precision without adding length.
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?
Adequate for a simple search tool with 2 params and no output schema, but lacks details on search behavior (e.g., fuzzy matching, supported metadata fields) and how results are ranked.
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 adequate descriptions for query and limit. Description adds only that search is 'full-text' and covers metadata; no additional meaning beyond 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?
Clear verb+resource+scope: 'full-text search across file names and metadata' with return of ranked results and file IDs. Distinguishes from sibling tools like list_files (listing without search) and get_file (single file retrieval).
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?
Implies use for full-text search but lacks explicit when to use vs. alternatives (e.g., list_files for unfiltered listing, get_file for known file). No guidance on when not to use.
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. Dates show when Glama detected each change.
v1.0.0get_analyticsget_billing_usageget_compliance_scoreget_conversationget_fileget_file_download_urlget_file_versionsget_job_statusget_notificationslist_conversationslist_fileslist_frameworkssearch_filesEach tool targets a distinct area: file management, compliance, analytics, conversations, billing, notifications, and job status. There is no overlap in purposes despite some related functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_files, get_file_download_url), with no mixing of conventions or ambiguous verbs.
With 13 tools, the server is well-scoped for a compliance-focused file management platform. Each tool serves a clear purpose without unnecessary bloat or insufficiency.
The set lacks critical tools implied by descriptions: no create/upload file, no delete file, no protect file, no start scan trigger. Agents hitting these gaps will fail, as the domain expects CRUD and compliance actions.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
10,065 source-verified compliance nodes, 39 pillars, 25 MCP tools (EU AI Act, GDPR, NIST, MITRE).
AI governance MCP server for EU AI Act compliance and jurisdiction verification
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/teralynk/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server