Importly MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are clearly organized into four async operations (import, full metadata, basic metadata, transcription) each with a paired check tool, plus a balance check. The only ambiguity is between import_media with includeTranscript and transcribe_media, but descriptions clarify the intended use.
Naming Consistency5/5
All tool names follow a verb_noun pattern with action verbs (import_media, get_metadata, transcribe_media) and check_ prefixed status tools (check_import, check_metadata, check_basic_metadata, check_transcription). The pattern is consistent and predictable.
Tool Count5/5
With 9 tools, the server is well-scoped for its purpose: four async operations, four corresponding status checks, and a balance check. Each tool serves a distinct need without redundancy.
Completeness4/5
The server covers the core workflows of media import, metadata retrieval (full and basic), transcription, and balance monitoring. Minor gaps exist such as no job cancellation or listing, but these are not essential for the stated purpose.
Average 4.2/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the returned fields (title, duration, thumbnail) once the job completes, implying a read-only status check. However, it doesn't describe the response before completion, error handling, or whether the job is consumed, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main purpose, and every clause earns its place. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool, the description covers the main purpose and final output, but lacks details about the intermediate status response and error behavior. With no output schema, this is a notable gap, though the tool's low complexity keeps it acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the jobId parameter description already explains its origin. The tool description adds no additional meaning beyond confirming it's for a get_basic_metadata job, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a get_basic_metadata job, using a specific verb and resource. It distinguishes itself from sibling tools like check_metadata by explicitly scoping to get_basic_metadata jobs, and adds output details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after calling get_basic_metadata, and the parameter description reinforces that jobId comes from that call. However, it doesn't explicitly mention alternatives or when not to use, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that the full metadata object is returned once completed, but omits what happens before completion (e.g., returns status, null, or throws). It also does not mention whether the operation is read-only, which is a notable gap for a status-check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary action and followed by the key return behavior. Every word adds value, with no fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and successful return, but it lacks critical detail about the pre-completion response or error handling. Since this is a status-check tool, the behavior when the job is still running is essential and not disclosed, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter jobId as 'Job id returned by get_metadata'. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('check the status') and resource ('a get_metadata job'), distinguishing it from sibling tools like get_metadata (which likely initiates the job) and check_basic_metadata (for a different job type). It also specifies the return value, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is used to poll the status of a job started by get_metadata. It does not explicitly mention alternatives or exclusions, but the relationship to get_metadata is evident from the phrasing and parameter description, so the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds value by disclosing that the tool returns 'transcript text and timestamped segments once completed,' which is helpful, but it does not mention behavior for incomplete jobs, error handling, or that it is a read-only polling operation. This leaves some gaps but is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence summary, front-loaded with the primary purpose and followed by a key return-behavior detail. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema or annotations, the description covers the essential purpose and return content. It does not explain exact statuses or output structure, but given the low complexity, the information is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the only parameter 'jobId,' and the schema description already explains the origin of the value ('Job id returned by transcribe_media'). The tool description adds no further parameter detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a transcribe_media job, with a specific verb ('check') and resource ('transcribe_media job'), and distinguishes it from sibling check_* tools by naming the exact job type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for when to use this tool is clear: it is for checking transcription jobs, and the schema parameter description ('Job id returned by transcribe_media') reinforces that it is used after transcribe_media. No exclusions or alternative tools are mentioned, but none are needed given the resource-specific scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Check' and adds context that insufficient credits can cause failed jobs, but it does not state whether the operation is non-destructive, how the balance is returned, or any authentication/rate-limit nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 information. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (0 parameters, no output schema), the description covers the essential context: what the tool does and when to use it. However, it does not explicitly describe the return format, which is a minor gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially covered. The description adds no parameter-specific information, but none is needed. A baseline of 4 is appropriate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the remaining Importly credit balance for the configured API key.' It uses a specific verb ('Check') and resource ('credit balance'), and it distinguishes itself from sibling tools that handle imports, metadata, and transcription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'Use this to diagnose failed jobs (insufficient credits) or as a pre-flight check before large imports/transcriptions.' This gives clear context on when to invoke the tool, though it does not mention when-not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavior: it returns a media download URL and optionally a transcript 'once the job completes,' implying it may wait for completion. The read-only nature is evident from 'check the status.' It does not mention error handling, but the described behavior is sufficient for a status-check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and return value without redundancy. Every word earns its place, and it is compact and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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), and the description covers the main return value (URL, optional transcript). It does not describe status values or failure modes, but for a lightweight polling tool, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the only parameter (jobId), and its description ('Job id returned by import_media') already defines it clearly. The tool description adds no additional parameter details, but the schema handles the semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the status of an import_media job.' It uses a specific verb ('check') and resource ('import_media job'). This distinguishes it from sibling tools like check_metadata and check_transcription, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to check jobs created by import_media, providing clear context. While it does not explicitly name alternatives, the sibling tools' names (check_metadata, check_transcription) indicate they serve different purposes, so there is no ambiguity about when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 server-side execution via yt-dlp, residential proxies, and ffmpeg, hosted storage output, and async behavior. It lacks details on failure modes or rate limits but is transparent about the core workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: first states the purpose and output, second explains the technical implementation, third covers async behavior and the optional transcript. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter async tool with no output schema, the description covers the main use case, direct link result, jobId polling, and optional transcript. It does not discuss cost or error handling, but is fairly complete for an import operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds a bit of meaning by calling out includeTranscript, but it does not elaborate on audio/video quality defaults or transcript language beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Download the video/audio at any URL' and lists supported sites (YouTube, TikTok, X, 1000+). This specific verb+resource distinguishes it from sibling check/status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the async pattern: 'returns a jobId immediately; poll check_import for the result.' It also mentions the optional transcript option, but does not explicitly contrast with the sibling transcribe_media tool for transcription-only jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the async nature via 'Async: poll check_basic_metadata with the returned jobId', the limited scope of data ('title, duration, and thumbnail only'), and cost-related traits ('Cheaper and quicker'). It does not explicitly state read-only behavior, but 'identify or validate' implies a non-mutating operation, which is sufficient for this context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose and return scope, the second gives usage guidance and async note. It is front-loaded with the verb and resource, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain what is returned, which it does ('title, duration, and thumbnail'). It also covers the async workflow, differentiating from get_metadata, and provides a clear use case. Given the simple single-parameter schema, the description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (url) has 100% schema description coverage with a concrete example, so the schema already fully documents it. The tool description adds only contextual framing (video/audio URL) but no additional parameter semantics. Per the rubric, baseline 3 is appropriate when schema covers parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Fast-path metadata for a video/audio URL' with specific return fields (title, duration, thumbnail), and distinguishes itself from the sibling tool get_metadata by noting it is 'Cheaper and quicker than get_metadata'. This gives a specific verb+resource+scope and differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'use this to identify or validate a media URL before importing or transcoding it', providing a clear when-to-use context. It also implies when not to use it by contrasting with get_metadata for richer metadata. The async polling instruction ('poll check_basic_metadata with the returned jobId') further guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses server-side download/extraction, async behavior (returns jobId, poll check_transcription), and cost scaling with a cap mechanism. This goes beyond a simple 'transcribe' statement and provides useful operational context, though it could mention failure modes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, server-side handling with no external tools, and async/cost guidance. Information is front-loaded with the main action, and no fluff or repetition. Exceptionally concise for the amount of context provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects for a complex async tool: what it does, how to handle the async pattern (jobId + polling), cost implications, and the lack of external dependencies. Even without an output schema, the agent knows how to initiate and retrieve results. This is highly complete for the given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining maxCostDollars as 'cap spend on long media,' which enriches the schema's generic description. It also clarifies the tool's output (timestamped segments) indirectly. Language and url are straightforward from schema, so the added context for cost is meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Transcribe the audio of any video/audio URL... to text with timestamped segments.' It explicitly differentiates itself from siblings by mentioning 'Async: returns a jobId immediately; poll check_transcription for the transcript,' which contrasts with the polling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to transcribe media from various sites) and explicitly names check_transcription as the alternative for obtaining results. It also advises setting maxCostDollars for long media. However, it does not explicitly mention when not to use it relative to other import tools, though the async/cost guidance largely covers usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the async behavior (poll check_metadata), that no media is downloaded, and that it works across 1000+ sites. It does not mention auth or rate limits, but the core non-blocking pattern is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the first lists fields, the second covers site breadth, the third covers async flow and alternative tool. Front-loaded with the main verb and resource, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is self-sufficient. It explains the full lifecycle (submit URL → get jobId → poll check_metadata), lists expected metadata fields, and gives context on which sites work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the url parameter with a concrete example, so baseline is 3. The description adds the 'video/audio URL' qualifier and lists supported sites, clarifying accepted input beyond the schema's generic 'Media page URL'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Extract full metadata for a video/audio URL' – a specific verb and resource followed by a list of returned fields. It differentiates from the sibling get_basic_metadata by emphasizing 'full metadata', making the tool's unique purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to prefer get_basic_metadata for lighter needs ('For just title/duration/thumbnail, prefer the faster get_basic_metadata') and tells the agent to poll check_metadata with the returned jobId for results. This is clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![importly-mcp MCP server](https://glama.ai/mcp/servers/yyildiz/importly-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yyildiz/importly-mcp)

Score Badge

Copy to your README.md:

[![importly-mcp MCP server](https://glama.ai/mcp/servers/yyildiz/importly-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yyildiz/importly-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yyildiz/importly-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server