Skip to main content
Glama

Stoory Hire Specialist

Create task

create_task

Invites one or more chosen specialists to a project — does NOT charge payment. budget is a single amount for the whole task (not multiplied per specialist) — whoever accepts it does the work for it. Requires user_confirmed=true, set only after the user has explicitly confirmed in the conversation the choice of specialists, the list of shared files and the estimated cost. Estimate budget yourself from the problem's complexity (e.g. 1h = a single well-localized bug / a simple document fix / a minor graphic tweak; 2h = a standard debug across a few files / a draft legal document (e.g. Privacy Policy) / a landing page design; 3h = an architecture review, a full legal package (ToS+Privacy+GDPR) or a compliance audit, full branding, no clear diagnosis) times the specialist's min_rate_per_hour (from search_specialists) — this field is informational, not enforced, always in USD (the only currency on the marketplace).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
budgetYes
languageYesThe task's language — must match the language the user phrased title/description in (there is no auto-detection, set it according to the user's input).
timelineNoHow urgent the project is from the client's perspective — ask the user directly, do not guess.No rush
descriptionYes
context_filesNoThe minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub), or — if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. For a large binary with no URL and no way to upload it yourself, don't inline it — tell the user to add it to the task repo manually instead. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The GitHub username used to invite the client into the task repo comes from their Stoory account, not from you — you never see or pass it. If create_task fails because it's missing or invalid, tell the user to check/set their GitHub username in their Stoory account settings, then retry create_task.
specialist_idsYesId of one or more specialists to invite.
user_confirmedYesMust be true — set it only after the user's explicit confirmation in the conversation.
problem_contextYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedInput schema / properties / context_files / description
      Previous value: -"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."New value: +"The minimal set of files the specialist needs. Each entry is { name, url?, content_base64? } and must carry exactly one source. `url` is strongly preferred: pass a link if the user gave one (Google Drive / Dropbox / S3 / raw GitHub), or — if you have a way to upload the file yourself (e.g. a code execution / shell environment) — upload it to any URL-reachable location first and pass that link instead of the raw bytes; the server just downloads it, which is fast and costs you almost no extra tokens. Use `content_base64` only as a last resort, when there is no URL and you have no way to produce one yourself (e.g. a small file the user attached directly in a chat-only client with no upload capability of its own) — inlining bytes means writing out the entire file as text, which is slow and burns far more tokens than a URL for anything beyond a tiny file. Before falling back to it, tell the user that creating the task will take noticeably longer and use more tokens because of it. Raw base64 only, never a `data:...;base64,` prefix. This server runs remotely and cannot read the caller's disk, so never pass local paths. For a large binary with no URL and no way to upload it yourself, don't inline it — tell the user to add it to the task repo manually instead. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The GitHub username used to invite the client into the task repo comes from their Stoory account, not from you — you never see or pass it. If create_task fails because it's missing or invalid, tell the user to check/set their GitHub username in their Stoory account settings, then retry create_task."
  2. Changed1 schema field changed
    • changedInput schema / properties / context_files / description
      Previous value: -"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."New value: +"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. A non-empty list always gets a repo, even if every entry ends up in blocked_files (unreadable or filtered) — so the 'add it manually' fallback always has a real repo_url to point to. The user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."
  3. Changed1 schema field changed
    • changedInput schema / properties / context_files / description
      Previous value: -"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."New value: +"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files; raw base64 only, no `data:...;base64,` prefix). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."
  4. Changed10 schema fields changed
    • changedInput schema / properties / context_files / description
      Previous value: -"Minimalny zestaw plików potrzebny specjaliście — tylko ścieżki lokalne, NIE wklejaj treści plików. Serwer sam czyta plik z dysku i wrzuca go do prywatnego repo GitHub utworzonego dla tego taska — treść nigdy nie trafia do kontekstu modelu. Nigdy całe repo, max 1 plik = ~900KB. Przy niepustej liście user musi mieć ustawiony github_username — jeśli create_task to zgłosi, dopytaj usera o jego login GitHub i spróbuj ponownie."New value: +"The minimal set of files the specialist needs. This server runs remotely and cannot read the caller's disk, so do NOT pass local paths. Each entry is { name, url?, content_base64? } and must carry exactly one source: `url` (the server downloads it — prefer this when the user gave a link, e.g. Google Drive / Dropbox / S3 / raw GitHub) or `content_base64` (inline bytes, for small local or chat-uploaded files). For a large binary with no URL (e.g. an image), do not inline it — tell the user to add it to the task repo manually. The server scans every file for secrets and pushes the rest to a private GitHub repo created for this task; contents never enter the model context. Never the whole repo, max 1 file = ~900KB. With a non-empty list the user must have github_username set — if create_task reports it missing, ask the user for their GitHub login and try again."
    • addedInput schema / properties / context_files / items / properties / content_base64
      Added value: +{
      +  "type": "string"
      +}
    • addedInput schema / properties / context_files / items / properties / name
      Added value: +{
      +  "type": "string"
      +}
    • removedInput schema / properties / context_files / items / properties / path
      Removed value: -{
      -  "type": "string"
      -}
    • addedInput schema / properties / context_files / items / properties / url
      Added value: +{
      +  "format": "uri",
      +  "type": "string"
      +}
    • changedInput schema / properties / context_files / items / required
      Previous value: -[
      -  "path"
      -]New value: +[
      +  "name"
      +]
    • changedInput schema / properties / language / description
      Previous value: -"Język taska — musi odpowiadać językowi, w jakim user sformułował title/description (nie ma automatycznego wykrywania, ustaw zgodnie z danymi usera)."New value: +"The task's language — must match the language the user phrased title/description in (there is no auto-detection, set it according to the user's input)."
    • changedInput schema / properties / specialist_ids / description
      Previous value: -"Id jednego lub kilku specjalistów do zaproszenia."New value: +"Id of one or more specialists to invite."
    • changedInput schema / properties / timeline / description
      Previous value: -"Jak pilny jest projekt z perspektywy klienta — pytaj usera wprost, nie zgaduj."New value: +"How urgent the project is from the client's perspective — ask the user directly, do not guess."
    • changedInput schema / properties / user_confirmed / description
      Previous value: -"Musi być true — ustaw wyłącznie po jawnym potwierdzeniu przez usera w rozmowie"New value: +"Must be true — set it only after the user's explicit confirmation in the conversation."
  5. First observed

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries full burden and delivers: it discloses that no payment is charged, that budget is a single whole-task amount not multiplied per specialist and is informational/unenforced, and the context_files parameter description discloses side effects — server scans for secrets, pushes to a private GitHub repo, contents never enter model context, max 1 file ≈900KB, never local paths — plus the failure/retry flow for a missing GitHub username. This far exceeds what annotations would typically provide.

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 main description is a run-on chain of clauses, but every clause earns its place: the budget heuristics and confirmation gate are operationally necessary, and context_files' paragraph prevents costly token-burning and disk-access mistakes. Length is justified density rather than padding, though it could be restructured into clearer sentences.

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?

