Skip to main content
Glama
deenesjakoruzh
mquan

Routine

by mquan
OverviewSchemaRelated ServersScoreDiscussions
TypeScript

MCP Routine

🌅🍳☕️📰🚗💼 MCP Routine is a MCP server that lets you create custom tools on the fly. It stitches actions executed by multiple MCP tools into a reusable routine.

Why?

If you perform the same sequence of tool calls over and over, a routine will save you time and remove prompting inconsistencies. A routine includes full context of the exact set of tools and inputs needed to execute a full task.

Installation

Copy the following into your MCP client's JSON file

{
  "mcpServers": {
    "myRoutines": {
      "command": "npx",
      "args": ["-y", "mcp-routine"],
      "env": {
        "FILENAME": "/path/to/your/mcp-routines.json"
      }
    }
  }
}

How to use it?

  1. Perform your task by prompting AI to execute tools.

  2. Once the task is completed, instruct AI to create a new routine for your task.

  3. Refresh your MCP client to update the tools. Then use it to execute the same sequence of tools.

The MCP server includes the following tools to manage routines

create-routine
load-routines
update-routine
delete-routine

Examples

Research a topic, then write the result into a new page in a given folder.

**User**: "add an Onboarding page to the Getting started page

**AI**: I'll help you add an "Onboarding" page to the Getting Started page. First, I'll need to find the Getting Started page ID.

Let me search for it:
Great, I found the Getting Started page. Now I'll create a new "Onboarding" page under it:

I've successfully created a new page titled "Onboarding" under the Getting Started page. The page has been created with a basic title, and you can now access it at the URL provided in the response. Would you like me to add any specific content to this new Onboarding page?

**User**:Yes, add some placeholder information for a standard onboarding experience

**AI**: I'll add some structured placeholder content to the Onboarding page to outline a standard onboarding experience.

**User**: now convert all these steps into a route to insert a page into a parent page

**AI**: I'll create a routine that captures the steps we just performed to insert a page into a parent page with structured content. This will make it reusable for future similar tasks.

I've created a routine called insert_structured_page that captures the workflow we used. The routine has three main steps:
1. Search for the parent page using its title to get the page ID
2. Create a new page under the found parent page
3. Add structured content to the new page with sections and bullet points

The routine is parameterized so you can customize:
- parent_page_title: The title of the parent page to search for
- new_page_title: The title for the new page
- welcome_message: Introduction text for the page
- section1_title: Title for the first section (can add more sections as needed)
- bullet_point1, bullet_point2, bullet_point3: Bullet points under sections
- help_message: The help/support message at the bottom

To use this routine, you would just need to provide these parameters with your desired content, and it will create a structured page with consistent formatting.

Development

Build

npm run build

Execute

npx -y --prefix /path/to/local/mcp-routine routine

Publish

npm publish --access public

Available Tools

4 tools
create-routineC

Create a custom routine from recently run actions. Inspect recently run tools

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionYesDescription of the tool, provide as much context as possible so that when user calls the tool again the LLM can follow the instruction to complete the task with different set of inputs
nameYesName of the custom tool to be created
stepsYes

TDQS

C2.8/5.0
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 limited behavioral information. It mentions inspecting recently run tools but doesn't disclose what 'create' entails - whether this persists routines, requires permissions, has rate limits, or returns any confirmation. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.

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 brief but somewhat vague - 'inspect recently run tools' could be more specific. While concise, it's not optimally front-loaded with the most critical information about what creation entails. The two clauses could be better structured for clarity.

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 creation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation, how routines are stored/accessed, or provide enough context about the 'steps' parameter's relationship to 'recently run actions.' The description should do more to compensate for missing structured information.

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 67%, and the description adds no parameter-specific information beyond what's in the schema. The description doesn't explain what 'recently run actions' means in relation to the steps parameter or provide context about parameter relationships. Baseline 3 is appropriate since the schema does most of the documentation 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 tool creates a custom routine from recently run actions, specifying both the verb ('create') and resource ('custom routine'). It distinguishes from siblings by focusing on creation rather than deletion, loading, or updating. However, it doesn't explicitly contrast with siblings in the description text itself.

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 minimal usage guidance - only mentioning 'inspect recently run tools' as a prerequisite. It doesn't specify when to use this versus alternatives like update-routine for modifying existing routines, or provide context about when routine creation is appropriate versus direct tool execution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete-routineA

Delete a routine by name. Always confirm with user that they want to delete it. User may supply a name that's not exactly as how it's stored. Use the load-routines tool to get the list of all routines.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesExact name of the routine to be deleted.

TDQS

A4/5.0
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 mentions the need for user confirmation and potential name mismatches, adding useful context. However, it lacks details on permissions, error handling, or irreversible effects, leaving gaps for a destructive operation.

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 core action ('Delete a routine by name') and efficiently includes essential usage notes in two additional sentences. Each sentence earns its place by providing critical guidance without redundancy or unnecessary elaboration.

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 destructive nature and lack of annotations or output schema, the description is partially complete. It covers purpose and usage well but misses details on behavioral aspects like confirmation mechanisms, error responses, or side effects, which are important for such an operation.

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 the 'name' parameter fully. The description adds marginal value by noting that 'User may supply a name that's not exactly as how it's stored,' but this doesn't provide additional syntax or format details beyond the schema's 'Exact name' description.

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 ('Delete') and resource ('a routine by name'), distinguishing it from sibling tools like create-routine, load-routines, and update-routine. It precisely defines what the tool does without being vague or tautological.

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 provides explicit guidance on when to use this tool: 'Always confirm with user that they want to delete it' and 'Use the load-routines tool to get the list of all routines.' It also addresses an alternative (load-routines) for verification, making usage context clear and comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

