oh-my-cassette

Server Quality Checklist

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

Latest release: v0.4.12
Disambiguation4/5
Most tools have clearly distinct purposes—editing, timeline reading, config, login, etc. However, the three music matchers (cassette_match_bgm, cassette_match_exact_bgm, jamendo_music_matcher) overlap in function and could be confused. Additionally, cassette_answer_question and cassette_job_status both support resuming interrupted jobs, causing some ambiguity. Descriptions help resolve most conflicts, but a few boundaries remain fuzzy.
Naming Consistency3/5
Almost all tools share the cassette_ prefix, which helps, but the structure is inconsistent: some use verb_noun (cassette_make_prompt, cassette_list_assets), some are bare verbs (cassette_edit, cassette_login), some are nouns (cassette_timeline, cassette_config), and one tool uses a different prefix entirely (jamendo_music_matcher). The naming is readable but lacks a uniform convention.
Tool Count4/5
With 15 tools, the count sits at the upper edge of the typical well-scoped range. Most tools serve distinct purposes, but the music-matching suite (3 tools) and job-resumption pair (answer_question, job_status) could potentially be consolidated. Overall, the size is appropriate for the Cassette editing domain without excessive bloat.
Completeness4/5
The tool set covers the core workflow: media ingestion, asset listing, timeline reading, direct editing, job execution, job status/cancellation, review resolution, configuration, and login. Minor gaps exist—such as no explicit session deletion or asset removal—but agents can work around them. The music-matching options are more extensive than strictly necessary, but the essential editing lifecycle is fully covered.
Average 3.3/5 across 15 of 15 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 131 commits in the last 12 weeks
- Last stable release on August 6, 2026
- 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.
Tools from this server were used 2 times in the last 30 days.
This repository includes a glama.json configuration file.
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 provided, the description fully bears the burden of behavioral disclosure. It only mentions 'cooperative cancellation' without explaining side effects, prerequisites, or error states, leaving significant ambiguity about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of only 9 words, which is concise but sacrifices necessary detail. It avoids fluff but is notably underspecified for safe tool use.
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 lack of annotations and ambiguous description, the tool description is insufficiently complete. An output schema exists but is not shown in the description, and crucial context about cooperative cancellation behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'job_id' has 0% schema coverage (no description), and the tool description adds no additional meaning or guidance about the format or constraints of the job ID.
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 ('cancel') and the resource ('persisted Cassette job'), and the purpose is easily distinguished from sibling tools like 'cassette_run_job' or 'cassette_job_status'.
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 (e.g., whether cancellation is only for running jobs, or if it can be used on completed ones), and no explicit 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It only says 'build a prompt', but does not state whether it is read-only, mutates state, requires authentication, or what side effects occur. Very limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but for a tool with 10 parameters and no schema descriptions, it is too brief to be useful. Every sentence should add value; this one is too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no schema descriptions, no annotations, and an output schema, the description is severely incomplete. It does not describe return values, behavior, or parameter roles. The complexity demands much more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the 10 parameters. It mentions 'natural-language instruction' and 'session assets', but does not map these to parameters like instruction, session_id, or requires_assets. No additional meaning beyond the schema.
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 verb 'build' and resource 'complete Cassette edit prompt', distinguishing it from siblings like cassette_edit (which performs the edit) and cassette_answer_question. It indicates inputs: natural-language instruction and session assets.
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 on when to use this tool vs. alternatives. With siblings like cassette_edit, cassette_answer_question, etc., the description does not help the agent decide which to invoke.
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 mentions 'optionally register' implying a side effect, but does not disclose behavioral details such as required permissions, state changes, or what happens on match. The agent lacks crucial 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, achieving conciseness. However, it is under-specified, omitting necessary details; it is not a model of clarity. It earns its place but does not fully inform.
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?
Despite the tool having 7 parameters, 3 required, and an output schema, the description fails to cover return values or parameter usage. The agent lacks sufficient context to invoke the tool effectively, especially for fallback and optimization options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 7 parameters (e.g., session_id, instruction, search_queries, fallback fields). The agent cannot understand how to use these parameters, severely impairing correct invocation.
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 matches and optionally registers a Free To Use background-music asset for a session, specifying the resource type and action. However, it does not differentiate from sibling tools like cassette_match_exact_bgm or jamendo_music_matcher, leaving ambiguity about when to use this specific tool.
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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The agent must infer usage from the name and description alone.
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 provided, so the description must bear the full burden. It mentions optional download and session registration but does not disclose side effects, required permissions, error behavior, or what 'register with the session' entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices completeness. It is adequately sized but could benefit from a structured breakdown given the tool's 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?
With 10 parameters, 0% schema coverage, no annotations, and an output schema, the description is insufficient. It covers only a fraction of the tool's functionality, leaving critical gaps in understanding for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only hints at 'title', 'artist', and 'download'. It fails to explain the remaining 7 parameters (session_id, instruction, singer, songTitle, song_title, continue_after_match, optimization_enabled), leaving the agent with no insight into their purpose.
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 matches an exact song and artist, with optional download and session registration. However, it does not differentiate from the sibling 'cassette_match_bgm', which likely has a similar 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 guidance on when to use this tool versus alternatives like 'cassette_match_bgm' or 'jamendo_music_matcher'. Lacks context on prerequisites or 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. It only mentions that rendering starts for decision=export, but omits any side effects, reversibility, permissions, or what happens for other decision values. This is insufficient transparency.
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 only two sentences and front-loads the core behavior. While very concise, it lacks detail; however, conciseness is still good as it avoids unnecessary words.
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 4 parameters with no schema descriptions, no annotations, but an output schema exists, the description is incomplete. It does not explain how to use parameters, expected output, or handle different decisions. More context is needed for safe usage.
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. It adds minimal meaning by mentioning 'explicit, validated decision=export', but does not explain job_id, reason, summary, or the enum values beyond export. The other decisions remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool resolves a review-required completion and mentions rendering starts for decision=export. This gives a general idea but is vague about what 'resolve' entails (e.g., approve, reject) and does not clearly differentiate from sibling tools like cassette_run_job or cassette_edit.
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, such as cassette_run_job or cassette_edit. There is no mention of prerequisites, context, or when not to use it.
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 behaviors but only mentions optional registration without explaining side effects, authentication needs, or mutation. The term 'validated fixed-form' remains undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and clarity. It front-loads 'Search Jamendo' well but fails to earn its place with meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, 2 required) and no parameter descriptions, the description is woefully incomplete. The agent lacks essential context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate but only vaguely references preferences via 'validated fixed-form music preferences'. 17 of 19 parameters are completely unexplained, severely hindering correct invocation.
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 the tool searches Jamendo and optionally registers a result, which gives a clear action. However, the phrase 'validated fixed-form music preferences' is vague and the tool name 'matcher' suggests more than just search, slightly reducing clarity.
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 siblings or alternatives. Neither prerequisites nor contexts are mentioned, leaving the agent without decision support.
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 provided, so description bears full responsibility. It describes two modes but does not explain behavioral details such as error handling, side effects, required permissions, or what happens when parameters are omitted. The notion of 'resume an interrupted job' is mentioned without clarifying the role of job_id or response fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, which is concise, but it sacrifices clarity. It is front-loaded with the main actions, yet it is too brief to convey necessary details about parameters and modes. It could be expanded without becoming verbose.
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 complexity (6 optional parameters, two modes) and the presence of an output schema (unmentioned), the description is insufficient. It does not explain how the output relates to the input, nor does it cover parameter interactions or behavior in failure cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the six parameters. It only casually mentions job_id and response, but does not explain context, question, asset_count, or instruction. With 0% coverage, the description fails to compensate, leaving the agent without guidance on how to use these parameters.
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?
Description clearly states two distinct actions: classify a question or resume an interrupted job. Verb 'classify' and 'resume' are specific, and the resource 'Cassette question' is identified. However, 'question mode' is somewhat vague, and the tool does not strongly differentiate from siblings beyond the context of Cassette jobs.
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?
Provides two usage scenarios (new classification or resumption), which gives context. However, it lacks explicit guidance on when to use this tool versus alternatives like cassette_run_job or cassette_review_completion, and no 'when not to use' or prerequisites are mentioned.
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 all behavioral traits. It mentions session_id generation but fails to specify whether the original file is moved/copied, permissions required, or other side effects. The description is insufficient for critical behavioral understanding.
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?
Two sentences with no fluff; the main purpose is stated first. Every sentence provides essential information without redundancy.
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 11 parameters and an output schema, the description is too sparse. It omits explanation of many parameters, the ingestion workflow, and what the output contains. The presence of an output schema is not mentioned, so the description contributes little to overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema), and the description only minimally addresses 'source_path' and 'session_id'. The remaining 9 parameters (caption, chat_id, etc.) are completely unexplained, leaving the agent without critical semantic context.
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 ingests a trusted local media file from the active host project or configured media root, which matches the name and distinguishes it from the sibling tool 'cassette_list_assets'.
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?
It implies the file must be trusted and local, but does not explicitly state when to use this tool versus the sibling or provide alternative usage contexts. No exclusions or prerequisites are mentioned.
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 must disclose behavioral traits, but it only states the action. It does not mention that the operation is read-only, the format of the response, pagination, or any side effects. The agent lacks critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks necessary detail. It is not overly verbose, but it sacrifices completeness for brevity.
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?
Despite having an output schema, the description does not reference what the tool returns, leaving the agent unsure about the response structure. Combined with missing annotations and parameter semantics, the overall context is insufficient for reliable use.
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. However, it only implies that session_id relates to a session, without explaining what session_id and chat_id represent or how they affect results. The optionality and null defaults are confusing without clarification.
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 (List), the resource (media assets), and the scope (isolated to one Cassette session). It effectively differentiates from the sibling tool cassette_ingest_media by implying listing vs. ingestion.
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 only hints at usage by stating 'isolated to one Cassette session,' but provides no explicit guidance on when to use this tool, what parameters to provide, or when to choose it over the sibling. The parameters are both optional, creating ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature ('Read'), the effect of contact_sheet=true ('tiles poster into one image, zero render'), and labels the output as a 'bounded text digest'. Missing details about side effects or data limits, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word adds value. No redundancy or excess.
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?
Given the absence of parameter documentation and the presence of an output schema (not shown), the description adequately covers the main usage but leaves parameter details unspecified. It could be more complete by explaining what the text digest includes or how detail/profile affect results.
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 0% description coverage for 4 parameters. The description only explains the contact_sheet parameter. The detail and profile parameters are not mentioned, leaving their semantics unclear. This adds value for one parameter but fails to compensate for the others.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'reads the live Cassette timeline as a bounded text digest', using a specific verb and resource. It distinguishes from sibling tools like cassette_edit, cassette_ingest_media, and cassette_answer_question by focusing solely on reading state before answering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this before any statement about project state — never answer from memory.' This tells the agent when to use the tool and what to avoid, though it does not explicitly name alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses streaming progress notifications, terminal envelope values (succeeded, needs_user, etc.), and the non-polling nature. It does not cover authorization or rate limits, but the behavioral core is well-stated.
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, no fluff, front-loaded with the main action. Every sentence adds value, and the warning about polling is placed efficiently.
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 17 undocumented parameters, the description is too thin. The output schema exists but cannot compensate for missing parameter guidance. The agent would struggle to correctly fill parameters beyond 'wait'.
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%, and the description only explains the 'wait' parameter behavior. The other 16 parameters (url, model, prompt, etc.) receive no explanation, leaving the agent without guidance on how to use them despite the rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs one Cassette edit turn and waits for settlement, using 'Run one Cassette edit turn' as a specific verb+resource. It distinguishes from sibling cassette_job_status by explaining that tool is for resuming interrupted jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (run a turn and wait) and when-not-to-use (do not poll cassette_job_status after this call). It also explains the alternative (use cassette_job_status for resuming interrupted jobs) and the wait parameter semantics for detaching.
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?
Without annotations, the description must carry the full transparency burden. It discloses that changes are 'persisted for the session' and 'applied from the next cassette_run_job turn,' and warns of default matching. However, it does not mention potential side effects or whether changes are reversible, which is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the core purpose, and each sentence adds unique value: purpose, usage pattern, and default behavior warning. No wasted words.
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 presence of an output schema, the description appropriately focuses on behavior rather than return values. It covers what to expect when reading ('current choice and available options') and when writing (persistence and timing). Minor gap: does not explicitly state that writing returns the updated config, but the output schema likely covers this.
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 0% schema description coverage, the description effectively compensates by explaining the purpose and usage of each parameter: 'model (id or label)' and 'thinking_level' with implied enum set. It clarifies the read/write pattern using session_id alone vs. with parameters, adding meaning beyond the bare schema.
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: 'Get or set the session's Cassette model and thinking level.' It uses specific verbs (Get, set) and resources (model, thinking level), and distinguishes itself from sibling tools like cassette_run_job by focusing on configuration rather than execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: call with only session_id to read current config, or pass model/thinking_level to modify. It also advises 'change only when the user asks,' indicating appropriate invocation context. However, it does not explicitly state when not to use this tool versus alternatives, though the context implies it.
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?
Despite no annotations, the description discloses key behaviors: it is a single-call operation (not a loop) and wait_for_change_sec allows up to 30 seconds for job progression. No contradictions or missing critical traits.
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 consists of two concise sentences, each adding essential information. No wasted words; front-loaded with purpose and usage.
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?
While the description covers the main use case, it omits explanations for three of four parameters (limit, job_id, session_id), which are important for correct invocation. Given the presence of an output schema, this is a moderate gap.
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%, but the description only explains wait_for_change_sec. Parameters limit, job_id, and session_id are not mentioned, leaving their roles unclear (e.g., pagination or filtering).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Re-attach to a job whose cassette_run_job call did not return'. This specific verb-resource combination distinguishes it from siblings like cassette_run_job (which starts a job) and cassette_cancel_job (which cancels).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (when cassette_run_job did not return due to host restart, cancellation, or wait=false) and provides guidance: 'Call it once and act on the phase; it is not a progress loop.' It also explains the wait_for_change_sec parameter's role.
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?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral details: passwords are always server-generated, replacement affects all machines, credentials are verified before writing, and wrong passwords leave existing setups untouched. This exceeds typical descriptions and provides strong safety-relevant context.
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 front-loaded with the main purpose and uses four sentences that each add value. There is slight redundancy ('never chosen' and 'never invent one'), but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and an output schema, and the description covers the key scenarios: normal login, password replacement, and failure behavior. Since output schema exists, return values need not be described. The description is complete enough for an agent to safely invoke the 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 0% schema description coverage, the description compensates well: it explains that password must be the user's server-generated one, that request_new_password triggers replacement, and that confirm_replace is required for that flow. Email is not explicitly explained but is self-evident from the login context.
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+resource structure: 'Sign this machine in to Cassette' and 'have a replacement password emailed.' It clearly distinguishes the tool from siblings, as it is the only authentication/login tool among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the normal password flow ('Pass email plus the generated password') and when to request a replacement ('If they no longer have it... pass request_new_password=true with confirm_replace=true'). It provides clear decision criteria without explicitly naming alternative tools, but the conditions are unambiguous.
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?
No annotations provided, but description fully discloses behavioral traits: requires CASSETTE_DIRECT_EDIT=1, uses manual-editor command lane, needs expected_version, explains undo mechanism with cursorSequence. Discloses input 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?
Concise 3-4 sentences with front-loaded purpose and usage. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity and existing output schema, description covers purpose, usage, prerequisites, and parameter hints. Sufficient for correct invocation.
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 has 0% coverage, but description adds meaning: input is always {"payload": {...}}, expected_version from last timeline read, tool_name 'undo' with input.cursorSequence. Does not explicitly map each parameter but provides significant context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a 'surgical no-LLM timeline edit' and distinguishes from sibling cassette_run_job for big or creative briefs. Uses specific verbs like trim, text, delete, undo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for small named changes' and 'big or creative briefs go through cassette_run_job', providing alternative and context. Also advises to use after reading cassette_timeline.
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:

[![oh-my-cassette MCP server](https://glama.ai/mcp/servers/Cassette-Editor/oh-my-cassette/badges/card.svg)](https://glama.ai/mcp/servers/Cassette-Editor/oh-my-cassette)

Score Badge

Copy to your README.md:

[![oh-my-cassette MCP server](https://glama.ai/mcp/servers/Cassette-Editor/oh-my-cassette/badges/score.svg)](https://glama.ai/mcp/servers/Cassette-Editor/oh-my-cassette)

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/Cassette-Editor/oh-my-cassette'

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