Noves MCP Server

Official

by Noves-Inc

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.1.3
Disambiguation2/5
Several tools overlap significantly: get_translated_transaction and get_transaction_details both describe a specific transaction in natural language, and get_wallet_summary and analyze_wallet both provide wallet insights. This creates ambiguity in choosing the right tool for a given task.
Naming Consistency5/5
All tool names follow a consistent 'get_' prefix with descriptive nouns (e.g., get_recent_transactions, get_historical_token_price). The pattern is uniform and predictable across the entire set.
Tool Count5/5
With 9 tools, the server is well-scoped for its domain of blockchain analytics and price lookups. Each tool targets a specific resource or operation, and the count is neither too sparse nor overwhelming.
Completeness4/5
The tool surface covers recent transactions, specific transaction details, transfers, wallet summaries, and token price data, which is comprehensive for a transaction-translation and wallet-analytics server. A minor gap is the lack of tools for token balance or blockchain-level queries, but core workflows are well represented.
Average 3.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It mentions natural language summaries (an output trait) but does not state whether the operation is read-only, if it has side effects, or any limitations. This is insufficient for a tool making analysis calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is efficiently structured, though it sacrifices details for brevity. The trade-off is acceptable given the minimal tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of get_wallet_summary as a sibling, the description is incomplete for contextual selection. It does not clarify what 'insights' entail, what the output structure looks like, or how this differs from simply getting a wallet summary. The description is too sparse for an agent to make a fully informed decision.
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 provides descriptions for all three parameters (chain, timeframe, walletAddress), so schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already states, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as analyzing wallet activity and providing natural language insights, which distinguishes it from simple data retrieval tools. However, it does not explicitly differentiate from the similar sibling get_wallet_summary, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of scenarios like 'use for high-level insights' or how it compares to get_wallet_summary, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 does not disclose any behavioral traits such as whether the price is live, if there are rate limits, or what side effects might occur. The read-only nature is implied but not explicitly stated, and there is no mention of error conditions or return format.
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 efficiently conveys the tool's purpose without any redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two well-documented parameters, the description is minimal. However, there is no output schema, so the description should explain what the price response looks like (e.g., currency, format). It also does not mention supported chains or any caveats, leaving the agent without complete context for invocation and response handling.
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 description coverage is 100%, with both 'chain' and 'tokenAddress' clearly documented. The description adds minimal extra meaning, only echoing 'specific blockchain' which is already in the schema. Baseline of 3 is appropriate since the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and specifies the resource 'current price of a token on a specific blockchain', which is clear. It implicitly distinguishes from siblings like get_historical_token_price and get_token_price_comparison, but does not explicitly name them or highlight the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_historical_token_price or get_token_price_comparison. There is no mention of exclusions, prerequisites, or recommended use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only says 'comprehensive summary with key insights' but does not explain what insights are included, how the summary is computed, or whether it affects state. This is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but the phrases 'comprehensive' and 'key insights' are vague filler that reduce precision. Still, it is appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations exist, so the description must explain what the summary contains and how it differs from sibling tools like analyze_wallet. It fails to do so, leaving users unsure about the return format or the exact scope of 'wallet activity'.
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 description coverage is 100%, so each parameter is documented in the input schema. The description adds no additional meaning about the parameters or their relationships, keeping this at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'comprehensive summary of wallet activity', identifying a specific verb and resource. However, it does not differentiate from sibling tools like analyze_wallet or get_recent_transactions, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The word 'summary' implies an overview use case, but there is no explicit context, exclusions, or mention of related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only says 'Get historical price' and adds no information about side effects, authentication, rate limits, or return format. For a read operation, this minimal information is insufficient for the agent to anticipate behavior.
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, clear sentence that is front-loaded with the core purpose. Every word contributes to the meaning, with no filler or 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?
The tool has no output schema, so the description should convey what the result contains (e.g., currency, price format). It does not, leaving the return value ambiguous. However, the tool is simple and the input parameters are well-documented, so it is minimally viable.
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 already provides descriptions for all three parameters (chain, tokenAddress, timestamp) with 100% coverage. The description adds no additional meaning beyond what the schema already states, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the historical price of a token at a specific timestamp, using a specific verb and resource. It is distinct enough from siblings like get_current_token_price and get_token_price_comparison because of the 'historical' and 'timestamp' qualifiers, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios such as needing current prices or comparing prices, nor does it exclude any use cases. There is no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'get detailed transfer information' without explaining what 'detailed' includes, the scope of 'recent', or any edge cases. It does not disclose whether only token transfers are returned or if all transfers are included, leaving the agent guessing.
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 sentence with no waste, immediately stating the action and focus. It is well-structured and front-loaded with the important terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what the tool returns and from what scope. It mentions 'recent transactions' and 'limit' but does not explain how these interact or what 'detailed transfer information' concretely looks like. The description is insufficient for an agent to predict the tool's output.
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 description coverage is 100%, so all parameters are documented (chain, walletAddress, limit). The description adds minimal extra meaning, only the phrase 'focus on token movements' hints at parameter relevance. Baseline of 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get), resource (transfer information from recent transactions), and focus (token movements). It distinguishes itself from siblings like get_transaction_details by specifying 'recent transactions' and 'transfer information', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving transfer-related data from recent transactions, but does not provide explicit when/when-not guidance or mention alternative tools. It gives a sense of context ('recent transactions', 'token movements') but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the output format. It does not mention side effects, limitations, required permissions, or error conditions. While 'get' implies a read operation, the description provides no explicit safety or behavioral 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 a single, efficiently worded sentence that front-loads the verb and resource. It avoids redundancy and extra filler, achieving maximal clarity in minimal space.
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?
The description covers the essential purpose and output type (natural language analysis) but lacks specifics about what the analysis includes or potential edge cases. Without an output schema or annotations, more detail might be expected, yet the simplicity of the tool (2 params) keeps 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 already documents both parameters with descriptions (chain as 'Blockchain network', transactionHash as 'Transaction hash to analyze'), achieving 100% schema description coverage. The tool description adds no extra parameter meaning, 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 identifies the tool's function: to 'get detailed analysis of a specific transaction' and explicitly notes the output is a 'natural language description'. This distinguishes it from sibling tools like get_transaction_transfers (transfers only) or get_translated_transaction (translation), establishing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to choose this tool over siblings, nor does it mention any exclusions or alternative tools. The agent is left to infer applicability based solely on the vague term 'detailed analysis'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states what the tool does (generates a human-readable description) but does not mention whether the operation is read-only, what output format to expect, or any limitations of the translation service.
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, well-structured sentence that conveys purpose and method without redundant words. It 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 simple get-type tool with two well-documented parameters and no output schema, the description is sufficient. It clearly states what the tool does and how it differs from likely siblings. It could mention the return format, but this is not critical given the tool's simplicity.
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 description coverage is 100%: both 'chain' and 'transactionHash' are described adequately in the input schema. The description does not add parameter-specific details beyond the schema, so the baseline score 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 explicitly identifies the action ('Get'), the target ('human-readable description of a specific transaction'), and the method ('using Noves translation'). This distinguishes it from sibling tools like get_transaction_details (likely raw details) and get_transaction_transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description and tool name: when a user wants a natural language explanation of a transaction. However, there is no explicit guidance on when to choose this over siblings or any exclusions/alternatives.
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, the description carries the full burden. It discloses the return format ('natural language descriptions') and implies read-only behavior via 'Get', but it does not mention pagination, sorting, or authentication. The added behavioral trait (natural language descriptions) gives it a 3 rather than lower.
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 12-word sentence that conveys the purpose without any fluff. Every word earns its place, making it extremely concise and well-structured.
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 read tool with no output schema and no annotations, the description provides a clear purpose but does not fully cover expected behavior or return details. It is adequate but could benefit from mentioning the default limit or the nature of 'natural language descriptions' to be more 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?
Schema coverage is 100% with each parameter (chain, limit, walletAddress) already described. The description does not add parameter-level semantics beyond mentioning the wallet address, so the baseline 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 names a specific action ('Get recent transactions') and resource ('wallet address'), and adds a distinguishing feature ('natural language descriptions') that differentiates it from sibling tools like get_transaction_details or get_translated_transaction. It is clear and specific.
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 clearly implies when to use this tool (when you need recent transactions for a wallet address), but it does not explicitly name alternatives or scenarios to avoid. It provides clear context without exclusions, matching a 4.
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 discloses the core behavior (comparing prices) but does not specify the output format, such as whether it returns a percentage, absolute difference, or a structured object. This is adequate but lacks detail on return value or potential side effects.
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, focused sentence that conveys the essential purpose without waste. It is well-structured and front-loaded, making it easy for an agent to parse quickly.
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?
The tool has no output schema and no annotations, so the description must cover the essentials. It does explain the main purpose but omits details like the result format, units, or edge-case handling (e.g., equal timestamps). Suitable for a simple tool but not comprehensive.
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 description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema—it only reinforces the 'between two timestamps' relationship. No additional parameter details are given, but the schema already documents each parameter sufficiently.
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: comparing token price between two timestamps to show price change. This explicitly distinguishes it from sibling tools like get_current_token_price and get_historical_token_price, which do not involve comparison between two points in time.
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 use case: when users need to compare prices at two different timestamps. It does not explicitly name alternatives or exclusions, but the context is clear given the sibling tool names and the 'between two timestamps' phrasing. A brief mention of when not to use it would push it to 5.
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:

[![noves-mcp MCP server](https://glama.ai/mcp/servers/Noves-Inc/noves-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Noves-Inc/noves-mcp)

Score Badge

Copy to your README.md:

[![noves-mcp MCP server](https://glama.ai/mcp/servers/Noves-Inc/noves-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Noves-Inc/noves-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/Noves-Inc/noves-mcp'

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