load-routinesD

Load routines

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1.8/5.0
Behavior1/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. 'Load routines' gives no insight into what the tool does behaviorally—whether it's a read-only operation, requires authentication, has side effects, or handles errors. It fails to describe any behavioral traits, leaving the agent with no understanding of how the tool behaves beyond its vague name.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly concise to the point of under-specification. 'Load routines' is a two-word phrase that lacks necessary detail for effective tool use. While it avoids verbosity, it fails to provide essential information, making it inefficient rather than appropriately concise. Every word should earn its place, but here the description is too sparse to be useful.

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 lack of annotations and output schema, the description is incomplete for a tool that likely performs a data retrieval operation. It doesn't explain what 'load' entails (e.g., returns a list, fetches details), how results are structured, or any operational context. With no structured fields to compensate, the description fails to provide the necessary completeness for an agent to use the tool effectively.

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% description coverage, meaning no parameters need documentation. The description doesn't add parameter details, which is acceptable given the absence of parameters. Since there are no parameters to explain, the description adequately avoids unnecessary complexity, aligning with the schema's completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Load routines' is a tautology that essentially restates the tool name without adding meaningful context. While it indicates the action ('load') and resource ('routines'), it lacks specificity about what 'load' means in this context (e.g., retrieve, fetch, list) and doesn't distinguish it from sibling tools like 'create-routine' or 'update-routine'. This minimal description provides only basic purpose without clarity on scope or differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/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. There is no mention of prerequisites, context for usage, or comparison with sibling tools such as 'create-routine', 'delete-routine', or 'update-routine'. Without any usage instructions, an agent cannot determine appropriate scenarios for invoking this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update-routineA

Update a routine by name. Factor in the existing schema and update only the portion specified by the user. Always confirm with user that they want to update it. User may supply a name that's not exactly as how it's stored. Use the load-routines tool to get the list of all routines.

ParametersJSON Schema
NameRequiredDescriptionDefault
descriptionYesDescription of the routine.
nameYesExact name of the routine to be updated.
stepsYesSteps of the routine.

TDQS

A3.8/5.0
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 valuable context: it mentions updating only the portion specified by the user (partial updates), confirming with the user before proceeding, and handling inexact name matching. However, it doesn't cover critical aspects like whether this is a destructive operation, what permissions are required, error handling, or what happens to unspecified fields.

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 appropriately sized with four sentences, each adding value: the core purpose, partial update behavior, user confirmation requirement, and prerequisite tool usage. It's front-loaded with the main action. However, the last sentence about name matching could be integrated more smoothly, and some redundancy exists (e.g., 'by name' is implied in the schema).

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 no annotations and no output schema, the description provides moderate context: it covers the update operation, partial updates, user confirmation, and prerequisite steps. However, for a mutation tool with three required parameters, it lacks details on error conditions, side effects, return values, and security implications. The schema handles parameter documentation well, but behavioral aspects are incomplete.

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 three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema—it mentions 'name' and 'portion specified by the user' but doesn't clarify parameter interactions or usage nuances. Baseline 3 is appropriate when 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 verb ('update') and resource ('routine by name'), making the purpose immediately understandable. It distinguishes from siblings by focusing on updating rather than creating, deleting, or loading routines. However, it doesn't explicitly contrast with 'create-routine' beyond the verb difference.

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 provides explicit guidance on when to use this tool vs alternatives: it mentions using 'load-routines' to get the list of all routines first, which implies this tool should be used after identifying the routine to update. It also specifies that the user may supply a name that's not exactly as stored, indicating a prerequisite step of name matching.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

  1. 4 tool updatesv1.0.0
    • First observedcreate-routine
    • First observeddelete-routine
    • First observedload-routines
    • First observedupdate-routine
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: create-routine, delete-routine, load-routines, and update-routine cover the four basic CRUD operations for routines. There is no overlap in functionality, making it easy for an agent to select the correct tool for any given task involving routine management.

Naming Consistency5/5

All tool names follow a consistent verb-noun pattern with hyphen separation (e.g., create-routine, delete-routine). This predictable naming scheme enhances readability and makes the tool set easy to navigate without any deviations or mixed conventions.

Tool Count5/5

With 4 tools, the server is well-scoped for managing routines, covering create, read, update, and delete operations. Each tool earns its place by addressing a core aspect of routine lifecycle management, avoiding both bloat and insufficiency for the domain.

Completeness5/5

The tool set provides complete CRUD coverage for the routine domain: create-routine, load-routines (read), update-routine, and delete-routine. There are no obvious gaps, as all essential operations for managing routines are included, ensuring agents can handle full lifecycle workflows without dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/mquan/mcp-routine'

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