Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bike MCP Server list my open Bike documents and show me the outline of the first one"
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.
MCP (Model Context Protocol) server for Bike outliner app on macOS.
bike_list_documents - List all open documents
bike_get_document_outline - Read document structure (supports max_depth)
bike_query_rows - Search rows using Bike's outline path syntax
bike_create_document - Create new documents with optional structure
bike_create_rows - Add rows with nested children and positioning
bike_update_row - Edit row content and type (batch support)
bike_delete_row - Remove rows (batch support)
bike_group_rows - Group/move multiple rows under a parent
Related MCP server: MCP Mac Apps Server
macOS (uses AppleScript)
Node.js 18+
Bike app installed
Download bike-mcp-server.mcpb from releases
Double-click the file to open with Claude Desktop
Click Install
cd bike-mcp-server
npm install
npm run buildAdd to your Claude Desktop config file (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"bike": {
"command": "node",
"args": ["/path/to/bike-mcp-server/dist/index.js"]
}
}
}Then restart Claude Desktop.
# Watch mode for development
npm run dev
# Build
npm run build
# Run directly
npm startThe server communicates with Bike via AppleScript, using the osascript command. All operations require Bike to be running with a document open.
The outline structure is returned as human-readable indented text:
My Document (doc:abc123)
- First item [row:row-1]
- Sub-item [row:row-1-1]
- Second item [row:row-2]Here are some prompts you can use with Claude Desktop:
Explore your outlines: "List my open Bike documents and show me the outline of the first one"
Create structured content: "Create a new Bike document with a project plan that has 3 main phases, each with 2-3 tasks"
Search and transform: "Find all rows containing 'TODO' in my Bike document and convert them to task items"
No account or authentication required. To test the server:
Open Bike app on macOS
Create or open a document with some sample content
Use Claude Desktop to interact with your outlines
This server does not collect, store, or transmit any personal data. All communication happens locally between Claude Desktop and the Bike app via AppleScript. No data leaves your machine.
MIT
Creates a new document in Bike, optionally with an outline structure.
Args:
structure (array, optional): Outline structure to populate the document. Each node can have:
name (string): Text content (may contain HTML if html=true)
type (string, optional): Row type (body, heading, task, code, quote, note, unordered, ordered, hr)
children (array, optional): Nested child nodes If not provided, creates an empty document.
html (boolean, optional): If true, name fields may contain HTML formatting: , , , , ,
Returns: Document info: "Untitled (doc:XXX)"
Examples:
Empty doc: bike_create_document({})
With structure: bike_create_document({ structure: [ { name: "Project", type: "heading", children: [ { name: "Task 1", type: "task" }, { name: "Task 2", type: "task" } ]} ] })
With HTML: bike_create_document({ structure: [{ name: "Click <a href="https://example.com">here" }], html: true })
Errors:
"Bike is not running" - Open Bike app first
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | If true, name fields may contain HTML formatting (strong, em, code, mark, s, a). | |
| structure | No | Outline structure to populate the document. Same format as bike_create_rows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses the return format ('Untitled (doc:XXX)'), behavior with/without structure, and error conditions. This adds valuable context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, Examples, and Errors sections. It is concise yet comprehensive, front-loading the main purpose and using examples efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, nested structure, no output schema), the description covers all necessary aspects: parameter details, return value, error messages, and usage examples. This ensures the agent can use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3, but the description elaborates on the nested structure of the 'structure' parameter, explains HTML formatting, and provides concrete examples, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new document in Bike, optionally with an outline structure.' The verb 'create' and resource 'document' are specific, and it distinguishes from sibling tools like bike_list_documents or bike_get_document_outline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use (creating documents), includes error messages like 'Bike is not running' for diagnostics, and gives examples. However, it doesn't explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates one or more rows with optional nested structure.
Args:
structure (array, required): Array of rows to create. Each can have:
name (string): Text content (may contain HTML if html=true)
type (string, optional): Row type (body, heading, task, code, quote, note, unordered, ordered, hr)
children (array, optional): Nested child rows
parent_id (string, optional): Parent row ID. If not provided, adds to root.
position (string, optional): Where to insert - 'first', 'last' (default), 'before', 'after'
reference_id (string, optional): Required for 'before'/'after' positioning.
html (boolean, optional): If true, name fields may contain HTML formatting: , , , , ,
Returns: Confirmation: "Created N row(s)"
Examples:
Single row: bike_create_rows({ structure: [{ name: "New item" }] })
With type: bike_create_rows({ structure: [{ name: "Task", type: "task" }] })
Nested: bike_create_rows({ structure: [ { name: "Parent", children: [{ name: "Child" }] } ] })
At position: bike_create_rows({ structure: [{ name: "First!" }], position: "first" })
Before row: bike_create_rows({ structure: [{ name: "Before X" }], position: "before", reference_id: "Kx9" })
With HTML: bike_create_rows({ structure: [{ name: "Click <a href="https://example.com">here" }], html: true })
Errors:
"Bike is not running" - Open Bike app first
"No document is open" - Open a document first
"reference_id is required" - When using before/after without reference_id
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | If true, name fields may contain HTML formatting (strong, em, code, mark, s, a). | |
| position | No | Where to insert: 'first'/'last' child of parent, or 'before'/'after' reference_id. | last |
| parent_id | No | ID of the parent row. If not provided, adds to root level. | |
| structure | Yes | Array of rows to create. Each can have name, type, and children. | |
| reference_id | No | Required when position is 'before' or 'after'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses all relevant behaviors: creation with nesting, positioning, HTML support, and prerequisite errors. Annotations are all false, and the description does not contradict them, fully covering the tool's effects and requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Errors, Examples), but is somewhat verbose. However, every sentence adds value, and the examples are particularly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and complex nested options, the description is thorough: it covers all parameters, provides examples for common use cases, and lists error conditions. No output schema exists, but the return format is adequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema provides 100% description coverage for parameters, the tool description enhances understanding with detailed examples, nested structure explanations, and usage patterns for each parameter, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates one or more rows with nested structure, using a specific verb and resource. It is distinct from sibling tools like update, delete, and group, establishing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context such as optional parent_id, positioning options, and error conditions, but does not explicitly guide when to use this tool versus alternatives like bike_update_row. The naming and sibling list make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes one or more rows from the document.
WARNING: This is a destructive operation. Deleted rows and all their children will be permanently removed. This action cannot be undone via the MCP server (though Bike's undo may work if used immediately).
Args:
row_ids (string[], required): Array of row IDs to delete.
Returns: Confirmation with count: "Deleted 3 row(s)"
Examples:
Delete one row: bike_delete_row({ row_ids: ["Kx9"] })
Delete multiple: bike_delete_row({ row_ids: ["Kx9", "Lm2", "Np4"] })
Errors:
"Bike is not running" - Open Bike app first
"No document is open" - Open a document first
| Name | Required | Description | Default |
|---|---|---|---|
| row_ids | Yes | Array of row IDs to delete. Children will also be deleted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the destructiveHint annotation: deleted rows and children are permanently removed, undo only available via Bike's undo. This fully informs the agent of consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, warning, args, returns, examples, and errors. Each sentence is necessary and front-loaded with key warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers return value format and error messages. Annotations handle safety, schema handles parameter, description covers behavior and examples. Complete for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning by explaining that row_ids is an array of IDs, children will be deleted, and provides examples of usage with specific IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes one or more rows from the document, using a specific verb ('delete') and resource ('rows'). This distinguishes it from sibling tools like create, update, and query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prominent warning about destructive nature and permanence, but does not explicitly state when to use this tool vs alternatives. The context of siblings implies usage, and examples help clarify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the complete outline structure of the currently open Bike document.
Returns a hierarchical tree of rows with their IDs, text content, and children. Bike must be running with a document open for this tool to work.
Args:
max_depth (number, optional): Maximum depth of the outline tree to return. If not specified, returns the complete tree.
Returns: Human-readable indented outline with IDs:
Document Name (doc:root-id)
First item [row:Kx9]
Sub-item 1 [row:Lm2]
Sub-item 2 [row:Np4]
Second item [row:Qr7]
Examples:
Get full outline: bike_get_document_outline({})
Get only 2 levels deep: bike_get_document_outline({ max_depth: 2 })
Errors:
"Bike is not running" - Open Bike app first
"No document is open" - Open a document in Bike first
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Maximum depth of the outline tree to return. If not specified, returns the full tree. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive. Description adds that it returns a hierarchical tree with IDs and text, and explains behavior when max_depth is omitted. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, but slightly verbose with examples and error messages. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, description includes sample output format, examples, and error cases. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter fully (100%), and description adds context that omitting max_depth returns the full tree, which adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the outline structure of the currently open Bike document, using specific verb+resource. It distinguishes from siblings like bike_list_documents which lists documents, not outlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that Bike must be running with a document open, and gives examples. However, it does not explicitly state when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Groups multiple rows under a new or existing parent row.
Two modes:
Create new group: Provide group_name to create a new parent row and move specified rows into it. By default, the group is created in-place (before the first row being grouped).
Move to existing: Provide parent_id to move rows into an existing row.
Use position ('first'/'last' for root, 'before'/'after' with reference_id) to override placement.
| Name | Required | Description | Default |
|---|---|---|---|
| row_ids | Yes | Array of row IDs to group together. | |
| position | No | Where to place the new group row. Default: in-place (before the first row being grouped). Use 'first'/'last' for root level, or 'before'/'after' with reference_id. | last |
| parent_id | No | ID of an existing row to move the rows into. If not provided, a new group row is created. | |
| group_name | No | Name for the new group row. Required if parent_id is not provided. | |
| reference_id | No | Required when position is 'before' or 'after'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so description carries burden. It describes that rows are moved under a parent and default placement behavior, but does not disclose side effects like removal from previous groups or impact on row ordering within the parent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured into sections for each mode and position, uses bullet-style clarity. Every sentence provides distinct information; only minor redundancy in explaining default placement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and no output schema, the description adequately covers the two modes and placement options. It could elaborate on the effect on existing row hierarchy, but overall 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description adds value by explaining the relationship between group_name and parent_id for the two modes, and clarifying position defaults and requirements (e.g., reference_id needed for 'before'/'after').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool groups multiple rows under a parent, with two specific modes (create new group or move to existing). The verb 'group' and resource 'rows' are explicit, and it distinguishes from sibling tools like bike_create_rows or bike_update_row.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditions for using each mode: group_name for new group, parent_id for existing. Also explains position parameter usage. However, lacks guidance on when not to use this tool (e.g., when simpler reordering suffices).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all open documents in Bike.
Returns a list of all currently open documents with their names and IDs. The active (front) document is marked with an asterisk (*). Bike must be running for this tool to work.
Args: None
Returns: List of documents, one per line (active marked with *):
Active Document (doc:abc123) Other Document (doc:def456)
Examples:
List all open docs: bike_list_documents({})
Errors:
"Bike is not running" - Open Bike app first
"No documents open" - No documents are currently open
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining the output format (active document marked with asterisk) and error conditions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with clear sections (Args, Returns, Examples, Errors). Every sentence provides value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, the description fully covers functionality, prerequisites (Bike must be running), output format, examples, and error cases. Annotations provide safety context. No output schema exists, but the description adequately explains the return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema is empty. The description does not need to add parameter semantics. Per guidelines, 0 parameters baseline is 4. The description explains the return format, which is helpful but not directly parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists all open documents in Bike' with a specific verb and resource. It distinguishes from sibling tools like bike_get_document_outline and bike_create_document, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes important usage context: 'Bike must be running for this tool to work.' It also lists error messages like 'Bike is not running' and 'No documents open', guiding when the tool can be used. However, it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for rows using Bike's outline path syntax.
Outline paths are powerful queries for filtering rows:
/project → Top-level rows containing "project"
//task → All rows of type "task" (anywhere)
//@done → Rows with @done attribute
//heading → All heading rows
/a/b → "b" rows inside "a" rows
/a union /b → Rows matching "a" OR "b"
/a intersect /b → Rows matching "a" AND "b"
Args:
outline_path (string, required): The outline path query.
Returns: Matching rows formatted as:
Row text [row:XXX]
Or scalar result (count, boolean, text) depending on the query.
Examples:
Find all tasks: bike_query_rows({ outline_path: "//task" })
Find headings: bike_query_rows({ outline_path: "//heading" })
Find by text: bike_query_rows({ outline_path: "//project" })
Find with attribute: bike_query_rows({ outline_path: "//@done" })
Errors:
"Bike is not running" - Open Bike app first
"No document is open" - Open a document first
| Name | Required | Description | Default |
|---|---|---|---|
| outline_path | Yes | Outline path query (e.g., '//task', '//@done', '//heading'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds important behavioral details: return format (row text or scalar), error conditions, and prerequisites. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for syntax, args, returns, examples, and errors. It is slightly lengthy but justified by the query complexity. Front-loading the purpose and examples helps quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with one parameter and no output schema, the description covers syntax, return format, examples, and error prerequisites comprehensively. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a basic example. The tool description greatly expands meaning by detailing outline path syntax, advanced operators (union, intersect), and multiple examples, far exceeding the schema's brief note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Title 'Query Bike Rows' and description 'Search for rows using Bike's outline path syntax' clearly state the tool's function. Examples differentiate it from siblings like bike_create_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context with examples and error messages indicating prerequisites (Bike running, document open). It lacks direct comparison to alternatives like bike_get_document_outline but still guides usage effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates one or more rows' text content and/or type.
Args:
updates (array, required): Array of row updates. Each update has:
row_id (string, required): ID of the row to update
name (string, optional): New text content (may contain HTML if html=true)
type (string, optional): New row type (body, heading, quote, code, note, unordered, ordered, task, hr)
html (boolean, optional): If true, name contains HTML formatting: , , , , , NOTE: HTML updates recreate the row, so the row ID will change. Children are preserved. If you need the new ID, call bike_get_document_outline after.
Returns: Confirmation: "Updated N row(s)"
Examples:
Single update: bike_update_row({ updates: [{ row_id: "Kx9", name: "New text" }] })
Batch to task: bike_update_row({ updates: [ { row_id: "A1", type: "task" }, { row_id: "B2", type: "task" }, { row_id: "C3", type: "task" } ] })
Mixed: bike_update_row({ updates: [ { row_id: "X", name: "Title", type: "heading" }, { row_id: "Y", type: "task" } ] })
With HTML: bike_update_row({ updates: [ { row_id: "Z", name: "Important task", html: true } ] })
Errors:
"Bike is not running" - Open Bike app first
"No document is open" - Open a document first
"At least one of 'name' or 'type' must be provided" - Per row
| Name | Required | Description | Default |
|---|---|---|---|
| updates | Yes | Array of row updates. Each update has row_id (required), name (optional), type (optional), html (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that HTML updates recreate the row, changing the row ID while preserving children, and recommends fetching the new ID via bike_get_document_outline. This adds value beyond annotations. However, the idempotentHint annotation is contradicted by the row ID change behavior on HTML updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into Args, Returns, Examples, and Errors sections. The first sentence states the core purpose. Examples are concise and illustrative, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter (updates) with nested structure, the description thoroughly covers its inner fields, return value (confirmation message), and error cases. No output schema exists, so the description appropriately provides the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds examples showing how each field is used, clarifies the meaning of html and type values, and explains constraints like the need for at least one of name or type per row.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates one or more rows' text content and/or type. It distinguishes from sibling tools (create, delete, query) through its action verb and examples showing 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples demonstrate various use cases (single update, batch to task, mixed updates, HTML). Error messages provide context for when the tool cannot be used. However, no explicit comparison to alternatives like bike_create_rows for when to create vs update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: listing documents, retrieving outlines, creating documents, creating rows, grouping rows, updating rows, deleting rows, and querying. Even though create_document and create_rows both create structure, they operate at different levels (document vs. rows within a document), avoiding ambiguity.
All tools follow the pattern 'bike_<verb>_<noun>' using imperative verbs (list, get, create, group, update, delete, query). The naming is uniform and predictable, with only minor plural/singular variation that does not hinder understanding.
With 8 tools, the server is well-scoped for a focused outlining application. Each tool addresses a core functionality without unnecessary bloat, and the count feels natural for the domain.
The tool set covers essential CRUD operations for rows (create, read via outline/query, update, delete) and document lifecycle (create, list). Missing operations like explicit row reordering or document closing are minor and can be worked around via existing tools, making the surface largely complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Streamline your Attio workflows using natural language to search, create, update, and organize com…
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hildersantos/bike-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
