How do I use jazz-tools-mcp-v2?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jazz-tools-mcp-v2 query todos where done is false" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

jazz-tools-mcp-v2

by kodyka

Overview Schema Related Servers Score Discussions

TypeScript

Remote

jazz-tools-mcp-v2

MVP Model Context Protocol data connector for the official jazz-tools@alpha server.

This project deliberately targets the current Jazz 2 alpha architecture. It does not use the old jazz-nodejs / CoJSON 0.9.x APIs and it does not start a second Jazz sync server.

Jazz itself also ships jazz-tools mcp. That is the official documentation MCP (list_pages, search_docs, get_doc). This repository is a separate, privileged connector for application data.

Security boundary

This MCP connects with Jazz admin/backend credentials and therefore operates with privileged backend access, not an end-user permission-scoped session.

read tools may see rows an ordinary user would not be permitted to read
mutation tools, when enabled, may bypass ordinary row-level user policies
JAZZ_MCP_PRINCIPAL changes write attribution only; it does not impersonate a user for permission evaluation

Treat this process and its secrets like database administrator credentials. Run it only in trusted operator/agent environments. Writes remain disabled by default.

Related MCP server: Snowflake Cube Server

What it connects to

The official self-hosted server is started like this:

export JAZZ_APP_ID="replace-with-your-app-id"
export JAZZ_ADMIN_SECRET="replace-with-admin-secret"

npx jazz-tools@alpha server "$JAZZ_APP_ID" \
  --port 1625 \
  --data-dir ./data \
  --admin-secret "$JAZZ_ADMIN_SECRET"

The MCP connector talks to that process in two ways:

HTTP catalogue endpoints discover the published Jazz schema.
Jazz's own NAPI backend runtime connects to the app-scoped WebSocket sync endpoint for queries and mutations.

There is no SQL bridge and no invented REST CRUD API.

MVP tools

Read tools:

jazz_status
jazz_reload_schema
jazz_list_tables
jazz_describe_table
jazz_query
jazz_get_row

Mutation tools, disabled by default:

jazz_insert
jazz_update
jazz_delete

jazz_query uses the same generic Jazz query JSON shape used by the official Jazz Inspector. Example:

{
  "table": "todos",
  "where": {
    "done": false,
    "title": { "contains": "ship" }
  },
  "select": ["title", "done", "$createdBy", "$updatedAt"],
  "orderBy": [{ "column": "title", "direction": "asc" }],
  "limit": 25
}

Where predicates are AND-combined. Query-level OR is not part of the current Jazz query API. The connector validates operators against the Jazz column type (contains for text, range operators for numeric/timestamp fields, etc.).

Query-time Jazz magic columns supported by the connector are:

$canRead, $canEdit, $canDelete
$createdBy, $createdAt, $updatedBy, $updatedAt

They are query-only system columns and cannot be passed as mutation fields. Row id is likewise not accepted in mutation values; Jazz manages row identity separately.

Requirements

Node.js 22.12+
a running jazz-tools@alpha server
an app ID
the server admin secret
at least one published schema for the app

For Node backends Jazz requires jazz-napi as an explicit dependency. This repository therefore depends on both:

jazz-tools@alpha
jazz-napi@alpha

The connector follows the npm alpha tag for both packages. The research snapshot for this MVP was checked against official Jazz 2.0.0-alpha.53 and repository commit fa7d33b3ecfc9fcb673cd7c7bb9c35d700255e1d on 2026-08-16.

Setup

npm install
cp .env.example .env

Set at least:

JAZZ_SERVER_URL=http://127.0.0.1:1625
JAZZ_APP_ID=replace-with-your-app-id
JAZZ_ADMIN_SECRET=replace-with-admin-secret

Then:

npm run build
npm start

The server uses MCP stdio. Do not write logs to stdout; stdout is reserved for MCP JSON-RPC.

Example MCP client config

{
  "mcpServers": {
    "jazz-data": {
      "command": "node",
      "args": ["/absolute/path/to/jazz-tools-mcp-v2/dist/index.js"],
      "env": {
        "JAZZ_SERVER_URL": "http://127.0.0.1:1625",
        "JAZZ_APP_ID": "your-app-id",
        "JAZZ_ADMIN_SECRET": "your-admin-secret"
      }
    }
  }
}

Using a name such as jazz-data avoids confusion with Jazz's built-in docs MCP.

Schema discovery

The MCP does not crawl your source tree for schema.ts.

At first use it calls the official Jazz schema catalogue APIs:

GET /apps/<app-id>/schemas
GET /apps/<app-id>/schema/<schema-hash>
X-Jazz-Admin-Secret: ...

By default it selects the newest published schema using publishedAt, falling back to the last returned hash. Pin a specific schema with:

JAZZ_SCHEMA_HASH=<hash>

If the server has no schema yet, run your Jazz application in its normal development flow so structural schema auto-sync occurs, or use the project's normal jazz-tools@alpha deploy workflow.

After a new deployment, call jazz_reload_schema or restart the MCP process. Jazz contexts are schema-bound after initialization, so reload tears down the old local runtime before loading the new schema.

Authentication modes

Preferred production backend mode

The Jazz v2 backend documentation recommends explicit backend identity for server-connected server-owned work. Start Jazz with both secrets:

npx jazz-tools@alpha server "$JAZZ_APP_ID" \
  --port 1625 \
  --data-dir ./data \
  --admin-secret "$JAZZ_ADMIN_SECRET" \
  --backend-secret "$JAZZ_BACKEND_SECRET"

Then configure:

JAZZ_BACKEND_SECRET=...

The MCP uses context.asBackend(schema).

To stamp mutation provenance while retaining backend-level permissions:

JAZZ_MCP_PRINCIPAL=mcp:agent