For a complex mutating tool with no annotations and no output schema, the description covers prerequisites, money semantics, file-handling rules, and a real failure mode (GitHub username — with a retry instruction). The main remaining gap is the unspecified return value and explicit lifecycle placement relative to search_specialists/cancel_task, which are minor against the depth present.

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?

Schema description coverage is 56% — language, timeline, context_files, specialist_ids, and user_confirmed are documented in-schema. The main description compensates for the undocumented budget by adding an estimation methodology, USD currency note, and 'not enforced' semantics; context_files has exceptionally deep guidance (URL vs base64, token costs, size cap, secret scanning). title/description/problem_context stay bare but are self-evident string fields.

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 opening clause states a specific verb+resource ('Invites one or more chosen specialists to a project') that is immediately distinguishable from the sibling family of cancel/get/search tools. It loses the fifth point because it does not explicitly name a sibling it is not, though the family contrast is obvious.

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?

Sets an explicit, enforceable prerequisite — user_confirmed=true only after the user explicitly confirmed specialists, shared files, and estimated cost in the conversation — telling the agent when it is permitted to call this tool. It also references search_specialists for min_rate_per_hour to derive the budget. No explicit when-not-to-use or alternative-naming, but as the sole creation tool in the family the context is sufficient.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

The tools are mostly distinct: search_specialists, create_task, cancel_task, and get_task_repo_files each have clear, separate roles. However, get_task_result and get_task_status overlap somewhat since both report task status, though get_task_result additionally provides the repo link.

Naming Consistency5/5

Tool names follow a consistent verb_noun pattern: create_task, cancel_task, get_task_status, get_task_result, get_task_repo_files, and search_specialists. The one non-get verb, search_specialists, still fits the same predictable convention.

Tool Count5/5

Six tools is well-scoped for the hiring-specialist workflow: searching, creating, canceling, monitoring, retrieving results, and inspecting repo files. Each tool serves a necessary step without unnecessary expansion.

Completeness4/5

The core lifecycle is covered: find a specialist, create a task, cancel if needed, check status, retrieve results, and inspect files. Minor gaps exist such as no explicit task-listing tool or ability to update task details, but these are not obvious dead ends for the stated purpose.