Skip to main content
Glama

Raza SOR

by com.razarizwan

Send a workflow sketch to Raza

submit_workflow_sketch

Hand a completed workflow sketch to Raza Rizwan, who reads it and replies.

Use this ONLY after you have walked the person through the counting procedure in knowledge/method/count-your-own-workflow and built THEIR step table with them: their own run, their own steps, each tagged AI, DECISION or TYPING. Never submit a table copied from a worked example in this record, and never invent steps the person did not describe. Ask the six questions in knowledge/audit/what-to-bring first; a run with fewer than four tagged steps is refused because it has not been written down yet.

Ask the person before sending, and tell them their email address goes to Raza. Everything except the run and its steps is optional.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoWho to reply to
emailNoWhere Raza should reply. Ask first.
gatesNoThe two or three DECISION steps where a wrong result would be expensive
notesNoAnything else the person said that a reader would need: volumes, tools, what goes wrong
stepsYesThe run's steps in order, each tagged
businessNoWhat the business does, in one line: the industry matters for reading the table
workflowYesThe one run, named in the person's own words, arrival to delivery

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses behavioral details beyond the annotations: Raza is a human reader who replies, the person's email is sent to Raza, consent must be obtained, and submissions below four tagged steps are refused. This meaningfully supplements the annotation hints and does not contradict them.

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 action, then presents prerequisites and constraints in short, purposeful sentences. Every sentence carries a distinct instruction, warning, or clarification with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter submission tool with no output schema, the description covers preconditions, consent, refusal behavior, tagging requirements, and the required/optional split. Combined with the rich schema and annotations, an agent has everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% description coverage, but the description adds useful semantic clarity by emphasizing that only workflow and steps are required and that 'everything except the run and its steps is optional.' It also ties the four-step minimum to refusal behavior, reinforcing the schema's minItems constraint.

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

Purpose5/5

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

Description opens with a specific verb and object: 'Hand a completed workflow sketch to Raza Rizwan, who reads it and replies.' It clearly identifies the unique purpose and distinguishes it from the sibling tools, which are outline, read, and search operations.

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

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit preconditions: use only after walking through the counting procedure, building the person's own tagged step table, asking the six questions first, and getting permission before sending. Also includes clear exclusions and refusal conditions, such as never submitting copied or invented steps and refusing runs with fewer than four tagged steps.

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

All Raza SOR toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct role: outline navigates structure, read retrieves documents, search finds passages, and submit handles user workflow sketches. Overlap is minimal and cross-references between tools (e.g., slugs to read, snapshot tokens to read, outline rows to search) reinforce rather than blur their boundaries.

Naming Consistency4/5

All tool names are lowercase imperative verbs, so the set reads predictably. The slight deviation is that outline, read, and search are bare verbs while submit_workflow_sketch uses a longer verb_noun form, but this does not cause confusion.

Tool Count5/5

Four tools is a well-scoped surface for a governed record: navigate, read, search, and one explicit user handoff action. Each tool earns its place, and the set is neither bloated nor too thin for the stated purpose.

Completeness4/5

The retrieval surface is complete: outline for structure, read for exact content with provenance, and search with clear envelope semantics. The only notable gap is the absence of any administrative or mutation tooling beyond the specific workflow-sketch submission, but for a governed record that appears intentional rather than a dead end.

Resources