This uses context.withAttribution(...) and requires JAZZ_BACKEND_SECRET.

Compatibility mode: admin secret only

The exact self-host example above contains only --admin-secret. The current alpha Rust server accepts admin_secret in its WebSocket handshake as backend access, so the connector retains an admin-only compatibility path and uses the context's admin-authenticated transport.

This path is tested in CI against Jazz's official startLocalJazzServer + deploy test utilities. For production server-owned work, prefer the explicit backend-secret mode above.

Write safety

Writes are off by default:

JAZZ_MCP_ALLOW_WRITES=false

Enable explicitly:

JAZZ_MCP_ALLOW_WRITES=true

Mutation confirmation defaults to Jazz's edge durability tier:

JAZZ_MCP_DURABILITY=edge

Allowed values are local, edge, and global.

The MVP intentionally does not expose schema mutation, permission mutation, migrations, arbitrary HTTP requests, raw SQLite access, or arbitrary SQL. Those operations have stronger Jazz-specific invariants and should continue through the official validate, deploy, permissions, and migrations flows.

The current query surface also intentionally omits relation include(...), recursive gather(...), reactive subscriptions, and arbitrary query JSON.

Verification

CI runs on Node 22.12 and performs:

npm install
npm run check
npm test
npm run build

Tests include an integration smoke test using the official Jazz testing utilities to:

start an in-memory Jazz server
deploy a real schema and permissions bundle
connect this MCP adapter without passing the backend secret
discover the published schema through the admin catalogue
insert/query/update/delete through Jazz's native runtime and WebSocket protocol

For a manual server test, see docs/testing.md.

Test with MCP Inspector

After installing dependencies and building:

npx @modelcontextprotocol/inspector node ./dist/index.js

Provide the Jazz environment variables in the shell that launches the Inspector.

Research

License

MIT

Available Tools

9 tools

jazz_deleteA

Destructive

Delete one Jazz row with privileged backend access through Jazz's native delete operation. Disabled unless JAZZ_MCP_ALLOW_WRITES=true.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`table`	Yes

TDQS

A3.9/5.0

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.

jazz_describe_tableA

Read-only

Return the official Jazz WASM schema descriptor for one table plus supported query-time magic columns.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes

TDQS

A4/5.0

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.

jazz_get_rowA

Read-only

Fetch one Jazz row by table name and row id.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`table`	Yes

TDQS

A3.8/5.0

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.

jazz_insertA

Insert a row using Jazz's native local-first mutation API with privileged backend access. Disabled unless JAZZ_MCP_ALLOW_WRITES=true.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes
`values`	Yes

TDQS

A3.8/5.0

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.

jazz_list_tablesA

Read-only

List tables in the published Jazz schema currently used by the connector.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

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.

jazz_queryA

Read-only

Query a Jazz table through Jazz's native query builder. where values may be scalars (eq) or type-supported operator objects such as {gt: 5}, {contains: "foo"}, or {in: [...]}. Conditions are AND-combined; query-level OR is not supported. Magic columns such as $createdBy/$updatedAt may be selected or filtered. This is not SQL.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`table`	Yes
`where`	No
`offset`	No
`select`	No
`orderBy`	No

TDQS

A4.4/5.0

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.

jazz_reload_schemaB

Read-onlyIdempotent

Drop the local Jazz runtime and reload the newest published schema from the server catalogue.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

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.

jazz_statusA

Read-only

Check the configured jazz-tools@alpha server, loaded schema, privileged auth mode, and write safety settings.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

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.

jazz_updateA

Update fields on one Jazz row with privileged backend access and wait for configured durability. Disabled unless JAZZ_MCP_ALLOW_WRITES=true.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`table`	Yes
`values`	Yes

TDQS

A3.9/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.0Aug 17, 2026
- First observedjazz_delete
- First observedjazz_describe_table
- First observedjazz_get_row
- First observedjazz_insert
- First observedjazz_list_tables
- First observedjazz_query
- First observedjazz_reload_schema
- First observedjazz_status
- First observedjazz_update

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.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.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Algenta MCP Server C
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
1402
LodestoneOAuth
com.studiocorsair
One connector URL giving any MCP client live access to 21 services and 51 tools.
Developer Tools Agent Orchestration
1
OmegaAIOAuth
com.queryomega
Query, browse, and automate OmegaAI workspaces from any MCP client. Streamable HTTP with OAuth 2.0.
Workplace & Productivity App Automation
2
GentkeyOAuth
com.gentkey
One MCP URL for all your connectors — scoped writes, enforced constraints, and a full audit trail.
Developer Tools Security
1

Related MCP Servers

mcp-graphql
Developer Tools Databases
blurrah
A
license
B
quality
D
maintenance
MCP for working with GraphQL servers.
Updated a year ago (2025-09-08 14:28 UTC)
2
1,317
407
MIT
Snowflake Cube Server
Databases Data Platforms
isaacwasserman
A
license
Not graded
quality
C
maintenance
MCP Server for interacting with Cube semantic layers that provides tools for querying and describing data from Cube deployments.
Updated 2 years ago (2025-01-30 23:51 UTC)
15
GPL 3.0
graphql-mcp-server
Developer Tools Data Platforms
vogler75
A
license
Not graded
quality
D
maintenance
Automatically generates MCP tools from any GraphQL API by introspecting its schema, supporting queries, mutations, and authentication.
Updated 8 months ago (2026-01-06 15:55 UTC)
5
GPL 3.0
JSON Path MCP Server
File Systems Developer Tools
deermakov
F
license
Not graded
quality
D
maintenance
MCP server that provides tools to read JSON files and query data using jsonPath expressions.
Updated 6 months ago (2026-03-05 09:32 UTC)
-

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