jazz-tools-mcp-v2

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: querying, fetching by ID, creating, updating, deleting, status checks, schema reload, table listing, and table description. No overlapping functionality.
Naming Consistency5/5
All tools follow a consistent jazz_<verb> pattern with snake_case, e.g., jazz_query, jazz_get_row, jazz_list_tables. Naming is uniform and predictable.
Tool Count5/5
9 tools is well-suited for a Jazz database MCP server. The set covers CRUD operations, schema introspection, and administrative actions without being excessive or thin.
Completeness5/5
The tool set provides full CRUD coverage (insert, get/query, update, delete), schema exploration (list tables, describe table), and operational management (status, reload schema). No obvious gaps for the domain.
Average 3.9/5 across 9 of 9 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and idempotentHint=true, but the description explicitly says 'Drop the local Jazz runtime,' implying a destructive side effect. This directly contradicts the read-only claim, making the description misleading about the tool's actual behavior.
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 that front-loads the action. However, the word 'drop' is unnecessarily alarming and detracts from clarity, though structurally the description is well-sized.
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 tool's simplicity (0 params, no output schema), the description should clearly state the operation and side effects. The contradiction between 'drop' and readOnlyHint leaves the agent confused, and there is no mention of when this tool should be invoked, making it incomplete.
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 input schema has zero parameters, so there are no parameter semantics to explain. The description need not compensate, and the baseline for 0 params is 4.
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 states a clear action: drop the local Jazz runtime and reload the newest schema from the server catalogue. This distinguishes it from sibling data-access tools like jazz_query and jazz_get_row. However, the verb 'drop' introduces slight ambiguity, as it could be interpreted as terminating the runtime rather than merely refreshing it.
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 the tool should be used to refresh the local schema to match the newest published version, but it does not explicitly state when to use it over alternatives like jazz_describe_table, nor does it mention exclusions. The usage context is implied rather than explicit.
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?
Annotations already declare readOnlyHint=true, and the description's 'Fetch' aligns with that. The description adds the scope (by table name and row id) but does not disclose behaviors like what happens if the row is not found or whether the response is wrapped.
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 short sentence, front-loaded with the verb 'Fetch', and contains no unnecessary words. It is highly concise and directly to the point.
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 2-parameter read tool with annotations indicating read-only behavior, the description covers the core purpose and parameter identity well. There is no output schema to explain, and the description is adequately complete for its simplicity. It lacks mention of error cases or return format, which are not strictly necessary here.
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 0% description coverage for parameters. The description compensates by mapping 'table name' to the 'table' parameter and 'row id' to the 'id' parameter, but it adds no further semantics beyond their names and purpose.
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 uses a specific verb 'Fetch' and a clear resource 'one Jazz row', explicitly identifying the operation and the key identifiers (table name and row id). This clearly distinguishes it from sibling tools like jazz_insert, jazz_delete, and the broader jazz_query.
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 the tool is used when you have a table name and row id and want that single row. However, it provides no explicit guidance on when to use this instead of jazz_query or other siblings, nor any exclusion criteria.
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?
Annotations already indicate this is a mutating, non-idempotent operation. The description adds valuable behavioral context: 'privileged backend access' and the environment variable requirement. No contradiction with annotations.
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?
A single sentence with no filler, front-loading the core action and then the key prerequisite. Every word earns its place.
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 two-parameter insert tool with annotations, the description covers the primary usage context and gate condition. However, it omits return value expectations and error behavior, which would be helpful without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameter descriptions, and the description does not explain 'table' or 'values'. 'Insert a row' implies 'values' represents the row data, but no structural details are provided, which is insufficient given the 0% schema coverage.
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: 'Insert a row' using Jazz's native mutation API. This specific verb+resource action distinguishes it from sibling tools like jazz_update and jazz_delete, and the mention of privileged backend access adds specificity.
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 creating new rows and provides the critical prerequisite that it is disabled unless JAZZ_MCP_ALLOW_WRITES=true. However, it does not explicitly contrast with alternatives like jazz_update for modifying existing rows or mention when not 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?
Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is known. The description adds valuable context beyond annotations: it requires 'privileged backend access' and mentions the JAZZ_MCP_ALLOW_WRITES flag, which explains the operational condition for destructive writes. It also explicitly states 'Delete one Jazz row,' indicating the scope of destruction.
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 with no unnecessary words. It front-loads the action and includes a critical operational note about the write flag. 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 simple two-parameter delete tool with no output schema, the description covers the essential behavioral aspects: it deletes one row, requires privileged access, and is gated by a configuration flag. It does not explain return values (none expected) or parameter syntax, but given the tool's simplicity and existing annotation coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It does not mention 'table' or 'id' at all, nor does it clarify how they identify the row. The phrase 'one Jazz row' implies the need for identifiers, but the description fails to explicitly connect these parameters to their function.
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 action ('Delete one Jazz row') with a specific resource ('Jazz row') and scope ('one'), making it distinct from sibling tools like jazz_query, jazz_insert, and jazz_update. The inclusion of 'native delete operation' reinforces its purpose as the deletion tool.
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 mentions that the tool is 'Disabled unless JAZZ_MCP_ALLOW_WRITES=true', which is a clear prerequisite, but it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The usage is implied as the delete operation, but no direct comparative guidance is given.
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?
Beyond annotations (which only mark not read-only, not idempotent, not destructive), the description adds that the operation uses 'privileged backend access' and 'wait[s] for configured durability,' and is disabled unless JAZZ_MCP_ALLOW_WRITES=true. This provides context not available in annotations.
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?
One sentence, front-loaded with the primary action, and no fluff. The additional clauses about privileges and enablement provide important context without excessive length.
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 description covers the core purpose, the need for privileged access, durability behavior, and the enablement condition. It lacks explicit return value details and a more detailed explanation of the values parameter, but the sibling tool set and schema context make it reasonably complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three required parameters (table, id, values) with no descriptions. The description only generally mentions 'update fields on one Jazz row,' implying table and id identify the row and values are the fields, but it does not explain the expected structure of the values object or any constraints. With 0% schema coverage, more explicit parameter mapping would be needed.
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 'Update fields on one Jazz row' – a specific verb (update) and resource (Jazz row). It differentiates from sibling tools like jazz_insert and jazz_delete by signaling modification of existing rows.
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 modifying existing Jazz rows but does not explicitly contrast with alternatives or state when not to use it. It mentions the prerequisite of JAZZ_MCP_ALLOW_WRITES=true and privileged access, but no direct comparison to siblings.
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?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds that the tool returns a schema descriptor plus magic columns, but it does not disclose error behavior (e.g., nonexistent table) or any additional operational constraints. This is consistent with annotations and provides some context, but not beyond basic expectations.
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 that front-loads the main action and resource. It contains no filler and every word contributes to understanding—the qualifiers 'official', 'WASM', 'query-time magic columns' are all informative.
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 that the tool has only one parameter and an annotation declaring read-only, the description provides adequate high-level context: it states the return type (schema descriptor) and the additional magic columns. However, it omits any detail about the output structure or potential errors, which could be helpful but is not essential for a simple metadata tool.
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?
With schema description coverage at 0%, the description must clarify the only parameter. It does so by saying 'for one table', indicating that the 'table' parameter is the table identifier. No further format or restriction details are given, but minimal ambiguity remains given the single parameter.
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 uses a specific verb 'Return' and identifies the resource as 'the official Jazz WASM schema descriptor for one table'. This clearly distinguishes it from siblings like jazz_list_tables (lists tables) and jazz_query (queries data). The mention of 'magic columns' adds further specificity.
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 its usage—when you need the schema descriptor for a specific table—but it does not provide explicit guidance on when to use this versus sibling tools like jazz_list_tables or jazz_query. No alternatives or exclusions are mentioned.
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?
Annotations already declare readOnlyHint=true, and the description adds the scoping detail that tables are from the 'published Jazz schema currently used by the connector,' which is useful context. However, it does not disclose additional behavioral traits such as return format or whether the list might be stale.
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 efficient sentence that front-loads the verb 'List' and specifies the resource clearly. No unnecessary words 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 read-only list tool with no parameters and no output schema, the description is mostly sufficient. It clearly states what it lists, though it could explicitly mention that the return is a collection of table names, but this is implied and not a significant gap.
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?
With zero parameters, the schema carries no information, and the description correctly implies no arguments are needed. The baseline for 0 params is 4, and the description does not need to compensate for any undocumented 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?
Description uses the specific verb 'List' with the resource 'tables in the published Jazz schema currently used by the connector,' clearly distinguishing it from siblings like jazz_describe_table (which describes a single table) and jazz_query (which queries data).
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 phrase 'currently used by the connector' implies this is the appropriate tool for viewing the active table set, but no explicit alternatives or when-not-to-use guidance is provided. Usage is inferred rather than directly stated.
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?
Annotations already provide readOnlyHint=true, so the description does not contradict that. The description adds specific behavioral context by listing exactly what status aspects are checked (server, schema, auth mode, write safety). This goes beyond the annotation and helps the agent understand the tool's focus, though it does not elaborate on potential response details.
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, concise sentence that front-loads the action ('Check') and then lists the key elements. It contains zero filler and is clearly structured for quick parsing.
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?
Given the tool's low complexity (0 parameters, no output schema) and the readOnlyHint annotation, the description is complete enough. It clearly indicates what the tool checks, which is sufficient for an agent to understand the tool's purpose and invocation. No return format is explicitly documented, but the listed items imply the expected status information.
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 input schema has zero parameters, and the baseline for 0 params is 4. The description appropriately avoids mentioning parameters since there are none. No additional parameter semantics are needed.
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 uses the specific verb 'Check' and enumerates distinct items (server, schema, auth mode, write safety settings), making it clear this is a status/configuration inspection tool. It clearly differentiates from sibling tools like jazz_query or jazz_insert by focusing on configuration rather than data operations.
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 verifying the current server state, but there is no explicit guidance on when to use this tool versus alternatives. No exclusion or alternative tool is mentioned, though the nature of the tool and sibling names make the context reasonably clear. It lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint annotation, the description adds crucial behavioral detail: operator objects (gt, contains, in), AND-combining of conditions, lack of OR support, and magic column capabilities. It also warns 'This is not SQL', which prevents misuse. This goes well beyond the minimal annotation.
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, front-loaded with the core purpose, then essential details on operators, limitations, and non-SQL nature. Every sentence adds value without redundancy or fluff.
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 moderate complexity and absent output schema, the description covers the critical aspects of querying behavior and parameters. It could mention return value shape or pagination, but the existing detail on where and limitations makes it largely self-sufficient for an agent to use correctly.
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 description coverage is 0%, so the description must compensate. It thoroughly explains the 'where' parameter semantics (scalars vs operators, AND-only logic) and notes magic columns for select/filter. However, it does not elaborate on select, orderBy, limit, or offset semantics beyond their schema names, leaving some gaps.
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 'Query a Jazz table through Jazz's native query builder'—a specific verb, resource, and scope. It distinguishes itself from siblings like jazz_get_row by indicating its query-builder nature and explicitly saying 'This is not SQL', which differentiates it from SQL-based query tools.
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 querying with structured conditions but does not explicitly state when to use this over alternatives like jazz_get_row or when not to use it. It provides no 'use this when' guidance, but the query semantics are described, offering implied context.
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:

[![jazz-tools-mcp-v2 MCP server](https://glama.ai/mcp/servers/kodyka/jazz-tools-mcp-v2/badges/card.svg)](https://glama.ai/mcp/servers/kodyka/jazz-tools-mcp-v2)

Score Badge

Copy to your README.md:

[![jazz-tools-mcp-v2 MCP server](https://glama.ai/mcp/servers/kodyka/jazz-tools-mcp-v2/badges/score.svg)](https://glama.ai/mcp/servers/kodyka/jazz-tools-mcp-v2)

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/kodyka/jazz-tools-mcp-v2'

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