Oscribble MCP Server

by oscargavin

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific operations in the Oscribble task management domain. For example, oscribble_begin_task starts timing, oscribble_complete_task marks completion, and oscribble_complete_task_with_timing adds duration calculation, with no significant overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with the 'oscribble_' prefix, such as oscribble_add_raw_task, oscribble_list_projects, and oscribble_update_task. This uniformity makes the tool set predictable and easy to navigate for an agent.
Tool Count5/5
With 11 tools, the server provides a well-scoped set that covers essential task management operations without being overwhelming. This count is appropriate for handling projects, tasks, timing, and status updates in a focused domain.
Completeness5/5
The tool set offers comprehensive CRUD and lifecycle coverage for task management, including creating (add_raw_task), reading (list_tasks, get_task_details), updating (update_task), and deleting equivalents (complete/uncomplete), along with search, timing, and project listing, leaving no obvious gaps for core workflows.
Average 3.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions recording a start timestamp, implying a write operation, but does not disclose behavioral traits such as permissions needed, whether it's idempotent, error handling, or how it interacts with other tools (e.g., if starting a task affects its status). This leaves significant gaps 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 a single, efficient sentence that front-loads the key action and purpose. There is no wasted wording, making it appropriately sized and easy to understand at a glance.
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 complexity of a timing tool with no annotations and no output schema, the description is incomplete. It fails to explain what happens after timing begins (e.g., does it return a confirmation or task state?), potential side effects, or how it fits into the broader workflow with siblings, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters in the input schema. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain format constraints or relationships between parameters), so it meets the baseline of 3 for high schema coverage without extra value.
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 ('Begin timing') and resource ('a task'), specifying that it records a start timestamp. However, it does not explicitly differentiate this from sibling tools like 'oscribble_complete_task_with_timing' or 'oscribble_update_task', which might involve similar timing operations, leaving some ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., if the task must exist or be in a specific state), exclusions, or comparisons to siblings like 'oscribble_complete_task_with_timing', which might handle timing differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Mark a task as complete') which implies a mutation, but doesn't describe effects (e.g., task status change, potential notifications, permissions required), response format, or error handling. This leaves significant gaps 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every part contributing essential information.
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 complexity (a mutation tool with no annotations and no output schema), the description is incomplete. It lacks details on behavioral effects, error cases, or return values, which are crucial for proper tool invocation. Sibling tools suggest this is part of a task management system, but the description doesn't leverage that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('project_name', 'task_id') documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., format details, examples, constraints), so it meets the baseline for high schema coverage without compensating value.
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 ('Mark a task as complete') and the resource ('in an Oscribble project'), providing specific verb+resource pairing. However, it doesn't explicitly differentiate from sibling tools like 'oscribble_complete_task_with_timing' or 'oscribble_uncomplete_task', which would require more specific scope or contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., task must exist, be in progress), exclusions, or comparisons to siblings like 'oscribble_complete_task_with_timing' (which might include timing data) or 'oscribble_uncomplete_task' (for reversing completion).
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 fully disclose behavioral traits. It mentions 'calculate duration from start time', which adds useful context about timing behavior. However, it fails to describe critical aspects like whether this is a destructive mutation, what permissions are required, how errors are handled, or what the output looks like, leaving significant gaps.
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 directly states the tool's purpose and key behavior ('calculate duration from start time'). It is front-loaded with no unnecessary words, making it highly concise and well-structured.
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 complexity of a task completion tool with timing calculation, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral implications (e.g., mutation effects, error handling), output format, and usage context, which are essential for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('project_name' and 'task_id'). The description does not add any meaning beyond the schema, such as explaining how these parameters interact with the timing calculation. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
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 ('complete a task') and adds a specific behavior ('calculate duration from start time'), which distinguishes it from the sibling 'oscribble_complete_task'. However, it doesn't specify what resource is being completed (e.g., a task in a project management system), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like 'oscribble_complete_task' or 'oscribble_uncomplete_task'. The description implies usage for tasks with timing needs, but lacks context on prerequisites, error conditions, 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves tasks but doesn't cover critical aspects like whether it's read-only, safe to use, requires authentication, has rate limits, or what the return format looks like. This is a significant gap for a tool with no annotation coverage.
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 directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 output schema, the description is incomplete. It doesn't explain what 'unblocked' or 'ready to work on' means in this context, the return format, or any behavioral traits. For a tool with no structured data to rely on, this leaves too many gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'project_name' clearly documented. The description doesn't add any meaning beyond the schema, such as explaining how 'project_name' relates to filtering unblocked tasks, but the baseline is 3 since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('tasks that are not blocked and ready to work on'), making it easy to understand what it does. However, it doesn't explicitly distinguish itself from sibling tools like 'oscribble_list_tasks' or 'oscribble_search_tasks', which likely also retrieve tasks, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or compare it to sibling tools such as 'oscribble_list_tasks' or 'oscribble_search_tasks', leaving the agent to guess based on the name 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?
With no annotations provided, the description carries full burden but only states it lists tasks with filtering. It doesn't disclose behavioral traits like whether this is a read-only operation, pagination behavior, error conditions, or what the output format looks like. For a tool with zero annotation coverage, this is insufficient.
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?
Single sentence with zero waste - every word contributes to understanding the tool's purpose. Efficiently communicates the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the return values look like, error handling, or behavioral constraints. Given the sibling tools indicate this is part of a task management system, more context about the listing operation would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema (project_name and filter_status with enum values). Baseline 3 is appropriate when schema does all the work.
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 ('List') and resource ('tasks from an Oscribble project') with the specific scope of optional status filtering. It distinguishes from siblings like 'oscribble_search_tasks' by focusing on listing rather than searching, but doesn't explicitly contrast them.
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 'oscribble_get_unblocked_tasks' or 'oscribble_search_tasks'. The description mentions optional filtering but doesn't provide context for choosing between this and other task-retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches tasks but doesn't describe key behaviors: whether it's read-only or has side effects, what the output format looks like (e.g., list of tasks with details), if there are rate limits, authentication needs, or error conditions. This leaves significant gaps for a search operation.
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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and scope, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.
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 complexity of a search tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., safety, output format), usage context compared to siblings, and doesn't compensate for the absence of structured output information, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting both parameters ('project_name' and 'query') with their types and purposes. The description adds minimal value beyond this, only implying that 'query' searches 'text and notes' without providing additional syntax or format details. This meets the baseline for high schema coverage.
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 ('Search') and target resource ('tasks'), specifying the search scope ('by keyword in text and notes'). However, it doesn't distinguish this tool from sibling tools like 'oscribble_list_tasks' or 'oscribble_get_task_details' that might also retrieve tasks, leaving some ambiguity about when to use this specific search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to sibling tools like 'oscribble_list_tasks' for unfiltered listing or 'oscribble_get_task_details' for specific task retrieval, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'update' implying mutation, but doesn't disclose permissions needed, whether changes are reversible, rate limits, or how notes are handled ('will be appended' is mentioned but not elaborated). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and lists key fields without waste. Every word contributes to understanding the tool's scope, making it appropriately sized and structured for quick comprehension.
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 complexity (7 parameters, mutation operation) with no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., error handling, response format), usage guidelines, and doesn't compensate for the absence of structured safety or output information, making it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description lists the updatable fields (text, priority, effort estimate, deadline, notes), which aligns with the schema but adds no additional meaning beyond what's already specified, such as format details or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('task properties') with specific fields listed (text, priority, effort estimate, deadline, notes). It distinguishes from siblings like 'oscribble_begin_task' or 'oscribble_complete_task' by focusing on property updates rather than state changes, but doesn't explicitly contrast with all siblings like 'oscribble_get_task_details' for read vs. write operations.
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 is provided. It doesn't mention prerequisites (e.g., needing an existing task), exclusions (e.g., not for creating tasks), or comparisons to siblings like 'oscribble_add_raw_task' for new tasks or 'oscribble_complete_task' for status updates, leaving usage context implied at best.
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 retrieving information, which implies a read-only operation, but doesn't disclose behavioral traits like whether it requires authentication, has rate limits, or what happens if the task doesn't exist. This is a significant gap for a tool with no annotation coverage.
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 key action ('Get detailed information') and specifies the scope ('about a specific task') and included details ('metadata, notes, and blockers'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity is moderate (a read operation with two required parameters), no annotations, and no output schema, the description is minimally adequate. It states the purpose but lacks details on behavior, error handling, or return format, which could hinder an AI agent's ability to use it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with both parameters ('project_name' and 'task_id') clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides, such as explaining the relationship between project and task or the format of the task ID, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific task', specifying what information is included (metadata, notes, and blockers). It distinguishes from siblings like 'oscribble_list_tasks' by focusing on a single task's details rather than listing multiple tasks, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed information about a specific task is needed, as opposed to listing or searching tasks. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'oscribble_search_tasks' or mention prerequisites such as needing the project name and task ID, leaving some ambiguity.
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 the action ('Mark a task as incomplete') and optional logging, but does not disclose behavioral traits such as permissions required, whether the operation is reversible, error handling, or rate limits. This leaves significant gaps 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 front-loaded with the core purpose in the first sentence and adds optional details in the second. Both sentences earn their place by clarifying the action and the note feature, with no wasted words or 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects like side effects, error responses, or prerequisites, and does not explain what happens after marking a task incomplete (e.g., status changes). Given the complexity and lack of structured data, it should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value by hinting at the purpose of 'attempt_note' ('log a failed attempt note with details'), but does not provide additional syntax or format details beyond what the schema specifies. Baseline 3 is appropriate as the schema handles most of the documentation.
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 specific action ('Mark a task as incomplete') on a specific resource ('in an Oscribble project'), and distinguishes it from sibling tools like 'oscribble_complete_task' by specifying the opposite operation. It also mentions the optional logging feature, adding 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 usage when a task needs to be reverted from completed to incomplete, possibly after a failed attempt, but does not explicitly state when to use this tool versus alternatives like 'oscribble_update_task' or provide exclusions. The mention of 'failed attempt note' suggests a context but lacks clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists projects but does not cover critical aspects like whether it's read-only, pagination behavior, error handling, or performance characteristics. For a list operation with zero annotation coverage, this leaves significant gaps in understanding 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('List all Oscribble projects') and includes essential details without redundancy. Every word serves a purpose, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but not fully complete. It explains what the tool does and what data it returns, but lacks behavioral context (e.g., safety, performance) that would help an agent use it effectively in broader workflows.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the output details. It adds value by specifying what data is returned, which compensates for the lack of an output 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 specific action ('List all') and resource ('Oscribble projects'), including the exact fields returned ('names, paths, and last accessed timestamps'). It distinguishes from sibling tools like 'oscribble_list_tasks' by specifying it lists projects rather than tasks, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, such as whether it should be used for initial discovery or how it relates to other project-related tools. Without such information, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the deferred formatting ('will be formatted by Oscribble on next sync'), which is not obvious from the schema. However, it lacks details on permissions, error handling, or response behavior, leaving gaps 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 a single, efficient sentence that is front-loaded with the core action and includes essential behavioral context without any wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is minimally complete. It covers the purpose and key behavioral trait (deferred formatting) but lacks details on outcomes, errors, or integration with sibling tools, which could enhance agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, but it doesn't need to compensate for low coverage, resulting in a baseline score.
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 specific action ('Add raw task text') and resource ('to a project'), and distinguishes it from siblings by specifying that the text will be formatted by Oscribble on next sync, unlike other task manipulation tools like oscribble_begin_task or oscribble_update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to add raw task text that will be formatted later), but it doesn't explicitly state when not to use it or name alternatives among the sibling tools, such as when immediate formatting is needed versus deferred formatting.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/oscargavin/oscribble-mcp'

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