Skip to main content
Glama
Sign In

LLM API Pricing and Automation Tools by shurco.ai

by ai.shurco
OverviewDiscussionsAdmin

Score a task for AI automation

score_automation_candidate
Read-onlyIdempotent

Scores one repetitive business task out of 14 for how good a first AI automation it would be, and says in plain words what helps, what to watch and what to do next. Ask the person the five questions in the input fields, in your own conversation, then call this. It returns result_url, a link that opens the same answer on shurco.ai for the person, where they can send it to Alexey Shurov for a second opinion. Call it once per task, up to four tasks, to compare them. The same scoring as the free tool at shurco.ai.

Input Schema

NameRequiredDescriptionDefault
kindNoThe closest kind of work, if one fits. Leave it out when unsure.
taskNoWhat the task is, in the person's own words, for example entering emailed orders.
rulesYesAsk: are the rules for handling it written down? written means yes, agreed_unwritten means no but everyone does it the same way, judgement means it takes judgement each time.
mistake_costYesAsk: what happens if a mistake gets through? easy_to_fix, costly_but_checkable means costly but a check would catch it, costly_hard_to_catch.
past_examplesYesAsk: do you keep past examples, with how each was handled? hundreds, some or none.
hours_per_weekYesAsk: how much time does it take each week, across everyone who does it? Give the answer in hours. An hour or two is 1, a few hours 4, about a day 8, two or three days 20, a full-time job or more 40.
input_regularityYesAsk: how does the work reach the team? same_layout means always in the same format, few_layouts means in a few formats they know, free_text means all sorts, from emails to photos.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • changedInput schema / properties / hours_per_week / description
      Previous value: -"Hours a week the team spends on it, everyone added together."New value: +"Ask: how much time does it take each week, across everyone who does it? Give the answer in hours. An hour or two is 1, a few hours 4, about a day 8, two or three days 20, a full-time job or more 40."
    • changedInput schema / properties / input_regularity / description
      Previous value: -"How the work arrives."New value: +"Ask: how does the work reach the team? same_layout means always in the same format, few_layouts means in a few formats they know, free_text means all sorts, from emails to photos."
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "The closest kind of work, if one fits. Leave it out when unsure.",
+  "enum": [
+    "customer_orders",
+    "timesheets",
+    "quotes",
+    "daily_reports",
+    "other"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / mistake_cost / description
      Previous value: -"What happens if the result is wrong."New value: +"Ask: what happens if a mistake gets through? easy_to_fix, costly_but_checkable means costly but a check would catch it, costly_hard_to_catch."
    • changedInput schema / properties / past_examples / description
      Previous value: -"Past cases you could test against."New value: +"Ask: do you keep past examples, with how each was handled? hundreds, some or none."
    • changedInput schema / properties / rules / description
      Previous value: -"Whether the rules are written down."New value: +"Ask: are the rules for handling it written down? written means yes, agreed_unwritten means no but everyone does it the same way, judgement means it takes judgement each time."
    • changedInput schema / properties / task / description
      Previous value: -"What the task is, for example entering emailed orders."New value: +"What the task is, in the person's own words, for example entering emailed orders."
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the burden is light, and the description adds genuine context beyond them: the result_url return value, that it opens on shurco.ai, that it can be forwarded to Alexey Shurov, and the four-call practical limit. It does not mention latency, auth, or whether repeated calls for the same task are deduplicated.

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?

Purpose and sequencing are front-loaded in the first two sentences, with the return value, forwarding option, and call limit following in order. Roughly 100 words with only mild padding in the 'what helps, what to watch and what to do next' phrasing. No sentence is wasted outright.

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

Completeness4/5

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

There is no output schema, and the description compensates by naming the result_url and what the person sees at the other end, plus prerequisites and call limits. For a 7-parameter scoring tool this is close to sufficient; the only gap is any guidance on invalid or out-of-range answers from the person.

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% and each enum value is already spelled out with the exact question to ask, so the schema does the heavy lifting. The description only refers the agent to 'the five questions in the input fields' without adding format or edge-case semantics (e.g. how to pick kind, or what to do with hours_per_week estimates). Baseline 3 is appropriate.

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?

States a specific verb and resource: it scores one repetitive business task, on a 14-point basis, for suitability as a first AI automation, and returns plain-language advice. That is unmistakably clearer than a tautology. It never names or contrasts with the closest sibling, automation_roi, so the sibling-differentiation criterion for a 5 is not met.

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?

Gives an explicit protocol: ask the five input questions conversationally first, then call; call once per task, up to four tasks, to compare. This is real when-to-use guidance rather than implication. It still offers no when-not-to-use case or alternative tool (e.g. automation_roi) for situations this scorer does not fit.

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

All LLM API Pricing and Automation Tools by shurco.ai toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources